[JBoss JIRA] (WFCORE-1132) Only set socket send and receive buffer sizes if it is in the configuration
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1132?page=com.atlassian.jira.plugi... ]
David Lloyd updated WFCORE-1132:
--------------------------------
Fix Version/s: 2.0.2.Final (EAP 7)
> Only set socket send and receive buffer sizes if it is in the configuration
> ---------------------------------------------------------------------------
>
> Key: WFCORE-1132
> URL: https://issues.jboss.org/browse/WFCORE-1132
> Project: WildFly Core
> Issue Type: Bug
> Components: Remoting
> Affects Versions: 2.0.1.Final
> Reporter: Andrig Miller
> Priority: Blocker
> Fix For: 2.0.2.Final (EAP 7)
>
>
> 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.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[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 updated WFCORE-1132:
--------------------------------
Summary: Only set socket send and receive buffer sizes if it is in the Remoting subsystem configuration (was: Only set socket send and receive buffer sizes if it is in the configuration)
> 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
> Components: Remoting
> Affects Versions: 2.0.1.Final
> Reporter: Andrig Miller
> Priority: Blocker
> Fix For: 2.0.2.Final (EAP 7)
>
>
> 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.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFCORE-1132) Only set socket send and receive buffer sizes if it is in the configuration
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1132?page=com.atlassian.jira.plugi... ]
David Lloyd commented on WFCORE-1132:
-------------------------------------
The "receive-buffer-size" and "send-buffer-size" management attributes have a default value of 8192 (bytes) as of 2.0 of the subsystem (that is, since WildFly 8 onwards). This is obviously a very poor default. On my system at least, the default buffer sizes are nearer to 100s of kilobytes.
The performance team argues that there should be no default, letting the OS choose. I'm okay with that, and I'm also okay with changing the default to something more sensible in the 128k range, depending on what works best for compatibility, etc.
> Only set socket send and receive buffer sizes if it is in the configuration
> ---------------------------------------------------------------------------
>
> Key: WFCORE-1132
> URL: https://issues.jboss.org/browse/WFCORE-1132
> Project: WildFly Core
> Issue Type: Bug
> Components: Remoting
> Affects Versions: 2.0.1.Final
> Reporter: Andrig Miller
> Priority: Critical
>
> 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.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFCORE-1132) Only set socket send and receive buffer sizes if it is in the configuration
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1132?page=com.atlassian.jira.plugi... ]
David Lloyd updated WFCORE-1132:
--------------------------------
Priority: Blocker (was: Critical)
> Only set socket send and receive buffer sizes if it is in the configuration
> ---------------------------------------------------------------------------
>
> Key: WFCORE-1132
> URL: https://issues.jboss.org/browse/WFCORE-1132
> Project: WildFly Core
> Issue Type: Bug
> Components: Remoting
> Affects Versions: 2.0.1.Final
> Reporter: Andrig Miller
> Priority: Blocker
>
> 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.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFCORE-1132) Only set socket send and receive buffer sizes if it is in the configuration
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1132?page=com.atlassian.jira.plugi... ]
David Lloyd updated WFCORE-1132:
--------------------------------
Component/s: Remoting
> Only set socket send and receive buffer sizes if it is in the configuration
> ---------------------------------------------------------------------------
>
> Key: WFCORE-1132
> URL: https://issues.jboss.org/browse/WFCORE-1132
> Project: WildFly Core
> Issue Type: Bug
> Components: Remoting
> Affects Versions: 2.0.1.Final
> Reporter: Andrig Miller
> Priority: Critical
>
> 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.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFCORE-1132) Only set socket send and receive buffer sizes if it is in the configuration
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1132?page=com.atlassian.jira.plugi... ]
David Lloyd moved XNIO-256 to WFCORE-1132:
------------------------------------------
Project: WildFly Core (was: XNIO)
Key: WFCORE-1132 (was: XNIO-256)
Issue Type: Bug (was: Feature Request)
Affects Version/s: 2.0.1.Final
(was: 3.3.2.Final)
> Only set socket send and receive buffer sizes if it is in the 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: Critical
>
> 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.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-4761) Unchecked exceptions in login modules are eaten by Picketbox
by Unni N (JIRA)
[ https://issues.jboss.org/browse/WFLY-4761?page=com.atlassian.jira.plugin.... ]
Unni N commented on WFLY-4761:
------------------------------
To reproduce you can try the following.
Take out the dependency your custom module is using. For example, for me log4j dependency was missing. But its hard to identity unless you debug the org.jboss.security.authentication.JBossCachedAuthenticationManager
> Unchecked exceptions in login modules are eaten by Picketbox
> ------------------------------------------------------------
>
> Key: WFLY-4761
> URL: https://issues.jboss.org/browse/WFLY-4761
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 8.2.0.Final
> Reporter: Matěj Liszka
> Assignee: Darran Lofthouse
>
> In one of ABB software projects, during development of a custom login module (extending org.jboss.security.auth.spi.DatabaseServerLoginModule) I was not able to trace any errors in the log while the module apparently failed to execute its code. After debugging the Picketbox library (it is picketbox-infinispan-4.0.21.Final.jar) I found out that unchecked exceptions in the login module are eaten by return statement from finally blocks of calling methods. This happened in case of runtime errors in method initialize as well as in case of unsatisfied module dependencies (missing dependencies in module.xml). The workaround (which could be also the bug fix for this problem) was to modify org.jboss.security.authentication.JBossCachedAuthenticationManager by catching runtime errors in the second part of implementation of defaultLogin method and by rethrowing them wrapped as LoginException.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFCORE-1120) Launcher sets "-Djava.net.preferIPv4Stack=true" also with IPv6 profile
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1120?page=com.atlassian.jira.plugi... ]
James Perkins commented on WFCORE-1120:
---------------------------------------
Actually my patch won't catch that either. I'll have to think about the best solution to catch those. I'd rather not look for every JVM argument. The system property one was quite easy, but this would be more complicated.
One solution would be to use {{setJavaOptions()}} rather than {{addJavaOption()}}. In fact looking at the wildfly-arquillian code I'd say we should likely use the setter instead. That would be the same behavior as [previous versions|https://github.com/wildfly/wildfly/blob/8.1.0.Final/arquillian/c...].
> Launcher sets "-Djava.net.preferIPv4Stack=true" also with IPv6 profile
> ----------------------------------------------------------------------
>
> Key: WFCORE-1120
> URL: https://issues.jboss.org/browse/WFCORE-1120
> Project: WildFly Core
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 2.0.1.Final
> Reporter: Marek Kopecký
> Assignee: James Perkins
>
> *Description of problem:*
> Domain tests "-Djava.net.preferIPv4Stack=true" also with IPv6 profile. This property is set in AbstractCommandBuilder of WildFly-Core:
> https://github.com/wildfly/wildfly-core/blob/master/launcher/src/main/jav...
> There should be option for disable of this option in arquillian.xml file. And testsuite should use this option with IPv6 profile.
> *How reproducible:*
> Always
> *Steps to Reproduce:*
> # ./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -Dnode0=$MYTESTIPV6_1 -Dnode1=$MYTESTIPV6_2 -Dipv6 -Dts.manualmode -Dtest=OutboundLdapConnectionTestCase -DtestLogToFile=false -Djboss.dist=$JBOSS_DIST -Dts.noSmoke
> *Actual results:*
> {noformat}
> 07:04:26,054 INFO [org.jboss.as.arquillian.container.managed.ManagedDeployableContainer] (main) Starting container with: [/qa/tools/opt/jdk1.8.0_last/bin/java,
> ...
> -Djava.net.preferIPv4Stack=true, -Djava.net.preferIPv4Stack=false
> ...
> {noformat}
> *Expected results:*
> EAP is not started with "-Djava.net.preferIPv4Stack=true" property with IPv6 profile
> *Additional info:*
> Jenkins reproducer job: https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EAP7/view/EAP7-AS-T...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5658) Improve the subsystem test schema test coverage
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-5658?page=com.atlassian.jira.plugin.... ]
Kabir Khan updated WFLY-5658:
-----------------------------
Description:
Currently the way to enable the AbstractSubsystemBaseTest testSchema() and testSchemaOfSubsystemTemplates() tests is to override getSubsystemXsdPath() and getSubsystemTemplatePaths().
Rather than making it explicit to turn on, it should be explicit to turn off.
Also the current way of doing this uses Assume.assumeTrue() to check if a test has provided a schema file, which provides a lot of ignored test noise in the test output. If the xsd should not be tested, methods should instead override testSchema() or testSchemaOfSubsystemTemplates() and provide an empty implementation with a comment saying why it is not important.
was:
Currently the way to enable the AbstractSubsystemBaseTest testSchema() and testSchemaOfSubsystemTemplates() tests is to override getSubsystemXsdPath() and getSubsystemTemplatePaths().
Rather than making it explicit to turn on, it should be explicit to turn off.
> Improve the subsystem test schema test coverage
> -----------------------------------------------
>
> Key: WFLY-5658
> URL: https://issues.jboss.org/browse/WFLY-5658
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 10.0.0.CR4
> Reporter: Kabir Khan
> Assignee: Kabir Khan
> Fix For: 10.0.0.Final
>
>
> Currently the way to enable the AbstractSubsystemBaseTest testSchema() and testSchemaOfSubsystemTemplates() tests is to override getSubsystemXsdPath() and getSubsystemTemplatePaths().
> Rather than making it explicit to turn on, it should be explicit to turn off.
> Also the current way of doing this uses Assume.assumeTrue() to check if a test has provided a schema file, which provides a lot of ignored test noise in the test output. If the xsd should not be tested, methods should instead override testSchema() or testSchemaOfSubsystemTemplates() and provide an empty implementation with a comment saying why it is not important.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFCORE-1128) Improve the subsystem test schema test coverage
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1128?page=com.atlassian.jira.plugi... ]
Kabir Khan updated WFCORE-1128:
-------------------------------
Description:
Currently the way to enable the AbstractSubsystemBaseTest testSchema() and testSchemaOfSubsystemTemplates() tests is to override getSubsystemXsdPath() and getSubsystemTemplatePaths().
Rather than making it explicit to turn on, it should be explicit to turn off.
Also the current way of doing this uses Assume.assumeTrue() to check if a test has provided a schema file, which provides a lot of ignored test noise in the test output. If the xsd should not be tested, methods should instead override testSchema() or testSchemaOfSubsystemTemplates() and provide an empty implementation with a comment saying why it is not important.
was:
Currently the way to enable the AbstractSubsystemBaseTest testSchema() and testSchemaOfSubsystemTemplates() tests is to override getSubsystemXsdPath() and getSubsystemTemplatePaths().
Rather than making it explicit to turn on, it should be explicit to turn off.
> Improve the subsystem test schema test coverage
> -----------------------------------------------
>
> Key: WFCORE-1128
> URL: https://issues.jboss.org/browse/WFCORE-1128
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.0.1.Final
> Reporter: Kabir Khan
> Assignee: Kabir Khan
> Fix For: 2.0.2.Final (EAP 7)
>
>
> Currently the way to enable the AbstractSubsystemBaseTest testSchema() and testSchemaOfSubsystemTemplates() tests is to override getSubsystemXsdPath() and getSubsystemTemplatePaths().
> Rather than making it explicit to turn on, it should be explicit to turn off.
> Also the current way of doing this uses Assume.assumeTrue() to check if a test has provided a schema file, which provides a lot of ignored test noise in the test output. If the xsd should not be tested, methods should instead override testSchema() or testSchemaOfSubsystemTemplates() and provide an empty implementation with a comment saying why it is not important.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months