Thanks,
It is my ReadFilter. Thanks for drawing my attention to it.
Regards,
John
On Tue, Apr 7, 2009 at 11:27 AM, Oleksiy Stashok <Oleksiy.Stashok_at_sun.com>wrote:
> Hi John,
>
>
>
> I'm at a wall with using grizzly. I am unable to debug the following
>> situation. I'm wondering if there are some tools or techniques you may know
>> about that can help me.
>>
>> It only looks like the OP_READ is either not being registered, doesn't
>> stick in the selector (maybe being unregistered?), or the selector is
>> outright ignoring OP_READ registration.
>>
>> This is a UDP application for streaming media packets. The grizzly server
>> is to receive a datagram of about 200 bytes every 20ms. At the same time,
>> the grizzly server will send a datagram at same size and rate.
>>
>> But this is what I observe some of the times I run the application:
>> 1) media packets are being sent out from the socket (this is good)
>> 2) media packets sent to the server are not being processed (this is bad)
>> 3) unix command, lsof, shows the connected UDP port
>> 4) wireshark shows the two way traffic.
>>
>>
>> The above appears to be non-deterministic. I have two test clients. For
>> one test client, the above is observable for most but not all tests. For
>> another test client, the above is observable for far fewer tests.
>>
>> I can tell the incoming media packets are not being processed in two ways.
>> The first way, for testing, my application prints a log message when a
>> certain pattern shows in the input stream, and my test clients send that
>> pattern on a low period. Once I see that log messages are not being
>> printed, then I attach to the jvm using remote debugger and activate break
>> points in the receiving code paths. If these break points are not reached,
>> then I know that the incoming data is not being processed.
>>
>> I have the grizzly source code and have put break points deep into the
>> Controller.handleSelectedKeys for the OP_READ case. This break point is not
>> occuring. So, I think that there are one of three conditions: OP_READ was
>> not registered, OP_READ was registered but later unset inadvertently, or the
>> selector is simply ignoring OP_READ altogether. (or maybe something else?)
>>
>> Any insights? or ideas on how to debug?
>>
> In Grizzly ReadFilter we reregister UDP channel SelectionKey to listen for
> OP_READ at line ReadFilter:158.
> If you're using custom ReadFilter, may be you have some different logic
> there?
>
> The place, where you can check keys to get registered for events is:
> TCPSelectorHandler.processPendingOperations() line 415.
>
> If you'll have problems with debugging that - please send me the testcase
> to reproduce the issue.
>
> Thanks.
>
> WBR,
> Alexey.
>
>
>>
>> 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
>
>