Deadlock after adding ExecutionHandler

["이희승 (Trustin Lee)"]

Hi Ian,

Sorry for being late in fixing this critical issue.  I've just checked
in the fix you suggested.  It looks fine to me.  Although it is
desirable to make the MATPE more correct so that it's just enough to
call semaphore.release() only once, I believe it's impossible without
sacrificing performance - Calling release() another time sounds like a
good compromise in my opinion.

Thanks,
Trustin

On 07/27/2010 04:39 AM, IanS wrote:
> 
> I had this happen again today and I believe I figured out what is causing it
> on the Netty side.
> 
> I believe the reason is that Semaphore.release() only releases one thread,
> but there were multiple waiting, and the others may never got released only
> if the object sizes vary.
> 
> This is because it it is possible two threads with relatively small messages
> could be waiting, but then a large message finishes, and that only calls
> release() on one of the threads, and after that, we're back below the
> maxTotalMemorySize, so release() isn't going to get called again.
> 
> I'm not sure my solution is the best, but this does work in my case.
> 
> After semaphore.release() in MemoryAwareThreadPoolExecutor.java, I added:
> 
> 	if(totalCounter < maxTotalMemorySize) {
>         		while(semaphore.hasQueuedThreads()) {
>         			semaphore.release();
>         		}
>         	}
> 
> Hopefully, this or something similar is a worthwhile change?
> 
> Ian

-- 
what we call human nature in actuality is human habit
http://gleamynode.net/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 293 bytes
Desc: OpenPGP digital signature
Url : http://lists.jboss.org/pipermail/netty-users/attachments/20100826/a7122f1e/attachment-0001.bin