Bug 1032312

Summary:	[GSS] (6.2.x) Protocol incompatibility between serializable classes with different non-serializable superclasses
Product:	[JBoss] JBoss Enterprise Application Platform 6	Reporter:	Brad Maxwell <bmaxwell>
Component:	Remoting	Assignee:	David M. Lloyd <david.lloyd>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Jitka Kozana <jkudrnac>
Severity:	unspecified	Docs Contact:	Russell Dickenson <rdickens>
Priority:	unspecified
Version:	6.2.0	CC:	bmaxwell, lthon, myarboro, smumford
Target Milestone:	CR1
Target Release:	EAP 6.2.1
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
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:
Clones:	1052204 1052208 (view as bug list)		Environment:
Last Closed:	2014-02-24 20:14:53 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1052204
Bug Blocks:	1027004, 1032313

Description Brad Maxwell 2013-11-20 00:22:11 UTC

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-20 00:24:47 UTC

Fixed in JBoss Marshalling 1.4.3

Comment 2 Scott Mumford 2014-01-20 05:56:01 UTC

Marking for inclusion in 6.2.1 release notes documentation.

Comment 3 Scott Mumford 2014-01-23 02:33:33 UTC

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-24 00:10:36 UTC

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 14:39:20 UTC

Verified with EAP 6.2.1.CP.CR1.