Re: [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 . _______________________________________________ jbosscache-dev mailing list jbosscache-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosscache-dev