November 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-1132) Only set socket send and receive buffer sizes if it is in the Remoting subsystem configuration

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1132?page=com.atlassian.jira.plugi... ] David Lloyd edited comment on WFCORE-1132 at 11/13/15 9:40 AM: --------------------------------------------------------------- [~andy.miller] You've made the same mistake that I, Jason, and then Brian made. :-) The setting in the Remoting schema is about sizing for NIO ByteBuffers used by Remoting. For this purpose, 8192 is actually an optimal size for these buffers (since they can be filled and emptied using scatter/gather operations). This value never makes its way to a socket option call. It maps to RemotingOptions.[SEND|RECEIVE]_BUFFER_SIZE, whereas the socket options come from org.xnio.Options.[SEND_RECEIVE]_BUFFER. In retrospect I might have chosen less ambiguous names... But in any event, that schema element is a red herring, and we still have failed to reproduce this problem locally. was (Author: dmlloyd): [~anmiller] You've made the same mistake that I, Jason, and then Brian made. :-) The setting in the Remoting schema is about sizing for NIO ByteBuffers used by Remoting. For this purpose, 8192 is actually an optimal size for these buffers (since they can be filled and emptied using scatter/gather operations). This value never makes its way to a socket option call. It maps to RemotingOptions.[SEND|RECEIVE]_BUFFER_SIZE, whereas the socket options come from org.xnio.Options.[SEND_RECEIVE]_BUFFER. In retrospect I might have chosen less ambiguous names... But in any event, that schema element is a red herring, and we still have failed to reproduce this problem locally. > Only set socket send and receive buffer sizes if it is in the Remoting subsystem configuration > ---------------------------------------------------------------------------------------------- > > Key: WFCORE-1132 > URL: https://issues.jboss.org/browse/WFCORE-1132 > Project: WildFly Core > Issue Type: Bug > Affects Versions: 2.0.1.Final > Reporter: Andrig Miller > Priority: Blocker > Fix For: 2.0.2.Final (EAP 7) > > > Original report: > {quote} > In our testing of Wildfy 10 CR4, in the performance lab, we found that one of the differences between EAP 6.4.x and Wildfly 10 was that EAP does not set the socket send and receive buffers. We changed the configuration of Wildfly (Undertow) to remove the buffer parameters from the configuration, and we found that the buffer sizes were still be set to 8k. We hacked XNIO to comment out the setting of these parameters, and latency improved quite a bit. > So, we need a permanent fix so that the socket send and receive buffers are only set, if they are specified in the configuration. > {quote} > This applies to the Remoting subsystem configuration, versions 2.0 and onwards, and also possibly to Undertow, though that subsystem does not appear to use default values. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1132) Only set socket send and receive buffer sizes if it is in the Remoting subsystem configuration

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1132?page=com.atlassian.jira.plugi... ] David Lloyd commented on WFCORE-1132: ------------------------------------- Yeah that's why I'm hoping to either reproduce it locally, or get a stacktrace capture of when that actually happens in XNIO. I guess you could even just jam a log.error(new Throwable(), "") in there. > Only set socket send and receive buffer sizes if it is in the Remoting subsystem configuration > ---------------------------------------------------------------------------------------------- > > Key: WFCORE-1132 > URL: https://issues.jboss.org/browse/WFCORE-1132 > Project: WildFly Core > Issue Type: Bug > Affects Versions: 2.0.1.Final > Reporter: Andrig Miller > Priority: Blocker > Fix For: 2.0.2.Final (EAP 7) > > > Original report: > {quote} > In our testing of Wildfy 10 CR4, in the performance lab, we found that one of the differences between EAP 6.4.x and Wildfly 10 was that EAP does not set the socket send and receive buffers. We changed the configuration of Wildfly (Undertow) to remove the buffer parameters from the configuration, and we found that the buffer sizes were still be set to 8k. We hacked XNIO to comment out the setting of these parameters, and latency improved quite a bit. > So, we need a permanent fix so that the socket send and receive buffers are only set, if they are specified in the configuration. > {quote} > This applies to the Remoting subsystem configuration, versions 2.0 and onwards, and also possibly to Undertow, though that subsystem does not appear to use default values. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1132) Only set socket send and receive buffer sizes if it is in the Remoting subsystem configuration

