October 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (SWSQE-1226) Remove params for HUB, TAG, IMAGE from upstream/downstream where possible

by Filip Brychta (Jira)

Filip Brychta created SWSQE-1226: ------------------------------------ Summary: Remove params for HUB, TAG, IMAGE from upstream/downstream where possible Key: SWSQE-1226 URL: https://issues.redhat.com/browse/SWSQE-1226 Project: Kiali QE Issue Type: QE Task Reporter: Filip Brychta Assignee: Filip Brychta We are always using OLM for downstream job so there is no sense in using HUB/IMAGE/TAG parameters. For upstream job we probably don't need it for istio and jaeger -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1225) External Jaeger SMCP v2

by Filip Brychta (Jira)

Filip Brychta created SWSQE-1225: ------------------------------------ Summary: External Jaeger SMCP v2 Key: SWSQE-1225 URL: https://issues.redhat.com/browse/SWSQE-1225 Project: Kiali QE Issue Type: Sub-task Reporter: Filip Brychta Assignee: Filip Brychta We need to add configuration for external jaeger for API v2 -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[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

1
0
0 / 0

[JBoss JIRA] (WFLY-13940) SingletonDeploymentJBossAllTestCase fails frequently in CI

by Paul Ferraro (Jira)

Paul Ferraro created WFLY-13940: ----------------------------------- Summary: SingletonDeploymentJBossAllTestCase fails frequently in CI Key: WFLY-13940 URL: https://issues.redhat.com/browse/WFLY-13940 Project: WildFly Issue Type: Bug Components: Clustering Affects Versions: 21.0.0.Beta1 Reporter: Paul Ferraro Assignee: Paul Ferraro https://ci.wildfly.org/project.html?projectId=WF_PullRequest&buildTypeId=... -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

[JBoss JIRA] (JGRP-2487) Support TLS in TCP/TCP_NIO

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2487?page=com.atlassian.jira.plugin... ] Bela Ban updated JGRP-2487: --------------------------- Fix Version/s: 5.2 (was: 5.1) > Support TLS in TCP/TCP_NIO > -------------------------- > > Key: JGRP-2487 > URL: https://issues.redhat.com/browse/JGRP-2487 > Project: JGroups > Issue Type: Enhancement > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Major > Fix For: 5.2 > > > Add support for SSLSocketFactory, as well as being able to create our own from a supplied keystore. Transparent support for WildFly OpenSSL should also be added. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[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

1
0
0 / 0

[JBoss JIRA] (WFLY-13938) Upgrade WildFly Core to 13.0.0.Final

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFLY-13938?page=com.atlassian.jira.plugi... ] Jeff Mesnil updated WFLY-13938: ------------------------------- Description: Dev tag: https://github.com/wildfly/wildfly-core/releases/tag/13.0.0.Final Diff to previous integrated released: https://github.com/wildfly/wildfly-core/compare/13.0.0.Beta6...13.0.0.Final > Upgrade WildFly Core to 13.0.0.Final > ------------------------------------ > > Key: WFLY-13938 > URL: https://issues.redhat.com/browse/WFLY-13938 > Project: WildFly > Issue Type: Component Upgrade > Components: Server > Reporter: Brian Stansberry > Assignee: Jeff Mesnil > Priority: Blocker > Fix For: 21.0.0.Final > > > Dev tag: https://github.com/wildfly/wildfly-core/releases/tag/13.0.0.Final > Diff to previous integrated released: https://github.com/wildfly/wildfly-core/compare/13.0.0.Beta6...13.0.0.Final -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira October 2020