incubator-yoko-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mosur Ravi, Balaji" <br...@iona.com>
Subject RE: I think I found my RMI problem....now how do I fix it?
Date Fri, 08 Dec 2006 14:28:57 GMT
Also, please add test cases as you fix the issues... Currently, the RMI
area lacks tests...

- Balaji

-----Original Message-----
From: Dain Sundstrom [mailto:dain@iq80.com] 
Sent: Thursday, December 07, 2006 5:52 PM
To: yoko-dev@incubator.apache.org
Subject: Re: I think I found my RMI problem....now how do I fix it?

Don't forget to add copious comments to the code so someone else  
doesn't have to repeat this painful process :)

-dain

On Dec 7, 2006, at 1:14 PM, Rick McGuire wrote:

> Ok, think I've got it really solved now (at least for one test  
> case).  My reasoning below was correct, but there was another  
> underlying root cause.  Serialization of the Stub class was broken  
> for a couple of reasons.  First of all, I inadvertently added the  
> readObject()/writeObject() methods with public rather than private  
> access.  Apparantly, serialization will only call them if they're  
> private.  Secondly, The Stub() class was relying on the constructor  
> to set up the default delegate.  For classes that implement  
> readObject(), writeObject(), the no argument constructor is NOT  
> called, which was something I'd noticed in my debugging that  
> puzzled me at the time.
> Rick
>
>
> Rick McGuire wrote:
>> Ok, after about 7-8 days of debugging, I've finally figured out  
>> what's going on with my RMI problem, but I don't know how to fix  
>> it.  The root of the problem is whenever a remote object (i.e., a  
>> stub) is gets serialized and then deserialized, the object is  
>> unusable  because it doesn't have a delegate set (via _set_delegate 
>> ()).  During serialization, the code in  
>> RMIStubHandler.stubWriteReplace() replaces the serialized Stub  
>> with an instance of RMIPersistentStub.  RMIPersistentStub does a  
>> _set_delegate(stub._get_delegate()) to initialize with the same  
>> delegate value.
>> During deserialization, RMIPersistentStub calls
>>
>>                result = javax.rmi.PortableRemoteObject.narrow 
>> (this, type);
>>
>> to activate the object.  But this fails because the stub  
>> _get_delegate() throws an exception because no delegate has been  
>> set.  After much digging, and head scratching, I finally figured  
>> out why the delegate is null.  The delegate field in the  
>> ObjectImpl superclass is transient!  So when this object is  
>> serialized and then deserialized, the connection to the original  
>> object is lost.  I've checked against the Sun implementation, and  
>> it appears that field is marked transient there too.  So, I'm  
>> guessing RMIPersistentStub needs to pass the delegate information  
>> via some other means that will survive the serialization process.   
>> Does anybody have any suggestions on what the appropriate fix  
>> would be?
>>
>> Rick
>>


Mime
View raw message