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
>>
>>
>