[jbosscache-dev] RE: [javagroups-users] Possible speedup of void RPC response

[Manik Surtani]

Sounds like a need for a dedicated RPC layer.  :-)

I think being able to register a marshaller for return values is  
certainly a good thing though -  I can think of 2 places where this  
can currently be a problem in JBC (although I haven't seen anyone  
speak of them yet): clustered cache loaders and data gravitation,  
both of which expect return values from RPC calls.

Cheers,
--
Manik Surtani

Lead, JBoss Cache
JBoss, a division of Red Hat

Email: manik at jboss.org
Telephone: +44 7786 702 706
MSN: manik at surtani.org
Yahoo/AIM/Skype: maniksurtani


On 29 Aug 2006, at 16:09, Brian Stansberry wrote:

> (Moving to this list a thread related to a new 2.4 feature for using a
> JGroups Marshaller for marshalling RPC responses as well as requests.)
>
> Bela Ban wrote:
>> Brian Stansberry wrote:
>>> I haven't had a chance to do the CPU profile, but did run the AS
>>> testsuite.
>>>
>>> Using the registered Marshaller for return marshalling leads to all
>>> sorts of problems; the specialized marshallers in JBoss Cache  
>>> weren't
>>> designed to marshal responses, so all hell breaks loose. A ton of
>>> session replication test cases fail.
>>
>> What do you mean by "were not designed" ?  Is there a chance
>> we can make it work rather than introducing the kludge below ?
>>
>
> The JBC marshallers were written assuming all they had to do was
> marshal/unmarshal a MethodCall, which is all that was required  
> before. I
> haven't looked in detail, but wouldn't be surprised if there are casts
> to MethodCall.  Beyond just failing, if region-based marshalling is in
> effect, using it for responses would be very inefficient.  If
> region-based marshalling is in effect, the marshaller writes the Fqn
> string at the start of the stream so it can be parsed out by the
> unmarshaller and used to check if the region is active and if the call
> should be made. If the call isn't region-specific (e.g. a call used  
> for
> buddy group formation), "NULL" is written.  So, if we used the current
> marshaller for a response, the string "NULL" would be written for  
> every
> void response.
>
> These things can be fixed going forward, but the kludge was needed to
> make 2.4 usable with existing releases of JBoss Cache.
>
>> Besides, don't you have classloader problems when JGroups
>> (rather than the Marshaller) unmarshalls values ? Because, by  
>> default,
>> Util.objectFromByteBuffer() simply uses the system classloader !
>>
>
> The only objects ever included in a response are JBC exceptions.  This
> *would* be a problem if JBC were loaded by a different classloader  
> than
> JGroups.  I've never heard any complaint about this, so I guess people
> don't configure it that way (JBoss AS certainly doesn't.)
>
>>> How about adding a property
>>> RpcDispatcher.setResponseMarshaller(Marshaller m)? If set, the
>>> Marshaller gets passed through to RequestCorrelator. If not, the old
>>> behavior remains, which is backward compatible.
>>>
>>> I've attached a patch that does that. With this in place, the
>>> failing tests all pass again.
>>>
>>> Having the ability to marshal responses would definitely be a good
>>> thing for the JBoss HAPartition. For JBC, your optimized Util method
>>> should be fine, as all that's ever returned is null or an exception
>>
>> Okay, I'll apply this patch, but could you please create a
>> JIRA issue to look into using the same Marshaller that's used
>> for incoming requests ?
>
> Thanks. JIRAs are http://jira.jboss.com/jira/browse/JBCACHE-752 and
> http://jira.jboss.com/jira/browse/JBAS-3583 .
>
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev