[JBoss JIRA] (DROOLS-3944) DMN Editor: Data type usability study
by Elizabeth Clayton (Jira)
[ https://issues.jboss.org/browse/DROOLS-3944?page=com.atlassian.jira.plugi... ]
Elizabeth Clayton updated DROOLS-3944:
--------------------------------------
Sprint: 2019 Week 23-25
> DMN Editor: Data type usability study
> -------------------------------------
>
> Key: DROOLS-3944
> URL: https://issues.jboss.org/browse/DROOLS-3944
> Project: Drools
> Issue Type: Task
> Components: DMN Editor
> Environment: Version 7.4
> Reporter: Elizabeth Clayton
> Assignee: Sarahjane Clark
> Priority: Major
> Labels: UX, UXTeam, Usability, drools-tools
>
> Lightweight usability study to test the ease of use in viewing, creating, editing and deleting data types, particularly structured data types.
> GOALS: Access the Data Type editor in terms of productivity and usability.
> * Ease of use when creating a complex type (concern: minimizing the mouse usage.)
> * Ease of use when saving a basic data type (e.g. age: number)
> * Discoverability of actions in the kebab menu, especially, insert nested, delete.
> * Ease of use/accuracy: Type-ahead of the data type selector.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
1 month, 1 week
[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, 7 months
[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)
4 years
[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)
4 years
[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)
4 years
[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)
4 years
[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)
4 years
[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)
4 years