Hi John,
>
> Unfortunately, the use case load is 50 datagrams per second per
> direction per channel. I would like to avoid the cpu cycles of the
> security check described by Java apidoc for the non-connected UDP
> channels.
>
> Is the change to support connected UDP channels deep?
Actually I wanted to say that Grizzly doesn't support non-connected
datagram channels, and connected UDP channels are currently supported.
So please let me know, what you think could be improved.
I will appreciate your feedback and help, if possible :)
Thanks.
WBR,
Alexey.
> In preliminary tests, grizzly has done well using connected
> channels. My test connects-transmits-closes and repeats. I ran the
> test for 20 channels at the above load over 5 or 6 repeats with each
> connection lasting 50 seconds. Things seem to work well enough.
>
> So, if you think I have a chance to understand the issues and
> grizzly internals, and you think a grizzly beginner can accomplish
> it, I'm willing to help.
>
> Regards,
> John
>
> On Thu, Apr 2, 2009 at 8:35 AM, Oleksiy Stashok <Oleksiy.Stashok_at_sun.com
> > wrote:
> Hi John,
>
> IMHO for your usecase, you can use not-connected UDP channels, which
> are not bound to specific destination address.
> Though, not sure we're supporting such a UDP connections in Grizzly
> now, but for sure we have to make them work.
>
> WBR,
> Alexey.
>
>
>>
>> I had a change of thinking overnight. My current thinking on port
>> unreachable: my application should not ignore it.
>>
>>
>> John
>>
>> On Wed, Apr 1, 2009 at 8:55 PM, John Franey <jjfraney_at_gmail.com>
>> wrote:
>>
>> Thanks.
>>
>> So, the spin is not occuring now.
>>
>> But I think the OP_READ selection is disabled: data sent to the
>> port after port unreachable is not read.
>>
>> In my application, I expect Port Unreachable at times, and the
>> channel should remain operating.
>>
>> How would I now restart OP_READ on this open socket?
>>
>> 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
>>
>>
>>
>
>