>
> 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?
We prefer to use public lists, but if there is something, say business
details, you don't want to share - you can write directly.
> I have a user level question which I'll post on a new thread on this
> user's list.
Great! Will be glad to help you on that.
WBR,
Alexey.
>
>
>
> 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
>>>
>>>
>>>
>>
>>
>
>