[
http://jira.jboss.com/jira/browse/JGRP-284?page=comments#action_12342018 ]
Bela Ban commented on JGRP-284:
-------------------------------
I'll look into it. While we're at it, I noticed JBoss clustering is
missing something: we use an external Marshaller (if configured) to
#1 Marshal requests at the caller
#2 Unmarshall requests at the receiver(s)
BUT we don't use the Marshaller implementation to
#3 Marshal return values into byte[] buffers at the receiver(s) and
#4 Unmarshal the return value at the sender
So I'm going to
- use the configured Marshaller to do #3 and #4
- if there is no Marshaller set, I'll use JGroups'
Util.objectTo/FromByteBuffer, which I'll optimize too
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