[JBoss JIRA] (WFLY-10389) NPE during server shutdown when using scattered cache
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-10389?page=com.atlassian.jira.plugin... ]
James Perkins resolved WFLY-10389.
----------------------------------
Fix Version/s: 15.0.0.Final
Resolution: Done
> NPE during server shutdown when using scattered cache
> -----------------------------------------------------
>
> Key: WFLY-10389
> URL: https://issues.jboss.org/browse/WFLY-10389
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 13.0.0.Beta1
> Reporter: Michal Vinkler
> Assignee: Paul Ferraro
> Priority: Major
> Fix For: 15.0.0.Final, 15.0.0.Beta1
>
>
> We hit NPE when running tests for RFE EAP7-867.
> EAP distribution was built from https://github.com/pferraro/wildfly/tree/scattered .
> Test description: Positive stress test (no failover), 4-node EAP cluster, clients: starting with 400 clients in the beginning, raising the number of clients to 6000 in the end of the test.
> During clean server shutdown in the end of the test, server logged NPE and got stuck:
> {code}
> [JBossINF] [0m[31m07:55:57,643 ERROR [org.infinispan.scattered.impl.ScatteredStateConsumerImpl] (thread-200,ejb,dev214) ISPN000471: Failed processing values received from remote node during rebalance.: java.lang.NullPointerException
> [JBossINF] at org.infinispan.scattered.impl.ScatteredStateConsumerImpl.applyValues(ScatteredStateConsumerImpl.java:505)
> [JBossINF] at org.infinispan.scattered.impl.ScatteredStateConsumerImpl.lambda$getValuesAndApply$8(ScatteredStateConsumerImpl.java:475)
> [JBossINF] at java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:760)
> [JBossINF] at java.util.concurrent.CompletableFuture$UniWhenComplete.tryFire(CompletableFuture.java:736)
> [JBossINF] at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474)
> [JBossINF] at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1962)
> [JBossINF] at org.infinispan.remoting.transport.AbstractRequest.complete(AbstractRequest.java:66)
> [JBossINF] at org.infinispan.remoting.transport.impl.SingleTargetRequest.receiveResponse(SingleTargetRequest.java:56)
> [JBossINF] at org.infinispan.remoting.transport.impl.SingleTargetRequest.onResponse(SingleTargetRequest.java:35)
> [JBossINF] at org.infinispan.remoting.transport.impl.RequestRepository.addResponse(RequestRepository.java:53)
> [JBossINF] at org.infinispan.remoting.transport.jgroups.JGroupsTransport.processResponse(JGroupsTransport.java:1304)
> [JBossINF] at org.infinispan.remoting.transport.jgroups.JGroupsTransport.processMessage(JGroupsTransport.java:1207)
> [JBossINF] at org.infinispan.remoting.transport.jgroups.JGroupsTransport.access$200(JGroupsTransport.java:123)
> [JBossINF] at org.infinispan.remoting.transport.jgroups.JGroupsTransport$ChannelCallbacks.receive(JGroupsTransport.java:1342)
> [JBossINF] at org.jgroups.JChannel.up(JChannel.java:819)
> [JBossINF] at org.jgroups.fork.ForkProtocolStack.up(ForkProtocolStack.java:134)
> [JBossINF] at org.jgroups.stack.Protocol.up(Protocol.java:340)
> [JBossINF] at org.jgroups.protocols.FORK.up(FORK.java:134)
> [JBossINF] at org.jgroups.protocols.FRAG3.up(FRAG3.java:166)
> [JBossINF] at org.jgroups.protocols.FlowControl.up(FlowControl.java:343)
> [JBossINF] at org.jgroups.protocols.FlowControl.up(FlowControl.java:343)
> [JBossINF] at org.jgroups.protocols.pbcast.GMS.up(GMS.java:864)
> [JBossINF] at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:240)
> [JBossINF] at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1002)
> [JBossINF] at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:728)
> [JBossINF] at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:383)
> [JBossINF] at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:600)
> [JBossINF] at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:119)
> [JBossINF] at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:199)
> [JBossINF] at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:252)
> [JBossINF] at org.jgroups.protocols.MERGE3.up(MERGE3.java:276)
> [JBossINF] at org.jgroups.protocols.Discovery.up(Discovery.java:267)
> [JBossINF] at org.jgroups.protocols.TP.passMessageUp(TP.java:1248)
> [JBossINF] at org.jgroups.util.SubmitToThreadPool$SingleMessageHandler.run(SubmitToThreadPool.java:87)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [JBossINF] at org.jboss.as.clustering.jgroups.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:52)
> [JBossINF] at java.lang.Thread.run(Thread.java:748)
> [JBossINF]
> {code}
> Scattered cache was configured with bias-lifespan="0".
> Server configuration:
> http://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/eap-7x-stress-ses...
> Server link:
> http://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/eap-7x-stress-ses...
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFLY-10976) Artemis warnings during startup
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-10976?page=com.atlassian.jira.plugin... ]
James Perkins updated WFLY-10976:
---------------------------------
Fix Version/s: 15.0.0.Final
> Artemis warnings during startup
> -------------------------------
>
> Key: WFLY-10976
> URL: https://issues.jboss.org/browse/WFLY-10976
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 14.0.0.Final
> Reporter: Rich DiCroce
> Assignee: Brian Stansberry
> Priority: Major
> Fix For: 15.0.0.Beta1, 15.0.0.Final
>
>
> Artemis logs these warnings during startup when using the stock standalone-full.xml configuration:
> {code}
> 12:11:31,997 WARN [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 62) AMQ222269: Please use a fixed value for "journal-pool-files". Default changed per https://issues.apache.org/jira/browse/ARTEMIS-1628
> 12:11:32,000 INFO [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 62) AMQ221075: Usage of wildcardRoutingEnabled configuration property is deprecated, please use wildCardConfiguration.enabled instead
> {code}
> It looks like there's a config option that could be used to silence the first one, but I have no idea what the second one is talking about.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFLY-10247) undefine connectors attribute of broadcast-group throws IllegalArgumentException
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-10247?page=com.atlassian.jira.plugin... ]
James Perkins updated WFLY-10247:
---------------------------------
Fix Version/s: 15.0.0.Final
> undefine connectors attribute of broadcast-group throws IllegalArgumentException
> --------------------------------------------------------------------------------
>
> Key: WFLY-10247
> URL: https://issues.jboss.org/browse/WFLY-10247
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Claudio Miranda
> Assignee: Bartosz Baranowski
> Priority: Major
> Fix For: 15.0.0.Beta1, 15.0.0.Final
>
>
> {code}
> /profile=full-ha/subsystem=messaging-activemq/server=default/broadcast-group=bg-group1:undefine-attribute(name=connectors)
> {
> "outcome" => "failed",
> "failure-description" => {"domain-failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException"},
> "rolled-back" => true
> }
> {code}
> {code}
> 2018-04-16 15:41:16,830 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("undefine-attribute") failed - address: ([
> ("profile" => "full-ha"),
> ("subsystem" => "messaging-activemq"),
> ("server" => "default"),
> ("broadcast-group" => "bg-group1")
> ]): java.lang.IllegalArgumentException
> at org.jboss.dmr.ModelValue.asList(ModelValue.java:143)
> at org.jboss.dmr.ModelNode.asList(ModelNode.java:1592)
> at org.wildfly.extension.messaging.activemq.BroadcastGroupDefinition.validateConnectors(BroadcastGroupDefinition.java:149)
> at org.wildfly.extension.messaging.activemq.BroadcastGroupWriteAttributeHandler.finishModelStage(BroadcastGroupWriteAttributeHandler.java:47)
> at org.jboss.as.controller.AbstractWriteAttributeHandler.execute(AbstractWriteAttributeHandler.java:95)
> at org.jboss.as.controller.operations.global.WriteAttributeHandler.doExecuteInternal(WriteAttributeHandler.java:194)
> at org.jboss.as.controller.operations.global.WriteAttributeHandler.execute(WriteAttributeHandler.java:115)
> at org.jboss.as.controller.operations.global.UndefineAttributeHandler.execute(UndefineAttributeHandler.java:52)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:982)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:726)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:450)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1408)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:423)
> at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:243)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:263)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:229)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:243)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:240)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$400(ModelControllerClientOperationHandler.java:138)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:162)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:158)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:287)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:244)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:158)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
> 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:1378)
> at java.lang.Thread.run(Thread.java:748)
> at org.jboss.threads.JBossThread.run(JBossThread.java:485)
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFLY-10961) MP-OpenTracing Jaeger's can't see a concrete sender
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-10961?page=com.atlassian.jira.plugin... ]
James Perkins updated WFLY-10961:
---------------------------------
Fix Version/s: 15.0.0.Final
> MP-OpenTracing Jaeger's can't see a concrete sender
> ---------------------------------------------------
>
> Key: WFLY-10961
> URL: https://issues.jboss.org/browse/WFLY-10961
> Project: WildFly
> Issue Type: Bug
> Components: MP OpenTracing
> Affects Versions: 14.0.0.Final
> Reporter: Juraci Paixão Kröhling
> Assignee: Juraci Paixão Kröhling
> Priority: Major
> Fix For: 15.0.0.Beta1, 15.0.0.Final
>
>
> One of the last changes made to WF 14 was to split the MP-OpenTracing dependencies into smaller modules. This introduced a bug where the Jaeger Core module can't see a Sender from Jaeger Thrift. This is loaded via the Service Loader, so, Jaeger Core has to be shipped with Jaeger Thrift on the same module, to avoid a circular dependency (as Jaeger Thrift depends on classes defined on Jaeger Core).
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFLY-10389) NPE during server shutdown when using scattered cache
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-10389?page=com.atlassian.jira.plugin... ]
James Perkins reopened WFLY-10389:
----------------------------------
> NPE during server shutdown when using scattered cache
> -----------------------------------------------------
>
> Key: WFLY-10389
> URL: https://issues.jboss.org/browse/WFLY-10389
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 13.0.0.Beta1
> Reporter: Michal Vinkler
> Assignee: Paul Ferraro
> Priority: Major
> Fix For: 15.0.0.Beta1, 15.0.0.Final
>
>
> We hit NPE when running tests for RFE EAP7-867.
> EAP distribution was built from https://github.com/pferraro/wildfly/tree/scattered .
> Test description: Positive stress test (no failover), 4-node EAP cluster, clients: starting with 400 clients in the beginning, raising the number of clients to 6000 in the end of the test.
> During clean server shutdown in the end of the test, server logged NPE and got stuck:
> {code}
> [JBossINF] [0m[31m07:55:57,643 ERROR [org.infinispan.scattered.impl.ScatteredStateConsumerImpl] (thread-200,ejb,dev214) ISPN000471: Failed processing values received from remote node during rebalance.: java.lang.NullPointerException
> [JBossINF] at org.infinispan.scattered.impl.ScatteredStateConsumerImpl.applyValues(ScatteredStateConsumerImpl.java:505)
> [JBossINF] at org.infinispan.scattered.impl.ScatteredStateConsumerImpl.lambda$getValuesAndApply$8(ScatteredStateConsumerImpl.java:475)
> [JBossINF] at java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:760)
> [JBossINF] at java.util.concurrent.CompletableFuture$UniWhenComplete.tryFire(CompletableFuture.java:736)
> [JBossINF] at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474)
> [JBossINF] at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1962)
> [JBossINF] at org.infinispan.remoting.transport.AbstractRequest.complete(AbstractRequest.java:66)
> [JBossINF] at org.infinispan.remoting.transport.impl.SingleTargetRequest.receiveResponse(SingleTargetRequest.java:56)
> [JBossINF] at org.infinispan.remoting.transport.impl.SingleTargetRequest.onResponse(SingleTargetRequest.java:35)
> [JBossINF] at org.infinispan.remoting.transport.impl.RequestRepository.addResponse(RequestRepository.java:53)
> [JBossINF] at org.infinispan.remoting.transport.jgroups.JGroupsTransport.processResponse(JGroupsTransport.java:1304)
> [JBossINF] at org.infinispan.remoting.transport.jgroups.JGroupsTransport.processMessage(JGroupsTransport.java:1207)
> [JBossINF] at org.infinispan.remoting.transport.jgroups.JGroupsTransport.access$200(JGroupsTransport.java:123)
> [JBossINF] at org.infinispan.remoting.transport.jgroups.JGroupsTransport$ChannelCallbacks.receive(JGroupsTransport.java:1342)
> [JBossINF] at org.jgroups.JChannel.up(JChannel.java:819)
> [JBossINF] at org.jgroups.fork.ForkProtocolStack.up(ForkProtocolStack.java:134)
> [JBossINF] at org.jgroups.stack.Protocol.up(Protocol.java:340)
> [JBossINF] at org.jgroups.protocols.FORK.up(FORK.java:134)
> [JBossINF] at org.jgroups.protocols.FRAG3.up(FRAG3.java:166)
> [JBossINF] at org.jgroups.protocols.FlowControl.up(FlowControl.java:343)
> [JBossINF] at org.jgroups.protocols.FlowControl.up(FlowControl.java:343)
> [JBossINF] at org.jgroups.protocols.pbcast.GMS.up(GMS.java:864)
> [JBossINF] at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:240)
> [JBossINF] at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1002)
> [JBossINF] at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:728)
> [JBossINF] at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:383)
> [JBossINF] at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:600)
> [JBossINF] at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:119)
> [JBossINF] at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:199)
> [JBossINF] at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:252)
> [JBossINF] at org.jgroups.protocols.MERGE3.up(MERGE3.java:276)
> [JBossINF] at org.jgroups.protocols.Discovery.up(Discovery.java:267)
> [JBossINF] at org.jgroups.protocols.TP.passMessageUp(TP.java:1248)
> [JBossINF] at org.jgroups.util.SubmitToThreadPool$SingleMessageHandler.run(SubmitToThreadPool.java:87)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [JBossINF] at org.jboss.as.clustering.jgroups.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:52)
> [JBossINF] at java.lang.Thread.run(Thread.java:748)
> [JBossINF]
> {code}
> Scattered cache was configured with bias-lifespan="0".
> Server configuration:
> http://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/eap-7x-stress-ses...
> Server link:
> http://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/eap-7x-stress-ses...
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFLY-10784) WeldStartCompletionService failed when optional components not installed
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-10784?page=com.atlassian.jira.plugin... ]
James Perkins updated WFLY-10784:
---------------------------------
Fix Version/s: 15.0.0.Final
> WeldStartCompletionService failed when optional components not installed
> ------------------------------------------------------------------------
>
> Key: WFLY-10784
> URL: https://issues.jboss.org/browse/WFLY-10784
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 12.0.0.Final, 13.0.0.Final
> Reporter: Alexander Kudrevatykh
> Assignee: Matej Novotny
> Priority: Major
> Fix For: 15.0.0.Beta1, 15.0.0.Final
>
> Attachments: arq-test.tar.xz
>
>
> WebComponents are optional and fail in initialising it not causes fail of deployment, but when starting EAR application with included WAR fail in deployment since Wildfly 12 because WeldStartCompletionService depends on all components regardless of their type
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFLY-10630) HttpSessionListener.sessionDestroyed() not called if session invalidated in another WAR
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-10630?page=com.atlassian.jira.plugin... ]
James Perkins updated WFLY-10630:
---------------------------------
Fix Version/s: 15.0.0.Final
> HttpSessionListener.sessionDestroyed() not called if session invalidated in another WAR
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-10630
> URL: https://issues.jboss.org/browse/WFLY-10630
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.Final, 13.0.0.Final
> Environment: Windows 10, Java 1.8.0_131
> Reproducible with both WildFly-10.0.0.Final and Wildfly-13.0.0.Final
> Reporter: Bernhard Kabelka
> Assignee: Paul Ferraro
> Priority: Major
> Fix For: 15.0.0.Beta1, 15.0.0.Final
>
> Attachments: LoginForm.png, roles.properties, sessionlistener-test.ear, standalone.xml, users.properties
>
>
> For sessions shared across different WARs in a single EAR, the notification of HttpSessionListener works differently in WildFly 10.0.0.Final (and Wildfly 13.0.0.Final) than it it used to work in WildFly 8.2.0.Final:
> I have an EAR containing two WARs with enabled session sharing across the WARs. Basically, one WAR contains the web UI, and the other WAR contains the REST interfaces for AJAX calls made by the UI. The user authenticates against the UI-WAR. On logout, a REST method in the AJAX-WAR is triggered which calls HttpSession.invalidate() on the user session.
> In WildFly 8.2.0.Final, a HttpSessionListener in the UI-WAR gets notified immediately about session creation and destruction.
> In WildFly 13.0.0.Final, however, a HttpSessionListener in either WAR only gets one of the two notifications:
> * In the UI-WAR, I get a notification about the created session immediately when the login form is loaded. However, I do not receive any notification about the session destruction (unless it times out).
> * In the AJAX-WAR, I do not get any notification about the session creation at all, but I immediately receive a notification about the session destruction.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months