Houura :-)
The default socket buffer size is changed by mina 2 ?
Le 5 janv. 2013 06:26, Emmanuel Lécharny elecha...@gmail.com a écrit :
Some more results after the modification I suggest at the end of my last
mail (ie, do the write immediately, instead of using a queue, when we can)
:
Mina3
Regarding the message size, I noticed that Mina2 writes only a sub part of
the message (size is computed from the receive buffer size if I remember
correctly) whereas Netty tries to write the buffer buffer to the socket. So
If you did the same in Mina3, it may explain why it is slow
Jeff
On
Le 1/5/13 1:27 PM, Jeff MAURY a écrit :
Regarding the message size, I noticed that Mina2 writes only a sub part of
the message
Do you mean the full message don't get written ? I would be extremely
surprised if it were the case, and it would worth a JIRA and a fix...
(size is computed from
No, I did not mean there's a bug but what I meant is that when Mina2 has to
write a large message, it will split the message in small parts when
writing to the socket whereas Netty tries to write the full message to the
socket (as Mina3 from what you said). This may explain why Netty becomes
Le 1/5/13 7:21 PM, Jeff MAURY a écrit :
No, I did not mean there's a bug but what I meant is that when Mina2 has to
write a large message, it will split the message in small parts when
writing to the socket whereas Netty tries to write the full message to the
socket (as Mina3 from what you
I'm working on the netty server. It should be ok by the end of the week-end.
Regarding the performance for large message, should'nt it be related to jni
i mean the conversion from the java bytebuffer to a memory array that is
expected by the os socket layer ?
Jeff
Le 5 janv. 2013 19:42, Emmanuel
perhaps we should try reading/writing direct buffers
On Sat, Jan 5, 2013 at 8:23 PM, Jeff MAURY jeffma...@gmail.com wrote:
I'm working on the netty server. It should be ok by the end of the
week-end.
Regarding the performance for large message, should'nt it be related to jni
i mean the