[JBoss JIRA] (WFLY-10920) IllegalStateException: java.util.ConcurrentModificationException
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-10920?page=com.atlassian.jira.plugin... ]
James Perkins updated WFLY-10920:
---------------------------------
Fix Version/s: 15.0.0.Final
> IllegalStateException: java.util.ConcurrentModificationException
> ----------------------------------------------------------------
>
> Key: WFLY-10920
> URL: https://issues.jboss.org/browse/WFLY-10920
> Project: WildFly
> Issue Type: Bug
> Components: MP Config
> Affects Versions: 14.0.1.Final, 14.0.0.Final
> Reporter: tommaso borgato
> Assignee: Jeff Mesnil
> Priority: Critical
> Fix For: 15.0.0.Beta1, 15.0.0.Final
>
> Attachments: clusterbench-ee7-shared-sessions.ear, clusterbench-ee7.ear, perf18-consoleText.txt
>
>
> One of the many affected scenarios is [perflab_eap-7x-failover-http-session-shutdown-dist-sync-shared-sessions|h...]: it is a 4 nodes (running with the standalone-ha.xml configuration) fail-over scenario where the deployed EAR contains two WAR sharing http sessions:
> {{clusterbench-ee7-shared-sessions.ear/META-INF/jboss-all.xml}}:
> {noformat}
> <jboss umlns="urn:jboss:1.0">
> <shared-session-config xmlns="urn:jboss:shared-session-config:1.0">
> <session-config>
> <cookie-config>
> <path>/</path>
> </cookie-config>
> </session-config>
> </shared-session-config>
> </jboss>
> {noformat}
> During server shut-down the EAR is stopped and we observe the following error:
> {noformat}
> [JBossINF] [0m[0m05:49:46,803 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 99) WFLYCLINF0003: Stopped clusterbench-ee7-shared-sessions.ear cache from web container
> [JBossINF] [0m[0m05:49:46,805 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000080: Disconnecting JGroups channel ejb
> [JBossINF] [0m[31m05:49:46,813 ERROR [org.jboss.as.server.deployment] (MSC service thread 1-6) WFLYSRV0043: Deployment unit processor org.wildfly.extension.microprofile.config.smallrye.deployment.SubsystemDeploymentProcessor@6953f688 unexpectedly threw an exception during undeploy phase POST_MODULE of subdeployment "clusterbench-ee7-web-default-2.war" of deployment "clusterbench-ee7-shared-sessions.ear": java.util.ConcurrentModificationException
> [JBossINF] at java.util.HashMap$HashIterator.nextNode(HashMap.java:1442)
> [JBossINF] at java.util.HashMap$EntryIterator.next(HashMap.java:1476)
> [JBossINF] at java.util.HashMap$EntryIterator.next(HashMap.java:1474)
> [JBossINF] at io.smallrye.config.SmallRyeConfigProviderResolver.releaseConfig(SmallRyeConfigProviderResolver.java:71)
> [JBossINF] at org.wildfly.extension.microprofile.config.smallrye.deployment.SubsystemDeploymentProcessor.undeploy(SubsystemDeploymentProcessor.java:102)
> [JBossINF] at org.jboss.as.server.deployment.DeploymentUnitPhaseService.safeUndeploy(DeploymentUnitPhaseService.java:211)
> [JBossINF] at org.jboss.as.server.deployment.DeploymentUnitPhaseService.stop(DeploymentUnitPhaseService.java:204)
> [JBossINF] at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:1792)
> [JBossINF] at org.jboss.msc.service.ServiceControllerImpl$StopTask.execute(ServiceControllerImpl.java:1761)
> [JBossINF] at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1556)
> [JBossINF] at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> [JBossINF] at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> [JBossINF] at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> [JBossINF] at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> [JBossINF] at java.lang.Thread.run(Thread.java:748)
> [JBossINF]
> [JBossINF] [0m[31m05:49:46,812 ERROR [org.jboss.as.server.deployment] (MSC service thread 1-4) WFLYSRV0043: Deployment unit processor org.wildfly.extension.microprofile.config.smallrye.deployment.SubsystemDeploymentProcessor@6953f688 unexpectedly threw an exception during undeploy phase POST_MODULE of subdeployment "clusterbench-ee7-web-default-1.war" of deployment "clusterbench-ee7-shared-sessions.ear": java.util.ConcurrentModificationException
> [JBossINF] at java.util.HashMap$HashIterator.nextNode(HashMap.java:1442)
> [JBossINF] at java.util.HashMap$EntryIterator.next(HashMap.java:1476)
> [JBossINF] at java.util.HashMap$EntryIterator.next(HashMap.java:1474)
> [JBossINF] at io.smallrye.config.SmallRyeConfigProviderResolver.releaseConfig(SmallRyeConfigProviderResolver.java:71)
> [JBossINF] at org.wildfly.extension.microprofile.config.smallrye.deployment.SubsystemDeploymentProcessor.undeploy(SubsystemDeploymentProcessor.java:102)
> [JBossINF] at org.jboss.as.server.deployment.DeploymentUnitPhaseService.safeUndeploy(DeploymentUnitPhaseService.java:211)
> [JBossINF] at org.jboss.as.server.deployment.DeploymentUnitPhaseService.stop(DeploymentUnitPhaseService.java:204)
> [JBossINF] at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:1792)
> [JBossINF] at org.jboss.msc.service.ServiceControllerImpl$StopTask.execute(ServiceControllerImpl.java:1761)
> [JBossINF] at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1556)
> [JBossINF] at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> [JBossINF] at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> [JBossINF] at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> [JBossINF] at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> [JBossINF] at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Also other scenarios like [perflab_eap-7x-failover-http-session-shutdown-dist-sync-nb-state-transfer...] and [perflab_eap-7x-failover-remote-jdg-session-shutdown-invalidation-sync-hot...] exhibits the same error: I assume it does not depend on the shared sessions configuration mentioned above;
> Find attached:
> - the complete server log (perf18-consoleText.txt)
> - the EAR used for the shared-sessions scenario (clusterbench-ee7-shared-sessions.ear)
> - the EAR used for the [perflab_eap-7x-failover-http-session-shutdown-dist-sync-nb-state-transfer...] scenario (clusterbench-ee7.ear)
>
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFLY-10986) Concurrent Modification Exception when starting server with external JMS broker
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-10986?page=com.atlassian.jira.plugin... ]
James Perkins updated WFLY-10986:
---------------------------------
Fix Version/s: 15.0.0.Final
> Concurrent Modification Exception when starting server with external JMS broker
> -------------------------------------------------------------------------------
>
> Key: WFLY-10986
> URL: https://issues.jboss.org/browse/WFLY-10986
> Project: WildFly
> Issue Type: Bug
> Components: JCA, JMS
> Affects Versions: 14.0.1.Final
> Reporter: Martin Styk
> Assignee: Kabir Khan
> Priority: Blocker
> Fix For: 15.0.0.Beta1, 15.0.0.Final
>
>
> Start of a WildFly with resource adapter configured to remote messaging broker sometimes fails with following error.
> {code}
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.resourceadapters.ra."wmq.jmsra".CF: org.jboss.msc.service.StartException in service jboss.resourceadapters.ra."wmq.jmsra".CF: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1728)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1556)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1364)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.util.ConcurrentModificationException
> at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:909)
> at java.util.ArrayList$Itr.next(ArrayList.java:859)
> at java.util.Collections$UnmodifiableCollection$1.next(Collections.java:1042)
> at org.jboss.as.connector.metadata.api.resourceadapter.ActivationSecurityUtil.isLegacySecurityRequired(ActivationSecurityUtil.java:41)
> at org.jboss.as.connector.subsystems.resourceadapters.ConnectionDefinitionService.start(ConnectionDefinitionService.java:68)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1736)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1698)
> ... 6 more
> {code}
> This issue was introduced in fix for WFLY-9978 in [this commit |https://github.com/ehsavoie/wildfly/commit/8d35c77130c8ba8c47008e1de1225971fa5d8c2e]
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFLY-10991) Memory leak when deployment is redeployed multiple times
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-10991?page=com.atlassian.jira.plugin... ]
James Perkins updated WFLY-10991:
---------------------------------
Fix Version/s: 15.0.0.Final
> Memory leak when deployment is redeployed multiple times
> --------------------------------------------------------
>
> Key: WFLY-10991
> URL: https://issues.jboss.org/browse/WFLY-10991
> Project: WildFly
> Issue Type: Bug
> Components: MP OpenTracing
> Affects Versions: 14.0.0.Beta2
> Reporter: Jan Stourac
> Assignee: Juraci Paixão Kröhling
> Priority: Blocker
> Fix For: 15.0.0.Beta1, 15.0.0.Final
>
> Attachments: memoryLeaks.war, problematic-wf-build-heap-diff-start-end-org-filter.png, problematic-wf-build-heap-diff-start-end.png, sane-wf-build-heap-diff-start-end-org-filter.png, sane-wf-build-heap-diff-start-end.png
>
>
> It looks like redeploying attached deployment [^memoryLeaks.war] multiple times (our automated test does it 100 times), there seems to be some memory leak in the WildFly. Using git bisect, the commit that started to fail is [651dc8a2f0d4ccad6a35f7b1d28626b43ebb2a5d in WildFly repository|https://github.com/wildfly/wildfly/commits/651dc8a2f0d4ccad6a3...]. That is why I selected MP OpenTracing component for this issue. Actual testing deployment is very simple and contains just some jsp file with some EJB classes that are used to call GC and check current heap usage.
> Brief description of the test:
> # attached deployment is deployed
> # System.gc() is called via EJB call
> # it checks initial heap usage at the beginning of the test via EJB call that checks all instances of ManagementFactory.getMemoryPoolMXBeans()
> # deployment is redeployed 100 times
> # calls System.gc() via EJP call again and checks heap usage again via EJB call and compares the results
> Size of the extra heap in use is about 25MB plus when compared to the initial size.
> I tried to check manually via [visualVM|https://visualvm.github.io/] tool. You can create a heapdump at the beginning of the test and at the end of the test. Then compare them easily and check the differences. Using a filter I can see quite a huge increase of instances of the {{org.jboss.modules.*}} classes. However, biggest memory footprint is huge increase of the instances of the {{java.util.HashMap$Node}}, {{char[]}}, {{java.util.HashMap$Node[]}} and few others. I don't see such huge increase of the instances of these classes when I use older build of WildFly prior to the problematic commit. To be honest I don't see direct link with the problematic commit I linked before. As the heapdumps are too big to be attached here, I am attaching some screenshots.
> Also, when microprofile-opentracing-smallrye subsystem is removed via:
> {code}
> /subsystem=microprofile-opentracing-smallrye:remove()
> {code}
> then no more memory leak is detected, after adding the subsystem back, the leak is present again. Thus opentracing is involved somehow into this indeed.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFLY-11092) XtsAsLogger doesn't compile on JDK11, WildFly can't be build on Java 11
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-11092?page=com.atlassian.jira.plugin... ]
James Perkins updated WFLY-11092:
---------------------------------
Fix Version/s: 15.0.0.Final
> XtsAsLogger doesn't compile on JDK11, WildFly can't be build on Java 11
> -----------------------------------------------------------------------
>
> Key: WFLY-11092
> URL: https://issues.jboss.org/browse/WFLY-11092
> Project: WildFly
> Issue Type: Bug
> Components: Server, XTS
> Environment: {noformat}
> java version "11" 2018-09-25
> Java(TM) SE Runtime Environment 18.9 (build 11+28)
> Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11+28, mixed mode)
> {noformat}
> Reporter: Petr Kremensky
> Assignee: Ondra Chaloupka
> Priority: Blocker
> Labels: Java11
> Fix For: 15.0.0.Beta1, 15.0.0.Final
>
>
> Compilation failure on JDK 11 introduced by https://github.com/wildfly/wildfly/pull/11702
> {noformat}
> [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.7.0:compile (default-compile) on project wildfly-xts: Compilation failure
> [ERROR] /home/pkremens/devel/wildfly/xts/target/generated-sources/annotations/org/jboss/as/xts/logging/XtsAsLogger_$logger.java:[11,22] '.' expected
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFLY-10812) JDK11 Some security tests fail on closed channel exception
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-10812?page=com.atlassian.jira.plugin... ]
James Perkins updated WFLY-10812:
---------------------------------
Fix Version/s: 15.0.0.Final
> JDK11 Some security tests fail on closed channel exception
> ----------------------------------------------------------
>
> Key: WFLY-10812
> URL: https://issues.jboss.org/browse/WFLY-10812
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Reporter: Richard Opalka
> Assignee: Jan Kalina
> Priority: Blocker
> Fix For: 15.0.0.Beta1, 15.0.0.Final
>
>
> With latest JDK11 (build 11-ea+25) the following tests fail due to closed channel exception: modified:
> * testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/security/loginmodules/LdapExtLikeAdvancedLdapLMTestCase.java
> * testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/security/loginmodules/LdapExtLoginModuleTestCase.java
> * testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/security/loginmodules/LdapLoginModuleTestCase.java
> * testsuite/integration/elytron/src/test/java/org/wildfly/test/integration/elytron/ssl/UndertowTwoWaySslNeedClientAuthTestCase.java
> * testsuite/integration/iiop/src/test/java/org/jboss/as/test/iiopssl/basic/IIOPSslInvocationTestCase.java
> * testsuite/integration/manualmode/src/test/java/org/jboss/as/test/manualmode/security/OutboundLdapConnectionClientCertTestCase.java
> * testsuite/integration/manualmode/src/test/java/org/jboss/as/test/manualmode/security/OutboundLdapConnectionTestCase.java
> * testsuite/integration/manualmode/src/test/java/org/jboss/as/test/manualmode/web/ssl/CertificateRolesLoginModuleTestCase.java
> * testsuite/integration/manualmode/src/test/java/org/jboss/as/test/manualmode/web/ssl/DatabaseCertLoginModuleTestCase.java
> * testsuite/integration/manualmode/src/test/java/org/jboss/as/test/manualmode/web/ssl/HTTPSWebConnectorTestCase.java
> * testsuite/integration/ws/src/test/java/org/jboss/as/test/integration/ws/wsse/trust/WSTrustTestCase.java
> Is there a known SSL issue in JDK11? Could somebody from our security team investigate this issue?
> When these tests will start passing WF test suite will be passing 100% of tests on JDK11.
> Potential investigator from our security team may want to include this PR:
> https://github.com/wildfly/wildfly/pull/11499
> to fix known JDK11 issues.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFLY-10937) Starting WFLY scripts with JDK 11 blows up with ModuleNotFoundException java.se
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-10937?page=com.atlassian.jira.plugin... ]
James Perkins updated WFLY-10937:
---------------------------------
Fix Version/s: 15.0.0.Final
> Starting WFLY scripts with JDK 11 blows up with ModuleNotFoundException java.se
> -------------------------------------------------------------------------------
>
> Key: WFLY-10937
> URL: https://issues.jboss.org/browse/WFLY-10937
> Project: WildFly
> Issue Type: Bug
> Components: Scripts
> Reporter: Marek Kopecký
> Assignee: Richard Opalka
> Priority: Blocker
> Labels: Java11, blocker-WF14, jdk11
> Fix For: 15.0.0.Beta1, 15.0.0.Final
>
>
> Starting WFLY scripts with JDK 11 blows up with ModuleNotFoundException java.se
> *Affected scripts*
> * appclient
> * jdr
> * wsconsume
> * wsprovide
> *Example of logs*
> {noformat}
> [mkopecky@dhcp-10-40-4-197 bin]$ ./jdr.sh
> org.jboss.modules.ModuleNotFoundException: java.se
> at org.jboss.modules.Module.addPaths(Module.java:1266)
> at org.jboss.modules.Module.link(Module.java:1622)
> at org.jboss.modules.Module.relinkIfNecessary(Module.java:1650)
> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:296)
> at org.jboss.modules.Main.main(Main.java:437)
> [mkopecky@dhcp-10-40-4-197 bin]$
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFLY-10736) Server in cluster hangs during start after previous kill
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-10736?page=com.atlassian.jira.plugin... ]
James Perkins updated WFLY-10736:
---------------------------------
Fix Version/s: 15.0.0.Final
> Server in cluster hangs during start after previous kill
> --------------------------------------------------------
>
> Key: WFLY-10736
> URL: https://issues.jboss.org/browse/WFLY-10736
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Reporter: Miroslav Novak
> Assignee: Paul Ferraro
> Priority: Blocker
> Labels: blocker-WF14
> Fix For: 15.0.0.Beta1, 15.0.0.Final
>
> Attachments: Lodh2TestCase.testRemoteJcaInboundOnly-traces.zip, Lodh2TestCase.testRemoteJcaInboundOnly.zip, Lodh2TestCase.testRemoteJcaInboundOnly2.zip, clusterKilTest.zip, logs-traces.zip, logs-traces2.zip, logs-traces3.zip, logs-traces4.zip, logs-with-workaround.zip, node-1-thread-dump-before-kill-shutdown-sequence.txt, server-with-mdb.log, standalone-full-ha-1.xml, standalone-full-ha-2.xml
>
>
> There is regression in JGroups or Infinispan in one of our tests for fault tolerance of JMS bridges. However work on JMS bridge appears to be unrelated. Issue was hit in WF weekly run.
> Test Scenario:
> * There are two servers. InQueue is deployed on Node 1,
> * OutQueue is deployed on Node 2. Both servers are started.
> * Large byte messages are sent to InQueue deployed on Node 1. Bridge between servers/queues transfers messages from node 1 to node 2.
> * Node 1 is killed and started again.
> * All messages are received from OutQueue deployed on Node 2.
> Result:
> Node 1 does not start after kill and hangs. There is following exception logged in node 2:
> {code}
> :26:17,894 INFO [org.infinispan.CLUSTER] (thread-12,ejb,node-2) ISPN100000: Node node-1 joined the cluster
> 09:26:18,520 INFO [org.infinispan.CLUSTER] (thread-12,ejb,node-2) ISPN000094: Received new cluster view for channel ejb: [node-2|7] (2) [node-2, node-1]
> 09:26:18,521 INFO [org.infinispan.CLUSTER] (thread-12,ejb,node-2) ISPN100001: Node node-1 left the cluster
> 09:26:18,521 INFO [org.infinispan.CLUSTER] (thread-12,ejb,node-2) ISPN000094: Received new cluster view for channel ejb: [node-2|7] (2) [node-2, node-1]
> 09:26:18,522 INFO [org.infinispan.CLUSTER] (thread-12,ejb,node-2) ISPN100001: Node node-1 left the cluster
> 09:26:18,522 INFO [org.infinispan.CLUSTER] (thread-12,ejb,node-2) ISPN000094: Received new cluster view for channel ejb: [node-2|7] (2) [node-2, node-1]
> 09:26:18,522 INFO [org.infinispan.CLUSTER] (thread-12,ejb,node-2) ISPN100001: Node node-1 left the cluster
> 09:26:18,522 INFO [org.infinispan.CLUSTER] (thread-12,ejb,node-2) ISPN000094: Received new cluster view for channel ejb: [node-2|7] (2) [node-2, node-1]
> 09:26:18,523 INFO [org.infinispan.CLUSTER] (thread-12,ejb,node-2) ISPN100001: Node node-1 left the cluster
> 09:26:18,868 INFO [org.infinispan.CLUSTER] (remote-thread--p5-t2) ISPN000310: Starting cluster-wide rebalance for cache default, topology CacheTopology{id=17, phase=READ_OLD_WRITE_ALL, rebalanceId=6, currentCH=ReplicatedConsistentHash{ns = 256, owners = (2)[node-2: 122, node-1: 134]}, pendingCH=ReplicatedConsistentHash{ns = 256, owners = (3)[node-2: 84, node-1: 90, node-1: 82]}, unionCH=null, actualMembers=[node-2, node-1, node-1], persistentUUIDs=[12443bfb-e88a-46f3-919e-9213bf38ce19, 2873237f-d881-463f-8a5a-940bf1d764e5, a05ea8af-a83b-42a9-b937-dc2da1cae6d1]}
> 09:26:18,869 INFO [org.infinispan.CLUSTER] (remote-thread--p5-t2) [Context=default][Scope=node-2]ISPN100002: Started rebalance with topology id 17
> 09:26:18,870 INFO [org.infinispan.CLUSTER] (transport-thread--p14-t5) [Context=default][Scope=node-2]ISPN100003: Node node-2 finished rebalance phase with topology id 17
> 09:26:18,981 INFO [org.infinispan.CLUSTER] (remote-thread--p5-t2) [Context=default][Scope=node-1]ISPN100003: Node node-1 finished rebalance phase with topology id 17
> 09:27:18,530 WARN [org.infinispan.topology.ClusterTopologyManagerImpl] (transport-thread--p15-t4) ISPN000197: Error updating cluster member list: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 4 from node-1
> at org.infinispan.remoting.transport.impl.MultiTargetRequest.onTimeout(MultiTargetRequest.java:167)
> at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:87)
> at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:22)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_131]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [rt.jar:1.8.0_131]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_131]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_131]
> Suppressed: java.util.concurrent.ExecutionException: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 4 from node-1
> at java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:357) [rt.jar:1.8.0_131]
> at java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1915) [rt.jar:1.8.0_131]
> at org.infinispan.util.concurrent.CompletableFutures.await(CompletableFutures.java:82)
> at org.infinispan.remoting.transport.Transport.invokeRemotely(Transport.java:71)
> at org.infinispan.topology.ClusterTopologyManagerImpl.confirmMembersAvailable(ClusterTopologyManagerImpl.java:540)
> at org.infinispan.topology.ClusterTopologyManagerImpl.updateCacheMembers(ClusterTopologyManagerImpl.java:523)
> at org.infinispan.topology.ClusterTopologyManagerImpl.handleClusterView(ClusterTopologyManagerImpl.java:334)
> at org.infinispan.topology.ClusterTopologyManagerImpl.access$500(ClusterTopologyManagerImpl.java:85)
> at org.infinispan.topology.ClusterTopologyManagerImpl$ClusterViewListener.lambda$handleViewChange$0(ClusterTopologyManagerImpl.java:745)
> at org.infinispan.executors.LimitedExecutor.runTasks(LimitedExecutor.java:144)
> at org.infinispan.executors.LimitedExecutor.access$100(LimitedExecutor.java:33)
> at org.infinispan.executors.LimitedExecutor$Runner.run(LimitedExecutor.java:174)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_131]
> at org.wildfly.clustering.service.concurrent.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:47)
> ... 1 more
> Caused by: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 4 from node-1
> at org.infinispan.remoting.transport.impl.MultiTargetRequest.onTimeout(MultiTargetRequest.java:167)
> at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:87)
> at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:22)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_131]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [rt.jar:1.8.0_131]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_131]
> ... 1 more
> [CIRCULAR REFERENCE:java.util.concurrent.ExecutionException: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 4 from node-1]
> 09:27:18,530 WARN [org.infinispan.topology.ClusterTopologyManagerImpl] (transport-thread--p16-t4) ISPN000197: Error updating cluster member list: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 4 from node-1
> at org.infinispan.remoting.transport.impl.MultiTargetRequest.onTimeout(MultiTargetRequest.java:167)
> at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:87)
> at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:22)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_131]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [rt.jar:1.8.0_131]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_131]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_131]
> Suppressed: java.util.concurrent.ExecutionException: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 4 from node-1
> at java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:357) [rt.jar:1.8.0_131]
> at java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1915) [rt.jar:1.8.0_131]
> at org.infinispan.util.concurrent.CompletableFutures.await(CompletableFutures.java:82)
> at org.infinispan.remoting.transport.Transport.invokeRemotely(Transport.java:71)
> at org.infinispan.topology.ClusterTopologyManagerImpl.confirmMembersAvailable(ClusterTopologyManagerImpl.java:540)
> at org.infinispan.topology.ClusterTopologyManagerImpl.updateCacheMembers(ClusterTopologyManagerImpl.java:523)
> at org.infinispan.topology.ClusterTopologyManagerImpl.handleClusterView(ClusterTopologyManagerImpl.java:334)
> at org.infinispan.topology.ClusterTopologyManagerImpl.access$500(ClusterTopologyManagerImpl.java:85)
> at org.infinispan.topology.ClusterTopologyManagerImpl$ClusterViewListener.lambda$handleViewChange$0(ClusterTopologyManagerImpl.java:745)
> at org.infinispan.executors.LimitedExecutor.runTasks(LimitedExecutor.java:144)
> at org.infinispan.executors.LimitedExecutor.access$100(LimitedExecutor.java:33)
> at org.infinispan.executors.LimitedExecutor$Runner.run(LimitedExecutor.java:174)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_131]
> at org.wildfly.clustering.service.concurrent.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:47)
> ... 1 more
> Caused by: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 4 from node-1
> at org.infinispan.remoting.transport.impl.MultiTargetRequest.onTimeout(MultiTargetRequest.java:167)
> at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:87)
> at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:22)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_131]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [rt.jar:1.8.0_131]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_131]
> ... 1 more
> [CIRCULAR REFERENCE:java.util.concurrent.ExecutionException: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 4 from node-1]
> {code}
> There is default JGroups udp stack configured which is used by Infinispan. Both of the servers (jgroups udp) are bound to 127.0.0.1. Node 2 has port offset 1000.
> Attaching thread dump from node 1 when it hangs during start.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFLY-11121) CI - Master linux JDK 11 job - compilation fails - forked embedded process has failed
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-11121?page=com.atlassian.jira.plugin... ]
James Perkins updated WFLY-11121:
---------------------------------
Fix Version/s: 15.0.0.Final
> CI - Master linux JDK 11 job - compilation fails - forked embedded process has failed
> --------------------------------------------------------------------------------------
>
> Key: WFLY-11121
> URL: https://issues.jboss.org/browse/WFLY-11121
> Project: WildFly
> Issue Type: Bug
> Reporter: Rostislav Svoboda
> Assignee: Alexey Loubyansky
> Priority: Blocker
> Labels: Java11
> Fix For: 15.0.0.Beta1, 15.0.0.Final
>
>
> Compilation of Master linux JDK 11 job fails - forked embedded process has failed.
> https://ci.wildfly.org/viewType.html?buildTypeId=WF_MasterLinuxJdk11
> {code}
> [Step 2/3] [ERROR] Failed to execute goal org.wildfly.galleon-plugins:wildfly-galleon-maven-plugin:
> 2.0.0.Final:generate-feature-specs (feature-spec-build) on project wildfly-servlet-galleon-pack:
> Feature spec generator failed: Forked embedded process has failed -> [Help 1]
> {code}
> My local machine runs are passing for me, using {{java version "11" 2018-09-25 (build 11+28)}}
> This fail can be related to VMs setup on TeamCity, another option can be galleon related issue.
> CCing also [~aloubyansky]
> We need to have valid Java 11 runs on upstream to guard proper functionality of WildFly.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFLY-10945) JDK11 ws testsuite SSL failures
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-10945?page=com.atlassian.jira.plugin... ]
James Perkins updated WFLY-10945:
---------------------------------
Fix Version/s: 15.0.0.Final
> JDK11 ws testsuite SSL failures
> -------------------------------
>
> Key: WFLY-10945
> URL: https://issues.jboss.org/browse/WFLY-10945
> Project: WildFly
> Issue Type: Sub-task
> Components: Test Suite
> Affects Versions: 14.0.0.Beta2
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Blocker
> Fix For: 15.0.0.Beta1, 15.0.0.Final
>
>
> ws testsuite failures on JDK-11:
> * missing local IP in SubjectAlternativeNamesExtension
> * TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 + TLS1.2 seems buggy on JDK-11: Invalid ECDH ServerKeyExchange signature
> * not issue after switching to TLS1.1 or to ciphersuite TLS_RSA_WITH_AES_256_CBC_SHA256 -> JDK bug
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months