Might be related to http://issues.apache.org/jira/browse/DIRMINA-561
Also read
http://java.sun.com/j2se/1.5.0/docs/api/java/net/ServerSocket.html#setReceiveBufferSize(int)
:
"It is possible to change the value subsequently, by calling
|Socket.setReceiveBufferSize(int)|
<http://java.sun.com/j2se/1.5.0/docs/api/java/net/Socket.html#setReceiveBufferSize%28int%29>.
However, if the application wishes to allow a receive window larger than
64K bytes, as defined by RFC1323 then the proposed value must be set in
the ServerSocket *before* it is bound to a local address. This implies,
that the ServerSocket must be created with the no-argument constructor,
then setReceiveBufferSize() must be called and lastly the ServerSocket
is bound to an address by calling bind(). "
Zvika Gart wrote:
And here are the logs
On Thu, Nov 26, 2009 at 7:19 PM, Zvika Gart <[email protected]> wrote:
Attached are the strace logs with the trace=network for the MINA
implementation and the simple NIO implementation. both ran for about 30
seconds.
As you can see the MINA implementation makes lots of getsockopt system
calls to get the receive buffer size (for each receive?).
In this link http://79.125.32.246/capture.tbz you can find tcp dumps of
the two implementations.
ACK patterns are affected by the capabilities of the receiving application
- how fast it reads data from the socket. You can see that the window size
in the MINA implementation doesn't grow and is stuck at about 64KB while in
the simple NIO it gets to 2MB. This is probably because the MINA
implementation is slow at reading from the socket.
If you need more logs or want me to run further tests please let me know.
On Thu, Nov 26, 2009 at 4:04 AM, Tuure Laurinolli <
[email protected]> wrote:
Zvika Gart wrote:
- Check if there are some differences in the traffic (e.g. TCP ACK
patterns)
You didn't say anything about this yet.
- Check syscall patterns of the MINA version and try to see if something
is
taking unreasonably long time (pure NIO implementation might be helpful
here)
- As for syscall patterns, I'll need your help as I am a .NET programmer
and
not familiar with Java/Linux profiling...
Have you ever done anything with the Sysinternals file monitoring tools?
Strace is similar tool for Linux, except its output is textual. You should
find and read some tutorial about it to get some idea of how to use it.
For an actual test run, something along the lines of "strace
-o/tmp/traceout -f -s2048 -tt -e trace=network java -jar myserver.jar"
should output all network-related syscalls that your process performs to
/tmp/traceout. You'll have to the comparing yourself, though.
I'd expect there to be epoll() calls in MINA case, and if there is
something to read, recv() calls to read it. The threaded blocking version
should probably just sit blocking in recv(). I'd try to minimize other thing
going on in the same process for the test, since there will probably be
enough noise in any case.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
