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
>