On 03/13/2013 10:40 PM, Mark Thomas wrote:
On 13/03/2013 21:20, Remy Maucherat wrote:
On Wed, 2013-03-13 at 20:52 +0000, Mark Thomas wrote:
I mean check for Socket.setsbb somewhere after the socket is
returned from poller. Either the new buffer has been set or
the buffer address is different because of Socket.sendbb's offset param
(in this case it would be -11530560 so some wrong calculation)
Inside Socket.setsbb we get the ByteBuffer's direct address and later
reuse it inside Socket.sendbb(long socket, int offset, int len) call
by using 'socket->jsbuff + offset' and that offseted address is
displayed in
the upper debug trace (and if they are not the same OpenSSL will return
SSL_ERROR_SSL)
I'm using Socket.send() with the same buffer.
That won't work cause each time we use different buffer
either from stack (up to 8192 bytes) or malloc'd for larger ones
because we need to copy from byte array.
I'm looking at switching to sendb instead.
If you spare some time to refactor and use sendsbb next after trying
sendb, it's supposed to be faster [I never did a real comparison test
though].
I strongly suspect that sendb vs sendbb won't be the biggest bottleneck
in my code.
There is an extra JNI call and passing object across JNI boundary
uses some time. But you are right, that's not the biggest bottleneck.
However like Remy said, since you have to use the same buffer anyhow
and that buffer must not change its address there's no point to pass it
on each call and internally call JNIEnv->GetDirectBufferAddress(buf).
Just use Socket.setsbb and then Socket.sendbb.
Socket.sendb is usually used for blocking sockets.
Regards
--
^TM
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
