On Thu, Apr 2, 2009 at 11:52 AM, Oleksiy Stashok <Oleksiy.Stashok_at_sun.com>wrote:
>
> 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? :)
>
Sure. First, the selector is spinning and I want it to stop, and you
provided a fix for that but the channel didn't receive anymore. I want the
channel to still be able receive datagrams after an exception, namely after
a PortUnreachableException. On second thinking, I guess now this is no
longer required, because I'm now willing to close down the channel on a
PortUnreachableException. I guess I still thought it were possible, and
that I would better understand grizzly.
Thanks for the explanation for why this fix is inadvisable.
> 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
>>
>>
>>
>
>