1) The default behaviour is only to copy the data in the case where previously it didn't have enough data to do a decode. In my tests > 90% of the time it was not copying but using the allocated received buffer.
2) This is what happens? Looking at the code:
ByteBuffer buf = ( ByteBuffer ) session.getAttribute( BUFFER );
// if we have a session buffer, append data to that otherwise
// use the buffer read from the network directly
if( buf != null )
{
buf.put( in );
buf.flip();
}
else
{
buf = in;
}
RG
| Michael Bauroth <[EMAIL PROTECTED]>
02/05/2006 14:01
|
To: [email protected] cc: Subject: Re: JRockit and other stuff |
Hi,
I've two questions regarding the CumulativeProtocolDecoder:
1) every time the buffer goes empty it will be removed and for the next
call new created. Especially for direct buffers this is a major
performance bottleneck. Isn't it? But when I'm keeping it (overriding
removeSessionBuffer), how can I reduce it's size instead?
2) the decode method first copies all data into the session buffer,
before it starts to decode the message in doDecode. Here is a lot of
time overhead for the copy process itself. Wouldn't it be better to try
if the incoming data can be decoded directly without the copy process?
WDYT
Regards
Michael
This communication is for informational purposes only. It is not intended
as an offer or solicitation for the purchase or sale of any financial
instrument or as an official confirmation of any transaction. All market prices,
data and other information are not warranted as to completeness or accuracy and
are subject to change without notice. Any comments or statements made herein
do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries
and affiliates.
