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. >> >> 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. While I have tried not to do anything too stupid, my self imposed requirement to have WebSocket running purely on the Servlet 3.1 API without taking any short-cuts directly from WebSocket to the low-level IO has added some overhead. I'm pretty sure there is some fat that could be trimmed there. In the meantime it looks like sendb is working now I am using a directly allocated buffer. I need to do some more testing but things are (finally) looking up a bit. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
