since it's a ConcurrentLinkedQueue it could be a perf killer to do a .size() from the oracle javadoc :
""Beware that, unlike in most collections, the size method is NOT a constant-time operation. Because of the asynchronous nature of these queues, determining the current number of elements requires a traversal of the elements."" Julien On Mon, Dec 5, 2011 at 3:20 PM, Chad Beaulac <[email protected]> wrote: > Excellent. I like the counter in the write algorithm. > > Sent from my iPhone > > On Dec 5, 2011, at 8:50 AM, Emmanuel Lecharny <[email protected]> wrote: > >> On 12/5/11 2:39 PM, Chad Beaulac wrote: >>> Looks perfect except one thing. Don't allow clients to put WriteRequest's >>> into the queue while you're draining it. If you allow other threads to >>> enqueue more WriteRequest's, the algorithm is unbounded and you risk >>> getting stuck writing for only one channel. I added a synchronized block >>> below. >> >> We can avoid the synchronized section by getting the queue size at the >> beginning : >> >> Queue<WriteRequest> queue = session.getWriteQueue(); >> >> int size = queue.size(); >> >> while (size > 0) { >> ... // process each entry in the queue >> size--; >> } >> >> But I don't even think it's necessary : a session can only be processed by >> one single thread, which is the one which process the write (the selector's >> thread). >> >> Of course, if we add an executor somewhere in the chain, this is a different >> story, but then, we will need to add some synchronization at the executor >> level, not on the selector level, IMO. >> >> >> >> -- >> Regards, >> Cordialement, >> Emmanuel Lécharny >> www.iktek.com >>
