[jboss-jira] [JBoss JIRA] Commented: (JGRP-284) Optimize marshalling of return values

[Bela Ban (JIRA)]

    [ http://jira.jboss.com/jira/browse/JGRP-284?page=comments#action_12342020 ] 
            
Bela Ban commented on JGRP-284:
-------------------------------

First part is donw - we now use the Marshaller (when set). This required moving unmarshalling of the return value from GroupRequest (where it didn't really belong) to RequestCorrelator

> Optimize marshalling of return values
> -------------------------------------
>
>                 Key: JGRP-284
>                 URL: http://jira.jboss.com/jira/browse/JGRP-284
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.4
>
>
> I was doing some CPU profiling of JBoss HttpSession replication and
> noticed that GroupRequest.receiveResponse() took ~ 5% of the total CPU
> time. Thought that was a bit odd, given that all the RPC calls in JBoss
> Cache are to void methods. 
> Had a look at Util.objectTo/FromByteBuffer, and if the response is null,
> an ObjectOutputStream gets created, and then
> ObjectOutputStream.writeObject(null) gets called.  That method does a
> fair amount of stuff before ultimately writing a byte to the stream.  On
> the other side, an ObjectInputStream is created and readObject() also
> jumps through quite a few hoops just to read that byte and return null.
> Since in HEAD you're now writing an initial byte to the stream to signal
> Streamable or not, perhaps having a 3rd value to signal null would make
> sense.  Lets you skip the whole initiation of the
> ObjectInput/OutputStream as well as the overhead I described.
> Brian Stansberry

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira