[JBoss JIRA] (WFLY-13941) Failed to persist session attribute with Websocket endpoints
by Abi Sarwan (Jira)
Abi Sarwan created WFLY-13941:
---------------------------------
Summary: Failed to persist session attribute with Websocket endpoints
Key: WFLY-13941
URL: https://issues.redhat.com/browse/WFLY-13941
Project: WildFly
Issue Type: Bug
Components: Web Sockets
Affects Versions: 13.0.0.Final
Reporter: Abi Sarwan
Assignee: Flavia Rainone
Attachments: mavenproject1-1.0.war
When WildFly is configured to persist sessions (standalone mode) during restart/redeploy and contains a websocket endpoint, a NotSerializableException is thrown:
Failed to persist session attribute io.undertow.websocket.current-connections with value [WebSocket13Channel peer /127.0.0.1:64853 local /127.0.0.1:8080[ No Receiver [] -- [] -- []]] for session xxxxxxxx: java.io.NotSerializableException: io.undertow.websockets.core.protocol.version13.WebSocket13Channel
This start to happen in wildfly 13. The deployment works fine in wildfly 12.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[JBoss JIRA] (WFLY-13924) HTTP2 is not working with Oracle JDK8 u261
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/WFLY-13924?page=com.atlassian.jira.plugi... ]
Darran Lofthouse commented on WFLY-13924:
-----------------------------------------
The underlying issue here is the JDK8 ALPN Hack no longer works against 1.8.0_261 with the following error reported:
{code}
2020-10-06 14:46:08,923 DEBUG [io.undertow] (default I/O-3) JDK8 ALPN Hack failed : java.lang.NoSuchFieldException: handshaker
at java.lang.Class.getDeclaredField(Class.java:2070)
at io.undertow.protocols.ssl.ALPNHackSSLEngine.<clinit>(ALPNHackSSLEngine.java:79)
at io.undertow.protocols.alpn.JDK8HackAlpnProvider.isEnabled(JDK8HackAlpnProvider.java:36)
at io.undertow.protocols.alpn.ALPNManager.getProvider(ALPNManager.java:71)
at io.undertow.server.protocol.http.AlpnOpenListener$1.apply(AlpnOpenListener.java:260)
at io.undertow.server.protocol.http.AlpnOpenListener$1.apply(AlpnOpenListener.java:239)
at io.undertow.server.protocol.http.AlpnOpenListener$SSLConduitUpdater.apply(AlpnOpenListener.java:432)
at io.undertow.server.protocol.http.AlpnOpenListener$SSLConduitUpdater.apply(AlpnOpenListener.java:421)
at io.undertow.protocols.alpn.DefaultAlpnEngineManager.registerEngine(DefaultAlpnEngineManager.java:31)
at io.undertow.protocols.alpn.ALPNManager.registerEngineCallback(ALPNManager.java:80)
at io.undertow.server.protocol.http.AlpnOpenListener.handleEvent(AlpnOpenListener.java:239)
at io.undertow.server.protocol.http.AlpnOpenListener.handleEvent(AlpnOpenListener.java:67)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:291)
at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.ChannelListeners$DelegatingChannelListener.handleEvent(ChannelListeners.java:1092)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.nio.QueuedNioTcpServer2.acceptTask(QueuedNioTcpServer2.java:178)
at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:612)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:479
{code}
The property "io.undertow.protocols.alpn.jdk8" works as it allows the JDK9AlpnProvider to operate which used the methods directly but I suspect this workaround is going to then fail once an Elytron SSLContext is used (this example is using one from the legacy security domain).
> HTTP2 is not working with Oracle JDK8 u261
> ------------------------------------------
>
> Key: WFLY-13924
> URL: https://issues.redhat.com/browse/WFLY-13924
> Project: WildFly
> Issue Type: Bug
> Components: Security, Web (Undertow)
> Affects Versions: 20.0.0.Final, 20.0.1.Final, 21.0.0.Beta1
> Reporter: Jan Stourac
> Assignee: Flavia Rainone
> Priority: Critical
> Fix For: 21.0.0.Final
>
>
> There seems to be some problem with HTTP2 support with new Oracle JDK8 u261 and WildFly since {{20.0.0.Final}} version. When request against server is executed, then HTTP2 is not established and communication remains via HTTP/1.1.
> There is no such issue when I use {{WildFly 19.0.0.Final}}. Also, if I switch back to an older Oracle JDK8 u241, there is no such issue even with newer WildFly versions.
> This all seems to be tied with backport of ALPN support into the Oracle JDK8 recently and also work in following issue UNDERTOW-1726.
> There seems to be a workaround available - to define '-Dio.undertow.protocols.alpn.jdk8' during the server startup. With this property configured, the issue seems to disappear (as such, blocker priority of this may be discussed).
> *What is the issue here:*
> This is a change in default behavior of the server (HTTP2 not working with Oracle JDK8u261+ since WildFly 20.0.0.Final). We should try to resolve this without default behavior change if possible. Only in case there is really no other solution, we need to document such thing.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[JBoss JIRA] (WFLY-13924) HTTP2 is not working with Oracle JDK8 u261
by Jan Stourac (Jira)
[ https://issues.redhat.com/browse/WFLY-13924?page=com.atlassian.jira.plugi... ]
Jan Stourac updated WFLY-13924:
-------------------------------
Priority: Critical (was: Blocker)
> HTTP2 is not working with Oracle JDK8 u261
> ------------------------------------------
>
> Key: WFLY-13924
> URL: https://issues.redhat.com/browse/WFLY-13924
> Project: WildFly
> Issue Type: Bug
> Components: Security, Web (Undertow)
> Affects Versions: 20.0.0.Final, 20.0.1.Final, 21.0.0.Beta1
> Reporter: Jan Stourac
> Assignee: Flavia Rainone
> Priority: Critical
> Fix For: 21.0.0.Final
>
>
> There seems to be some problem with HTTP2 support with new Oracle JDK8 u261 and WildFly since {{20.0.0.Final}} version. When request against server is executed, then HTTP2 is not established and communication remains via HTTP/1.1.
> There is no such issue when I use {{WildFly 19.0.0.Final}}. Also, if I switch back to an older Oracle JDK8 u241, there is no such issue even with newer WildFly versions.
> This all seems to be tied with backport of ALPN support into the Oracle JDK8 recently and also work in following issue UNDERTOW-1726.
> There seems to be a workaround available - to define '-Dio.undertow.protocols.alpn.jdk8' during the server startup. With this property configured, the issue seems to disappear (as such, blocker priority of this may be discussed).
> *What is the issue here:*
> This is a change in default behavior of the server (HTTP2 not working with Oracle JDK8u261+ since WildFly 20.0.0.Final). We should try to resolve this without default behavior change if possible. Only in case there is really no other solution, we need to document such thing.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[JBoss JIRA] (JGRP-2504) Poor throughput over high latency TCP connection when recv_buf_size is configured
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2504?page=com.atlassian.jira.plugin... ]
Bela Ban commented on JGRP-2504:
--------------------------------
More Info: http://diag.ddns.net/reports/TCPWindows.html
> Poor throughput over high latency TCP connection when recv_buf_size is configured
> ---------------------------------------------------------------------------------
>
> Key: JGRP-2504
> URL: https://issues.redhat.com/browse/JGRP-2504
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 5.0.0.Final
> Reporter: Andrew Skalski
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 5.1
>
> Attachments: SpeedTest.java, bla5.java, bla6.java, bla7.java, delay-ip.sh
>
>
> I recently finished troubleshooting a unidirectional throughput bottleneck involving a JGroups application (Infinispan) communicating over a high-latency (~45 milliseconds) TCP connection.
> The root cause was JGroups improperly configuring the receive/send buffers on the listening socket. According to the tcp(7) man page:
> {code:java}
> On individual connections, the socket buffer size must be set prior to
> the listen(2) or connect(2) calls in order to have it take effect.
> {code}
> However, JGroups does not set the buffer size on the listening side until after accept().
> The result is poor throughput when sending data from client (connecting side) to server (listening side.) Because the issue is a too-small TCP receive window, throughput is ultimately latency-bound.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[JBoss JIRA] (JGRP-2504) Poor throughput over high latency TCP connection when recv_buf_size is configured
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2504?page=com.atlassian.jira.plugin... ]
Bela Ban commented on JGRP-2504:
--------------------------------
OK, so I read your comment. I understand socket options are inherited, but what sense does SO_SNDBUF make here? This option cannot be set on a ServerSocket anyway (perhaps this can be done in C?), only SO_RCVBUF, so does this mean the send-buffer cannot be set on a socket returned by accept()?
Also:
{quote}
If the application explicitly configures SO_RCVBUF, this automatic management is disabled
{quote}
Does this mean, the value of SO_RCVBUF is the *max* value a receive window can have?
> Poor throughput over high latency TCP connection when recv_buf_size is configured
> ---------------------------------------------------------------------------------
>
> Key: JGRP-2504
> URL: https://issues.redhat.com/browse/JGRP-2504
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 5.0.0.Final
> Reporter: Andrew Skalski
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 5.1
>
> Attachments: SpeedTest.java, bla5.java, bla6.java, bla7.java, delay-ip.sh
>
>
> I recently finished troubleshooting a unidirectional throughput bottleneck involving a JGroups application (Infinispan) communicating over a high-latency (~45 milliseconds) TCP connection.
> The root cause was JGroups improperly configuring the receive/send buffers on the listening socket. According to the tcp(7) man page:
> {code:java}
> On individual connections, the socket buffer size must be set prior to
> the listen(2) or connect(2) calls in order to have it take effect.
> {code}
> However, JGroups does not set the buffer size on the listening side until after accept().
> The result is poor throughput when sending data from client (connecting side) to server (listening side.) Because the issue is a too-small TCP receive window, throughput is ultimately latency-bound.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months