On Thu, Apr 2, 2009 at 10:16 AM, Oleksiy Stashok <Oleksiy.Stashok_at_sun.com>wrote:
> 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.
>
Fantastic. What a relief.
> So please let me know, what you think could be improved.
> I will appreciate your feedback and help, if possible :)
>
Sure. Right now, I'm trying to learn the main intentions of the code.
Should I use developer's email list for internals questions?
I have a user level question which I'll post on a new thread on this user's
list.
Regards,
John
> 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
>>>>
>>>>
>>>>
>>>
>>
>>
>
>