Hi Swen,
On 1/4/07, Swen Moczarski <[EMAIL PROTECTED]> wrote:
Hi, I have done some performance tests. A client is sending a lot of small
messages over a connection to a server. In
spite of the read-throttle-filter (
org.apache.mina.filter.ReadThrottleFilterBuilder) the server will be
overloaded and I
get out-of-memory exceptions.
Before the message will be forwarded to the ExecutionFilter, the
ReadThrottleFilter makes use of ByteBuffer.remaining()
for increasing the calculated size of the connection buffer. But after
passing the ExecutionFilter the method
ByteBuffer.capacity() is used to decrease the size. Is that behaviour
intended?
When I'm patching the ReadThrottleFilterBuilder to use ByteBuffer.capacity()
for both cases the performance test works
absolutely fine, there are no longer out-of-memory exceptions. BTW, in the
SVN-history I have seen that the first
version uses ByteBuffer.capacity() for both cases.
It seems like there was a mistake. Could you try to change both capacity()
calls to remaining()? I think it's a correct fix than using capacity().
I have a second question: Is it correct that for a SocketAcceptor the
ReadThrottleFilter have to add in the session
created method like this:
public void sessionCreated(IoSession session) throws Exception {
ReadThrottleFilterBuilder builder = new ReadThrottleFilterBuilder();
builder.attach(session.getFilterChain());
}
This is the first time where the ExecutionFilter is available in the
filter chain.
Yes, looks fine to me.
HTH,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP key fingerprints:
* E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E
* B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
