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
server?
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
list.
