On 27 July 2008 04:47, Tuure Laurinolli wrote: > 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?).
I realized that my clients are not even reading the data from the socket input stream, thus congesting the byte[] in the server VM that is trying to write to these clients. This is implemented in the _run_ method for each of the clients (implementing java.lang.Runnable), but the _start_ method was not invoked on any of them. This bug on my side was due to the fact that this code worked 100% before, but was refactored a few times in the meantime, and obviously getting rid of this socket inputstream handling (starting of the threads) in the process. However, no excuse and sincere apologies for this. I'm glad I found it because as I said earlier: On 26 July 2008 14:14, Gerrit Grobbelaar wrote: > > > > I still believe I'm doing something wrong in my code though, as I > > > > read only good things about MINA in the reviews, Back to some stats: Simulated clients: 150 (each 1 msg every 3 seconds) JVM uptime: 1h30mins Total heap mem: 16MB byte[] heap mem: 1.1MB This is GREAT seeing that before with the above criteria byte[] allocations caused the VM to crash (OOM) within 2 minutes. Thanks, Gerrit > -----Original Message----- > From: Tuure Laurinolli <[EMAIL PROTECTED]> > Sent: Sunday 27 July 2008 04:47 > To: [email protected] > CC: > Subject: Re: byte[] usage - not GCd > > > 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.
