[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 updated JGRP-2504:
---------------------------
Fix Version/s: 5.1
> 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
>
>
> 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, 12 months
[JBoss JIRA] (JGRP-2504) Poor throughput over high latency TCP connection when recv_buf_size is configured
by Andrew Skalski (Jira)
Andrew Skalski created JGRP-2504:
------------------------------------
Summary: 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
Attachments: SpeedTest.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, 12 months
[JBoss JIRA] (WFLY-13897) infinispan-server instances provisioned by testsuite never shutdown
by Radoslav Husar (Jira)
[ https://issues.redhat.com/browse/WFLY-13897?page=com.atlassian.jira.plugi... ]
Radoslav Husar edited comment on WFLY-13897 at 9/29/20 1:47 PM:
----------------------------------------------------------------
There seem to be couple of problems at play here:
1. The graceful shutdown doesn't work because the client doesn't authenticate, because there is no such configuration - Jira TBA.
2. When graceful shutdown doesn't success, PID is not obtained on JDK8 – also caused by ISPN-12366.
3. When PID is obtained on JDK11, the kill command is incorrect.
4. If that is fixed - the kill command only kills the parent process (sh) and not the child process (java = the server).
was (Author: rhusar):
There seem to be couple of problems at play here:
1. The graceful shutdown doesn't work because the client doesn't authenticate, because there is no such configuration - Jira TBA.
2. When graceful shutdown doesn't success, PID is not obtained on JDK8 – also caused by ISPN-12366.
3. When PID is obtained on JDK11, the kill command is incorrect.
4. If that is fixed - the kill command only kills the parent process and not the child process.
> infinispan-server instances provisioned by testsuite never shutdown
> -------------------------------------------------------------------
>
> Key: WFLY-13897
> URL: https://issues.redhat.com/browse/WFLY-13897
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Test Suite
> Affects Versions: 21.0.0.Beta1
> Reporter: Paul Ferraro
> Assignee: Radoslav Husar
> Priority: Critical
>
> Running the clustering testsuite locally leaves 9 instances of infinispan-server running. This wreaks havoc on the CI, which will remain running until the VM shuts down.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 12 months
[JBoss JIRA] (WFLY-13897) infinispan-server instances provisioned by testsuite never shutdown
by Radoslav Husar (Jira)
[ https://issues.redhat.com/browse/WFLY-13897?page=com.atlassian.jira.plugi... ]
Radoslav Husar commented on WFLY-13897:
---------------------------------------
There seem to be couple of problems at play here:
1. The graceful shutdown doesn't work because the client doesn't authenticate, because there is no such configuration - Jira TBA.
2. When graceful shutdown doesn't success, PID is not obtained on JDK8 – also caused by ISPN-12366.
3. When PID is obtained on JDK11, the kill command is incorrect.
4. If that is fixed - the kill command only kills the parent process and not the child process.
> infinispan-server instances provisioned by testsuite never shutdown
> -------------------------------------------------------------------
>
> Key: WFLY-13897
> URL: https://issues.redhat.com/browse/WFLY-13897
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Test Suite
> Affects Versions: 21.0.0.Beta1
> Reporter: Paul Ferraro
> Assignee: Radoslav Husar
> Priority: Critical
>
> Running the clustering testsuite locally leaves 9 instances of infinispan-server running. This wreaks havoc on the CI, which will remain running until the VM shuts down.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 12 months
[JBoss JIRA] (WFLY-13897) infinispan-server instances provisioned by testsuite never shutdown
by Radoslav Husar (Jira)
[ https://issues.redhat.com/browse/WFLY-13897?page=com.atlassian.jira.plugi... ]
Radoslav Husar commented on WFLY-13897:
---------------------------------------
There are other processes leaking as well, I see after running the suite:
{noformat}
51983 s002 S 0:00.00 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
52246 s002 S 0:00.01 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
52953 s002 S 0:00.01 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
53280 s002 S 0:00.01 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
53924 s002 S 0:00.01 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
54540 s002 S 0:00.00 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
54937 s002 S 0:00.00 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
55246 s002 S 0:00.01 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
55874 s002 S 0:00.01 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
73893 s002 S 0:00.00 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
74090 s002 S 0:00.00 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
74345 s002 S 0:00.01 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
77211 s002 S 0:00.00 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
77571 s002 S 0:00.00 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
78067 s002 S 0:00.01 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
78473 s002 S 0:00.01 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
83664 s002 S 0:00.01 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
84044 s002 S 0:00.01 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
84562 s002 S 0:00.01 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
85278 s002 S 0:00.01 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
86133 s002 S 0:00.01 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
87041 s002 S 0:00.01 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
96331 s002 S 0:00.00 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
96494 s002 S 0:00.01 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
96731 s002 S 0:00.01 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
96924 s002 S 0:00.01 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
97239 s002 S 0:00.01 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
97656 s002 S 0:00.01 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
97932 s002 S 0:00.01 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
98136 s002 S 0:00.01 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
98458 s002 S 0:00.01 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
{noformat}
> infinispan-server instances provisioned by testsuite never shutdown
> -------------------------------------------------------------------
>
> Key: WFLY-13897
> URL: https://issues.redhat.com/browse/WFLY-13897
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Test Suite
> Affects Versions: 21.0.0.Beta1
> Reporter: Paul Ferraro
> Assignee: Radoslav Husar
> Priority: Critical
>
> Running the clustering testsuite locally leaves 9 instances of infinispan-server running. This wreaks havoc on the CI, which will remain running until the VM shuts down.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 12 months
[JBoss JIRA] (DROOLS-5682) Forall with empty list constraint combined with or does not fire as expected
by Mario Fusco (Jira)
[ https://issues.redhat.com/browse/DROOLS-5682?page=com.atlassian.jira.plug... ]
Mario Fusco updated DROOLS-5682:
--------------------------------
Sprint: 2020 Week 40-42 (from Sep 28)
> Forall with empty list constraint combined with or does not fire as expected
> ----------------------------------------------------------------------------
>
> Key: DROOLS-5682
> URL: https://issues.redhat.com/browse/DROOLS-5682
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.32.0.Final, 7.33.0.Final, 7.34.0.Final, 7.35.0.Final, 7.36.0.Final, 7.37.0.Final, 7.38.0.Final, 7.39.0.Final, 7.40.0.Final, 7.41.0.Final, 7.42.0.Final, 7.43.0.Final
> Reporter: Matteo Casalino
> Assignee: Mario Fusco
> Priority: Major
> Attachments: forall-with-empty-list-constraint-combined-with-or.zip
>
>
> As of Drools {{7.32.0.Final}}, {{forall}} patterns with "empty list" constraints combined with other constraints through {{||}} will fail to match as expected.
> For example the following rule:
> {noformat}
> rule "forall with not equal"
> when forall($p : Pojo(y == 1)
> Pojo(x.empty || x contains 2, z == 3, this == $p))
> then
> end
> {noformat}
> will not fire against following facts:
> {noformat}
> Pojo{x=[2], y=0, z=0}
> Pojo{x=[], y=1, z=3}
> Pojo{x=[3], y=0, z=3}
> Pojo{x=[2], y=1, z=3}
> {noformat}
> We suspect a problem with the rewriting of the {{forall}} clause. It appears the clause is rewritten as:
> {{not Pojo(y == 1, (x.empty && !(x contains 2)) || !(z == 3))}}
> instead of the expected:
> {{not Pojo(y == 1, (!(x.empty) && !(x contains 2)) || !(z == 3))}}
> This is working fine when using Drools {{<= 7.31.0.Final}}.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 12 months
[JBoss JIRA] (DROOLS-5681) ByteArrayResource bytes attribute read/write twice
by Mario Fusco (Jira)
[ https://issues.redhat.com/browse/DROOLS-5681?page=com.atlassian.jira.plug... ]
Mario Fusco updated DROOLS-5681:
--------------------------------
Sprint: 2020 Week 40-42 (from Sep 28)
> ByteArrayResource bytes attribute read/write twice
> --------------------------------------------------
>
> Key: DROOLS-5681
> URL: https://issues.redhat.com/browse/DROOLS-5681
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.43.1.Final
> Reporter: Sylvain Lemoine
> Assignee: Mario Fusco
> Priority: Major
>
> When using Java standard serialization mechanism, we can see that ByteArrayResource is now written twice
> in ByteArrayResource
> {code:java}
> @Override
> public void writeExternal(ObjectOutput out) throws IOException {
> super.writeExternal( out );
> out.writeObject( bytes );
> out.writeObject(this.encoding);
> }{code}
> And super class writeExternal:
> {code:java}
> public void writeExternal(ObjectOutput out) throws IOException {
> //...
> out.writeObject( bytes );
> }{code}
> It works as it also read twice in ByteArrayResource#readExternal and ByteArrayResource#readExternal.
> Anyway, moving the bytes attribute from child class to super class in [bb5e421df|https://github.com/kiegroup/drools/commit/bb5e421df8950cb23... broke our project serialization as we rely on java serialization for our KieBase resources. Seems ok as we'll address it by some tweaking on serialVersionUID, but fixing this issue (read/write once instead of twice) will also break deserialization for projects which rely on it from 7.34.0.Final.
> Don't know if it's ok to fix it in the next version. I can make a PR for this case.
>
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 12 months
[JBoss JIRA] (WFLY-13915) JAXRS Client Quickstart arquilian tests missing commons-logging
by Eduardo Martins (Jira)
Eduardo Martins created WFLY-13915:
--------------------------------------
Summary: JAXRS Client Quickstart arquilian tests missing commons-logging
Key: WFLY-13915
URL: https://issues.redhat.com/browse/WFLY-13915
Project: WildFly
Issue Type: Bug
Components: Quickstarts
Affects Versions: 20.0.1.Final
Reporter: Eduardo Martins
Assignee: Eduardo Martins
There are errors when running arquillian tests in JAXRS Client quickstart, due to missing dependency on Apache Commons Logging:
{code}
[ERROR] Tests run: 5, Failures: 0, Errors: 5, Skipped: 0, Time elapsed: 1.853 s <<< FAILURE! - in org.jboss.as.quickstarts.jaxrsclient.test.ContactsRestClientIT
[ERROR] requestResponseFiltersTest(org.jboss.as.quickstarts.jaxrsclient.test.ContactsRestClientIT) Time elapsed: 0.186 s <<< ERROR!
java.lang.NoClassDefFoundError: org/apache/commons/logging/LogFactory
at org.jboss.as.quickstarts.jaxrsclient.test.ContactsRestClientIT.requestResponseFiltersTest(ContactsRestClientIT.java:218)
Caused by: java.lang.ClassNotFoundException: org.apache.commons.logging.LogFactory
at org.jboss.as.quickstarts.jaxrsclient.test.ContactsRestClientIT.requestResponseFiltersTest(ContactsRestClientIT.java:218)
[ERROR] delayedInvocationTest(org.jboss.as.quickstarts.jaxrsclient.test.ContactsRestClientIT) Time elapsed: 0.014 s <<< ERROR!
java.lang.NoClassDefFoundError: org/apache/commons/logging/LogFactory
at org.jboss.as.quickstarts.jaxrsclient.test.ContactsRestClientIT.delayedInvocationTest(ContactsRestClientIT.java:183)
[ERROR] asyncCrudTest(org.jboss.as.quickstarts.jaxrsclient.test.ContactsRestClientIT) Time elapsed: 0.014 s <<< ERROR!
java.lang.NoClassDefFoundError: org/apache/commons/logging/LogFactory
at org.jboss.as.quickstarts.jaxrsclient.test.ContactsRestClientIT.asyncCrudTest(ContactsRestClientIT.java:118)
[ERROR] invocationCallBackTest(org.jboss.as.quickstarts.jaxrsclient.test.ContactsRestClientIT) Time elapsed: 0.015 s <<< ERROR!
java.lang.NoClassDefFoundError: org/apache/commons/logging/LogFactory
at org.jboss.as.quickstarts.jaxrsclient.test.ContactsRestClientIT.invocationCallBackTest(ContactsRestClientIT.java:151)
[ERROR] cruedTest(org.jboss.as.quickstarts.jaxrsclient.test.ContactsRestClientIT) Time elapsed: 0.013 s <<< ERROR!
java.lang.NoClassDefFoundError: org/apache/commons/logging/LogFactory
at org.jboss.as.quickstarts.jaxrsclient.test.ContactsRestClientIT.cruedTest(ContactsRestClientIT.java:79)
{code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 12 months