September 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-12461) Can't use smallrye-health without weld extension

by Florian Sailer (Jira)

Florian Sailer created WFLY-12461: ------------------------------------- Summary: Can't use smallrye-health without weld extension Key: WFLY-12461 URL: https://issues.jboss.org/browse/WFLY-12461 Project: WildFly Issue Type: Bug Components: MP Health Affects Versions: 17.0.1.Final Reporter: Florian Sailer Assignee: Jeff Mesnil Since this commit in the smallrye implementation it was possible to use smallrye without CDI. https://github.com/smallrye/smallrye-health/commit/a6a7812877d74d2c3f5b29... I'm trying to migrate from Wildfly 15.0.1-Final to 17.0.1-Final, where the smallrye-health extension unfortunately needs weld to startup. It's not possbible for me to activate weld on my sever, because there are some problems using the org.apache.cxf.jaxrs framework with weld. I am getting the following exception while starting: 14:16:04,960 ERROR [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0362: Capabilities required by resource '/subsystem=microprofile-health-smallrye' are not available: org.wildfly.weld; There are no known registration points which can provide this capability. -- This message was sent by Atlassian Jira (v7.13.5#713005)

1 year, 2 months

2
1
0 / 0

[JBoss JIRA] (WFLY-13922) Upgrade RESTEasy to 3.13.2.Final

by Ronald Sigal (Jira)

Ronald Sigal created WFLY-13922: ----------------------------------- Summary: Upgrade RESTEasy to 3.13.2.Final Key: WFLY-13922 URL: https://issues.redhat.com/browse/WFLY-13922 Project: WildFly Issue Type: Component Upgrade Components: REST Reporter: Ronald Sigal Assignee: Ronald Sigal Fix For: 21.0.0.Beta1 Upgrade from 3.11.2.Final to 3.12.0.Final -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13828) remote+tls is not supported by EJBClient and remote-outbound-connection

by Ranabir Chakraborty (Jira)

[ https://issues.redhat.com/browse/WFLY-13828?page=com.atlassian.jira.plugi... ] Ranabir Chakraborty updated WFLY-13828: --------------------------------------- Git Pull Request: https://github.com/wildfly/wildfly-core/pull/4349, https://github.com/wildfly/jboss-ejb-client/pull/475 > remote+tls is not supported by EJBClient and remote-outbound-connection > ----------------------------------------------------------------------- > > Key: WFLY-13828 > URL: https://issues.redhat.com/browse/WFLY-13828 > Project: WildFly > Issue Type: Bug > Components: Remoting > Affects Versions: 20.0.1.Final > Reporter: Matthias Großmann > Assignee: Ranabir Chakraborty > Priority: Major > > Hi, > in our company we would like to use the newest Wildfly together with legacy servers like JBoss AS 7 over SSL. > This is possible with the Uri scheme "remote+tls" provided by jboss-remoting > https://github.com/jboss-remoting/jboss-remoting/blob/master/src/main/jav... > {code:java} > final RemoteConnectionProviderFactory remoteConnectionProviderFactory = new RemoteConnectionProviderFactory(); > ... > endpoint.addConnectionProvider("remote+tls", remoteConnectionProviderFactory, OptionMap.create(Options.SECURE, Boolean.TRUE)); > {code} > But that uri scheme is not supported by the jboss-ejb-client in current version > https://github.com/wildfly/jboss-ejb-client/blob/master/src/main/java/org... > {code} > public boolean supportsProtocol(final String uriScheme) { > switch (uriScheme) { > case "remote": > case "remote+http": > case "remote+https": > // compatibility > case "remoting": > case "http-remoting": > case "https-remoting": { > return true; > } > default: { > return false; > } > } > } > {code} > and also the remote-outbound-connection does not allow that protocol: > https://github.com/wildfly/wildfly-core/blob/master/remoting/subsystem/sr... > {code} > public enum Protocol { > REMOTE("remote"), > REMOTE_HTTP("remote+http"), > HTTP_REMOTING("http-remoting"), > HTTPS_REMOTING("https-remoting"), > REMOTE_HTTPS("remote+https"); > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13917) RESTEasy requires Bouncy Castle for multipart/signed resources

by James Perkins (Jira)

[ https://issues.redhat.com/browse/WFLY-13917?page=com.atlassian.jira.plugi... ] James Perkins updated WFLY-13917: --------------------------------- Description: The various {{multipart/signed}} providers require the Bouncy Castle modules. While these are currently set as module dependencies on the {{org.jboss.resteasy.resteasy-crypto}} module they need to be added to the deployment as they may be required during processing the deployment. (was: The various {{multipart/signed}} providers require the Bouncy Castle modules. While these are currently set as modules they need to be added to the deployment as they may be required there.) > RESTEasy requires Bouncy Castle for multipart/signed resources > -------------------------------------------------------------- > > Key: WFLY-13917 > URL: https://issues.redhat.com/browse/WFLY-13917 > Project: WildFly > Issue Type: Bug > Components: REST > Reporter: James Perkins > Assignee: James Perkins > Priority: Major > > The various {{multipart/signed}} providers require the Bouncy Castle modules. While these are currently set as module dependencies on the {{org.jboss.resteasy.resteasy-crypto}} module they need to be added to the deployment as they may be required during processing the deployment. -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2504) Poor throughput over high latency TCP connection when recv_buf_size is configured

by Andrew Skalski (Jira)

[ https://issues.redhat.com/browse/JGRP-2504?page=com.atlassian.jira.plugin... ] Andrew Skalski updated JGRP-2504: --------------------------------- Attachment: delay-ip.sh > 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)

3 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2504) Poor throughput over high latency TCP connection when recv_buf_size is configured

by Andrew Skalski (Jira)

[ https://issues.redhat.com/browse/JGRP-2504?page=com.atlassian.jira.plugin... ] Andrew Skalski reopened JGRP-2504: ---------------------------------- > 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)

3 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2504) Poor throughput over high latency TCP connection when recv_buf_size is configured

by Andrew Skalski (Jira)

[ https://issues.redhat.com/browse/JGRP-2504?page=com.atlassian.jira.plugin... ] Andrew Skalski commented on JGRP-2504: -------------------------------------- This change doesn't appear to be working yet. I looked at what it's doing using strace: {code:java} $ strace -f -o strace.out java -Djgroups.tcpping.initial_hosts=jgroups-west[7800],jgroups-east[7800] -cp jgroups-5.1.0.Alpha1-SNAPSHOT.jar:. SpeedTest <<< quit{code} The receive buffer is still not being configured ahead of bind/listen: {code:java} 7241 socket(AF_INET6, SOCK_STREAM, IPPROTO_IP) = 9 7241 setsockopt(9, SOL_IPV6, IPV6_V6ONLY, [0], 4) = 0 7241 fcntl(9, F_GETFL) = 0x2 (flags O_RDWR) 7241 fcntl(9, F_SETFL, O_RDWR|O_NONBLOCK) = 0 7241 setsockopt(9, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 7241 pread64(4, "\312\376\272\276\0\0\0007\0W\n\0002\0003\t\0\4\0004\v\0005\0006\7\0007\n\08\0"..., 1918, 9994511) = 1918 7241 pread64(4, "\312\376\272\276\0\0\0007\0/\n\0\10\0$\t\0\7\0%\n\0\t\0&\n\0\t\0'\7\0"..., 985, 16509997) = 985 7241 pread64(4, "\312\376\272\276\0\0\0007\1]\n\0Y\0\272\n\0\273\0\274\10\0\275\n\0}\0\276\t\0\30\0"..., 7728, 16686562) = 7728 7241 pread64(4, "\312\376\272\276\0\0\0007\0\33\n\0\3\0\26\7\0\27\7\0\30\1\0\6<init>\1\0"..., 536, 16509461) = 536 7241 bind(9, {sa_family=AF_INET6, sin6_port=htons(7800), inet_pton(AF_INET6, "::ffff:69.164.216.53", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, 28) = 0 7241 listen(9, 50) = 0 {code} Looking at the code, note [this section|https://github.com/belaban/JGroups/blob/master/src/org/jgroups/pr...]; the TcpServer constructor (which tries to pass recv_buf_size along to Util.createServerSocket) is run before recv_buf_size is set. Addressing the question of why the buffer size needs to be configured on the listening socket (rather than the accepted socket): Although I haven't yet read through the kernel sources to fully understand what's going on, I believe at least part of it has to do with negotiating the window scaling TCP option, which happens during connection handshake. By the way, if you don't have two geographically separated servers, you can create artificial latency using the Linux Netem module. (The kernel module name is sch_netem and is included in the kernel-modules-extra RPM; you will also need the iproute-tc RPM.) The syntax is arcane, so I will attach a shell script to this ticket. One other thing: I'm not sure where's the best place to report this, but the "Bug Reports" page on jgroups.org links to an old Jira URL at jira.jboss.com that no longer works. > 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 > > > 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)

3 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-5133) SNICombinedWithALPNTestCase fails with oracle JDK 8 261

by James Perkins (Jira)

[ https://issues.redhat.com/browse/WFCORE-5133?page=com.atlassian.jira.plug... ] James Perkins commented on WFCORE-5133: --------------------------------------- [~szaldana] The NPE looks to be a race condition somewhere. I don't think it's related to UNDERTOW-1726. Why passing {{io.undertow.protocols.alpn.jdk8}} seems to change the error is very strange, but doesn't change which ALPN provider is used. In call cases, with or without the property, ALPN is not used because the [{{ALPNHackSSLEngine}}|https://github.com/undertow-io/undertow/blob/0a0fcefe1003db45b65d35e9b8faa0c611f2dbf5/core/src/main/java/io/undertow/protocols/ssl/ALPNHackSSLEngine.java#L79] test fails with finding the {{handshaker}} field. There is no source for this in the Oracle JDK so I'm not sure what has changed. > SNICombinedWithALPNTestCase fails with oracle JDK 8 261 > ------------------------------------------------------- > > Key: WFCORE-5133 > URL: https://issues.redhat.com/browse/WFCORE-5133 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Jean Francois Denise > Assignee: Sonia Zaldana > Priority: Major > > Exception while using oracle JDK 261: > > {code} > at io.undertow.client.http.HttpClientConnection.handleError(HttpClientConnection.java:444) > at io.undertow.client.http.HttpClientConnection.handleError(HttpClientConnection.java:439) > at io.undertow.client.http.HttpClientConnection.initiateRequest(HttpClientConnection.java:430) > at io.undertow.client.http.HttpClientConnection.sendRequest(HttpClientConnection.java:347) > at org.jboss.as.test.integration.security.ssl.sni.SNICombinedWithALPNTestCase.performSimpleTest(SNICombinedWithALPNTestCase.java:242) > at org.jboss.as.test.integration.security.ssl.sni.SNICombinedWithALPNTestCase.testSimpleViaHostname(SNICombinedWithALPNTestCase.java:220) > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13866) Several traces created in Jaeger for just one method call

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-13866?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFLY-13866: ------------------------------------ Fix Version/s: (was: 21.0.0.Final) > Several traces created in Jaeger for just one method call > --------------------------------------------------------- > > Key: WFLY-13866 > URL: https://issues.redhat.com/browse/WFLY-13866 > Project: WildFly > Issue Type: Bug > Components: MP OpenTracing > Affects Versions: 21.0.0.Beta1 > Reporter: Fabio Burzigotti > Assignee: Emmanuel Hugonnet > Priority: Critical > > I am migrating one opentracing/fault-tolerance test from Thorntail TS [1] and I noticed that Wildfly SNAPSHOT is behaving differently with respect to what in the subject. > The test is pretty simple, deploying a REST app which makes use of injected service which in turn leverages microprofile opentracing (via API) and fault-tolerance (via annotations). The test executes the following 2 methods in the given order: > - call {{hello}}, which is synchronous and is throwing an exception, hence failing and gets called again then ending up with the fallback. This generates 1 trace with 4 spans in Jaeger and the behavior is consistent between TT and WildFly > - call {{helloAsync}}, which is asynchronous and is throwing an exception, hence failing and getting called again (asynchronously?) then ending up with the fallback. This generates the following traces in Jaeger: > TT: 1 trace with 4 spans > WildFly: 4 separate traces , i.e. the one for the REST endpoint GET method, two for the {{helloAsync}} calls and one for the fallback. > [1] > https://github.com/rhoar-qe/thorntail-test-suite/tree/master/microprofile... -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13921) MP Fault Tolerance integration with MP Context Propagation

by Radoslav Husar (Jira)

[ https://issues.redhat.com/browse/WFLY-13921?page=com.atlassian.jira.plugi... ] Radoslav Husar updated WFLY-13921: ---------------------------------- Description: Once MP Context Propagation makes it to WildFly (or even now if provisioned by a feature pack) we need to integrate Fault Tolerance to make use of it when provisioned. Goes without saying this needs test coverage. (was: Once MP Context Propagation makes it to WildFly (or even now if provisioned by a feature pack) we need to integrate Fault Tolerance to make use of it when provisioned.) > MP Fault Tolerance integration with MP Context Propagation > ---------------------------------------------------------- > > Key: WFLY-13921 > URL: https://issues.redhat.com/browse/WFLY-13921 > Project: WildFly > Issue Type: Feature Request > Components: MP Fault Tolerance > Affects Versions: 21.0.0.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Major > > Once MP Context Propagation makes it to WildFly (or even now if provisioned by a feature pack) we need to integrate Fault Tolerance to make use of it when provisioned. Goes without saying this needs test coverage. -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 6 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira September 2020