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?
Thanks,
John