mina-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tuure Laurinolli <tuure.laurino...@indagon.com>
Subject Re: byte[] usage - not GCd
Date Sun, 27 Jul 2008 02:47:58 GMT
Gerrit Grobbelaar wrote:
> YourKit shows the Class list as follows:
> - java.nio.HeapByteBuffer
>  - org.apache.mina.common.SimpleByteBufferAllocator$SimpleByteBuffer
>   - org.apache.mina.filter.codec.ProtocolCodecFilter$HiddenByteBuffer
>    - org.apache.mina.common.IoFilter$WriteRequest
>     - java.util.concurrent.ConcurrentLinkedQueue$Node

Is this the reference chain that keeps the byte[]s alive? Also, should 
it be interpreted so that there are ConcurrentLinkedQueue$Nodes that are 
alive (presumably because they are in a queue which is alive) that have 
references to WriteRequests that have references to HiddenByteBuffers 
that through some other objects refer to the actual byte[]s?

If this is the case, it would seem that write requests never get garbage 
collected for some reason. In a later message you mention that you get 
WriteTimeoutExceptions on MINA 2. Given these two clues I would think 
that your writes are not completing in timely manner. Are you sure that 
there is no source of congestion between the simulated clients and the 

Do note that if you are using TCP (and since you are talking about 
connections in the first place, you most likely are), the receiving end 
directly affects the sending end's ability to send data. I understand 
from your later messages that you have some custom network code deployed 
on the clients that are supposed to be receiving data. Can you ensure 
that the client is not possible cause of congestion (is it doing 
something other than blocking in a read(), recv() or select() call when 
waiting for data?).

A server-side remedy might be to reduce the write timeout, and to limit 
the maximum amount of data buffered for writing per connection. The 
former is done via IoSessionConfig in MINA 2 at least, but I think you 
have to actively check for the latter in your protocol code. There has 
been some discussion about it earlier on this mailing list, or the -dev 

View raw message