> When TLS 1.3 is introduced, whole sun.security.ssl.SSLSocketImpl was > rewritten. Correct, I meant rewritten TLSv1.3, the good news that 1.2- also were fixed. so, -- brand new TLS with any linger -- plain old TLS with linger>0
On Fri, Oct 30, 2020 at 3:10 PM Ivan Daschinsky <ivanda...@gmail.com> wrote: > Ilya, Anton. > It means that not if TLS 1.3 is worked ok and with TLS < 1.2 is not ok. > > When TLS 1.3 is introduced, whole sun.security.ssl.SSLSocketImpl was > rewritten. > There is not any code anymore that could cause a deadlock. > Therefore, in JDK, that supports TLS 1.3, this option is unnecessary, even > if you use TLS 1.2 > > > пт, 30 окт. 2020 г. в 14:46, Anton Vinogradov <a...@apache.org>: > > > Ilya > > > I think we should still keep setting linger if SSL is enabled > > Modern (updated) JVMs do not require this. > > AFAIK, Problem caused this workaround already fixed everywhere, including > > JDK 8. > > > > > If SSL only works with TLSv1.3 and no linger > > SSL works if > > -- TLSv1.3 with any linger > > -- TLSv1.2- with linger>0 > > > > > we should make TLSv1.3 a > > > default. If JVM does not support it, users will have to reconfigure > > > explicitly. > > I don't think it's a good idea to reconfigure production environments > this > > way. > > > > P.s. > > My +1 to zero linger as default + warning on SSL enabled on JVM before > the > > fix + warning at documentation + migration notes > > > > On Fri, Oct 30, 2020 at 2:19 PM Ilya Kasnacheev < > ilya.kasnach...@gmail.com > > > > > wrote: > > > > > Hello! > > > > > > I think we should still keep setting linger if SSL is enabled, and not > > > expect user to enable it (or face consequences). > > > > > > If SSL only works with TLSv1.3 and no linger, we should make TLSv1.3 a > > > default. If JVM does not support it, user will have to reconfigure > > > explicitly. > > > > > > Regards, > > > -- > > > Ilya Kasnacheev > > > > > > > > > пт, 30 окт. 2020 г. в 14:05, Steshin Vladimir <vlads...@gmail.com>: > > > > > > > * > > > > > > > > Hi, Igniters. > > > > > > > > We’ve found that enabled by default socket linger causes unexpected > > > > delay in detection of node failure. > > > > > > > > > > > > Moreover, long closing of socket works as Thread.sleep() within > > > > algorithms of failure detection and connection recovery in TCP > > > > discovery. These time gaps lead to hardly predictable behavior of the > > > > discovery. When the socket linger is enabled, it’s hard or even > > > > impossible to figure out what time is taken to detect node failure > and > > > > restore connections with the provided settings. > > > > > > > > Socket linger was enabled only as a workaround for SSL bugs (i.e. > [2], > > > > [3]). It was enabled without including in failure processing routines > > in > > > > TCP discovery SPI as described above. SSL bugs, mentioned above, were > > > > fixed and backported to various JDK, supporting TLS 1.3 ([4] and > [5]). > > > > > > > > > > > > I’d suggest to disable socket linger by default, because enabled > socket > > > > linger prolongs detection of node failure. The ticket is [1]. In case > > of > > > > SSL issues the linger could be enabled. Or one may just update JDK. > > > > We'll provide the documentation. > > > > > > > > WDYT? > > > > > > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-13643 > > > > > > > > [2] https://bugs.openjdk.java.net/browse/JDK-8219658 > > > > > > > > [3]https://issues.apache.org/jira/browse/IGNITE-12818 > > > > > > > > [4]https://bugs.openjdk.java.net/browse/JDK-8245468 > > > > > > > > [5] > > https://www.oracle.com/java/technologies/javase/8u261-relnotes.html > > > > > > > > * > > > > > > > > > > > > -- > Sincerely yours, Ivan Daschinskiy >