by Andrig Miller (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1132?page=com.atlassian.jira.plugi... ] Andrig Miller commented on WFCORE-1132: --------------------------------------- So, when we booted Wildfly 10 CR4, and used STRACE we clearly see those send/receive buffer size set, so its happening somewhere, and commenting out the two lines of code in XNIO solved, it, but the logic clearly shows that if those values are not in the OptionMap, they don't get set, so they are being set somewhere above XNIO. > Only set socket send and receive buffer sizes if it is in the Remoting subsystem configuration > ---------------------------------------------------------------------------------------------- > > Key: WFCORE-1132 > URL: https://issues.jboss.org/browse/WFCORE-1132 > Project: WildFly Core > Issue Type: Bug > Affects Versions: 2.0.1.Final > Reporter: Andrig Miller > Priority: Blocker > Fix For: 2.0.2.Final (EAP 7) > > > Original report: > {quote} > In our testing of Wildfy 10 CR4, in the performance lab, we found that one of the differences between EAP 6.4.x and Wildfly 10 was that EAP does not set the socket send and receive buffers. We changed the configuration of Wildfly (Undertow) to remove the buffer parameters from the configuration, and we found that the buffer sizes were still be set to 8k. We hacked XNIO to comment out the setting of these parameters, and latency improved quite a bit. > So, we need a permanent fix so that the socket send and receive buffers are only set, if they are specified in the configuration. > {quote} > This applies to the Remoting subsystem configuration, versions 2.0 and onwards, and also possibly to Undertow, though that subsystem does not appear to use default values. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1132) Only set socket send and receive buffer sizes if it is in the Remoting subsystem configuration

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1132?page=com.atlassian.jira.plugi... ] David Lloyd commented on WFCORE-1132: ------------------------------------- Ah I did "anmiller" and didn't even check the result! Sorry about that. > Only set socket send and receive buffer sizes if it is in the Remoting subsystem configuration > ---------------------------------------------------------------------------------------------- > > Key: WFCORE-1132 > URL: https://issues.jboss.org/browse/WFCORE-1132 > Project: WildFly Core > Issue Type: Bug > Affects Versions: 2.0.1.Final > Reporter: Andrig Miller > Priority: Blocker > Fix For: 2.0.2.Final (EAP 7) > > > Original report: > {quote} > In our testing of Wildfy 10 CR4, in the performance lab, we found that one of the differences between EAP 6.4.x and Wildfly 10 was that EAP does not set the socket send and receive buffers. We changed the configuration of Wildfly (Undertow) to remove the buffer parameters from the configuration, and we found that the buffer sizes were still be set to 8k. We hacked XNIO to comment out the setting of these parameters, and latency improved quite a bit. > So, we need a permanent fix so that the socket send and receive buffers are only set, if they are specified in the configuration. > {quote} > This applies to the Remoting subsystem configuration, versions 2.0 and onwards, and also possibly to Undertow, though that subsystem does not appear to use default values. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1132) Only set socket send and receive buffer sizes if it is in the Remoting subsystem configuration

by Andrig Miller (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1132?page=com.atlassian.jira.plugi... ] Andrig Miller commented on WFCORE-1132: --------------------------------------- Okay, I'm at a loss here, but org.xnio.Options.[SEND_RECEIVE]_BUFFER is what we commented out in XNIO that finally showed that the socket send receive buffers where no longer being set. And by the way, my name is not Andrew, but Andrig ;-) > Only set socket send and receive buffer sizes if it is in the Remoting subsystem configuration > ---------------------------------------------------------------------------------------------- > > Key: WFCORE-1132 > URL: https://issues.jboss.org/browse/WFCORE-1132 > Project: WildFly Core > Issue Type: Bug > Affects Versions: 2.0.1.Final > Reporter: Andrig Miller > Priority: Blocker > Fix For: 2.0.2.Final (EAP 7) > > > Original report: > {quote} > In our testing of Wildfy 10 CR4, in the performance lab, we found that one of the differences between EAP 6.4.x and Wildfly 10 was that EAP does not set the socket send and receive buffers. We changed the configuration of Wildfly (Undertow) to remove the buffer parameters from the configuration, and we found that the buffer sizes were still be set to 8k. We hacked XNIO to comment out the setting of these parameters, and latency improved quite a bit. > So, we need a permanent fix so that the socket send and receive buffers are only set, if they are specified in the configuration. > {quote} > This applies to the Remoting subsystem configuration, versions 2.0 and onwards, and also possibly to Undertow, though that subsystem does not appear to use default values. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1132) Only set socket send and receive buffer sizes if it is in the Remoting subsystem configuration

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1132?page=com.atlassian.jira.plugi... ] David Lloyd commented on WFCORE-1132: ------------------------------------- [~anmiller] You've made the same mistake that I, Jason, and then Brian made. :-) The setting in the Remoting schema is about sizing for NIO ByteBuffers used by Remoting. For this purpose, 8192 is actually an optimal size for these buffers (since they can be filled and emptied using scatter/gather operations). This value never makes its way to a socket option call. It maps to RemotingOptions.[SEND|RECEIVE]_BUFFER_SIZE, whereas the socket options come from org.xnio.Options.[SEND_RECEIVE]_BUFFER. In retrospect I might have chosen less ambiguous names... But in any event, that schema element is a red herring, and we still have failed to reproduce this problem locally. > Only set socket send and receive buffer sizes if it is in the Remoting subsystem configuration > ---------------------------------------------------------------------------------------------- > > Key: WFCORE-1132 > URL: https://issues.jboss.org/browse/WFCORE-1132 > Project: WildFly Core > Issue Type: Bug > Affects Versions: 2.0.1.Final > Reporter: Andrig Miller > Priority: Blocker > Fix For: 2.0.2.Final (EAP 7) > > > Original report: > {quote} > In our testing of Wildfy 10 CR4, in the performance lab, we found that one of the differences between EAP 6.4.x and Wildfly 10 was that EAP does not set the socket send and receive buffers. We changed the configuration of Wildfly (Undertow) to remove the buffer parameters from the configuration, and we found that the buffer sizes were still be set to 8k. We hacked XNIO to comment out the setting of these parameters, and latency improved quite a bit. > So, we need a permanent fix so that the socket send and receive buffers are only set, if they are specified in the configuration. > {quote} > This applies to the Remoting subsystem configuration, versions 2.0 and onwards, and also possibly to Undertow, though that subsystem does not appear to use default values. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (HIBERNATE-152) ServiceRegistry race condition

