[jboss-jira] [JBoss JIRA] Closed: (JBREM-623) need reset() call added back to JavaSerializationManager.sendObject() method
[ http://jira.jboss.com/jira/browse/JBREM-623?page=all ]
Ron Sigal closed JBREM-623.
---------------------------
Resolution: Done
Originally JavaSerializationManager.sendObject() called reset() then sent an extra object
(Boolean.TRUE) so that the TC_RESET byte emitted by reset() would be consumed in the
course of reading the Boolean.TRUE. However, this extra data caused a problem after
versioning was instituted because a version byte is now written before an invocation
request/response, and the TC_RESET byte was being interpreted as a version byte.
The solution was to reorganize sendObject() so that it calls reset() before sending the
data object, so that the TC_RESET is consumed before the data object. A drawback is that
the objects cached during one transmission are not deleted until the next transmission,
but at least the cached objects do not build up indefinitely.
It looked like this issue was done, but the tests
org.jboss.tests.remoting.transport.connection.SocketConnectionTestCase and
org.jboss.test.remoting.transport.connection.SocketConnectionCheckTestCase started running
very slowly in linux. It's not clear what fixed the problem, but the recent changes
made for JBREM-692 may be related. In any case, these tests now pass in both windows and
linux.
The changes have been made to remoting_2_x and HEAD.
need reset() call added back to JavaSerializationManager.sendObject()
method
----------------------------------------------------------------------------
Key: JBREM-623
URL: http://jira.jboss.com/jira/browse/JBREM-623
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: transport
Affects Versions: 2.2.0.Alpha3 (Bluto)
Reporter: Tom Elrod
Assigned To: Ron Sigal
Priority: Critical
Fix For: 2.2.0.Beta1 (Bluto)
Per JBREM-597, code was changed within JavaSerializationManager.sendObject() to not call
reset() on the ObjectOutputStream as would cause an error (see below). Although this
solution works, it is not optimal as need the reset() to be called to release the
references kept internally to the object stream (otherwise could potentially run out of
memory if are sending a lot of different object types).
Error when reset() method is called:
java.rmi.MarshalException: Failed to communicate. Problem during
marshalling/unmarshalling; nested exception is:
java.io.IOException: Can not read data for version 121. Supported versions: 1, 2
at
org.jboss.remoting.transport.socket.SocketClientInvoker.handleException(SocketClientInvoker.java:122)
at
org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:408)
at
org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:125)
at org.jboss.remoting.Client.invoke(Client.java:605)
at org.jboss.remoting.Client.invoke(Client.java:597)
at org.jboss.remoting.Client.invoke(Client.java:582)
at
org.jboss.test.remoting.transport.socket.connection.SocketTestClient.testInvocations(SocketTestClient.java:74)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at com.intellij.rt.execution.junit2.JUnitStarter.main(JUnitStarter.java:32)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:90)
Caused by: java.io.IOException: Can not read data for version 121. Supported versions:
1, 2
at
org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:503)
at
org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:370)
... 28 more
Test case: org.jboss.test.remoting.transport.socket.connection.SocketConnectionTestCase
& org.jboss.test.remoting.transport.socket.connection.SocketConnectionCheckTestCase
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira