Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1r8N54-009Wt5-Gb for pgsql-jdbc@arkaria.postgresql.org; Wed, 29 Nov 2023 16:06:31 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1r8N52-00BdBY-3Z for pgsql-jdbc@arkaria.postgresql.org; Wed, 29 Nov 2023 16:06:28 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1r8N51-00BdBQ-DC for pgsql-jdbc@lists.postgresql.org; Wed, 29 Nov 2023 16:06:27 +0000 Received: from sonic306-2.consmr.mail.bf2.yahoo.com ([74.6.132.41]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1r8N4x-007xiD-9M for pgsql-jdbc@lists.postgresql.org; Wed, 29 Nov 2023 16:06:25 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1701273980; bh=01j0ATwsRYLaie1TRnUJqquZ7qPp744t0qy+s3y6P4o=; h=Date:Subject:To:References:From:In-Reply-To:From:Subject:Reply-To; b=je5EH+tWSp467N+OIxtRPl0O0xObZDGUNc0w2xxACl+90izSd/ZizcVs+TTX/td8CxI1UnElzSWIpBlK90qbfnFbF46s1iz0dYWOr7pj9Cq8tRJ5XlFEx/JJYViDAk26pqB2UeXZqlwuchkHZlFATWAuUGPpiVGEbYAdGhVhODTcYaxMLIRLpnPqjxGyn3sWMaUuEBV42in/frZMLAHBxNV04B57Buwwh1X24weFVQbqPTpFZ4XNFs60naLicOOab8Ys8B2CIsTOA8BLkYPGYADiiFf0jUV6kd6HLJXAy0FQNzTyHQ+R1h40nWlAOtaE6AAA/Mba6R0zT5l7MOPNDw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1701273980; bh=Jy6/wPgdFA+QAGt01s3bXgDexAmCsxZ5RE/AhNad+s8=; h=X-Sonic-MF:Date:Subject:To:From:From:Subject; b=J9UpcufczqPLhUNBJEWQKhYzRGGyAXs3mA6WB7NiVkTjHA+hKYdaMY3uxBM4CCcMDyPOp5wKcOrwfuWPq3WDgZfyShiz57hI4FYTF+tWmYV4IwimOPKxO/IgAGWpDETXob7NHfNQmJnA79U1P3dA4D0aKT/i8UMJKEm6KFRGTXXHiwVWwaHdwE55R5hdgvizMJA3tRhoSNvzbL+SoWdyJUfF8yAftjU9nHz4qu5XvOmx345L6pPKNynGl+GXaXp7jm302NPG+VQ9YuyalMIPJUidET2GXqjs8eVAEYjW79Yb5TcWOKYJATH6T/c0OT1gTGGrOrKYumEgnJe3Rdfm9w== X-YMail-OSG: Aw8KJ_QVM1laNy2mtYEpX.8afJaTFEcznwJVcgQ3MQJi8gNUUYkIv9i94w7GXrO EvW0.xMznngXDMTl2J50G_xQX8gqj0NSJv6M5UN85mW6RRrYvDbdQbxjcg453MJPKkI.POqYqsZt QnNrAuDs.8E1wpvjmVwI9QdGI38qKNSy5F4UDAnRAJNLjNL4B0Xx2W248azJAnDZBLNk.P_VXx7S X6fNXaNFeUTKuuzulaT629vsbgK1c2l.iAfmNHgyukww2suwoux5qKo1L0qqmYZrPp.TjikkLauD uc8SVG7hEYkd8BqtiH4g88R41libQNTn5Adg3r.l15V4Ikc1osyUsHUmFJjByF7TpL.s.61j2mSo akJlIhOomKD5lEibiPCFcdT8sr9rOq8YloZWKs9fVFdTdUrcDjmCEYWsN.f2bfGnsKiiPfawwDZI 5dzraJOGNEQ48ENAMXDY4xQamlnwhz7cMQaAiSr5.k7yMJeXK2KmbpJpnHSMwaKBCvVrDkVRus8r Um_lMlupj.8wArG2h5BQYn8RYNpjoNBGkf2Gc1ae7N6FN4SBZ0quLMKc66Em2Qu8Fo69nw.zGAvY 8FTO5CfOPPZavwx3bk2lV8PA6ZRwYpPov.HobHJ0xRJ_D09O68WZk0T_H8Yj5vKiu1xakFcWOTO1 MNWHRBZ.bNN4g4dnoq.2nMlz29BJN7J4rsng4gNhDggNjIlUVcecd5d.vDQIjXKDMgu8kdSdcdS6 TM6BnKQR9q6tQOBV8pgUjV.z.fLN4G6FfaK53zXiuWZEpeHfTCjoozFNOZ6TLwtFHn8wKU2rerqB alWHuwLIdvsniSdLxn81k0c1hmEdaD1Hs_kLhKYq45ZkKBBykOqaLEDsRASrk0v17g7z9lARQGj3 FCu8VA44qjWauThUFKmqTmLCzEwxUqmMSh0I_Ab0qnoX33KKkLLRYs5A8Z5CtdQMY_eNXuunD_eD zz8HF6MnEDISgtMO6LKCuLygReT2hOOG7UQ9_RfrJOueZPFbZCwNyPaSEcLqnhYvJviwTPO.ry94 lHm4Sm1jrCDHzAkf1loVfHT6M7dPr1Ss8tNU7uP9xq5qBonupwcGVDUYPlci3_eWQaDO2PdcMn6o OWAcXPBAD8F6uODPyj8pUVLybzTCEX.AIv1XKtUUfaiPp9CdkDx6o2OrhCiWwhnVQ69kfcint0e4 pjiHGlToCWwbPK1NJChWWZXVyIMdwb1uhuBN0VQPhebc2UAONh_Si.MotRXj.kubCTpdm4tQYvn7 2sLqEfU9jTJZOAhinDrOzLU1Xd.hp_Oop3nyIF6Yw3rPS0AWyiXFZkmB__N_bBPLLgUlR2Uv2k2X GiE6CbtX6ZI.PGCbeTbug_KYZ1co671Nnuk1MzGJIvRi61MU3OHna4ArPOtHKY_Dvoyr_LP4lrbZ yHlowkyJ39KyO2hxeO1tFp2sg0mrdK1bMPSjjozxiqxt_rMWw70I5t4vCi6XTpEwlJhIf8JH0pHQ Qm1BusZwMnMchLQHLA.R_BHP8hXYx1FlQiuAm1Hy9cAB5CcrT3sCFIqsgdF3WyWuc1fWZMhFCCEh VKQavdR.BZPjtsUuW1Icj1qbt7kwxNZ2YbtX2caOzazovwN4IosBpsnfD9wo.TIkQYVa1eWdkR25 do7HbTWmPBeBvvcReG2oef99On9IAC5YXjoj_qH2GLUHtKH7iZrKZlUIyhkw9Jlwvr9F7nn.M.1H 9SlSG5kjTRGjxoYry2tce1yoXrafKW5kYoNx.7U0E4HEHwn2bY2G6B1U5Me2lCYFW0DxYlbQj4KA qBnHfcF3ha_Mp1nqJocCmFNC9Y.VdYJ4N97l3XOm9xin3CQqdL7iA2ItQuLXOhab56H2rEH3OuT8 6xZ7xEriGWchdhIYqZ.JKVU9btZAzBL3fxo7bwRHtOyrLhz6grfUEF91FZTFRQejjP3LCX55XDvx VYwaLve1nMb66NiVpJN8rmReYv7Fm6AJVkEDpHtjibl80NOjsfU_t_TxeyLAhJG.FlU48978KWCe ZIh6iq1VbeZeQOE4xfxQuATV.z.OegpMHFSF.4bHU2GQnc0gg4msLoUGbKC.v.eMaKRgNSeNgw8B 0.ZnP70TTkhhDqvyA0wvtXGrcGZaiCVPzMhHKqO8qnqC.EvHn8G3yUy9wH37htWIOZs4jK9d8Elr JF5Sk57jb74qaqshdsvBGdS.CoFlWxaDqaPXlTeB49AUioq.hbofIw45p1X0WmI7WfOaG0al8uyR GgwIVQBFLG8U- X-Sonic-MF: X-Sonic-ID: 7b9cf63d-1463-4b3c-b11e-3db37d7d75c5 Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.bf2.yahoo.com with HTTP; Wed, 29 Nov 2023 16:06:20 +0000 Received: by hermes--production-ir2-864cfb66d6-wjgq6 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID a96fa8af568e4d6639cc60ce2a169c97; Wed, 29 Nov 2023 16:06:17 +0000 (UTC) Content-Type: multipart/alternative; boundary="------------oSX3UTdJ6ZCL8c0LF62gHAQP" Message-ID: Date: Wed, 29 Nov 2023 17:06:16 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Driver hangs in connect->MakeSSL.convert->SSLSocketImpl.startHandshake Content-Language: en-US To: pgsql-jdbc@lists.postgresql.org References: <2c2e0f5d-4fe2-472f-a213-5cf58ec993c5.ref@yahoo.com> <2c2e0f5d-4fe2-472f-a213-5cf58ec993c5@yahoo.com> From: Martin Lichtin In-Reply-To: X-Mailer: WebService/1.1.21896 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 10266 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk This is a multi-part message in MIME format. --------------oSX3UTdJ6ZCL8c0LF62gHAQP Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 28/11/2023 21:28, Dave Cramer wrote: > On Tue, 28 Nov 2023 at 09:07, Dave Cramer > wrote: > > Hi Martin, > > Thanks for the report. I'll have a look. > Dave Cramer > > On Tue, 28 Nov 2023 at 08:27, Martin Lichtin > wrote: > > Hi > > I'm seeing this thread hanging in the "getConnection" method, > with no timeout in sight. > However, the PGXADataSource is configured with a > "connectTimeout" of 10 seconds. > >    java.lang.Thread.State: RUNNABLE >     at java.net.SocketInputStream.socketRead0(Native Method) >     at > java.net.SocketInputStream.socketRead(SocketInputStream.java:116) >     at java.net.SocketInputStream.read(SocketInputStream.java:171) >     at java.net.SocketInputStream.read(SocketInputStream.java:141) >     at > sun.security.ssl.SSLSocketInputRecord.read(SSLSocketInputRecord.java:464) >     at > sun.security.ssl.SSLSocketInputRecord.decode(SSLSocketInputRecord.java:165) >     at sun.security.ssl.SSLTransport.decode(SSLTransport.java:109) >     at > sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1392) >     at > sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1300) >     at > sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:435) >     at org.postgresql.ssl.MakeSSL.convert(MakeSSL.java:41) > ... >     at > java.sql.DriverManager.getConnection(DriverManager.java:247) >     at > org.postgresql.ds.common.BaseDataSource.getConnection(BaseDataSource.java:103) >     at > org.postgresql.xa.PGXADataSource.getXAConnection(PGXADataSource.java:49) >     at > org.postgresql.xa.PGXADataSource.getXAConnection(PGXADataSource.java:35) > > Any reason this timeout is not being applied here? > > The version in use here is 42.3.6 > > > This Make sure to pass any network timeouts to the new SSL connection. > by davecramer · Pull Request #3040 · pgjdbc/pgjdbc (github.com) >  should fix the problem, > can you check ? Thanks! I'll try. Was hoping for a SNAPSHOT version with this change in, but looks like these are no longer produced(?), although mentioned here https://jdbc.postgresql.org/download/ Anyways, it will be quite hard to reproduce this socket-read hang situation, so not sure I'll be able to test the change :) Some more observations (obv from a newcomer to this space..): As mentioned I'm setting "connectTimeout". Is this value somehow trickling down, and ending up at what's called "networkTimeout" in the code? I'm asking as networkTimeout is not a connection parameter.. https://jdbc.postgresql.org/documentation/use/ Also confusing to me is the existing parameter "sslResponseTimeout", this defaults to 5 seconds, and is already documented as 'the maximum time to wait for a response after requesting an SSL encrypted connection from the server'. Shouldn't this value be used in above case. Lastly, seeing "socketTimeout", however I would not want to set this one, as it could interfere with long-running queries, and to me, should not be used during connection setup. - Martin --------------oSX3UTdJ6ZCL8c0LF62gHAQP Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit


On 28/11/2023 21:28, Dave Cramer wrote:
On Tue, 28 Nov 2023 at 09:07, Dave Cramer <davecramer@postgres.rocks> wrote:
Hi Martin,

Thanks for the report. I'll have a look. 
Dave Cramer

On Tue, 28 Nov 2023 at 08:27, Martin Lichtin <lichtin@yahoo.com> wrote:

Hi

I'm seeing this thread hanging in the "getConnection" method, with no timeout in sight.
However, the PGXADataSource is configured with a "connectTimeout" of 10 seconds.

   java.lang.Thread.State: RUNNABLE
    at java.net.SocketInputStream.socketRead0(Native Method)
    at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
    at java.net.SocketInputStream.read(SocketInputStream.java:171)
    at java.net.SocketInputStream.read(SocketInputStream.java:141)
    at sun.security.ssl.SSLSocketInputRecord.read(SSLSocketInputRecord.java:464)
    at sun.security.ssl.SSLSocketInputRecord.decode(SSLSocketInputRecord.java:165)
    at sun.security.ssl.SSLTransport.decode(SSLTransport.java:109)
    at sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1392)
    at sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1300)
    at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:435)
    at org.postgresql.ssl.MakeSSL.convert(MakeSSL.java:41)
...
    at java.sql.DriverManager.getConnection(DriverManager.java:247)
    at org.postgresql.ds.common.BaseDataSource.getConnection(BaseDataSource.java:103)
    at org.postgresql.xa.PGXADataSource.getXAConnection(PGXADataSource.java:49)
    at org.postgresql.xa.PGXADataSource.getXAConnection(PGXADataSource.java:35)

Any reason this timeout is not being applied here?

The version in use here is 42.3.6


Thanks! I'll try. Was hoping for a SNAPSHOT version with this change in, but looks like these are no longer produced(?), although mentioned here https://jdbc.postgresql.org/download/  Anyways, it will be quite hard to reproduce this socket-read hang situation, so not sure I'll be able to test the change :)

Some more observations (obv from a newcomer to this space..):

As mentioned I'm setting "connectTimeout". Is this value somehow trickling down, and ending up at what's called "networkTimeout" in the code?
I'm asking as networkTimeout is not a connection parameter.. https://jdbc.postgresql.org/documentation/use/

Also confusing to me is the existing parameter "sslResponseTimeout", this defaults to 5 seconds, and is already documented as 'the maximum time to wait for a response after requesting an SSL encrypted connection from the server'. Shouldn't this value be used in above case.

Lastly, seeing "socketTimeout", however I would not want to set this one, as it could interfere with long-running queries, and to me, should not be used during connection setup.

- Martin

--------------oSX3UTdJ6ZCL8c0LF62gHAQP--