users@grizzly.java.net

Re: Grizzly stops working after UDP 5 packets

From: Radim Kolar SF.NET <hsn_at_sendmail.cz>
Date: Thu, 22 Nov 2007 02:36:42 +0100

> Which JDK are you using and on which platform? Can you do a jstack <PID>?
> Most likely it block in UDPWriteFilter line 78 (for probably 60 seconds).
> You might want to either reduce the timeout on the OutputWriter or use the
> new async Write queue :-)
no, all worker threads are blocked at waitForTask():292 and main thread
is blocked in select()

server socket is not closed according to netstat -a

i think problem is that UDP support not very suitable for writing servers.

1. udpwritefilter should query UDPSelectorHandler(boolean isClient) and in
server mode avoid closing channel on errors

2. because all Contexts share same SelectionKey() there must be
races between worker threads playing with registering key selectorHandler.register. UDPWriter registers OP_WRITE and Reader OP_READ.

BTW is there reason why UDPWriter registers in postExecute OP_WRITE?
this may be useful only if UDPWriter is at top of protocol chain, but writer
needs to get data to write from somewhere so its unlikely to be first in chain.

I will write my own version of UDPWriter (not closing socket and not registering OP_WRITE) and test it.

This is most likely cause of deadlock in my app because one worker deregisters
OP_READ from server channel and all packets starts to be ignored.