James Im wrote:
> I don't know.
> I've been asked a few times if my app had synchronization problems. If
> the driver traces contained enough info then these questions were
> superfluous I guess.
There is protection against concurrent access down in the code that
handles the protocol layer, but if there was a bug with that and you
were accessing a connection from multiple threads then it could explain
the behavior you see. But I would expect that to show up in the network
traces if that were the case, which it doesn't.
loglevel=2 logs as protocol-level messages are sent and received; you
could certainly log more detail, but I haven't managed to think of a
failure mode where more detail there would help diagnose it. If you're
prepared to do the work to add more detailed logging, go for it, but I
don't have time to do it myself.
> If you knew precisely what network traffic was going in and out through
> the socket why had I to capture the network traffic with wireshark and co?
It was possible that the driver was formatting things incorrectly at the
protocol level; since the logging at loglevel=2 does not log the exact
data sent/received I needed to see what was actually hitting the network.
(I am not convinced that commview is giving an accurate picture of what
is going on -- it looks suspiciously like it is hooking in at an API
level and then faking a network trace in libpcap format from that -- the
TCP data was all over the place..)
> Anyhow. You know better than me.
Ideally if you can get it happening between two machines where you can
get a good capture of the network traffic then I might be able to make
progress.. As it is, I don't think you've managed to do that, the
wireshark case seems to be something different (that probably needs
diagnosis on the server side to work out why the server is not
responding). It might be interesting to compare captures on the server
and client side in that case, since the connection gets abruptly reset.
For the moment I am going to have to shelve investigating this further
due to insufficient time .. It's certainly not an obvious problem, I
can't see anything wrong in the driver that would trigger it, and I am
beginning to suspect OS- or JVM- level weirdness since it is so
sensitive to your system setup. I know that there are antivirus/firewall
products that like to get their fingers into the windows network API,
and they've been known to cause strange bugs in the past .. Maybe that's
a possibility here?
-O
