[JBoss JIRA] (WFLY-5657) HttpServletRequest.changeSessionId() doesn't invalidate old session ID with distributed SSO
by Paul Ferraro (JIRA)
Paul Ferraro created WFLY-5657:
----------------------------------
Summary: HttpServletRequest.changeSessionId() doesn't invalidate old session ID with distributed SSO
Key: WFLY-5657
URL: https://issues.jboss.org/browse/WFLY-5657
Project: WildFly
Issue Type: Bug
Components: Clustering
Affects Versions: 10.0.0.CR4
Reporter: Paul Ferraro
Assignee: Paul Ferraro
The distributed SSO implementation stores a map of sessions using the session ID. If the user changes the session ID, this reference is never changed. Consequently, subsequent calls to SingleSignOn.getSession(SessionManager) will return null.
--
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 reassigned WFCORE-1120:
-------------------------------------
Assignee: James Perkins (was: Tomaz Cerar)
> 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] (WFCORE-1126) ManagedDatagramSocketBinding throw NPE
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-1126:
----------------------------------------
Summary: ManagedDatagramSocketBinding throw NPE
Key: WFCORE-1126
URL: https://issues.jboss.org/browse/WFCORE-1126
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Affects Versions: 2.0.0.CR8
Reporter: Stefan Dilk
Assignee: Brian Stansberry
Fix For: 3.0.0.Alpha1
i think i have found the same bug as in WFCORE-1033 but in another method.
in the previous bug the bind method was the problem, here i have the same NPE in the close method. there is no null check to registry as in the bind method.
{noformat}
[Server:mgmt-1-prod] 2015-11-10 00:37:15,454 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.jgroups.channel.ee.connector: org.jboss.msc.service.StartException in service jboss.jgroups.channel.ee.connector:
java.lang.NullPointerException
[Server:mgmt-1-prod] at org.wildfly.clustering.jgroups.spi.service.ChannelConnectorBuilder.start(ChannelConnectorBuilder.java:9
6)
[Server:mgmt-1-prod] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
[Server:mgmt-1-prod] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
[Server:mgmt-1-prod] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[Server:mgmt-1-prod] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[Server:mgmt-1-prod] at java.lang.Thread.run(Thread.java:745)
[Server:mgmt-1-prod] Caused by: java.lang.NullPointerException
[Server:mgmt-1-prod] at org.jboss.as.network.ManagedDatagramSocketBinding.close(ManagedDatagramSocketBinding.java:73)
[Server:mgmt-1-prod] at java.net.DatagramSocket.<init>(DatagramSocket.java:245)
[Server:mgmt-1-prod] at org.jboss.as.network.ManagedDatagramSocketBinding.<init>(ManagedDatagramSocketBinding.java:41)
[Server:mgmt-1-prod] at org.jboss.as.network.SocketBindingManagerImpl.createDatagramSocket(SocketBindingManagerImpl.java:87)
[Server:mgmt-1-prod] at org.jboss.as.clustering.jgroups.ManagedSocketFactory.createDatagramSocket(ManagedSocketFactory.java:103)
[Server:mgmt-1-prod] at org.jboss.as.clustering.jgroups.ManagedSocketFactory.createDatagramSocket(ManagedSocketFactory.java:113)
[Server:mgmt-1-prod] at org.jgroups.protocols.UDP.createDatagramSocketWithBindPort(UDP.java:487)
[Server:mgmt-1-prod] at org.jgroups.protocols.UDP.createSockets(UDP.java:361)
[Server:mgmt-1-prod] at org.jgroups.protocols.UDP.start(UDP.java:270)
[Server:mgmt-1-prod] at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:965)
[Server:mgmt-1-prod] at org.jgroups.JChannel.startStack(JChannel.java:890)
[Server:mgmt-1-prod] at org.jgroups.JChannel._preConnect(JChannel.java:553)
[Server:mgmt-1-prod] at org.jgroups.JChannel.connect(JChannel.java:288)
[Server:mgmt-1-prod] at org.jgroups.JChannel.connect(JChannel.java:279)
[Server:mgmt-1-prod] at org.wildfly.clustering.jgroups.spi.service.ChannelConnectorBuilder.start(ChannelConnectorBuilder.java:94)
[Server:mgmt-1-prod] ... 5 more
{noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFCORE-1089) IgnoredResourcesProfileCloneTestCase does not wait for domain stabilization following reload
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1089?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1089:
-------------------------------------
Fix Version/s: 2.0.2.Final (EAP 7)
> IgnoredResourcesProfileCloneTestCase does not wait for domain stabilization following reload
> --------------------------------------------------------------------------------------------
>
> Key: WFCORE-1089
> URL: https://issues.jboss.org/browse/WFCORE-1089
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, Test Suite
> Affects Versions: 2.0.0.CR9
> Reporter: Brian Stansberry
> Assignee: ehsavoie Hugonnet
> Fix For: 2.0.2.Final (EAP 7)
>
>
> IgnoredResourcesProfileCloneTestCase several times reloads the slave HC without restarting its servers. But it then does not wait for those servers to reconnect before continuing on. This means the servers may not be reattached to the domain when further modifications are made.
> I'm quite certain this is the cause of the failure at http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=76866&tab=buil... and the other time that test failed.
> IgnoredResourcesProfileCloneTestCase reloads the slave and then exits. CompositeOperationTestCase follows and immediately adds system-property=composite-op in its @Before method. The other-two server doesn't get this op as it's not reconnected. The test then later fails because the other-two server's state is not as expected.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFCORE-1115) Intermittent failures of CompositeOperationTestCase & CoreResourceManagementTestCase
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1115?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1115:
------------------------------------------
This has a "relates to" link to WFCORE-1089, which is ok, but the working assumption should be that this is "caused by" WFCORE-1089. My initial filing of 1089 followed analysis of intermittent cases of these two failures.
> Intermittent failures of CompositeOperationTestCase & CoreResourceManagementTestCase
> ------------------------------------------------------------------------------------
>
> Key: WFCORE-1115
> URL: https://issues.jboss.org/browse/WFCORE-1115
> Project: WildFly Core
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 3.0.0.Alpha1
> Reporter: Petr Kremensky
> Assignee: Brian Stansberry
> Attachments: TEST-org.jboss.as.test.integration.domain.suites.CompositeOperationTestCase.xml, TEST-org.jboss.as.test.integration.domain.suites.CoreResourceManagementTestCase.xml
>
>
> org.jboss.as.test.integration.domain.suites.CompositeOperationTestCase and org.jboss.as.test.integration.domain.suites.CoreResourceManagementTestCase from wildfly-core testsuite domain module starts to intermittently fail since 7.0.0.DR13 (2.0.0.CR8).
> Tests fails only once I run the whole Domain Mode Integration Tests module, running only these two tests in isolation never fails.
> [Reproducer job|https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-core-Comp...] which starts the tests in testsuite/domain module:
> \- *2.0.0.CR6* - intermittent failures of HcExtensionAndSubsystemManagementTestCase JBEAP-1598
> \- *2.0.0.CR7* - intermittent failures of HcExtensionAndSubsystemManagementTestCase JBEAP-1598
> \- *2.0.0.CR8* - no more HcExtensionAndSubsystemManagementTestCase failures, CompositeOperationTestCase and CoreResourceManagementTestCase starts failing
> \- *3.0.0.Alpha1-SNAPSHOT* - CompositeOperationTestCase and CoreResourceManagementTestCase intermittent fails
> Attaching surefire reports.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFCORE-1115) Intermittent failures of CompositeOperationTestCase & CoreResourceManagementTestCase
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1115?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFCORE-1115:
----------------------------------------
Assignee: ehsavoie Hugonnet (was: Brian Stansberry)
> Intermittent failures of CompositeOperationTestCase & CoreResourceManagementTestCase
> ------------------------------------------------------------------------------------
>
> Key: WFCORE-1115
> URL: https://issues.jboss.org/browse/WFCORE-1115
> Project: WildFly Core
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 3.0.0.Alpha1
> Reporter: Petr Kremensky
> Assignee: ehsavoie Hugonnet
> Attachments: TEST-org.jboss.as.test.integration.domain.suites.CompositeOperationTestCase.xml, TEST-org.jboss.as.test.integration.domain.suites.CoreResourceManagementTestCase.xml
>
>
> org.jboss.as.test.integration.domain.suites.CompositeOperationTestCase and org.jboss.as.test.integration.domain.suites.CoreResourceManagementTestCase from wildfly-core testsuite domain module starts to intermittently fail since 7.0.0.DR13 (2.0.0.CR8).
> Tests fails only once I run the whole Domain Mode Integration Tests module, running only these two tests in isolation never fails.
> [Reproducer job|https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-core-Comp...] which starts the tests in testsuite/domain module:
> \- *2.0.0.CR6* - intermittent failures of HcExtensionAndSubsystemManagementTestCase JBEAP-1598
> \- *2.0.0.CR7* - intermittent failures of HcExtensionAndSubsystemManagementTestCase JBEAP-1598
> \- *2.0.0.CR8* - no more HcExtensionAndSubsystemManagementTestCase failures, CompositeOperationTestCase and CoreResourceManagementTestCase starts failing
> \- *3.0.0.Alpha1-SNAPSHOT* - CompositeOperationTestCase and CoreResourceManagementTestCase intermittent fails
> Attaching surefire reports.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFCORE-1089) IgnoredResourcesProfileCloneTestCase does not wait for domain stabilization following reload
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1089?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFCORE-1089:
----------------------------------------
Assignee: ehsavoie Hugonnet
> IgnoredResourcesProfileCloneTestCase does not wait for domain stabilization following reload
> --------------------------------------------------------------------------------------------
>
> Key: WFCORE-1089
> URL: https://issues.jboss.org/browse/WFCORE-1089
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, Test Suite
> Affects Versions: 2.0.0.CR9
> Reporter: Brian Stansberry
> Assignee: ehsavoie Hugonnet
>
> IgnoredResourcesProfileCloneTestCase several times reloads the slave HC without restarting its servers. But it then does not wait for those servers to reconnect before continuing on. This means the servers may not be reattached to the domain when further modifications are made.
> I'm quite certain this is the cause of the failure at http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=76866&tab=buil... and the other time that test failed.
> IgnoredResourcesProfileCloneTestCase reloads the slave and then exits. CompositeOperationTestCase follows and immediately adds system-property=composite-op in its @Before method. The other-two server doesn't get this op as it's not reconnected. The test then later fails because the other-two server's state is not as expected.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFCORE-1119) ManagedDatagramSocketBinding throw NPE
by Stefan Dilk (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1119?page=com.atlassian.jira.plugi... ]
Stefan Dilk commented on WFCORE-1119:
-------------------------------------
wildfly 10 CR2 works and i have now tested wildfly 10CR4 but there with the same config i get this NPE.
i can not see the underlying failure.
> ManagedDatagramSocketBinding throw NPE
> --------------------------------------
>
> Key: WFCORE-1119
> URL: https://issues.jboss.org/browse/WFCORE-1119
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.0.0.CR8
> Reporter: Stefan Dilk
> Assignee: Brian Stansberry
> Fix For: 3.0.0.Alpha1
>
>
> i think i have found the same bug as in WFCORE-1033 but in another method.
> in the previous bug the bind method was the problem, here i have the same NPE in the close method. there is no null check to registry as in the bind method.
> {noformat}
> [Server:mgmt-1-prod] 2015-11-10 00:37:15,454 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.jgroups.channel.ee.connector: org.jboss.msc.service.StartException in service jboss.jgroups.channel.ee.connector:
> java.lang.NullPointerException
> [Server:mgmt-1-prod] at org.wildfly.clustering.jgroups.spi.service.ChannelConnectorBuilder.start(ChannelConnectorBuilder.java:9
> 6)
> [Server:mgmt-1-prod] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> [Server:mgmt-1-prod] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> [Server:mgmt-1-prod] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [Server:mgmt-1-prod] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [Server:mgmt-1-prod] at java.lang.Thread.run(Thread.java:745)
> [Server:mgmt-1-prod] Caused by: java.lang.NullPointerException
> [Server:mgmt-1-prod] at org.jboss.as.network.ManagedDatagramSocketBinding.close(ManagedDatagramSocketBinding.java:73)
> [Server:mgmt-1-prod] at java.net.DatagramSocket.<init>(DatagramSocket.java:245)
> [Server:mgmt-1-prod] at org.jboss.as.network.ManagedDatagramSocketBinding.<init>(ManagedDatagramSocketBinding.java:41)
> [Server:mgmt-1-prod] at org.jboss.as.network.SocketBindingManagerImpl.createDatagramSocket(SocketBindingManagerImpl.java:87)
> [Server:mgmt-1-prod] at org.jboss.as.clustering.jgroups.ManagedSocketFactory.createDatagramSocket(ManagedSocketFactory.java:103)
> [Server:mgmt-1-prod] at org.jboss.as.clustering.jgroups.ManagedSocketFactory.createDatagramSocket(ManagedSocketFactory.java:113)
> [Server:mgmt-1-prod] at org.jgroups.protocols.UDP.createDatagramSocketWithBindPort(UDP.java:487)
> [Server:mgmt-1-prod] at org.jgroups.protocols.UDP.createSockets(UDP.java:361)
> [Server:mgmt-1-prod] at org.jgroups.protocols.UDP.start(UDP.java:270)
> [Server:mgmt-1-prod] at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:965)
> [Server:mgmt-1-prod] at org.jgroups.JChannel.startStack(JChannel.java:890)
> [Server:mgmt-1-prod] at org.jgroups.JChannel._preConnect(JChannel.java:553)
> [Server:mgmt-1-prod] at org.jgroups.JChannel.connect(JChannel.java:288)
> [Server:mgmt-1-prod] at org.jgroups.JChannel.connect(JChannel.java:279)
> [Server:mgmt-1-prod] at org.wildfly.clustering.jgroups.spi.service.ChannelConnectorBuilder.start(ChannelConnectorBuilder.java:94)
> [Server:mgmt-1-prod] ... 5 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFCORE-1119) ManagedDatagramSocketBinding throw NPE
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1119?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1119:
------------------------------------------
Note this NPE is masking some other failure that would have been thrown anyway. The close() method is only called from DatagramSocket if the bind call failed for some reason.
> ManagedDatagramSocketBinding throw NPE
> --------------------------------------
>
> Key: WFCORE-1119
> URL: https://issues.jboss.org/browse/WFCORE-1119
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.0.0.CR8
> Reporter: Stefan Dilk
> Assignee: Brian Stansberry
> Fix For: 3.0.0.Alpha1
>
>
> i think i have found the same bug as in WFCORE-1033 but in another method.
> in the previous bug the bind method was the problem, here i have the same NPE in the close method. there is no null check to registry as in the bind method.
> {noformat}
> [Server:mgmt-1-prod] 2015-11-10 00:37:15,454 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.jgroups.channel.ee.connector: org.jboss.msc.service.StartException in service jboss.jgroups.channel.ee.connector:
> java.lang.NullPointerException
> [Server:mgmt-1-prod] at org.wildfly.clustering.jgroups.spi.service.ChannelConnectorBuilder.start(ChannelConnectorBuilder.java:9
> 6)
> [Server:mgmt-1-prod] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> [Server:mgmt-1-prod] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> [Server:mgmt-1-prod] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [Server:mgmt-1-prod] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [Server:mgmt-1-prod] at java.lang.Thread.run(Thread.java:745)
> [Server:mgmt-1-prod] Caused by: java.lang.NullPointerException
> [Server:mgmt-1-prod] at org.jboss.as.network.ManagedDatagramSocketBinding.close(ManagedDatagramSocketBinding.java:73)
> [Server:mgmt-1-prod] at java.net.DatagramSocket.<init>(DatagramSocket.java:245)
> [Server:mgmt-1-prod] at org.jboss.as.network.ManagedDatagramSocketBinding.<init>(ManagedDatagramSocketBinding.java:41)
> [Server:mgmt-1-prod] at org.jboss.as.network.SocketBindingManagerImpl.createDatagramSocket(SocketBindingManagerImpl.java:87)
> [Server:mgmt-1-prod] at org.jboss.as.clustering.jgroups.ManagedSocketFactory.createDatagramSocket(ManagedSocketFactory.java:103)
> [Server:mgmt-1-prod] at org.jboss.as.clustering.jgroups.ManagedSocketFactory.createDatagramSocket(ManagedSocketFactory.java:113)
> [Server:mgmt-1-prod] at org.jgroups.protocols.UDP.createDatagramSocketWithBindPort(UDP.java:487)
> [Server:mgmt-1-prod] at org.jgroups.protocols.UDP.createSockets(UDP.java:361)
> [Server:mgmt-1-prod] at org.jgroups.protocols.UDP.start(UDP.java:270)
> [Server:mgmt-1-prod] at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:965)
> [Server:mgmt-1-prod] at org.jgroups.JChannel.startStack(JChannel.java:890)
> [Server:mgmt-1-prod] at org.jgroups.JChannel._preConnect(JChannel.java:553)
> [Server:mgmt-1-prod] at org.jgroups.JChannel.connect(JChannel.java:288)
> [Server:mgmt-1-prod] at org.jgroups.JChannel.connect(JChannel.java:279)
> [Server:mgmt-1-prod] at org.wildfly.clustering.jgroups.spi.service.ChannelConnectorBuilder.start(ChannelConnectorBuilder.java:94)
> [Server:mgmt-1-prod] ... 5 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months