[JBoss JIRA] (WFCORE-1305) LoggingSubsystemRollbackTestCase fails intermittently
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1305?page=com.atlassian.jira.plugi... ]
James Perkins closed WFCORE-1305.
---------------------------------
Resolution: Out of Date
> LoggingSubsystemRollbackTestCase fails intermittently
> -----------------------------------------------------
>
> Key: WFCORE-1305
> URL: https://issues.jboss.org/browse/WFCORE-1305
> Project: WildFly Core
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 2.0.6.Final
> Reporter: Marek Kopecký
> Assignee: James Perkins
>
> *Description of problem:*
> LoggingSubsystemRollbackTestCase from wildfly-core fails intermittently.
> *How reproducible:*
> 40% with IBM JDK
> *Steps to Reproduce:*
> # mvn install -Dmaven.repo.local=$MAVEN_REPO_LOCAL -fae -Dmaven.test.failure.ignore=true -Dnode0=$MYTESTIP_1 -Dmcast=$MCAST_ADDR -DfailIfNoTests=false -Dts.domain -Dtest=LoggingSubsystemRollbackTestCase
> *Stacktrace:*
> {noformat}
> com.sun.tools.attach.AttachNotSupportedException: target not found
> at ibm.tools.attach.J9AttachProvider.attachVirtualMachine(J9AttachProvider.java:60)
> at com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:231)
> at org.jboss.byteman.agent.install.Install.attach(Install.java:390)
> at org.jboss.byteman.agent.install.Install.install(Install.java:129)
> at org.jboss.byteman.contrib.bmunit.BMUnitConfigState.loadAgent(BMUnitConfigState.java:516)
> at org.jboss.byteman.contrib.bmunit.BMUnitConfigState.pushConfigurationState(BMUnitConfigState.java:669)
> at org.jboss.byteman.contrib.bmunit.BMUnitRunner$1.evaluate(BMUnitRunner.java:73)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:113)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:85)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:54)
> at org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:134)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> {noformat}
> *Standard Output:*
> {noformat}
> byteman jar is /mnt/hudson_workspace/eap-7x-as-testsuite-test-core-rhel/19de6045/eap-local-maven-repository/org/jboss/byteman/byteman/2.2.1/byteman-2.2.1.jar
> {noformat}
> *Expected results:*
> No errors
> *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)
7 years, 10 months
- 1
- 0
[JBoss JIRA] (WFCORE-1556) Poor handling of 'required', 'nillable' and 'alternatives' in AttributeDefinition
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1556?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1556:
------------------------------------------
WFCORE-1761 is for the org.jboss.as.server.mgmt.NativeManagementResourceDefinition SOCKET_BINDING thing I noted in my first comment.
It occurred to me that this work might break our JMX integration but it looks like the OpenMBeanAttributeInfo we generate from our descriptions does not deal with required/alternatives/nillable in any way so we are free to do what we want there.
> Poor handling of 'required', 'nillable' and 'alternatives' in AttributeDefinition
> ---------------------------------------------------------------------------------
>
> Key: WFCORE-1556
> URL: https://issues.jboss.org/browse/WFCORE-1556
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
>
> The handling of the notions of 'required' and 'nillable' don't comply with the specs in https://docs.jboss.org/author/display/WFLY10/Description+of+the+Managemen..., particularly the "Description of an Attribute" part, where the 'required' and 'alternatives' fields are well described, with their relationship spelled out, while 'nillable' doesn't appear at all. Then in "Description of an Operation Parameter or Return Value" nillable is specified, although I think those descriptions could be tightened up in general.
> The read-resource-description output for an attribute doesn't show "required" at all.
> After a fair bit of thinking, I've finally recalled why the two separate notions of "required" and "nillable" exist in the first place.
> The "required" and "alternatives" pieces go together. Is something required? And then if it is required, an alternative satisfies. So you can have two attributes/params, both required, but they are alternatives so one is defined and the other is not. And this is an ok thing.
> And then 'nillable' comes in to help clients understand in a simple way whether they need to account for the possibility an undefined value. Basically:
> nillable = !required || alternatives != null
> Right now, nillable is implemented as
> nillable = !required
> There are a number of problems I see with AttributeDefinition:
> 1) We don't output the 'required' metadata unless it's an operation param being described. This is contrary to spec. However we shouldn't fix this unless we can have meaningful values for 'required', ones where the value can be true but the attribute/param can still have an undefined value, due to an alternative being present. If we can't fix that, there's no point outputting required as it's just redundant with what we output for 'nillable'.
> 2) We do output the 'nillable' metadata, even for attribute descriptions, where it isn't in the spec. But in this case I think we change the spec, as dropping nillable would be an incompatible change.
> 3) We don't properly validate the "required but has alternatives case." This can't be validated solely with ParameterValidator impls as those only see a single attribute value and don't have contextual information about other attributes/params. To get around this limitation, devs are saying that attributes with alternatives "allowNull" which is equivalent to saying they are not required. But they are required! So I think a fix for this will require AttributeDefinition itself to validate the overall resource model or operation object, and skip calling the ParameterValidator if the attribute/param is undefined and an alternative is defined.
> 4) AttributeDefinition and AbstractAttributeDefinitionBuilder unfortunately have a getter/setter/constructor param for property "allowNull" instead of a property named "required". This is unfortunate because "allowNull" intuitively maps to "nillable", but "required" is a much more useful thing to set. The value of "nillable" can be derived from a "required" setting and an "alternatives" setting, but the value of required cannot be so derived.
> I think a fix for this would probably start from 4), deprecating setAllowNull, adding get/setRequired and changing the meaning of the AD(Builder) constructor param to "required". The effect of this would be that all current code setting "allowNull" would now be setting a new "required" field. This should be a non-breaking change as in current code that's the effect anyway.
> Next would be to fix 3), by changing how AD validates.
> Next would be to change the metadata we output, such that "required" is always present and the "nillable" value is !required || alternatives != null. And change the spec accordingly.
> Last, in a separate task, would be to find attributes that were configuring "allowNull = true" solely to allow validation to pass when alternatives are present, and fix them to say "required=false".
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 10 months
- 1
- 0
[JBoss JIRA] (DROOLS-1270) support fact handle operations for REST APIs on kie server
by Edson Tirelli (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1270?page=com.atlassian.jira.plugi... ]
Edson Tirelli commented on DROOLS-1270:
---------------------------------------
Can you please clarify your request and provide an example?
> support fact handle operations for REST APIs on kie server
> ----------------------------------------------------------
>
> Key: DROOLS-1270
> URL: https://issues.jboss.org/browse/DROOLS-1270
> Project: Drools
> Issue Type: Enhancement
> Components: kie server
> Affects Versions: 6.5.0.CR1
> Environment: kie server
> Reporter: Dan Cimpoesu
> Assignee: Edson Tirelli
> Fix For: 6.5.0.Final
>
>
> Please support fact handle operations for REST APIs on kie server.
> Fact handle operations are currently not supported in kie server as they usually bring less value in rule based systems where most of the operations are stateless. Though they do provide rather big value for processes integrated with rules.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 10 months
- 1
- 0
[JBoss JIRA] (WFLY-7034) JDR is not collecting the file .overlays, layer.conf, version.txt config files
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-7034?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated WFLY-7034:
------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1372781
Bugzilla Update: Perform
> JDR is not collecting the file .overlays, layer.conf, version.txt config files
> ------------------------------------------------------------------------------
>
> Key: WFLY-7034
> URL: https://issues.jboss.org/browse/WFLY-7034
> Project: WildFly
> Issue Type: Bug
> Components: JDR
> Affects Versions: 10.1.0.Final
> Reporter: Brad Maxwell
> Assignee: Brad Maxwell
> Priority: Minor
>
> The JDR report when collecting files should be collecting
> $JBOSS_HOME/modules/system/layers/base/.overlays/.overlays
> $JBOSS_HOME/.installation/identity.conf
> $JBOSS_HOME/.installation/layers/base/layer.conf
> $JBOSS_HOME/.installation/patches/*/misc/version.txt
> This file is needed to confirm overlay priority and other layer configurations to make sure the installation is not corrupted.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 10 months
- 1
- 0
[JBoss JIRA] (WFLY-7035) [GSS](7.1.0) JDR is not collecting the file .overlays, layer.conf, version.txt config files
by Brad Maxwell (JIRA)
Brad Maxwell created WFLY-7035:
----------------------------------
Summary: [GSS](7.1.0) JDR is not collecting the file .overlays, layer.conf, version.txt config files
Key: WFLY-7035
URL: https://issues.jboss.org/browse/WFLY-7035
Project: WildFly
Issue Type: Bug
Components: JDR
Affects Versions: 10.1.0.Final
Reporter: Brad Maxwell
Assignee: Brad Maxwell
Priority: Minor
The JDR report when collecting files should be collecting
$JBOSS_HOME/modules/system/layers/base/.overlays/.overlays
$JBOSS_HOME/.installation/identity.conf
$JBOSS_HOME/.installation/layers/base/layer.conf
$JBOSS_HOME/.installation/patches/*/misc/version.txt
This file is needed to confirm overlay priority and other layer configurations to make sure the installation is not corrupted.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 10 months
- 1
- 0
[JBoss JIRA] (WFLY-7034) JDR is not collecting the file .overlays, layer.conf, version.txt config files
by Brad Maxwell (JIRA)
Brad Maxwell created WFLY-7034:
----------------------------------
Summary: JDR is not collecting the file .overlays, layer.conf, version.txt config files
Key: WFLY-7034
URL: https://issues.jboss.org/browse/WFLY-7034
Project: WildFly
Issue Type: Bug
Components: JDR
Affects Versions: 10.1.0.Final
Reporter: Brad Maxwell
Assignee: Brad Maxwell
Priority: Minor
The JDR report when collecting files should be collecting
$JBOSS_HOME/modules/system/layers/base/.overlays/.overlays
$JBOSS_HOME/.installation/identity.conf
$JBOSS_HOME/.installation/layers/base/layer.conf
$JBOSS_HOME/.installation/patches/*/misc/version.txt
This file is needed to confirm overlay priority and other layer configurations to make sure the installation is not corrupted.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 10 months
- 1
- 0
[JBoss JIRA] (WFLY-7029) RemoteFailoverTestCast#testGracefulShutdownConcurrentFailover fails with "ISPN000324: remote-failover-test.jar is in 'STOPPING' state and this is an invocation not belonging to an on-going transaction, so it does not accept new invocations."
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-7029?page=com.atlassian.jira.plugin.... ]
Radoslav Husar edited comment on WFLY-7029 at 9/2/16 3:31 PM:
--------------------------------------------------------------
Possible cause might be fix for ISPN-5918 with commit: https://github.com/infinispan/infinispan/pull/3805/commits/f8039053d6d76e...
was (Author: rhusar):
Possible cause https://github.com/infinispan/infinispan/pull/3805/commits/f8039053d6d76e...
> RemoteFailoverTestCast#testGracefulShutdownConcurrentFailover fails with "ISPN000324: remote-failover-test.jar is in 'STOPPING' state and this is an invocation not belonging to an on-going transaction, so it does not accept new invocations."
> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7029
> URL: https://issues.jboss.org/browse/WFLY-7029
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.1.0.Final
> Reporter: Radoslav Husar
> Assignee: Richard Achmatowicz
>
> https://ci.wildfly.org/viewLog.html?buildId=24851&tab=buildResultsDiv&bui...
> {noformat}
> 04:31:43,323 INFO [org.jboss.as.test.clustering.NodeUtil] (main) Stopping container=container-0, timeout=15
> 04:31:43,324 INFO [org.jboss.as.arquillian.container.controller.ClientWildFlyContainerController] (main) Manual stopping of a server instance with timeout=15
> [0m04:31:43,338 INFO [org.jboss.as.server] (management-handler-thread - 4) WFLYSRV0211: Suspending server with 15000 ms timeout.
> [0m04:31:43,343 INFO [org.jboss.ejb.client.remoting.NoSuchEJBExceptionResponseHandler] (Remoting "config-based-ejb-client-endpoint" task-10) Retrying invocation which failed on node node-0 with exception:: javax.ejb.NoSuchEJBException: No such EJB[appname=,modulename=remote-failover-test,distinctname=,beanname=SlowToDestroyStatefulIncrementorBean,viewclassname=org.jboss.as.test.clustering.cluster.ejb.remote.bean.Incrementor]
> at org.jboss.ejb.client.remoting.NoSuchEJBExceptionResponseHandler.processMessage(NoSuchEJBExceptionResponseHandler.java:64)
> at org.jboss.ejb.client.remoting.ChannelAssociation.processResponse(ChannelAssociation.java:386)
> at org.jboss.ejb.client.remoting.ChannelAssociation$ResponseReceiver.handleMessage(ChannelAssociation.java:498)
> at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:456)
> at org.jboss.remoting3.EndpointImpl$TrackingExecutor$1.run(EndpointImpl.java:731)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> [0m04:31:43,345 INFO [org.jboss.as.server] (Management Triggered Shutdown) WFLYSRV0241: Shutting down in response to management operation 'shutdown'
> [0m[0m04:31:43,430 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0019: Host default-host stopping
> [0m[0m04:31:43,436 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 29) MODCLUSTER000002: Initiating mod_cluster shutdown
> [0m[0m04:31:43,445 INFO [org.wildfly.extension.messaging-activemq] (ServerService Thread Pool -- 74) WFLYMSGAMQ0006: Unbound messaging object to jndi name java:/ConnectionFactory
> [0m[0m04:31:43,459 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000080: Disconnecting JGroups channel hibernate
> [0m[0m04:31:43,459 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000082: Stopping the RpcDispatcher for channel hibernate
> [0m[0m04:31:43,463 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN000080: Disconnecting JGroups channel server
> [0m[0m04:31:43,464 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN000082: Stopping the RpcDispatcher for channel server
> [0m[0m04:31:43,471 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 29) ISPN000029: Passivating all entries to disk
> [0m[0m04:31:43,472 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 29) ISPN000030: Passivated 2 entries in 0 milliseconds
> [0m[0m04:31:43,501 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000080: Disconnecting JGroups channel web
> [0m[0m04:31:43,501 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000082: Stopping the RpcDispatcher for channel web
> [0m[0m04:31:43,502 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 29) WFLYCLINF0003: Stopped remote-failover-test.jar cache from ejb container
> [0m[0m04:31:43,505 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000080: Disconnecting JGroups channel testDbPersistence
> [0m[0m04:31:43,505 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000082: Stopping the RpcDispatcher for channel testDbPersistence
> &#27;[0m&#27;[33m04:31:43,502 WARN [org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler] (thread-11,ee,node-0) ISPN000071: Caught exception when handling command LockControlCommand{cache=remote-failover-test.jar, keys=[UnknownSessionID [6951504948515351686656515249505365655750686851525048706670486766]], flags=[FORCE_WRITE_LOCK], unlock=false, gtx=GlobalTransaction:<node-1>:48:remote}: org.infinispan.IllegalLifecycleStateException: ISPN000324: remote-failover-test.jar is in 'STOPPING' state and this is an invocation not belonging to an on-going transaction, so it does not accept new invocations. Either restart it or recreate the cache container.
> at org.infinispan.transaction.impl.TransactionTable.getOrCreateRemoteTransaction(TransactionTable.java:364)
> at org.infinispan.transaction.impl.TransactionTable.getOrCreateRemoteTransaction(TransactionTable.java:354)
> at org.infinispan.commands.control.LockControlCommand.createContext(LockControlCommand.java:138)
> at org.infinispan.commands.control.LockControlCommand.createContext(LockControlCommand.java:38)
> at org.infinispan.remoting.inboundhandler.action.PendingTxAction.createContext(PendingTxAction.java:107)
> at org.infinispan.remoting.inboundhandler.action.PendingTxAction.init(PendingTxAction.java:57)
> at org.infinispan.remoting.inboundhandler.action.BaseLockingAction.check(BaseLockingAction.java:38)
> at org.infinispan.remoting.inboundhandler.action.DefaultReadyAction.isReady(DefaultReadyAction.java:42)
> at org.infinispan.remoting.inboundhandler.action.DefaultReadyAction.isReady(DefaultReadyAction.java:45)
> at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler$1.isReady(NonTotalOrderTxPerCacheInboundInvocationHandler.java:124)
> at org.infinispan.util.concurrent.BlockingTaskAwareExecutorServiceImpl.execute(BlockingTaskAwareExecutorServiceImpl.java:51)
> at org.infinispan.executors.LazyInitializingBlockingTaskAwareExecutorService.execute(LazyInitializingBlockingTaskAwareExecutorService.java:46)
> at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.handleRunnable(BasePerCacheInboundInvocationHandler.java:130)
> at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler.handle(NonTotalOrderTxPerCacheInboundInvocationHandler.java:99)
> at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleCacheRpcCommand(GlobalInboundInvocationHandler.java:126)
> at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleFromCluster(GlobalInboundInvocationHandler.java:75)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommandFromLocalCluster(CommandAwareRpcDispatcher.java:205)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:175)
> at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:455)
> at org.jgroups.blocks.RequestCorrelator.dispatch(RequestCorrelator.java:406)
> at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:357)
> at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:245)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:664)
> at org.jgroups.JChannel.up(JChannel.java:738)
> at org.jgroups.fork.ForkProtocolStack.up(ForkProtocolStack.java:120)
> at org.jgroups.stack.Protocol.up(Protocol.java:380)
> at org.jgroups.protocols.FORK.up(FORK.java:114)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:390)
> at org.jgroups.protocols.pbcast.GMS.up(GMS.java:1040)
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234)
> at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1070)
> at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:785)
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426)
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:649)
> at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:155)
> at org.jgroups.protocols.FD.up(FD.java:260)
> at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:310)
> at org.jgroups.protocols.MERGE3.up(MERGE3.java:285)
> at org.jgroups.protocols.Discovery.up(Discovery.java:296)
> at org.jgroups.protocols.MPING.up(MPING.java:178)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1601)
> at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1817)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at org.jboss.as.clustering.jgroups.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:52)
> at java.lang.Thread.run(Thread.java:745)
> &#27;[0m&#27;[0m04:31:43,517 INFO [org.wildfly.extension.messaging-activemq] (MSC service thread 1-2) WFLYMSGAMQ0006: Unbound messaging object to jndi name java:jboss/DefaultJMSConnectionFactory
> &#27;[0m&#27;[0m04:31:43,517 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS]
> &#27;[0m&#27;[0m04:31:43,518 INFO [org.jboss.as.connector.deployment] (MSC service thread 1-4) WFLYJCA0011: Unbound JCA ConnectionFactory [java:/JmsXA]
> &#27;[0m&#27;[0m04:31:43,535 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-8) WFLYJCA0019: Stopped Driver service with driver-name = h2
> &#27;[0m&#27;[0m04:31:43,547 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 2) WFLYCLINF0003: Stopped client-mappings cache from ejb container
> &#27;[0m04:31:43,565 INFO [org.jboss.ejb.client.remoting] (Remoting "config-based-ejb-client-endpoint" task-14) EJBCLIENT000016: Channel Channel ID b007a55b (outbound) of Remoting connection 017c35ab to /0:0:0:0:0:0:0:1:8080 of endpoint "config-based-ejb-client-endpoint" <1c33eee> can no longer process messages
> &#27;[0m04:31:43,576 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000080: Disconnecting JGroups channel ejb
> &#27;[0m&#27;[0m04:31:43,576 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000082: Stopping the RpcDispatcher for channel ejb
> &#27;[0m&#27;[0m04:31:43,575 INFO [org.apache.activemq.artemis.ra] (ServerService Thread Pool -- 35) AMQ151003: resource adaptor stopped
> &#27;[0m&#27;[0m04:31:43,591 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0008: Undertow AJP listener ajp suspending
> &#27;[0m&#27;[0m04:31:43,591 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0007: Undertow AJP listener ajp stopped, was bound to [::1]:8009
> &#27;[0m&#27;[0m04:31:43,592 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0008: Undertow HTTPS listener https suspending
> &#27;[0m&#27;[0m04:31:43,592 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0007: Undertow HTTPS listener https stopped, was bound to [::1]:8443
> &#27;[0m&#27;[31m04:31:43,585 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-11) ISPN000136: Error executing command GetKeyValueCommand, writing keys []: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from node-0, see cause for remote stack trace
> at org.infinispan.remoting.transport.AbstractTransport.checkResponse(AbstractTransport.java:44)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:795)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$1(JGroupsTransport.java:642)
> at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602)
> at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577)
> at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474)
> at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1962)
> at org.infinispan.remoting.transport.jgroups.RspListFuture.futureDone(RspListFuture.java:31)
> at org.jgroups.blocks.Request.checkCompletion(Request.java:152)
> at org.jgroups.blocks.GroupRequest.receiveResponse(GroupRequest.java:116)
> at org.jgroups.blocks.RequestCorrelator.dispatch(RequestCorrelator.java:427)
> at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:357)
> at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:245)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:664)
> at org.jgroups.JChannel.up(JChannel.java:738)
> at org.jgroups.fork.ForkProtocolStack.up(ForkProtocolStack.java:120)
> at org.jgroups.stack.Protocol.up(Protocol.java:380)
> at org.jgroups.protocols.FORK.up(FORK.java:114)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:390)
> at org.jgroups.protocols.pbcast.GMS.up(GMS.java:1040)
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234)
> at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1070)
> at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:785)
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426)
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:649)
> at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:155)
> at org.jgroups.protocols.FD.up(FD.java:260)
> at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:310)
> at org.jgroups.protocols.MERGE3.up(MERGE3.java:285)
> at org.jgroups.protocols.Discovery.up(Discovery.java:296)
> at org.jgroups.protocols.MPING.up(MPING.java:178)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1601)
> at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1817)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at org.jboss.as.clustering.jgroups.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:52)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.infinispan.commons.CacheException: Problems invoking command.
> at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.exceptionHandlingCommand(BasePerCacheInboundInvocationHandler.java:106)
> at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler.handle(NonTotalOrderTxPerCacheInboundInvocationHandler.java:101)
> at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleCacheRpcCommand(GlobalInboundInvocationHandler.java:126)
> at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleFromCluster(GlobalInboundInvocationHandler.java:75)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommandFromLocalCluster(CommandAwareRpcDispatcher.java:205)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:175)
> at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:455)
> at org.jgroups.blocks.RequestCorrelator.dispatch(RequestCorrelator.java:406)
> ... 27 more
> Caused by: org.infinispan.IllegalLifecycleStateException: ISPN000324: remote-failover-test.jar is in 'STOPPING' state and this is an invocation not belonging to an on-going transaction, so it does not accept new invocations. Either restart it or recreate the cache container.
> at org.infinispan.transaction.impl.TransactionTable.getOrCreateRemoteTransaction(TransactionTable.java:364)
> at org.infinispan.transaction.impl.TransactionTable.getOrCreateRemoteTransaction(TransactionTable.java:354)
> at org.infinispan.commands.control.LockControlCommand.createContext(LockControlCommand.java:138)
> at org.infinispan.commands.control.LockControlCommand.createContext(LockControlCommand.java:38)
> at org.infinispan.remoting.inboundhandler.action.PendingTxAction.createContext(PendingTxAction.java:107)
> at org.infinispan.remoting.inboundhandler.action.PendingTxAction.init(PendingTxAction.java:57)
> at org.infinispan.remoting.inboundhandler.action.BaseLockingAction.check(BaseLockingAction.java:38)
> at org.infinispan.remoting.inboundhandler.action.DefaultReadyAction.isReady(DefaultReadyAction.java:42)
> at org.infinispan.remoting.inboundhandler.action.DefaultReadyAction.isReady(DefaultReadyAction.java:45)
> at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler$1.isReady(NonTotalOrderTxPerCacheInboundInvocationHandler.java:124)
> at org.infinispan.util.concurrent.BlockingTaskAwareExecutorServiceImpl.execute(BlockingTaskAwareExecutorServiceImpl.java:51)
> at org.infinispan.executors.LazyInitializingBlockingTaskAwareExecutorService.execute(LazyInitializingBlockingTaskAwareExecutorService.java:46)
> at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.handleRunnable(BasePerCacheInboundInvocationHandler.java:130)
> at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler.handle(NonTotalOrderTxPerCacheInboundInvocationHandler.java:99)
> ... 33 more
> &#27;[0m&#27;[31m04:31:43,588 ERROR [org.jboss.as.ejb3.invocation] (default task-11) WFLYEJB0034: EJB Invocation failed on component SlowToDestroyStatefulIncrementorBean for method public abstract org.jboss.as.test.clustering.cluster.ejb.remote.bean.Result org.jboss.as.test.clustering.cluster.ejb.remote.bean.Incrementor.increment(): javax.ejb.EJBException: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from node-0, see cause for remote stack trace
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:187)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:277)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:53)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:328)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:67)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:201)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:263)
> at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.processMessage(VersionOneProtocolChannelReceiver.java:213)
> at org.jboss.as.ejb3.remote.protocol.versiontwo.VersionTwoProtocolChannelReceiver.processMessage(VersionTwoProtocolChannelReceiver.java:76)
> at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.handleMessage(VersionOneProtocolChannelReceiver.java:159)
> at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:456)
> at org.jboss.remoting3.EndpointImpl$TrackingExecutor$1.run(EndpointImpl.java:731)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from node-0, see cause for remote stack trace
> at org.infinispan.remoting.transport.AbstractTransport.checkResponse(AbstractTransport.java:44)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:795)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$1(JGroupsTransport.java:642)
> at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602)
> at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577)
> at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474)
> at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1962)
> at org.infinispan.remoting.transport.jgroups.RspListFuture.futureDone(RspListFuture.java:31)
> at org.jgroups.blocks.Request.checkCompletion(Request.java:152)
> at org.jgroups.blocks.GroupRequest.receiveResponse(GroupRequest.java:116)
> at org.jgroups.blocks.RequestCorrelator.dispatch(RequestCorrelator.java:427)
> at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:357)
> at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:245)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:664)
> at org.jgroups.JChannel.up(JChannel.java:738)
> at org.jgroups.fork.ForkProtocolStack.up(ForkProtocolStack.java:120)
> at org.jgroups.stack.Protocol.up(Protocol.java:380)
> at org.jgroups.protocols.FORK.up(FORK.java:114)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:390)
> at org.jgroups.protocols.pbcast.GMS.up(GMS.java:1040)
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234)
> at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1070)
> at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:785)
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426)
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:649)
> at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:155)
> at org.jgroups.protocols.FD.up(FD.java:260)
> at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:310)
> at org.jgroups.protocols.MERGE3.up(MERGE3.java:285)
> at org.jgroups.protocols.Discovery.up(Discovery.java:296)
> at org.jgroups.protocols.MPING.up(MPING.java:178)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1601)
> at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1817)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at org.jboss.as.clustering.jgroups.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:52)
> ... 1 more
> Caused by: org.infinispan.commons.CacheException: Problems invoking command.
> at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.exceptionHandlingCommand(BasePerCacheInboundInvocationHandler.java:106)
> at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler.handle(NonTotalOrderTxPerCacheInboundInvocationHandler.java:101)
> at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleCacheRpcCommand(GlobalInboundInvocationHandler.java:126)
> at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleFromCluster(GlobalInboundInvocationHandler.java:75)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommandFromLocalCluster(CommandAwareRpcDispatcher.java:205)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:175)
> at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:455)
> at org.jgroups.blocks.RequestCorrelator.dispatch(RequestCorrelator.java:406)
> ... 27 more
> Caused by: org.infinispan.IllegalLifecycleStateException: ISPN000324: remote-failover-test.jar is in 'STOPPING' state and this is an invocation not belonging to an on-going transaction, so it does not accept new invocations. Either restart it or recreate the cache container.
> at org.infinispan.transaction.impl.TransactionTable.getOrCreateRemoteTransaction(TransactionTable.java:364)
> at org.infinispan.transaction.impl.TransactionTable.getOrCreateRemoteTransaction(TransactionTable.java:354)
> at org.infinispan.commands.control.LockControlCommand.createContext(LockControlCommand.java:138)
> at org.infinispan.commands.control.LockControlCommand.createContext(LockControlCommand.java:38)
> at org.infinispan.remoting.inboundhandler.action.PendingTxAction.createContext(PendingTxAction.java:107)
> at org.infinispan.remoting.inboundhandler.action.PendingTxAction.init(PendingTxAction.java:57)
> at org.infinispan.remoting.inboundhandler.action.BaseLockingAction.check(BaseLockingAction.java:38)
> at org.infinispan.remoting.inboundhandler.action.DefaultReadyAction.isReady(DefaultReadyAction.java:42)
> at org.infinispan.remoting.inboundhandler.action.DefaultReadyAction.isReady(DefaultReadyAction.java:45)
> at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler$1.isReady(NonTotalOrderTxPerCacheInboundInvocationHandler.java:124)
> at org.infinispan.util.concurrent.BlockingTaskAwareExecutorServiceImpl.execute(BlockingTaskAwareExecutorServiceImpl.java:51)
> at org.infinispan.executors.LazyInitializingBlockingTaskAwareExecutorService.execute(LazyInitializingBlockingTaskAwareExecutorService.java:46)
> at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.handleRunnable(BasePerCacheInboundInvocationHandler.java:130)
> at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler.handle(NonTotalOrderTxPerCacheInboundInvocationHandler.java:99)
> ... 33 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 10 months
- 1
- 0
[JBoss JIRA] (WFLY-7029) RemoteFailoverTestCast#testGracefulShutdownConcurrentFailover fails with "ISPN000324: remote-failover-test.jar is in 'STOPPING' state and this is an invocation not belonging to an on-going transaction, so it does not accept new invocations."
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-7029?page=com.atlassian.jira.plugin.... ]
Radoslav Husar edited comment on WFLY-7029 at 9/2/16 3:31 PM:
--------------------------------------------------------------
Possible cause might be fix for ISPN-5918 by commit: https://github.com/infinispan/infinispan/pull/3805/commits/f8039053d6d76e...
was (Author: rhusar):
Possible cause might be fix for ISPN-5918 with commit: https://github.com/infinispan/infinispan/pull/3805/commits/f8039053d6d76e...
> RemoteFailoverTestCast#testGracefulShutdownConcurrentFailover fails with "ISPN000324: remote-failover-test.jar is in 'STOPPING' state and this is an invocation not belonging to an on-going transaction, so it does not accept new invocations."
> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7029
> URL: https://issues.jboss.org/browse/WFLY-7029
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.1.0.Final
> Reporter: Radoslav Husar
> Assignee: Richard Achmatowicz
>
> https://ci.wildfly.org/viewLog.html?buildId=24851&tab=buildResultsDiv&bui...
> {noformat}
> 04:31:43,323 INFO [org.jboss.as.test.clustering.NodeUtil] (main) Stopping container=container-0, timeout=15
> 04:31:43,324 INFO [org.jboss.as.arquillian.container.controller.ClientWildFlyContainerController] (main) Manual stopping of a server instance with timeout=15
> &#27;[0m04:31:43,338 INFO [org.jboss.as.server] (management-handler-thread - 4) WFLYSRV0211: Suspending server with 15000 ms timeout.
> &#27;[0m04:31:43,343 INFO [org.jboss.ejb.client.remoting.NoSuchEJBExceptionResponseHandler] (Remoting "config-based-ejb-client-endpoint" task-10) Retrying invocation which failed on node node-0 with exception:: javax.ejb.NoSuchEJBException: No such EJB[appname=,modulename=remote-failover-test,distinctname=,beanname=SlowToDestroyStatefulIncrementorBean,viewclassname=org.jboss.as.test.clustering.cluster.ejb.remote.bean.Incrementor]
> at org.jboss.ejb.client.remoting.NoSuchEJBExceptionResponseHandler.processMessage(NoSuchEJBExceptionResponseHandler.java:64)
> at org.jboss.ejb.client.remoting.ChannelAssociation.processResponse(ChannelAssociation.java:386)
> at org.jboss.ejb.client.remoting.ChannelAssociation$ResponseReceiver.handleMessage(ChannelAssociation.java:498)
> at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:456)
> at org.jboss.remoting3.EndpointImpl$TrackingExecutor$1.run(EndpointImpl.java:731)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> &#27;[0m04:31:43,345 INFO [org.jboss.as.server] (Management Triggered Shutdown) WFLYSRV0241: Shutting down in response to management operation 'shutdown'
> &#27;[0m&#27;[0m04:31:43,430 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0019: Host default-host stopping
> &#27;[0m&#27;[0m04:31:43,436 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 29) MODCLUSTER000002: Initiating mod_cluster shutdown
> &#27;[0m&#27;[0m04:31:43,445 INFO [org.wildfly.extension.messaging-activemq] (ServerService Thread Pool -- 74) WFLYMSGAMQ0006: Unbound messaging object to jndi name java:/ConnectionFactory
> &#27;[0m&#27;[0m04:31:43,459 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000080: Disconnecting JGroups channel hibernate
> &#27;[0m&#27;[0m04:31:43,459 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000082: Stopping the RpcDispatcher for channel hibernate
> &#27;[0m&#27;[0m04:31:43,463 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN000080: Disconnecting JGroups channel server
> &#27;[0m&#27;[0m04:31:43,464 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN000082: Stopping the RpcDispatcher for channel server
> &#27;[0m&#27;[0m04:31:43,471 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 29) ISPN000029: Passivating all entries to disk
> &#27;[0m&#27;[0m04:31:43,472 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 29) ISPN000030: Passivated 2 entries in 0 milliseconds
> &#27;[0m&#27;[0m04:31:43,501 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000080: Disconnecting JGroups channel web
> &#27;[0m&#27;[0m04:31:43,501 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000082: Stopping the RpcDispatcher for channel web
> &#27;[0m&#27;[0m04:31:43,502 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 29) WFLYCLINF0003: Stopped remote-failover-test.jar cache from ejb container
> &#27;[0m&#27;[0m04:31:43,505 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000080: Disconnecting JGroups channel testDbPersistence
> &#27;[0m&#27;[0m04:31:43,505 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000082: Stopping the RpcDispatcher for channel testDbPersistence
> &#27;[0m&#27;[33m04:31:43,502 WARN [org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler] (thread-11,ee,node-0) ISPN000071: Caught exception when handling command LockControlCommand{cache=remote-failover-test.jar, keys=[UnknownSessionID [6951504948515351686656515249505365655750686851525048706670486766]], flags=[FORCE_WRITE_LOCK], unlock=false, gtx=GlobalTransaction:<node-1>:48:remote}: org.infinispan.IllegalLifecycleStateException: ISPN000324: remote-failover-test.jar is in 'STOPPING' state and this is an invocation not belonging to an on-going transaction, so it does not accept new invocations. Either restart it or recreate the cache container.
> at org.infinispan.transaction.impl.TransactionTable.getOrCreateRemoteTransaction(TransactionTable.java:364)
> at org.infinispan.transaction.impl.TransactionTable.getOrCreateRemoteTransaction(TransactionTable.java:354)
> at org.infinispan.commands.control.LockControlCommand.createContext(LockControlCommand.java:138)
> at org.infinispan.commands.control.LockControlCommand.createContext(LockControlCommand.java:38)
> at org.infinispan.remoting.inboundhandler.action.PendingTxAction.createContext(PendingTxAction.java:107)
> at org.infinispan.remoting.inboundhandler.action.PendingTxAction.init(PendingTxAction.java:57)
> at org.infinispan.remoting.inboundhandler.action.BaseLockingAction.check(BaseLockingAction.java:38)
> at org.infinispan.remoting.inboundhandler.action.DefaultReadyAction.isReady(DefaultReadyAction.java:42)
> at org.infinispan.remoting.inboundhandler.action.DefaultReadyAction.isReady(DefaultReadyAction.java:45)
> at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler$1.isReady(NonTotalOrderTxPerCacheInboundInvocationHandler.java:124)
> at org.infinispan.util.concurrent.BlockingTaskAwareExecutorServiceImpl.execute(BlockingTaskAwareExecutorServiceImpl.java:51)
> at org.infinispan.executors.LazyInitializingBlockingTaskAwareExecutorService.execute(LazyInitializingBlockingTaskAwareExecutorService.java:46)
> at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.handleRunnable(BasePerCacheInboundInvocationHandler.java:130)
> at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler.handle(NonTotalOrderTxPerCacheInboundInvocationHandler.java:99)
> at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleCacheRpcCommand(GlobalInboundInvocationHandler.java:126)
> at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleFromCluster(GlobalInboundInvocationHandler.java:75)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommandFromLocalCluster(CommandAwareRpcDispatcher.java:205)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:175)
> at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:455)
> at org.jgroups.blocks.RequestCorrelator.dispatch(RequestCorrelator.java:406)
> at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:357)
> at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:245)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:664)
> at org.jgroups.JChannel.up(JChannel.java:738)
> at org.jgroups.fork.ForkProtocolStack.up(ForkProtocolStack.java:120)
> at org.jgroups.stack.Protocol.up(Protocol.java:380)
> at org.jgroups.protocols.FORK.up(FORK.java:114)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:390)
> at org.jgroups.protocols.pbcast.GMS.up(GMS.java:1040)
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234)
> at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1070)
> at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:785)
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426)
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:649)
> at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:155)
> at org.jgroups.protocols.FD.up(FD.java:260)
> at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:310)
> at org.jgroups.protocols.MERGE3.up(MERGE3.java:285)
> at org.jgroups.protocols.Discovery.up(Discovery.java:296)
> at org.jgroups.protocols.MPING.up(MPING.java:178)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1601)
> at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1817)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at org.jboss.as.clustering.jgroups.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:52)
> at java.lang.Thread.run(Thread.java:745)
> &#27;[0m&#27;[0m04:31:43,517 INFO [org.wildfly.extension.messaging-activemq] (MSC service thread 1-2) WFLYMSGAMQ0006: Unbound messaging object to jndi name java:jboss/DefaultJMSConnectionFactory
> &#27;[0m&#27;[0m04:31:43,517 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS]
> &#27;[0m&#27;[0m04:31:43,518 INFO [org.jboss.as.connector.deployment] (MSC service thread 1-4) WFLYJCA0011: Unbound JCA ConnectionFactory [java:/JmsXA]
> &#27;[0m&#27;[0m04:31:43,535 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-8) WFLYJCA0019: Stopped Driver service with driver-name = h2
> &#27;[0m&#27;[0m04:31:43,547 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 2) WFLYCLINF0003: Stopped client-mappings cache from ejb container
> &#27;[0m04:31:43,565 INFO [org.jboss.ejb.client.remoting] (Remoting "config-based-ejb-client-endpoint" task-14) EJBCLIENT000016: Channel Channel ID b007a55b (outbound) of Remoting connection 017c35ab to /0:0:0:0:0:0:0:1:8080 of endpoint "config-based-ejb-client-endpoint" <1c33eee> can no longer process messages
> &#27;[0m04:31:43,576 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000080: Disconnecting JGroups channel ejb
> &#27;[0m&#27;[0m04:31:43,576 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000082: Stopping the RpcDispatcher for channel ejb
> &#27;[0m&#27;[0m04:31:43,575 INFO [org.apache.activemq.artemis.ra] (ServerService Thread Pool -- 35) AMQ151003: resource adaptor stopped
> &#27;[0m&#27;[0m04:31:43,591 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0008: Undertow AJP listener ajp suspending
> &#27;[0m&#27;[0m04:31:43,591 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0007: Undertow AJP listener ajp stopped, was bound to [::1]:8009
> &#27;[0m&#27;[0m04:31:43,592 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0008: Undertow HTTPS listener https suspending
> &#27;[0m&#27;[0m04:31:43,592 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0007: Undertow HTTPS listener https stopped, was bound to [::1]:8443
> &#27;[0m&#27;[31m04:31:43,585 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-11) ISPN000136: Error executing command GetKeyValueCommand, writing keys []: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from node-0, see cause for remote stack trace
> at org.infinispan.remoting.transport.AbstractTransport.checkResponse(AbstractTransport.java:44)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:795)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$1(JGroupsTransport.java:642)
> at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602)
> at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577)
> at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474)
> at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1962)
> at org.infinispan.remoting.transport.jgroups.RspListFuture.futureDone(RspListFuture.java:31)
> at org.jgroups.blocks.Request.checkCompletion(Request.java:152)
> at org.jgroups.blocks.GroupRequest.receiveResponse(GroupRequest.java:116)
> at org.jgroups.blocks.RequestCorrelator.dispatch(RequestCorrelator.java:427)
> at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:357)
> at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:245)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:664)
> at org.jgroups.JChannel.up(JChannel.java:738)
> at org.jgroups.fork.ForkProtocolStack.up(ForkProtocolStack.java:120)
> at org.jgroups.stack.Protocol.up(Protocol.java:380)
> at org.jgroups.protocols.FORK.up(FORK.java:114)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:390)
> at org.jgroups.protocols.pbcast.GMS.up(GMS.java:1040)
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234)
> at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1070)
> at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:785)
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426)
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:649)
> at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:155)
> at org.jgroups.protocols.FD.up(FD.java:260)
> at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:310)
> at org.jgroups.protocols.MERGE3.up(MERGE3.java:285)
> at org.jgroups.protocols.Discovery.up(Discovery.java:296)
> at org.jgroups.protocols.MPING.up(MPING.java:178)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1601)
> at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1817)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at org.jboss.as.clustering.jgroups.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:52)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.infinispan.commons.CacheException: Problems invoking command.
> at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.exceptionHandlingCommand(BasePerCacheInboundInvocationHandler.java:106)
> at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler.handle(NonTotalOrderTxPerCacheInboundInvocationHandler.java:101)
> at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleCacheRpcCommand(GlobalInboundInvocationHandler.java:126)
> at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleFromCluster(GlobalInboundInvocationHandler.java:75)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommandFromLocalCluster(CommandAwareRpcDispatcher.java:205)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:175)
> at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:455)
> at org.jgroups.blocks.RequestCorrelator.dispatch(RequestCorrelator.java:406)
> ... 27 more
> Caused by: org.infinispan.IllegalLifecycleStateException: ISPN000324: remote-failover-test.jar is in 'STOPPING' state and this is an invocation not belonging to an on-going transaction, so it does not accept new invocations. Either restart it or recreate the cache container.
> at org.infinispan.transaction.impl.TransactionTable.getOrCreateRemoteTransaction(TransactionTable.java:364)
> at org.infinispan.transaction.impl.TransactionTable.getOrCreateRemoteTransaction(TransactionTable.java:354)
> at org.infinispan.commands.control.LockControlCommand.createContext(LockControlCommand.java:138)
> at org.infinispan.commands.control.LockControlCommand.createContext(LockControlCommand.java:38)
> at org.infinispan.remoting.inboundhandler.action.PendingTxAction.createContext(PendingTxAction.java:107)
> at org.infinispan.remoting.inboundhandler.action.PendingTxAction.init(PendingTxAction.java:57)
> at org.infinispan.remoting.inboundhandler.action.BaseLockingAction.check(BaseLockingAction.java:38)
> at org.infinispan.remoting.inboundhandler.action.DefaultReadyAction.isReady(DefaultReadyAction.java:42)
> at org.infinispan.remoting.inboundhandler.action.DefaultReadyAction.isReady(DefaultReadyAction.java:45)
> at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler$1.isReady(NonTotalOrderTxPerCacheInboundInvocationHandler.java:124)
> at org.infinispan.util.concurrent.BlockingTaskAwareExecutorServiceImpl.execute(BlockingTaskAwareExecutorServiceImpl.java:51)
> at org.infinispan.executors.LazyInitializingBlockingTaskAwareExecutorService.execute(LazyInitializingBlockingTaskAwareExecutorService.java:46)
> at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.handleRunnable(BasePerCacheInboundInvocationHandler.java:130)
> at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler.handle(NonTotalOrderTxPerCacheInboundInvocationHandler.java:99)
> ... 33 more
> &#27;[0m&#27;[31m04:31:43,588 ERROR [org.jboss.as.ejb3.invocation] (default task-11) WFLYEJB0034: EJB Invocation failed on component SlowToDestroyStatefulIncrementorBean for method public abstract org.jboss.as.test.clustering.cluster.ejb.remote.bean.Result org.jboss.as.test.clustering.cluster.ejb.remote.bean.Incrementor.increment(): javax.ejb.EJBException: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from node-0, see cause for remote stack trace
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:187)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:277)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:53)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:328)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:67)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:201)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:263)
> at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.processMessage(VersionOneProtocolChannelReceiver.java:213)
> at org.jboss.as.ejb3.remote.protocol.versiontwo.VersionTwoProtocolChannelReceiver.processMessage(VersionTwoProtocolChannelReceiver.java:76)
> at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.handleMessage(VersionOneProtocolChannelReceiver.java:159)
> at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:456)
> at org.jboss.remoting3.EndpointImpl$TrackingExecutor$1.run(EndpointImpl.java:731)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from node-0, see cause for remote stack trace
> at org.infinispan.remoting.transport.AbstractTransport.checkResponse(AbstractTransport.java:44)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:795)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$1(JGroupsTransport.java:642)
> at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602)
> at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577)
> at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474)
> at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1962)
> at org.infinispan.remoting.transport.jgroups.RspListFuture.futureDone(RspListFuture.java:31)
> at org.jgroups.blocks.Request.checkCompletion(Request.java:152)
> at org.jgroups.blocks.GroupRequest.receiveResponse(GroupRequest.java:116)
> at org.jgroups.blocks.RequestCorrelator.dispatch(RequestCorrelator.java:427)
> at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:357)
> at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:245)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:664)
> at org.jgroups.JChannel.up(JChannel.java:738)
> at org.jgroups.fork.ForkProtocolStack.up(ForkProtocolStack.java:120)
> at org.jgroups.stack.Protocol.up(Protocol.java:380)
> at org.jgroups.protocols.FORK.up(FORK.java:114)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:390)
> at org.jgroups.protocols.pbcast.GMS.up(GMS.java:1040)
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234)
> at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1070)
> at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:785)
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426)
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:649)
> at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:155)
> at org.jgroups.protocols.FD.up(FD.java:260)
> at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:310)
> at org.jgroups.protocols.MERGE3.up(MERGE3.java:285)
> at org.jgroups.protocols.Discovery.up(Discovery.java:296)
> at org.jgroups.protocols.MPING.up(MPING.java:178)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1601)
> at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1817)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at org.jboss.as.clustering.jgroups.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:52)
> ... 1 more
> Caused by: org.infinispan.commons.CacheException: Problems invoking command.
> at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.exceptionHandlingCommand(BasePerCacheInboundInvocationHandler.java:106)
> at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler.handle(NonTotalOrderTxPerCacheInboundInvocationHandler.java:101)
> at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleCacheRpcCommand(GlobalInboundInvocationHandler.java:126)
> at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleFromCluster(GlobalInboundInvocationHandler.java:75)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommandFromLocalCluster(CommandAwareRpcDispatcher.java:205)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:175)
> at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:455)
> at org.jgroups.blocks.RequestCorrelator.dispatch(RequestCorrelator.java:406)
> ... 27 more
> Caused by: org.infinispan.IllegalLifecycleStateException: ISPN000324: remote-failover-test.jar is in 'STOPPING' state and this is an invocation not belonging to an on-going transaction, so it does not accept new invocations. Either restart it or recreate the cache container.
> at org.infinispan.transaction.impl.TransactionTable.getOrCreateRemoteTransaction(TransactionTable.java:364)
> at org.infinispan.transaction.impl.TransactionTable.getOrCreateRemoteTransaction(TransactionTable.java:354)
> at org.infinispan.commands.control.LockControlCommand.createContext(LockControlCommand.java:138)
> at org.infinispan.commands.control.LockControlCommand.createContext(LockControlCommand.java:38)
> at org.infinispan.remoting.inboundhandler.action.PendingTxAction.createContext(PendingTxAction.java:107)
> at org.infinispan.remoting.inboundhandler.action.PendingTxAction.init(PendingTxAction.java:57)
> at org.infinispan.remoting.inboundhandler.action.BaseLockingAction.check(BaseLockingAction.java:38)
> at org.infinispan.remoting.inboundhandler.action.DefaultReadyAction.isReady(DefaultReadyAction.java:42)
> at org.infinispan.remoting.inboundhandler.action.DefaultReadyAction.isReady(DefaultReadyAction.java:45)
> at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler$1.isReady(NonTotalOrderTxPerCacheInboundInvocationHandler.java:124)
> at org.infinispan.util.concurrent.BlockingTaskAwareExecutorServiceImpl.execute(BlockingTaskAwareExecutorServiceImpl.java:51)
> at org.infinispan.executors.LazyInitializingBlockingTaskAwareExecutorService.execute(LazyInitializingBlockingTaskAwareExecutorService.java:46)
> at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.handleRunnable(BasePerCacheInboundInvocationHandler.java:130)
> at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler.handle(NonTotalOrderTxPerCacheInboundInvocationHandler.java:99)
> ... 33 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 10 months
- 1
- 0
[JBoss JIRA] (WFCORE-1761) Bogus "alternative" in server NativeManagementResourceDefinition.SOCKET_BINDING attribute definition
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-1761:
----------------------------------------
Summary: Bogus "alternative" in server NativeManagementResourceDefinition.SOCKET_BINDING attribute definition
Key: WFCORE-1761
URL: https://issues.jboss.org/browse/WFCORE-1761
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Affects Versions: 3.0.0.Alpha7
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Priority: Minor
SOCKET_BINDING declares that INTERFACE is an alternative. There is no INTERFACE attribute allowed on this resource. Perhaps this is leftover cruft.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 10 months
- 1
- 0
[JBoss JIRA] (WFCORE-1556) Poor handling of 'required', 'nillable' and 'alternatives' in AttributeDefinition
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1556?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1556:
-------------------------------------
Description:
The handling of the notions of 'required' and 'nillable' don't comply with the specs in https://docs.jboss.org/author/display/WFLY10/Description+of+the+Managemen..., particularly the "Description of an Attribute" part, where the 'required' and 'alternatives' fields are well described, with their relationship spelled out, while 'nillable' doesn't appear at all. Then in "Description of an Operation Parameter or Return Value" nillable is specified, although I think those descriptions could be tightened up in general.
The read-resource-description output for an attribute doesn't show "required" at all.
After a fair bit of thinking, I've finally recalled why the two separate notions of "required" and "nillable" exist in the first place.
The "required" and "alternatives" pieces go together. Is something required? And then if it is required, an alternative satisfies. So you can have two attributes/params, both required, but they are alternatives so one is defined and the other is not. And this is an ok thing.
And then 'nillable' comes in to help clients understand in a simple way whether they need to account for the possibility an undefined value. Basically:
nillable = !required || alternatives != null
Right now, nillable is implemented as
nillable = !required
There are a number of problems I see with AttributeDefinition:
1) We don't output the 'required' metadata unless it's an operation param being described. This is contrary to spec. However we shouldn't fix this unless we can have meaningful values for 'required', ones where the value can be true but the attribute/param can still have an undefined value, due to an alternative being present. If we can't fix that, there's no point outputting required as it's just redundant with what we output for 'nillable'.
2) We do output the 'nillable' metadata, even for attribute descriptions, where it isn't in the spec. But in this case I think we change the spec, as dropping nillable would be an incompatible change.
3) We don't properly validate the "required but has alternatives case." This can't be validated solely with ParameterValidator impls as those only see a single attribute value and don't have contextual information about other attributes/params. To get around this limitation, devs are saying that attributes with alternatives "allowNull" which is equivalent to saying they are not required. But they are required! So I think a fix for this will require AttributeDefinition itself to validate the overall resource model or operation object, and skip calling the ParameterValidator if the attribute/param is undefined and an alternative is defined.
4) AttributeDefinition and AbstractAttributeDefinitionBuilder unfortunately have a getter/setter/constructor param for property "allowNull" instead of a property named "required". This is unfortunate because "allowNull" intuitively maps to "nillable", but "required" is a much more useful thing to set. The value of "nillable" can be derived from a "required" setting and an "alternatives" setting, but the value of required cannot be so derived.
I think a fix for this would probably start from 4), deprecating setAllowNull, adding get/setRequired and changing the meaning of the AD(Builder) constructor param to "required". The effect of this would be that all current code setting "allowNull" would now be setting a new "required" field. This should be a non-breaking change as in current code that's the effect anyway.
Next would be to fix 3), by changing how AD validates.
Next would be to change the metadata we output, such that "required" is always present and the "nillable" value is !required || alternatives != null. And change the spec accordingly.
Last, in a separate task, would be to find attributes that were configuring "allowNull = true" solely to allow validation to pass when alternatives are present, and fix them to say "required=false".
was:
The handling of the notions of 'require'd and 'nillable' don't comply with the specs in https://docs.jboss.org/author/display/WFLY10/Description+of+the+Managemen..., particularly the "Description of an Attribute" part, where the 'required' and 'alternatives' fields are well described, with their relationship spelled out, while 'nillable' doesn't appear at all. Then in "Description of an Operation Parameter or Return Value" nillable is specified, although I think those descriptions could be tightened up in general.
The read-resource-description output for an attribute doesn't show "required" at all.
After a fair bit of thinking, I've finally recalled why the two separate notions of "required" and "nillable" exist in the first place.
The "required" and "alternatives" pieces go together. Is something required? And then if it is required, an alternative satisfies. So you can have two attributes/params, both required, but they are alternatives so one is defined and the other is not. And this is an ok thing.
And then 'nillable' comes in to help clients understand in a simple way whether they need to account for the possibility an undefined value. Basically:
nillable = !required || alternatives != null
Right now, nillable is implemented as
nillable = !required
There are a number of problems I see with AttributeDefinition:
1) We don't output the 'required' metadata unless it's an operation param being described. This is contrary to spec. However we we shouldn't fix this unless we can have meaningful values for 'required', ones where the value can be true but the attribute/param can still have an undefined value, due to an alternative being present. If we can't fix that, there's no point outputting required as it's just redundant with what we output for 'nillable'.
2) We do output the 'nillable' metadata, even for attribute descriptions, where it isn't in the spec. But in this case I think we change the spec, as dropping nillable would be an incompatible change.
3) We don't properly validate the "required but has alternatives case." This can't be validated solely with ParameterValidator impls as those only see a single attribute value and don't have contextual information about other attributes/params. To get around this limitation, devs are saying that attributes with alternatives "allowNull" which is equivalent to saying they are not required. But they are required! So I think a fix for this will require AttributeDefinition itself to validate the overall resource model or operation object, and skip calling the ParameterValidator if the attribute/param is undefined and an alternative is defined.
4) AttributeDefinition and AbstractAttributeDefinitionBuilder unfortunately have a getter/setter/constructor param for property "allowNull" instead of a property named "required". This is unfortunate because "allowNull" intuitively maps to "nillable", but "required" is a much more useful thing to set. The value of "nillable" can be derived from a "required" setting and an "alternatives" setting, but the value of required cannot be so derived.
I think a fix for this would probably start from 4), deprecating setAllowNull, adding get/setRequired and changing the meaning of the AD(Builder) constructor param to "required". The effect of this would be that all current code setting "allowNull" would now be setting a new "required" field. This should be a non-breaking change as in current code that's the effect anyway.
Next would be to fix 3), by changing how AD validates.
Next would be to change the metadata we output, such that "required" is always present and the "nillable" value is !required || alternatives != null. And change the spec accordingly.
Last, in a separate task, would be to find attributes that were configuring "allowNull = true" solely to allow validation to pass when alternatives are present, and fix them to say "required=false".
> Poor handling of 'required', 'nillable' and 'alternatives' in AttributeDefinition
> ---------------------------------------------------------------------------------
>
> Key: WFCORE-1556
> URL: https://issues.jboss.org/browse/WFCORE-1556
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
>
> The handling of the notions of 'required' and 'nillable' don't comply with the specs in https://docs.jboss.org/author/display/WFLY10/Description+of+the+Managemen..., particularly the "Description of an Attribute" part, where the 'required' and 'alternatives' fields are well described, with their relationship spelled out, while 'nillable' doesn't appear at all. Then in "Description of an Operation Parameter or Return Value" nillable is specified, although I think those descriptions could be tightened up in general.
> The read-resource-description output for an attribute doesn't show "required" at all.
> After a fair bit of thinking, I've finally recalled why the two separate notions of "required" and "nillable" exist in the first place.
> The "required" and "alternatives" pieces go together. Is something required? And then if it is required, an alternative satisfies. So you can have two attributes/params, both required, but they are alternatives so one is defined and the other is not. And this is an ok thing.
> And then 'nillable' comes in to help clients understand in a simple way whether they need to account for the possibility an undefined value. Basically:
> nillable = !required || alternatives != null
> Right now, nillable is implemented as
> nillable = !required
> There are a number of problems I see with AttributeDefinition:
> 1) We don't output the 'required' metadata unless it's an operation param being described. This is contrary to spec. However we shouldn't fix this unless we can have meaningful values for 'required', ones where the value can be true but the attribute/param can still have an undefined value, due to an alternative being present. If we can't fix that, there's no point outputting required as it's just redundant with what we output for 'nillable'.
> 2) We do output the 'nillable' metadata, even for attribute descriptions, where it isn't in the spec. But in this case I think we change the spec, as dropping nillable would be an incompatible change.
> 3) We don't properly validate the "required but has alternatives case." This can't be validated solely with ParameterValidator impls as those only see a single attribute value and don't have contextual information about other attributes/params. To get around this limitation, devs are saying that attributes with alternatives "allowNull" which is equivalent to saying they are not required. But they are required! So I think a fix for this will require AttributeDefinition itself to validate the overall resource model or operation object, and skip calling the ParameterValidator if the attribute/param is undefined and an alternative is defined.
> 4) AttributeDefinition and AbstractAttributeDefinitionBuilder unfortunately have a getter/setter/constructor param for property "allowNull" instead of a property named "required". This is unfortunate because "allowNull" intuitively maps to "nillable", but "required" is a much more useful thing to set. The value of "nillable" can be derived from a "required" setting and an "alternatives" setting, but the value of required cannot be so derived.
> I think a fix for this would probably start from 4), deprecating setAllowNull, adding get/setRequired and changing the meaning of the AD(Builder) constructor param to "required". The effect of this would be that all current code setting "allowNull" would now be setting a new "required" field. This should be a non-breaking change as in current code that's the effect anyway.
> Next would be to fix 3), by changing how AD validates.
> Next would be to change the metadata we output, such that "required" is always present and the "nillable" value is !required || alternatives != null. And change the spec accordingly.
> Last, in a separate task, would be to find attributes that were configuring "allowNull = true" solely to allow validation to pass when alternatives are present, and fix them to say "required=false".
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 10 months
- 1
- 0