The LinkedBlockingQueue should not have a length. (currently 10) - #61
The LinkedBlockingQueue should not have a length. (currently 10)#61JohanSmolders wants to merge 1 commit into
Conversation
The LinkedBlockingQueue should not have a length. If a message received has more then 10 messages being send back it renders the socket useless. Since the bufferQueue.put() method keeps waiting forever for the queue to shrink.
|
In the current situation reaching the buffers limit may cause a deadlock situation which is probably why you came up with this change. Thanks for calling attention on that! On the other hand this fix is not a long term solution because it makes it kind of easy to reach OutOfMemory states. A better way would be to not increase the limit of the LinkedBlockingQueue to much but actively schedule the data transfer if the buffer is full. That would keep the buffer from constantly growing and would eliminate deadlock possibility. If possible IO operations would be processed asynchronous but if not the IO operations would be performed by the thread calling the send. We could also solve the problem AND gain performance by making the handling of all the SelectionKeys asynchronous which should not be such a huge thing. |
|
Ok, there should no longer be problems with the internal queue. |
The LinkedBlockingQueue should not have a length.
If a message received has more then 10 messages being send back it
renders the socket useless. Since the bufferQueue.put() method keeps
waiting forever for the queue to shrink.