Looks like this change to the original code gives me desired effect.
Basically, the key registration occurs before another call that would throw
an exception.
} else if (protocol == UDP){
++ ctx.getSelectorHandler().register(key,
SelectionKey.OP_READ);
DatagramChannel datagramChannel =
(DatagramChannel)key.channel();
socketAddress = datagramChannel.receive(byteBuffer);
-- ctx.getSelectorHandler().register(key,
SelectionKey.OP_READ);
}
Regards,
John
On Wed, Apr 1, 2009 at 7:43 PM, Oleksiy Stashok <Oleksiy.Stashok_at_sun.com>wrote:
> Hi John,
> please try to make the following change in your custom ReadFilter:
>
> } catch(PortUnreachableException e) {
> ++
> ctx.setKeyRegistrationState(Context.KeyRegistrationState.CANCEL);
> -- invokeNextFilter = false;
> ++ return false;
> }
>
> WBR,
> Alexey.
>
> On Apr 1, 2009, at 14:36 , John Franey wrote:
>
>
> Alexey,
>
> My apologies.
>
> The code I sent over is probably more than a 'test case'. I can pare it
> down some, or course, if it can help. Please, let me know how you would
> like it to be presented.
>
> Also, I guess I omitted how to build and run:
>
> 1) the jar file has source code as a maven project. To extract, create a
> clean directory and unjar: jar xf proto.jar
>
> 2) at this point, you can probably import into IDE. I use eclipse and have
> been happy with the q4e maven plugin. I would not be able to explain how to
> import or build under other environments because I pretty much stick with
> q4e.
>
> 3) to build: mvn compile, ought to work, or build from your ide.
>
> 4) to run. the main class is grizzlyproto.AReceiver. There are no command
> line arguments to the main method. Attached is a logging.properties file to
> use which will bring out the log messages showing the spin (you probably
> already use one). Running from IDE is the easiest becuase it automatically
> provides runtime classpaths. I'll assume you know how to run from your
> IDE. I think there is maven plugin that will exec a main method with
> runtime dependencies on classpath. I can make that modification if you
> would like to run from command line using maven.
>
>
> Regards,
> John
>
> On Tue, Mar 31, 2009 at 9:47 PM, John Franey <jjfraney_at_gmail.com> wrote:
>
>> 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
>>>
>>>
>>
> <grizzly-logging.properties>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>
>
>