Hi John
I think this may be a problem of ReadFilter.
In UDP, a key is registered after DatagramChannel.receive. So, if an exception
occurs at DatagramChannel.receive, the key is not registered to selector.
Minoru
> In short, selector.select is not blocking and returning zero keys for some
> short time (~30ms) right after a datagram.receive gets a
> PortUnreachableException.
>
> I'd like to know if anyone would have an explanation.
>
>
>
>
> The longer story:
> I have a grizzly UDP client/server program. It opens a udp port and sends
> to a remote port that is NOT LISTENING. The remote host sends an ICMP port
> unreachable message.
>
> My grizzly selector returns a key for the socket for OP_READ.
>
> ReadFilter reads the channel and gets a PortUnreachableException.
>
> At this point, when Controller.doSelect calls the UDPSelectorHandler.select,
> the select does not block and returns zero keys. Usually, the select will
> block for one second, or return some number of keys. At this point, the
> select doesn't block and doesn't return any keys. doSelect is run twice
> every millesecond. Setting the log level to FINE will show the pollContext
> method many times per second. (I know doSelect is run twice every
> millisecond because I modified the Controller source code for extra
> logging.)
>
> doSelect spins for about 30ms, Then, after ReadFilter logs the exception,
> doSelect doesn't spin anymore.
>
>
>
>
>
> This behavior is worrisome to me because I do not have much cpu resource on
> my platform and I expect many PortUnreachable conditions in my UDP
> application.
>
> Anyone know why this could happen?
>
>
> Thanks,
> John