by rob moffat (JIRA)

rob moffat created HIBERNATE-152: ------------------------------------ Summary: ServiceRegistry race condition Key: HIBERNATE-152 URL: https://issues.jboss.org/browse/HIBERNATE-152 Project: Hibernate Integration Issue Type: Bug Reporter: rob moffat Assignee: Steve Ebersole Priority: Minor If I have multiple threads, all trying to use StatementPreparer, then what happens is that they all get a RefCursorSupport from the service registry, and start using it. The problem is, the initialisation process is: 1) create the instance of RefCursorSupport, 2) add it to the service registry, 3) then initialise the fields on it (specifically, jdbcServices). However, because the object is available from the service registry after creation, but before initialisation, the other threads can pull this back and start using it without jdbcServices initialised. This is a pervasive problem for all the objects in the service registry which have injected services that they depend on, I would think. I'm very surprised this hasn't been spotted sooner and fixed. cheers, Rob -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1132) Only set socket send and receive buffer sizes if it is in the Remoting subsystem configuration

by Andrig Miller (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1132?page=com.atlassian.jira.plugi... ] Andrig Miller commented on WFCORE-1132: --------------------------------------- We just found that the Remoting schema actually has 8192 as a default value. So, its coming from the schema, which is really bad in my opinion. > Only set socket send and receive buffer sizes if it is in the Remoting subsystem configuration > ---------------------------------------------------------------------------------------------- > > Key: WFCORE-1132 > URL: https://issues.jboss.org/browse/WFCORE-1132 > Project: WildFly Core > Issue Type: Bug > Affects Versions: 2.0.1.Final > Reporter: Andrig Miller > Priority: Blocker > Fix For: 2.0.2.Final (EAP 7) > > > Original report: > {quote} > In our testing of Wildfy 10 CR4, in the performance lab, we found that one of the differences between EAP 6.4.x and Wildfly 10 was that EAP does not set the socket send and receive buffers. We changed the configuration of Wildfly (Undertow) to remove the buffer parameters from the configuration, and we found that the buffer sizes were still be set to 8k. We hacked XNIO to comment out the setting of these parameters, and latency improved quite a bit. > So, we need a permanent fix so that the socket send and receive buffers are only set, if they are specified in the configuration. > {quote} > This applies to the Remoting subsystem configuration, versions 2.0 and onwards, and also possibly to Undertow, though that subsystem does not appear to use default values. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5677) Implicitly added resources (no transport, thread pools, etc) should be added by parent add operation instead of the parser

by Radoslav Husar (JIRA)

Radoslav Husar created WFLY-5677: ------------------------------------ Summary: Implicitly added resources (no transport, thread pools, etc) should be added by parent add operation instead of the parser Key: WFLY-5677 URL: https://issues.jboss.org/browse/WFLY-5677 Project: WildFly Issue Type: Bug Components: Clustering Affects Versions: 10.0.0.CR4 Reporter: Radoslav Husar Assignee: Paul Ferraro It looks like in the [infinispan subsystem parser|https://github.com/wildfly/wildfly/blob/master/clustering/infinisp...] some thread pools are explicitly added. This means these resources are not added if adding the subsystem via the {{add}} operation. These resources should be added like any other child resource of the subsystem. If the resources can't be added like that, e.g. they are truly defaults, the add handler for the parent can add a step to check for children and add any missing ones. This would result in the same behavior, but allow the {{add}} operation to work correctly. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5672) Implicitly added resources (no transport, thread pools, etc) should be added by parent add operation instead of the parser

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-5672?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-5672: --------------------------------- Summary: Implicitly added resources (no transport, thread pools, etc) should be added by parent add operation instead of the parser (was: The infinispan parser implicitly adds transport/thread-pools) > Implicitly added resources (no transport, thread pools, etc) should be added by parent add operation instead of the parser > -------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-5672 > URL: https://issues.jboss.org/browse/WFLY-5672 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.0.0.CR4 > Reporter: James Perkins > Assignee: Paul Ferraro > > It looks like in the [infinispan subsystem parser|https://github.com/wildfly/wildfly/blob/master/clustering/infinisp...] some thread pools are explicitly added. This means these resources are not added if adding the subsystem via the {{add}} operation. These resources should be added like any other child resource of the subsystem. > If the resources can't be added like that, e.g. they are truly defaults, the add handler for the parent can add a step to check for children and add any missing ones. This would result in the same behavior, but allow the {{add}} operation to work correctly. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 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 November 2015