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