Re: SQL query never ends
От | Oliver Jowett |
---|---|
Тема | Re: SQL query never ends |
Дата | |
Msg-id | 44DF055D.503@opencloud.com обсуждение исходный текст |
Ответ на | Re: SQL query never ends ("James Im" <im-james@hotmail.com>) |
Список | pgsql-jdbc |
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
В списке pgsql-jdbc по дате отправления: