users@grizzly.java.net

Re: PortUnreachable and udp

From: John Franey <jjfraney_at_gmail.com>
Date: Tue, 31 Mar 2009 21:47:13 -0400

Alexey,

Thanks.

Attached is a jar with maven project: pom and source.

Its a little more advanced then this morning.

I love the extensibility of grizzly. It lets me write my own components to
avoid design decisions that don't help. My source code has a few of these
extensions.

One is my own ReadFilter. There, I bury the PortUnreachableException,
(catch without any handling code). This lets the key get registered. Even
so, the spin still happens.

Remember to run this code with a logging level at FINE (or whatever) to see
the log message from Controller.pollContext.

In case it matters, I'm usually run with jrockit 1.6, but the same problem
happens with sun's 1.6.

I use ubuntu linux 8.10 64 bit.

Thanks.
Regards,
John


On Tue, Mar 31, 2009 at 4:39 PM, Oleksiy Stashok <Oleksiy.Stashok_at_sun.com>wrote:

> Hi John,
>
> I will appreciate if you can pack and send the testcase. I'll investigate
> it ASAP.
>
> Thanks.
>
> WBR,
> Alexey.
>
>
> On Mar 31, 2009, at 19:53 , John Franey wrote:
>
> 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
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>
>