Hello again,
We installed wireshark on our client machine (192.168.2.34) and here is the
list of messages it exchanges with the server (192.168.2.12) when the
problem occurs in Windows (we do not see this pattern when server db runs
in RedHat):
[No.] [Time] [Source] [Dest]
[Prot] [Len] [Info]
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
19521 173,605,647,000 192.168.2.34 192.168.2.12 TCP 174 [TCP
Retransmission] 61388 > copycat [PSH, ACK] Seq=944825 Ack=3046332 Win=65528
Len=120
19522 173,606,481,000 192.168.2.12 192.168.2.34 TCP 66 [TCP Dup ACK
19520#1] copycat > 61388 [ACK] Seq=3046362 Ack=944945 Win=65792 Len=0
SLE=944825 SRE=944945
19523 173,611,391,000 192.168.2.12 192.168.2.34 TCP 84 [TCP Retransmission]
copycat > 61388 [PSH, ACK] Seq=3046332 Ack=944945 Win=65792 Len=30
19524 174,211,536,000 192.168.2.12 192.168.2.34 TCP 84 [TCP Retransmission]
copycat > 61388 [PSH, ACK] Seq=3046332 Ack=944945 Win=65792 Len=30
19534 175,411,716,000 192.168.2.12 192.168.2.34 TCP 84 [TCP Retransmission]
copycat > 61388 [PSH, ACK] Seq=3046332 Ack=944945 Win=65792 Len=30
19551 177,812,001,000 192.168.2.12 192.168.2.34 TCP 84 [TCP Retransmission]
copycat > 61388 [PSH, ACK] Seq=3046332 Ack=944945 Win=65792 Len=30
19557 182,611,956,000 192.168.2.12 192.168.2.34 TCP 84 [TCP Retransmission]
copycat > 61388 [PSH, ACK] Seq=3046332 Ack=944945 Win=65792 Len=30
19586 192,211,377,000 192.168.2.12 192.168.2.34 TCP 60 copycat > 61388
[RST, ACK] Seq=3046362 Ack=944945 Win=0 Len=0
19587 192,211,424,000 192.168.2.34 192.168.2.12 TCP 54 [TCP Dup ACK
19521#1] 61388 > copycat [ACK] Seq=944945 Ack=3046332 Win=65528 Len=0
20797 492,220,857,000 192.168.2.34 192.168.2.12 TCP 55 [TCP Keep-Alive]
[TCP Window Full] 61388 > copycat [ACK] Seq=944944 Ack=3046332 Win=65528
Len=1
20798 493,219,885,000 192.168.2.34 192.168.2.12 TCP 55 [TCP Keep-Alive]
[TCP Window Full] 61388 > copycat [ACK] Seq=944944 Ack=3046332 Win=65528
Len=1
20799 494,219,933,000 192.168.2.34 192.168.2.12 TCP 55 [TCP Keep-Alive]
[TCP Window Full] 61388 > copycat [ACK] Seq=944944 Ack=3046332 Win=65528
Len=1
20804 495,219,916,000 192.168.2.34 192.168.2.12 TCP 55 [TCP Keep-Alive]
[TCP Window Full] 61388 > copycat [ACK] Seq=944944 Ack=3046332 Win=65528
Len=1
20805 496,219,891,000 192.168.2.34 192.168.2.12 TCP 55 [TCP Keep-Alive]
[TCP Window Full] 61388 > copycat [ACK] Seq=944944 Ack=3046332 Win=65528
Len=1
20809 497,219,873,000 192.168.2.34 192.168.2.12 TCP 55 [TCP Keep-Alive]
[TCP Window Full] 61388 > copycat [ACK] Seq=944944 Ack=3046332 Win=65528
Len=1
20823 498,219,845,000 192.168.2.34 192.168.2.12 TCP 55 [TCP Keep-Alive]
[TCP Window Full] 61388 > copycat [ACK] Seq=944944 Ack=3046332 Win=65528
Len=1
20826 499,219,830,000 192.168.2.34 192.168.2.12 TCP 55 [TCP Keep-Alive]
[TCP Window Full] 61388 > copycat [ACK] Seq=944944 Ack=3046332 Win=65528
Len=1
20830 500,219,828,000 192.168.2.34 192.168.2.12 TCP 55 [TCP Keep-Alive]
[TCP Window Full] 61388 > copycat [ACK] Seq=944944 Ack=3046332 Win=65528
Len=1
20831 501,219,806,000 192.168.2.34 192.168.2.12 TCP 55 [TCP Keep-Alive]
[TCP Window Full] 61388 > copycat [ACK] Seq=944944 Ack=3046332 Win=65528
Len=1
20832 502,219,779,000 192.168.2.34 192.168.2.12 TCP 54 61388 > copycat
[RST, ACK] Seq=944945 Ack=3046332 Win=0 Len=0
As shown, for some reason the server retransmits the same packet 5 times
(maybe thinking that client is not responding] and then resets connection
(packet #19586). The weird thing is that client side is always on a windows
machine and therefore its behavior should be the same no matter if the H2
server db is hosted on a windows or linux machine. Any ideas based on this
input?
Thank you in advance.
On Wednesday, May 8, 2013 2:25:06 PM UTC+3, Noel Grandin wrote:
>
> It would be interesting to see the client-side logs to see if there
> anything useful about why the client disconnects.
>
> Otherwise, you could try doing a Wireshark or Microsoft-Network-Monitor
> trace of the connection, to see where and when the disconnect is initiated.
>
> On 2013-05-08 11:08, Yanni Papadimitriou wrote:
>
> Hello Noel,
>
> Thank you for following up on this.
>
> I thought of this possibility, but do you have any idea why this would
> happen only if the server resides on a Windows machine and doesn't happen
> when on a Linux machine? Client code is exactly the same no matter what OS
> hosts the h2 server database.
>
> Thank you,
> Yanni.
>
> On Wednesday, May 8, 2013 10:21:12 AM UTC+3, Noel Grandin wrote:
>>
>>
>> That sounds like your client is timing out for some reason and
>> disconnecting from the database.
>>
>> On 2013-05-07 18:07, Yanni Papadimitriou wrote:
>> > Hello,
>> >
>> > While running the H2 database in remote tcp mode over Windows (Windows
>> > 7 to be exact), I have noticed that it becomes unresponsive when
>> > multiple queries hit it in short period of time. I have enabled
>> > tracing and am seeing logs such as:
>> >
>> > /*SQL #:1*/CALL LOCK_MODE();
>> > 03-28 12:16:29 lock: 2 shared read lock requesting for MY_TABLE_NAME
>> > 03-28 12:16:29 jdbc[2]:
>> > /*SQL l:50 #:1*/SELECT NAME FROM MY_TABLE_NAME WHERE ID = ? {1: 26};
>> > 03-28 12:16:29 jdbc[2]:
>> > /*SQL #:1*/CALL LOCK_MODE();
>> > 03-28 12:16:29 lock: 2 shared read lock requesting for MY_TABLE_NAME
>> > 03-28 12:16:29 jdbc[2]:
>> > /*SQL l:50 #:1*/SELECT NAME FROM MY_TABLE_NAME WHERE ID = ? {1: 27};
>> > 03-28 12:16:29 jdbc[2]:
>> > /*SQL #:1*/CALL LOCK_MODE();
>> > 03-28 12:16:29 lock: 2 shared read lock requesting for MY_TABLE_NAME
>> > 03-28 12:16:29 jdbc[2]:
>> > /*SQL l:50 #:1*/SELECT NAME FROM MY_TABLE_NAME WHERE ID = ? {1: 28};
>> > 03-28 12:16:48 jdbc[2]:
>> > /*SQL */ROLLBACK;
>> > 03-28 12:16:48 database: disconnecting session #2
>> > 03-28 12:16:48 database: closing C:/H2/db/data/my_db_name
>> > 03-28 12:16:48 lock: 1 shared read lock requesting for LOBS
>> > 03-28 12:16:48 lock: 1 shared read lock requesting for LOBS
>> >
>> > (followed by a few hundreds of logs related to shutting down the
>> database)
>> >
>> > I setup a Red Hat 5 virtual machine over that Windows 7 host,
>> > installed H2 database on the Red Hat machine and problem has
>> > disappeared. I have also never seen this problem while working in
>> > embedded mode on Windows 7 (but maybe this is just because it is
>> > running locally?).
>> >
>> > Is this a known issue for Windows in server mode? Is there any
>> > workaround? I have tried with both 1.3.171 and 1.3.165.
>> >
>> > Thank you in advance,
>> > Yanni.
>> > --
>> > You received this message because you are subscribed to the Google
>> > Groups "H2 Database" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> > an email to [email protected].
>> > To post to this group, send email to [email protected].
>> > Visit this group at http://groups.google.com/group/h2-database?hl=en.
>> > For more options, visit https://groups.google.com/groups/opt_out.
>> >
>> >
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "H2 Database" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected] <javascript:>.
> To post to this group, send email to [email protected]<javascript:>
> .
> Visit this group at http://groups.google.com/group/h2-database?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
>
>
--
You received this message because you are subscribed to the Google Groups "H2
Database" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/h2-database?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
