Bug 1032312 - [GSS] (6.2.x) Protocol incompatibility between serializable classes with different non-serializable superclasses
[GSS] (6.2.x) Protocol incompatibility between serializable classes with diff...
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: Remoting (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: CR1
: EAP 6.2.1
Assigned To: David M. Lloyd
Jitka Kozana
Russell Dickenson
Depends On: 1052204
Blocks: eap62-cp01-blockers 1032313
  Show dependency treegraph
Reported: 2013-11-19 19:22 EST by Brad Maxwell
Modified: 2014-02-24 15:14 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
It was found that in previous versions of JBoss EAP 6, the marshalling layer was introducing superfluous data pertaining to non-serializable classes into the serialization stream. This was causing a range of undesirable behaviors ranging from reduced performance to ClassNotFoundExceptions and other errors between different JVMs. This release of the product sees the extra data truncated as it should be. The protocol is now more performant and is again compatible between JVMs that have different class hierarchies for the same class.
Story Points: ---
Clone Of:
: 1052204 1052208 (view as bug list)
Last Closed: 2014-02-24 15:14:53 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
JBoss Issue Tracker JBMAR-156 Major Resolved Protocol incompatibility between serializable classes with different non-serializable superclasses 2017-02-08 15:36 EST

  None (edit)
Description Brad Maxwell 2013-11-19 19:22:11 EST
Protocol versions up to 3 of the River marshalling protocol erroneously serialize a class descriptor for the first non-serializable superclass of a serializable class.

This manifests itself particularly when an IBM JVM and a Sun JVM communicate by serializing a StringBuilder or StringBuffer class. The Sun JDK contains a shared superclass called AbstractStringBuilder which is not present in IBM's version.

In version 4 the stream should be marked with a NULL when the first non-serializable class is hit.  For version 3 though we can just mark it with java.lang.Object because that is also a single byte and should work as well (in 1.4 at least, this class is only used to detect the end of the chain; it is not used to make decisions about what constructor to invoke).  Only the sender needs to change; the receiver should continue functioning.
Comment 1 Brad Maxwell 2013-11-19 19:24:47 EST
Fixed in JBoss Marshalling 1.4.3
Comment 2 Scott Mumford 2014-01-20 00:56:01 EST
Marking for inclusion in 6.2.1 release notes documentation.
Comment 3 Scott Mumford 2014-01-22 21:33:33 EST
Requesting information (possibly even a draft release note) as I am having some difficulty parsing the details of this issue and it's resolution.

Brad, any assistance you can offer would be good. I'm lost somewhere in the series of serializable and non-serializable classes.
Comment 4 Scott Mumford 2014-01-23 19:10:36 EST
Thanks for the awesome content David. That was exactly what I needed! I've reformatted the note for publication and marked it for inclusion in the Release Notes document.
Comment 5 Ladislav Thon 2014-01-27 09:39:20 EST
Verified with EAP 6.2.1.CP.CR1.

Note You need to log in before you can comment on or make changes to this bug.