[DISCUSS] Disable socket linger by default in TCP discovery SPI.

[Steshin Vladimir]

*

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

*

[Ivan Daschinsky]

Hi!
Vova, I agree with you, this default behaviour is quite confusing. Even if
we want to workaround bug for old jdk's and SSL,
it's strange idea to affect all other users by default. I think that we
should add section in documentation how to workaround this issue,
and disable socket linger on close by default.

пт, 30 окт. 2020 г. в 14:05, Steshin Vladimir <[hidden email]>:

> *
>
> 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

[Ilya Kasnacheev]

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 <[hidden email]>:

> *
>
> 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
>
> *
>

[Anton Vinogradov-2]

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 <[hidden email]>
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 <[hidden email]>:
>
> > *
> >
> > 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
> >
> > *
> >
>

[Ivan Daschinsky]

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 <[hidden email]>:

> 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 <[hidden email]
> >
> 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 <[hidden email]>:
> >
> > > *
> > >
> > > 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

[Anton Vinogradov-2]

> 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 <[hidden email]> 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 <[hidden email]>:
>
> > 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 <
> [hidden email]
> > >
> > 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 <[hidden email]>:
> > >
> > > > *
> > > >
> > > > 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
>

[Ilya Kasnacheev]

Hello!

Is there any option to re-enable linger on SSL sockets?

Telling people to re-configure does not help if they can't.

Regards,
--
Ilya Kasnacheev


пт, 30 окт. 2020 г. в 15:21, Anton Vinogradov <[hidden email]>:

> > 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 <[hidden email]>
> 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 <[hidden email]>:
> >
> > > 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 <
> > [hidden email]
> > > >
> > > 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 <[hidden email]>:
> > > >
> > > > > *
> > > > >
> > > > > 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
> >
>

[Ivan Daschinsky]

Ilya, yes, there is an option TcpDiscoverySpi#soLinger. The main question
is why the default value is true, 5 instead of false,0

пн, 2 нояб. 2020 г., 20:14 Ilya Kasnacheev <[hidden email]>:

> Hello!
>
> Is there any option to re-enable linger on SSL sockets?
>
> Telling people to re-configure does not help if they can't.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> пт, 30 окт. 2020 г. в 15:21, Anton Vinogradov <[hidden email]>:
>
> > > 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 <[hidden email]>
> > 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 <[hidden email]>:
> > >
> > > > 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 <
> > > [hidden email]
> > > > >
> > > > 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 <[hidden email]
> >:
> > > > >
> > > > > > *
> > > > > >
> > > > > > 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
> > >
> >
>

[Steshin Vladimir]

     Ilya, hi.


     Of course: /TcpDiscoverySpi.setSoLinger(int)/ property. Always been.


02.11.2020 20:14, Ilya Kasnacheev пишет:
> Hello!
>
> Is there any option to re-enable linger on SSL sockets?
>
> Telling people to re-configure does not help if they can't.
>
> Regards,

[Anton Vinogradov-2]

Folks,
Seems, we've got an agreement that the fix is necessary.
Do we need to do except the following?
>> zero linger as default + warning on SSL enabled on JVM before the fix +
warning at documentation + migration notes

On Tue, Nov 3, 2020 at 2:38 PM Steshin Vladimir <[hidden email]> wrote:

>      Ilya, hi.
>
>
>      Of course: /TcpDiscoverySpi.setSoLinger(int)/ property. Always been.
>
>
> 02.11.2020 20:14, Ilya Kasnacheev пишет:
> > Hello!
> >
> > Is there any option to re-enable linger on SSL sockets?
> >
> > Telling people to re-configure does not help if they can't.
> >
> > Regards,
>

[Steshin Vladimir]

     The tickets are: [1] disables linger by default and [2] is the doc.


[1] https://issues.apache.org/jira/browse/IGNITE-13643

[2] https://issues.apache.org/jira/browse/IGNITE-13662

05.11.2020 11:00, Anton Vinogradov пишет:

> Folks,
> Seems, we've got an agreement that the fix is necessary.
> Do we need to do except the following?
>>> zero linger as default + warning on SSL enabled on JVM before the fix +
> warning at documentation + migration notes
>
> On Tue, Nov 3, 2020 at 2:38 PM Steshin Vladimir <[hidden email]> wrote:
>
>>       Ilya, hi.
>>
>>
>>       Of course: /TcpDiscoverySpi.setSoLinger(int)/ property. Always been.
>>
>>
>> 02.11.2020 20:14, Ilya Kasnacheev пишет:
>>> Hello!
>>>
>>> Is there any option to re-enable linger on SSL sockets?
>>>
>>> Telling people to re-configure does not help if they can't.
>>>
>>> Regards,

[Anton Vinogradov-2]

PR's merged.
Please make sure that users who use SSL will be notified to set linger at
2.10 migration doc.

On Fri, Nov 6, 2020 at 1:01 PM Steshin Vladimir <[hidden email]> wrote:

>      The tickets are: [1] disables linger by default and [2] is the doc.
>
>
> [1] https://issues.apache.org/jira/browse/IGNITE-13643
>
> [2] https://issues.apache.org/jira/browse/IGNITE-13662
>
> 05.11.2020 11:00, Anton Vinogradov пишет:
> > Folks,
> > Seems, we've got an agreement that the fix is necessary.
> > Do we need to do except the following?
> >>> zero linger as default + warning on SSL enabled on JVM before the fix +
> > warning at documentation + migration notes
> >
> > On Tue, Nov 3, 2020 at 2:38 PM Steshin Vladimir <[hidden email]>
> wrote:
> >
> >>       Ilya, hi.
> >>
> >>
> >>       Of course: /TcpDiscoverySpi.setSoLinger(int)/ property. Always
> been.
> >>
> >>
> >> 02.11.2020 20:14, Ilya Kasnacheev пишет:
> >>> Hello!
> >>>
> >>> Is there any option to re-enable linger on SSL sockets?
> >>>
> >>> Telling people to re-configure does not help if they can't.
> >>>
> >>> Regards,
>