On 7/4/07, Chris Chalmers <[EMAIL PROTECTED]> wrote:
Hi allChecking this again, it seems that an OOM is being thrown after all. The IoFilter throttling doesn't seem to kick in until too late, unfortunately. Looking at the SocketIoProcessor class, if I apply the throttle before the read call, this achieves the desired effect for me: (ie: limits memory usage significantly): private void process( Set<SelectionKey> selectedKeys ) { ... if (!throttle(session)) { read( session ); } ... } Unfortunately this solution is not clean as I am forced to modify the Mina source code and not use the API. Any better ideas anyone? Chris Chalmers wrote: > Hi Peter > > I'm now getting something strange: > - my read is throttling fine based on the number of outstanding writes > on a linked session > - the session.resumeRead() method is being called when the linked > writes have dropped > - however, the read is not resumed. > > I have limited memory usage to 64Mb, and at the point of session > resumption, 63.8Mb has been read in. > When using 256Mb, the process completes; at the point of resume, it > seems like the allocated memory doubles - I am hazarding a guess that > this could be causing the problem when using 64Mb. However, I don't > get an out-of-memory exception. > > Any ideas?
Did you try to add ReadThrottleFilter and WriteBufferLimitFilter *before* ExecutorFilter? I'm not sure this will work, but placing the filters before the ExecutorFilter will make the traffic control more immediate. It would be the best if you can provide us some test code that reproduces the problem, because it is the easiest way to fix our side. HTH, Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
