Hi Alexey,
Thanks. I can appreciate your point of view.
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?
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
>>>
>>>
>>>
>>
>
>