[jbosscache-dev] RE: [javagroups-users] Possible speedup of void RPC response
(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 .