> 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);
> }
That's quite strange. This fix looks dangerous. As it makes possible 2
threads to read from datagramChannel simultaneously.
Can you pls. remind one more time what is the desired effect you
need? :)
Thanks.
WBR,
Alexey.
>
>
> 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
>
>