This bug seems to be caused by a race condition between main thread and
kernel worker thread
1. Feeder keeps feeding the data from the main thread and buffer is reused
by Feeder
2. Buffers.wrap(MemoryManager.DEFAULT_MEMORY_MANAGER, buffer) seems to wrap
around buffer byte array rather than creating a new Buffer
3. AsyncWriteQueueRecord is created in TCPNIOAsyncQueueWriter.
AsyncWriteQueueRecord holds a reference to message where it holds the
Buffer. If the write queue is not full and the record gets processed by the
caller thread immediately, everything works correctly.
4. If the TCP socket is full or
TCPNIOTransport.setOptimizedForMultiplexing(true), and the write is enqueued
to be processed when the socket buffer is not full
5. When the socket can receive more data, it will trigger a selector to
execute in a kernel thread to process the remaining message. However, since
the buffer is getting reused, the message to be processed may have been
overwritten by Feeder in the main thread.
--
View this message in context: http://grizzly.1045725.n5.nabble.com/Grizzly-http-client-race-condition-tp5710847p5710849.html
Sent from the Grizzly - Users mailing list archive at Nabble.com.