来自 Wicket 模型（在 JRockit/Weblogic 上）的驻留字符串出现字符串不可序列化异常
以下似乎是 JRockit 或 Weblogic 的错误，但也许 此列表中的某人以前见过它并且有更好的 解决方法/解决方案。 我们一直在为政府机构开发 Wicket 应用程序 将由 15,000 个用户使用。该申请将是 部署在 JRockit 和 Red Hat 上运行的 Weblogic 集群上。 我们一直遇到奇怪的“模型对象不可序列化” 来自模型的异常并将其追溯到实习生（由 编译器）字符串对象在命中后变得不可序列化 具有数百个并行用户的服务器。一旦出现异常 对于给定的字符串引用，它会始终一致地出现 参考。 当前的解决方法是自定义模型类，该类具有重写的 setObject 方法检查对象是否是instanceof 可序列化，如果检查失败，则会在 模型。这消除了异常，但想要更好的解决方案 问题。 有人见过这样的东西吗？
The following seems to be a bug with JRockit or Weblogic, but maybe
someone on this list has seen it before and has a better
workaround/solution.
We have been developing a Wicket application for a government agency
that is going to be used by 15k users. The application will be
deployed on a Weblogic cluster running on JRockit and Red Hat.
We have been experiencing strange "Model object not serializable"
exceptions coming from Model and traced it back to interned (by the
compiler) String objects becoming not serializable after hitting the
server with a few hundred parallel users. Once the exception occurs
for a given String reference it keeps coming consistently for that
reference.
The current workaround is a custom Model class that has an overrided
setObject method which checks the object if it's instanceof
Serializable and if the check fails it sets new String(object) on the
Model. This eliminates the exceptions but would like a better solution
to the problem.
Has anyone seen anything like this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我使用jrockit R28.0.1-21-133393-1.6.0_20-20100512-2126-linux-x86_64遇到了同样的问题。在我的应用程序受到一些压力后，检票口模型抱怨字符串不可序列化。我无法使用启用 -Xdebug 标志来复制这种情况，以查看实际传递给 Model.setObject() 方法的内容。看起来我唯一的希望就是切换回sun jvm。
I encountered the same problem using jrockit R28.0.1-21-133393-1.6.0_20-20100512-2126-linux-x86_64. After some stress to my application wicket model complains about strings not being serializable. I'm unable to replicate the situation using -Xdebug flag enabled to see what's actually passed to Model.setObject() method. It looks like my only hope is to switch back to sun jvm.