You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ignite.apache.org by Steshin Vladimir <vl...@gmail.com> on 2020/10/30 11:04:58 UTC
[DISCUSS] Disable socket linger by default in TCP discovery SPI.
*
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
*
Re: [DISCUSS] Disable socket linger by default in TCP discovery SPI.
Posted by Ivan Daschinsky <iv...@gmail.com>.
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 <il...@gmail.com>:
> 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 <av...@apache.org>:
>
> > > 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 <iv...@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 <av...@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.kasnacheev@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 <vladsz83@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
> > >
> >
>
Re: [DISCUSS] Disable socket linger by default in TCP discovery SPI.
Posted by Anton Vinogradov <av...@apache.org>.
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 <vl...@gmail.com> 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 <vl...@gmail.com>
> 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,
>
Re: [DISCUSS] Disable socket linger by default in TCP discovery SPI.
Posted by Steshin Vladimir <vl...@gmail.com>.
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 <vl...@gmail.com> 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,
Re: [DISCUSS] Disable socket linger by default in TCP discovery SPI.
Posted by Anton Vinogradov <av...@apache.org>.
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 <vl...@gmail.com> 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,
>
Re: [DISCUSS] Disable socket linger by default in TCP discovery SPI.
Posted by Steshin Vladimir <vl...@gmail.com>.
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,
Re: [DISCUSS] Disable socket linger by default in TCP discovery SPI.
Posted by Ilya Kasnacheev <il...@gmail.com>.
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 <av...@apache.org>:
> > 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 <iv...@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 <av...@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.kasnacheev@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 <vl...@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
> >
>
Re: [DISCUSS] Disable socket linger by default in TCP discovery SPI.
Posted by Anton Vinogradov <av...@apache.org>.
> 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 <iv...@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 <av...@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.kasnacheev@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 <vl...@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
>
Re: [DISCUSS] Disable socket linger by default in TCP discovery SPI.
Posted by Ivan Daschinsky <iv...@gmail.com>.
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 <av...@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.kasnacheev@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 <vl...@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
Re: [DISCUSS] Disable socket linger by default in TCP discovery SPI.
Posted by Anton Vinogradov <av...@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 <il...@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 <vl...@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
> >
> > *
> >
>
Re: [DISCUSS] Disable socket linger by default in TCP discovery SPI.
Posted by Ilya Kasnacheev <il...@gmail.com>.
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 <vl...@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
>
> *
>
Re: [DISCUSS] Disable socket linger by default in TCP discovery SPI.
Posted by Ivan Daschinsky <iv...@gmail.com>.
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 <vl...@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