September 2020 - jboss-jira - Jboss List Archives

[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: -------------------------------- I made the following changes: * For TCP, I set the receive buffer size on {{ServerSocket}} _before_ calling {{bind()}}. This should be copied to the sockets received by {{accept()}}. However, I read that this behavior is implementation-dependent * Ditto for TCP_NIO2 and {{ServerSocketChannel}} * {{For }}{{DatagramSocket}} and {{MulticastSocket}}, there is no need to do this, as receive- and send buffer sizes can be set after calling {{bind()}}. Unfortunately, I cannot reproduce this, as I don't have 2 boxes in different geos. Please verify this fix works for you and re-open if needed. I was also under the impression that setting buffer sizes on TCP sockets is only an indication and the OS can choose to ignore this. As TCP adapts the receive-window size dynamically, I'm also a bit surprised that this didn't happen in your case? Perhaps the receive buffer size is the *max size* of the TCP receive window...? > 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)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-5134) AuditLogToTLSSyslogTestCase stucks with oracle JDK 11

by Sonia Zaldana (Jira)

[ https://issues.redhat.com/browse/WFCORE-5134?page=com.atlassian.jira.plug... ] Sonia Zaldana commented on WFCORE-5134: --------------------------------------- Hi [~ropalka], no it doesn't time out. Is there a possibility the regression was introduced in recent JDK builds in that case? > AuditLogToTLSSyslogTestCase stucks with oracle JDK 11 > ----------------------------------------------------- > > Key: WFCORE-5134 > URL: https://issues.redhat.com/browse/WFCORE-5134 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Jean Francois Denise > Priority: Major > > I am using oracle JDK 11, the test get stucks in tear down attempting to execute server tearDown action. I noticed that this test is not run on JDK12 due to a deadlock. The observed problem smells deadlock although jstack doesn't report any. > JDK: > java 11.0.8 2020-07-14 LTS > Java(TM) SE Runtime Environment 18.9 (build 11.0.8+10-LTS) > Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.8+10-LTS, mixed mode) > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-5134) AuditLogToTLSSyslogTestCase stucks with oracle JDK 11

by Richard Opalka (Jira)

[ https://issues.redhat.com/browse/WFCORE-5134?page=com.atlassian.jira.plug... ] Richard Opalka commented on WFCORE-5134: ---------------------------------------- Hello [~szaldana] . Does it fail due to deadlock or not (did it timeout)?. If yes then there is some probability the regression was reintroduced in recent JDK builds. > AuditLogToTLSSyslogTestCase stucks with oracle JDK 11 > ----------------------------------------------------- > > Key: WFCORE-5134 > URL: https://issues.redhat.com/browse/WFCORE-5134 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Jean Francois Denise > Priority: Major > > I am using oracle JDK 11, the test get stucks in tear down attempting to execute server tearDown action. I noticed that this test is not run on JDK12 due to a deadlock. The observed problem smells deadlock although jstack doesn't report any. > JDK: > java 11.0.8 2020-07-14 LTS > Java(TM) SE Runtime Environment 18.9 (build 11.0.8+10-LTS) > Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.8+10-LTS, mixed mode) > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5683) Collection editor not opening for DRL based scenarios

by Yeser Amer (Jira)

[ https://issues.redhat.com/browse/DROOLS-5683?page=com.atlassian.jira.plug... ] Yeser Amer edited comment on DROOLS-5683 at 9/30/20 8:20 AM: ------------------------------------------------------------- Hi [~jstastny], currently BigDecimal and LocalDate time are not supported. There is a BAPL https://issues.redhat.com/browse/BAPL-1721 where it's required to implement LocalDate. Can you please close this one and RHDM as duplicate and update 1721 to include BigDecimal? was (Author: yamer): Hi [~jstastny], currently BigDecimal and LocalDate time are not supported. There is a BAPL https://issues.redhat.com/browse/BAPL-1721 where the it's required to implement LocalDate. Can you please close this one and RHDM as duplicate and update 1721 to include BigDecimal? > Collection editor not opening for DRL based scenarios > ----------------------------------------------------- > > Key: DROOLS-5683 > URL: https://issues.redhat.com/browse/DROOLS-5683 > Project: Drools > Issue Type: Bug > Components: Test Scenarios Editor > Affects Versions: 7.44.0.Final > Reporter: Jan Stastny > Assignee: Yeser Amer > Priority: Major > Attachments: Screenshot from 2020-09-30 13-42-57.png > > > DRL based test scenario throws errors when opening Collection editors for lists of some datatypes (didn't do exhaustive search). > * BigDecimal > * LocalDateTime > Unexpected error appears when opening such cell for editing. > {code} > 2020-09-30 13:44:09,073 ERROR [org.kie.workbench.common.services.backend.logger.GenericErrorLoggerServiceImpl] (default task-13) Error from user: testadmin Error ID: -1734434608 Location: LibraryPerspective|$ProjectScreen,org.kie.workbench.common.screens.messageconsole.MessageConsole,,,Eorg.docks.PlaceHolder?name=testRunnerReportingPanel,Eorg.drools.scenariosimulation.TestTools?scesimeditorid=2,Eorg.drools.scenariosimulation.TestTools?scesimeditorid=3,Eorg.drools.scenariosimulation.TestTools?scesimeditorid=4,Eorg.drools.scenariosimulation.TestTools?scesimeditorid=5,],,,,,AddAssetsScreen,,,ScenarioSimulationEditor?path_uri=default://master@MySpace/test/src/test/resources/com/myspace/test/test2.scesim&file_name=test2.scesim&has_version_support=true Exception: Uncaught exception: (TypeError) : Cannot read property 'j' of null > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5683) Collection editor not opening for DRL based scenarios

by Yeser Amer (Jira)

[ https://issues.redhat.com/browse/DROOLS-5683?page=com.atlassian.jira.plug... ] Yeser Amer commented on DROOLS-5683: ------------------------------------ Hi [~jstastny], currently BigDecimal and LocalDate time are not supported. There is a BAPL https://issues.redhat.com/browse/BAPL-1721 where the it's required to implement LocalDate. Can you please close this one and RHDM as duplicate and update 1721 to include BigDecimal? > Collection editor not opening for DRL based scenarios > ----------------------------------------------------- > > Key: DROOLS-5683 > URL: https://issues.redhat.com/browse/DROOLS-5683 > Project: Drools > Issue Type: Bug > Components: Test Scenarios Editor > Affects Versions: 7.44.0.Final > Reporter: Jan Stastny > Assignee: Yeser Amer > Priority: Major > Attachments: Screenshot from 2020-09-30 13-42-57.png > > > DRL based test scenario throws errors when opening Collection editors for lists of some datatypes (didn't do exhaustive search). > * BigDecimal > * LocalDateTime > Unexpected error appears when opening such cell for editing. > {code} > 2020-09-30 13:44:09,073 ERROR [org.kie.workbench.common.services.backend.logger.GenericErrorLoggerServiceImpl] (default task-13) Error from user: testadmin Error ID: -1734434608 Location: LibraryPerspective|$ProjectScreen,org.kie.workbench.common.screens.messageconsole.MessageConsole,,,Eorg.docks.PlaceHolder?name=testRunnerReportingPanel,Eorg.drools.scenariosimulation.TestTools?scesimeditorid=2,Eorg.drools.scenariosimulation.TestTools?scesimeditorid=3,Eorg.drools.scenariosimulation.TestTools?scesimeditorid=4,Eorg.drools.scenariosimulation.TestTools?scesimeditorid=5,],,,,,AddAssetsScreen,,,ScenarioSimulationEditor?path_uri=default://master@MySpace/test/src/test/resources/com/myspace/test/test2.scesim&file_name=test2.scesim&has_version_support=true Exception: Uncaught exception: (TypeError) : Cannot read property 'j' of null > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13920) Upgrade Hibernate Validator from 6.0.20.Final to 6.0.21.Final

by Ilia Vassilev (Jira)

[ https://issues.redhat.com/browse/WFLY-13920?page=com.atlassian.jira.plugi... ] Ilia Vassilev updated WFLY-13920: --------------------------------- Labels: downstream_dependency (was: ) > Upgrade Hibernate Validator from 6.0.20.Final to 6.0.21.Final > ------------------------------------------------------------- > > Key: WFLY-13920 > URL: https://issues.redhat.com/browse/WFLY-13920 > Project: WildFly > Issue Type: Component Upgrade > Components: Build System > Reporter: Ilia Vassilev > Assignee: Ilia Vassilev > Priority: Major > Labels: downstream_dependency > > Tag: https://github.com/hibernate/hibernate-validator/releases/tag/6.0.21.Final > Diff: https://github.com/hibernate/hibernate-validator/compare/6.0.20.Final...6... > Commit hash: https://github.com/hibernate/hibernate-validator/commit/35a3544d6d62abf6d... -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13920) Upgrade Hibernate Validator from 6.0.20.Final to 6.0.21.Final

by Ilia Vassilev (Jira)

[ https://issues.redhat.com/browse/WFLY-13920?page=com.atlassian.jira.plugi... ] Ilia Vassilev moved JBEAP-20278 to WFLY-13920: ---------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-13920 (was: JBEAP-20278) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Build System (was: Build System) Affects Version/s: (was: 7.3.3.GA) Fix Version/s: (was: 7.3.4.GA) > Upgrade Hibernate Validator from 6.0.20.Final to 6.0.21.Final > ------------------------------------------------------------- > > Key: WFLY-13920 > URL: https://issues.redhat.com/browse/WFLY-13920 > Project: WildFly > Issue Type: Component Upgrade > Components: Build System > Reporter: Ilia Vassilev > Assignee: Ilia Vassilev > Priority: Major > > Tag: https://github.com/hibernate/hibernate-validator/releases/tag/6.0.21.Final > Diff: https://github.com/hibernate/hibernate-validator/compare/6.0.20.Final...6... > Commit hash: https://github.com/hibernate/hibernate-validator/commit/35a3544d6d62abf6d... -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5683) Collection editor not opening for DRL based scenarios

by Jan Stastny (Jira)

Jan Stastny created DROOLS-5683: ----------------------------------- Summary: Collection editor not opening for DRL based scenarios Key: DROOLS-5683 URL: https://issues.redhat.com/browse/DROOLS-5683 Project: Drools Issue Type: Bug Components: Test Scenarios Editor Affects Versions: 7.44.0.Final Reporter: Jan Stastny Assignee: Yeser Amer Attachments: Screenshot from 2020-09-30 13-42-57.png DRL based test scenario throws errors when opening Collection editors for lists of some datatypes (didn't do exhaustive search). * BigDecimal * LocalDateTime Unexpected error appears when opening such cell for editing. {code} 2020-09-30 13:44:09,073 ERROR [org.kie.workbench.common.services.backend.logger.GenericErrorLoggerServiceImpl] (default task-13) Error from user: testadmin Error ID: -1734434608 Location: LibraryPerspective|$ProjectScreen,org.kie.workbench.common.screens.messageconsole.MessageConsole,,,Eorg.docks.PlaceHolder?name=testRunnerReportingPanel,Eorg.drools.scenariosimulation.TestTools?scesimeditorid=2,Eorg.drools.scenariosimulation.TestTools?scesimeditorid=3,Eorg.drools.scenariosimulation.TestTools?scesimeditorid=4,Eorg.drools.scenariosimulation.TestTools?scesimeditorid=5,],,,,,AddAssetsScreen,,,ScenarioSimulationEditor?path_uri=default://master@MySpace/test/src/test/resources/com/myspace/test/test2.scesim&file_name=test2.scesim&has_version_support=true Exception: Uncaught exception: (TypeError) : Cannot read property 'j' of null {code} -- 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 edited comment on JGRP-2504 at 9/30/20 7:35 AM: --------------------------------------------------------- The attached {{bla5.java}} shows the issue: when line 22 is commented, the receive buffer is not as big as desired. Ditto for {{bla6.java}}, which shows how to do this with ServerSocketChannels. {{bla7}} shows datagram channels. was (Author: belaban): The attached {{bla5.java}} shows the issue: when line 22 is commented, the receive buffer is not as big as desired. Ditto for {{bla6.java}}, which shows how to do this with ServerSocketChannels. > 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)

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 updated JGRP-2504: --------------------------- Attachment: bla7.java > 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)

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 September 2020