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

[Bela Ban]

Okay. So for the future, an implementation similar to what 
Util.object{To,From}ByteBuffer() does might be an improvement.
I've applied some of your patch (didn't change RequestCorrelator), 
please check it out and test your unit tests.

I'll release a CR2 as soon as I have a first implementation of MergeView 
handling for the Multiplexer. Note that I fixed a bunch of bugs in the 
Multiplexer, so it's probably a good idea to cut a CR2 and let the code 
sit there and be tested for another week before we release 2.4 final.

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
>
>   

-- 
Bela Ban
Lead JGroups / Manager JBoss Clustering Group
JBoss - a division of Red Hat