Thanks Trustin - I'll try your suggestion and post some code if I don't
have any joy.
Trustin Lee wrote:
On 7/4/07, Chris Chalmers <[EMAIL PROTECTED]> wrote:
Hi all
Checking 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
