JMS奇怪的问题

发布于 11-25 13:34 字数 763 浏览 2 评论 0原文

我在一个系统中遇到问题,其中约 500 个服务器通过约 1000 个主题的 JMS 与中央服务器进行通信。这是一个已有 10 年历史的系统,直到几个月前还运行良好。

在过去 3 个月中,我遇到了以下类型的错误:

  • 中央服务器无法反序列化 Integer,因为消息中的 Integer 具有错误的 SerialVersionID

    <块引用>

    反序列化消息失败。 - 原因:java.io.InvalidClassException:java.lang.Integer;本地类不兼容:流classdesc serialVersionUID = 1360651450463909473,本地类serialVersionUID = 1360826667806852920

  • 中央服务器无法反序列化未知类

    <块引用>

    反序列化消息失败。 - 原因:java.lang.ClassNotFoundException:找不到类加载器:javnteger.Integer

  • JMS 尝试实例化抽象的 Number 类

    <块引用>

    捕获 JVM 错误:java.lang.InstantiationError:java.lang.Number

对于所有错误,问题都集中在一个随机主题中。如果该主题的消息被删除并从服务器再次发送,则一切正常。

我怀疑 JMS 硬件。硬盘没问题。我们需要测试记忆力,但我不知道下一步该看哪里。

有人有什么建议吗?

I have a problem in a system where ~500 servers are communicating with central server through JMS over ~1000 topics. It's a 10 year old system and it worked good until few months ago.

In the last 3 months I had these types of errors:

  • central server can't deserialize Integer because Integer in the message has wrong SerialVersionID

    Deserialize message failed. - cause: java.io.InvalidClassException: java.lang.Integer; local class incompatible: stream classdesc serialVersionUID = 1360651450463909473, local class serialVersionUID = 1360826667806852920

  • central server can't deserialize unknown class

    Deserialize message failed. - cause: java.lang.ClassNotFoundException: No ClassLoaders found for: javnteger.Integer

  • JMS tries to instantiate Number class which is abstract

    Caught JVM Error: java.lang.InstantiationError: java.lang.Number

For all errors problem is localized in one random topic. If messages from that topic are deleted and sent again from servers everything went ok.

I'm suspecting JMS hardware. HDD is ok. We need to test memory and I don't know where to look next.

Anyone has any suggestion?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

千鲤2024-12-02 13:34:03

这不是 JVM 问题。至少追溯到 JDK 1.2(如果你相信随 JDK 一起发布的 java.lang.Integer 源代码中的注释,实际上可以追溯到 1.0.2),Integer 的serialVersionUID 已经是“1360826667806852920L”,它与你的“本地类”版本相匹配。为了保持向后兼容性,他们从未更改过它。这一事实与“ClassNotFoundException:javnteger.Integer”(应该是java.lang.Integer)相结合,明确指出了数据损坏。发送者、接收者或网络本身正在破坏消息。坏内存似乎是一个可能的罪魁祸首,特别是如果它只是间歇性且很少发生的话。如果是网络,这种情况可能会发生得更频繁,而且更难以预测。

It's not a JVM issue. Back at least as far as JDK 1.2 (actually back to 1.0.2 if you believe the comment in the java.lang.Integer source distributed with the JDK), Integer's serialVersionUID has been "1360826667806852920L", which matches your "local class" version. They've never changed it in order to preserve backward compatibility. That fact combined with the "ClassNotFoundException: javnteger.Integer" (should be java.lang.Integer) points unmistakably to data corruption. Either a sender, a receiver, or the network itself is corrupting messages. Bad RAM would seem a likely culprit, especially if it's only intermittent and seldom. If it were the network, it would probably happen more often and be less predictable.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文