Re: Connection lost

Поиск
Список
Период
Сортировка
От dennis jenkins
Тема Re: Connection lost
Дата
Msg-id AANLkTimM_g2tF4XUIDYrTd875-IH4wPNrqWRIDCZXKfE@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Connection lost  (Hernan Danielan <hernandanielan@gmail.com>)
Список pgsql-general


On Thu, May 20, 2010 at 7:49 AM, Hernan Danielan <hernandanielan@gmail.com> wrote:
The server and the client are running in the same machine.That is why a network connection problem is almost imposible. I do not know if i am doing something wrong, my code is in my fist message. It is a extrange thing because with files less than 500KB works great. However with a file of 1.4MB it fails most of the time. Does the JDBC has a timeOut or something? does anybody knows another connector that i could use in order to test it?

I am really desperate because i have been with this problem for several days now.

Thank in advance,
Hernan


If you can duplicate the problem on demand, then I would try this:

1)  Disable SSL (so that TCPDUMP capture files are readable).

2)  I don't remember if TCPDUMP can sniff traffic on "lo" (loopback) adapater on Linux, but I'm pretty sure that you can't sniff loopback on Windows (wireshark) or Solaris (with either tcpdump or snoop, the kernel won't support it). If you are using a unix socket then configure your client to use an IP bound to a NIC on the server.

3)  Sniff the traffic between client and server.  If using TCPDUMP use the options "-s 0" (capture all bytes of the packet) and "-n" (don't do DNS lookups).  If using "snoop" on Solaris the options are different.

4)  Run your client using "strace" (Linux) or "truss" (BSD and Solaris) to record all syscalls.  You probably want to use the "-o" option (strace) to log to a file (instead of STDOUT).

5)  If you can connect to the backend and then pause, connect a "strace" or "truss" to the PID of the backend (use the "-p pid" argument).

6)  Let it run until it crashes.

7)  Compare the network and syscall traces with each other.  The network trace should show you who hung up (who sent the TCP RST or TCP FIN) packet, and if it was preceded by a delay or not.  The syscall trace will should you what the kernel though that your process(es) were doing.  Your answer is hopefully in there somewhere.  However, it is entirely possible that the client hung up on the server on its own volition and neither trace will show you why. :(  But you might get lucky too.

В списке pgsql-general по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: postgres startup failure
Следующее
От: Justin Pasher
Дата:
Сообщение: Re: Postgres stats collector showing high disk I/O