[JBoss JIRA] (DROOLS-2795) [DMN Designer] Data-types: Grid: DecisionTable
by Michael Anstis (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2795?page=com.atlassian.jira.plugi... ]
Michael Anstis updated DROOLS-2795:
-----------------------------------
Story Points: 5
> [DMN Designer] Data-types: Grid: DecisionTable
> ----------------------------------------------
>
> Key: DROOLS-2795
> URL: https://issues.jboss.org/browse/DROOLS-2795
> Project: Drools
> Issue Type: Feature Request
> Components: DMN Editor
> Reporter: Michael Anstis
> Assignee: Michael Anstis
>
> *_Decision Table_*
> - (x) Grid header _could_ show Output Data Type
> - (/) Editing Output Data Type is possible via Properties panel
> - (x) Hide Output Data Type in header when there are multiple {{OutputClause}} columns
> - (x) {{InputClause}} columns header should show Input Data Type
> - (x) {{InputClause}} columns should support changing the Input Data Type
> - (x) {{OutputClause}} columns header should show Output Data Type
> - (x) {{OutputClause}} columns should support changing the Output Data Type
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (DROOLS-2796) [DMN Designer] Data-types: Grid: Context
by Michael Anstis (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2796?page=com.atlassian.jira.plugi... ]
Michael Anstis updated DROOLS-2796:
-----------------------------------
Story Points: 5
> [DMN Designer] Data-types: Grid: Context
> ----------------------------------------
>
> Key: DROOLS-2796
> URL: https://issues.jboss.org/browse/DROOLS-2796
> Project: Drools
> Issue Type: Feature Request
> Components: DMN Editor
> Reporter: Michael Anstis
> Assignee: Michael Anstis
>
> *_Context_*
> - (x) Grid header _could_ show Output Data Type (for Decision/BKM)
> - (/) Editing Output Data Type (for Decision/BKM) is possible via Properties panel
> - (x) {{ContextEntry}} should show Output Data Type (for {{ContextEntry}})
> - (x) {{ContextEntry}} should support changing the Output Data Type (for {{ContextEntry}})
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (WFLY-6224) IllegalStateException "not in a valid state to be invoking cache operations on" in two cluster test
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-6224?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz edited comment on WFLY-6224 at 7/30/18 10:55 AM:
---------------------------------------------------------------------
A new version of a PR to handle this issue. This PR fixed the issue locally for me and did not introduce regressions. Because the test cases which manifest this problem are currently disabled, the WF clustering testsuite needs to be run with -Djboss.test.enableIntermittentFailingTests
was (Author: rachmato):
A new version of a PR to handle this issue.
> IllegalStateException "not in a valid state to be invoking cache operations on" in two cluster test
> ---------------------------------------------------------------------------------------------------
>
> Key: WFLY-6224
> URL: https://issues.jboss.org/browse/WFLY-6224
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 10.0.0.Final, 11.0.0.CR1, 13.0.0.Final
> Reporter: Ladislav Thon
> Assignee: Paul Ferraro
>
> During a 2clusters test eap-7x-failover-ejb-2clusters-ejbremote-shutdown-repl-async (where 2clusters test = standalone EJB client -> 2-node "forwarder" cluster -> 2-node "target" cluster -> back to "forwarder" -> back to standalone client), I'm seeing {{IllegalStateException: Transaction is not in a valid state to be invoking cache operations on}}:
> {code}
> 05:12:09,813 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-40) ISPN000136: Error executing command GetKeyValueCommand, writing keys []: java.lang.IllegalStateException: Transaction DummyTransaction{xid=DummyXid{id=352}, status=3} is not in a valid state to be invoking cache operations on.
> at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:394)
> at org.infinispan.interceptors.TxInterceptor.enlistIfNeeded(TxInterceptor.java:350)
> at org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:344)
> at org.infinispan.interceptors.TxInterceptor.visitGetKeyValueCommand(TxInterceptor.java:330)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.statetransfer.StateTransferInterceptor.visitReadCommand(StateTransferInterceptor.java:176)
> at org.infinispan.statetransfer.StateTransferInterceptor.visitGetKeyValueCommand(StateTransferInterceptor.java:153)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:107)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:76)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
> at org.infinispan.cache.impl.CacheImpl.get(CacheImpl.java:411)
> at org.infinispan.cache.impl.DecoratedCache.get(DecoratedCache.java:443)
> at org.infinispan.cache.impl.AbstractDelegatingCache.get(AbstractDelegatingCache.java:286)
> at org.wildfly.clustering.ejb.infinispan.bean.InfinispanBeanFactory.findValue(InfinispanBeanFactory.java:85)
> at org.wildfly.clustering.ejb.infinispan.bean.InfinispanBeanFactory.findValue(InfinispanBeanFactory.java:49)
> at org.wildfly.clustering.ejb.infinispan.InfinispanBeanManager.findBean(InfinispanBeanManager.java:238)
> at org.jboss.as.ejb3.cache.distributable.DistributableCache.release(DistributableCache.java:137)
> at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.releaseInstance(StatefulSessionSynchronizationInterceptor.java:168)
> at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor$StatefulSessionSynchronization.afterCompletion(StatefulSessionSynchronizationInterceptor.java:250)
> at org.jboss.as.txn.service.internal.tsr.JCAOrderedLastSynchronizationList.afterCompletion(JCAOrderedLastSynchronizationList.java:147)
> at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.afterCompletion(SynchronizationImple.java:96)
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.afterCompletion(TwoPhaseCoordinator.java:545)
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.afterCompletion(TwoPhaseCoordinator.java:476)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.SubordinateAtomicAction.doOnePhaseCommit(SubordinateAtomicAction.java:247)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.TransactionImple.doOnePhaseCommit(TransactionImple.java:283)
> at org.jboss.as.ejb3.remote.protocol.versionone.XidTransactionCommitTask.manageTransaction(XidTransactionCommitTask.java:85)
> at org.jboss.as.ejb3.remote.protocol.versionone.XidTransactionManagementTask.run(XidTransactionManagementTask.java:68)
> at org.jboss.as.ejb3.remote.protocol.versionone.TransactionRequestHandler.processMessage(TransactionRequestHandler.java:139)
> 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:717)
> 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)
> {code}
> The difference from WFLY-4678 is the circumstances.
> In the following text, I'm refering to the nodes by their real names: {{perf17}} is the standalone EJB client, the "forwarder" cluster is {{perf20}} and {{perf21}}, and the "target" cluster is {{perf18}} and {{perf19}}.
> The stack trace above is the first occurence of the exception, it appears on perf19 (https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-...). At that time, perf18 is just shutting down gracefully, but the perf19 log clearly shows that both Infinispan and JGroups have already figured out that perf18 went away. Still, the absence of graceful shutdown for transactions might be an explanation... except that there's no reason why the cache on perf19 would be in an invalid state if it's perf18 who is going down. So maybe perf19 had to reach out to perf18 for some reason and the exception actually comes from perf18... but the cache is REPL, so perf19 should have all data locally already and it shouldn't really have to reach out to perf18.
> So, not really sure why it happens.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (WFLY-10762) ISPN000136: Error executing command GetKeyValueCommand, writing keys []: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request
by tommaso borgato (JIRA)
[ https://issues.jboss.org/browse/WFLY-10762?page=com.atlassian.jira.plugin... ]
tommaso borgato updated WFLY-10762:
-----------------------------------
Summary: ISPN000136: Error executing command GetKeyValueCommand, writing keys []: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request (was: ISPN000136: Error executing command GetKeyValueCommand)
> ISPN000136: Error executing command GetKeyValueCommand, writing keys []: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10762
> URL: https://issues.jboss.org/browse/WFLY-10762
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 14.0.0.CR1
> Reporter: tommaso borgato
> Assignee: Paul Ferraro
>
> The error was observed in scenario {{*[eap-7x-failover-ejb-ejbservlet-jvmkill-dist-sync|https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/view/EAP7/view/EAP7-Clustering_JJB/view/clustering-ejb-ejbservlet-tests/job/eap-7x-failover-ejb-ejbservlet-jvmkill-dist-sync_perf27_JJB/1/]*}}: a 4 nodes cluster with a mod_jk load balancer where fail-over is introduced by killing the server jvm.
> The error was observed on node [dev215|https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/view/EAP7/vie...] :
> {noformat}
> [JBossINF] [0m[31m04:10:27,872 ERROR [org.infinispan.interceptors.impl.InvocationContextInterceptor] (timeout-thread--p11-t1) ISPN000136: Error executing command GetKeyValueCommand, writing keys []: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 40684 from dev213
> [JBossINF] at org.infinispan.remoting.transport.impl.MultiTargetRequest.onTimeout(MultiTargetRequest.java:167)
> [JBossINF] at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:87)
> [JBossINF] at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:22)
> [JBossINF] at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [JBossINF] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> [JBossINF] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [JBossINF] at java.lang.Thread.run(Thread.java:748)
> {noformat}
> {quote}
> Please note that this scenario is the counterpart of scenario {{*[eap-7x-failover-ejb-ejbservlet-jvmkill-dist-sync|https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/view/EAP7/view/EAP7-Clustering_JJB/view/clustering-ejb-ejbservlet-tests/job/eap-7x-failover-ejb-ejbservlet-jvmkill-dist-sync_JJB/]*}} with the only difference of being executed on a different segment (perf27 instead of perf17). This other scenario has zero sampling errors and doesn't exhibit this error.
> {quote}
> {quote}
> Please also note that this errors was observed *right after* other error described in [WFLY-10758|https://issues.jboss.org/browse/WFLY-10758] so they may be related. Please refer to that issue for the sequence of events that led to the error.
> {quote}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (WFLY-10763) ISPN000097: Error while processing a prepare in a single-phase transaction: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request
by tommaso borgato (JIRA)
[ https://issues.jboss.org/browse/WFLY-10763?page=com.atlassian.jira.plugin... ]
tommaso borgato updated WFLY-10763:
-----------------------------------
Summary: ISPN000097: Error while processing a prepare in a single-phase transaction: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request (was: ISPN000476: Timed out waiting for responses for request)
> ISPN000097: Error while processing a prepare in a single-phase transaction: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10763
> URL: https://issues.jboss.org/browse/WFLY-10763
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Reporter: tommaso borgato
> Assignee: Paul Ferraro
>
> The error was observed in scenario {{*[eap-7x-failover-ejb-ejbservlet-jvmkill-dist-sync|https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/view/EAP7/view/EAP7-Clustering_JJB/view/clustering-ejb-ejbservlet-tests/job/eap-7x-failover-ejb-ejbservlet-jvmkill-dist-sync_perf27_JJB/1/]*}}: a 4 nodes cluster with a mod_jk load balancer where fail-over is introduced by killing the server jvm.
> The error was observed on node [dev215|https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/view/EAP7/vie...] :
> {noformat}
> [JBossINF] [0m[31m04:10:27,889 ERROR [org.infinispan.transaction.impl.TransactionCoordinator] (default task-178) ISPN000097: Error while processing a prepare in a single-phase transaction: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 40700 from dev213
> [JBossINF] at org.infinispan.interceptors.impl.AsyncInterceptorChainImpl.invoke(AsyncInterceptorChainImpl.java:259)
> [JBossINF] at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:137)
> [JBossINF] at org.infinispan.transaction.impl.TransactionCoordinator.commit(TransactionCoordinator.java:155)
> [JBossINF] at org.infinispan.transaction.xa.XaTransactionTable.commit(XaTransactionTable.java:127)
> [JBossINF] at org.infinispan.transaction.xa.TransactionXaAdapter.commit(TransactionXaAdapter.java:68)
> [JBossINF] at org.infinispan.commons.tx.TransactionImpl.finishResource(TransactionImpl.java:419)
> [JBossINF] at org.infinispan.commons.tx.TransactionImpl.commitResources(TransactionImpl.java:466)
> [JBossINF] at org.infinispan.commons.tx.TransactionImpl.runCommit(TransactionImpl.java:335)
> [JBossINF] at org.infinispan.commons.tx.TransactionImpl.commit(TransactionImpl.java:110)
> [JBossINF] at org.wildfly.clustering.ee.infinispan.InfinispanBatch.close(InfinispanBatch.java:97)
> [JBossINF] at org.wildfly.clustering.web.undertow.session.DistributableSession.requestDone(DistributableSession.java:91)
> [JBossINF] at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:945)
> [JBossINF] at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:579)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:339)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> [JBossINF] at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> [JBossINF] at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> [JBossINF] at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> [JBossINF] at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> [JBossINF] at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> [JBossINF] at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> [JBossINF] at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> [JBossINF] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:360)
> [JBossINF] at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
> [JBossINF] at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> [JBossINF] at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> [JBossINF] at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> [JBossINF] at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1349)
> [JBossINF] at java.lang.Thread.run(Thread.java:748)
> [JBossINF] Caused by: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 40700 from dev213
> [JBossINF] at org.infinispan.remoting.transport.impl.MultiTargetRequest.onTimeout(MultiTargetRequest.java:167)
> [JBossINF] at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:87)
> [JBossINF] at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:22)
> [JBossINF] at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [JBossINF] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> [JBossINF] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [JBossINF] ... 1 more
> [JBossINF] Suppressed: org.infinispan.util.logging.TraceException
> [JBossINF] at org.infinispan.interceptors.impl.SimpleAsyncInvocationStage.get(SimpleAsyncInvocationStage.java:41)
> [JBossINF] at org.infinispan.interceptors.impl.AsyncInterceptorChainImpl.invoke(AsyncInterceptorChainImpl.java:250)
> [JBossINF] at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:137)
> [JBossINF] at org.infinispan.transaction.impl.TransactionCoordinator.commit(TransactionCoordinator.java:155)
> [JBossINF] at org.infinispan.transaction.xa.XaTransactionTable.commit(XaTransactionTable.java:127)
> [JBossINF] at org.infinispan.transaction.xa.TransactionXaAdapter.commit(TransactionXaAdapter.java:68)
> [JBossINF] at org.infinispan.commons.tx.TransactionImpl.finishResource(TransactionImpl.java:419)
> [JBossINF] at org.infinispan.commons.tx.TransactionImpl.commitResources(TransactionImpl.java:466)
> [JBossINF] at org.infinispan.commons.tx.TransactionImpl.runCommit(TransactionImpl.java:335)
> [JBossINF] at org.infinispan.commons.tx.TransactionImpl.commit(TransactionImpl.java:110)
> [JBossINF] at org.wildfly.clustering.ee.infinispan.InfinispanBatch.close(InfinispanBatch.java:97)
> [JBossINF] at org.wildfly.clustering.web.undertow.session.DistributableSession.requestDone(DistributableSession.java:91)
> [JBossINF] at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:945)
> [JBossINF] at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:579)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:339)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> [JBossINF] at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> [JBossINF] at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> [JBossINF] at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> [JBossINF] at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> [JBossINF] at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> [JBossINF] at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> [JBossINF] at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> [JBossINF] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:360)
> [JBossINF] at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
> [JBossINF] at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> [JBossINF] at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> [JBossINF] at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> [JBossINF] at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1349)
> [JBossINF] ... 1 more
> {noformat}
> {quote}
> Please note that this scenario is the counterpart of scenario {{*[eap-7x-failover-ejb-ejbservlet-jvmkill-dist-sync|https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/view/EAP7/view/EAP7-Clustering_JJB/view/clustering-ejb-ejbservlet-tests/job/eap-7x-failover-ejb-ejbservlet-jvmkill-dist-sync_JJB/]*}} with the only difference of being executed on a different segment (perf27 instead of perf17). This other scenario has zero sampling errors and doesn't exhibit this error.
> {quote}
> {quote}
> Please also note that this errors was observed *right after* other error described in [WFLY-10758|https://issues.jboss.org/browse/WFLY-10758] so they may be related. Please refer to that issue for the sequence of events that led to the error.
> {quote}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (WFLY-10754) NullPointerException using Stateless with configured interceptors
by Matej Novotny (JIRA)
[ https://issues.jboss.org/browse/WFLY-10754?page=com.atlassian.jira.plugin... ]
Matej Novotny updated WFLY-10754:
---------------------------------
Description:
I report a strange behavior on WildFly 13 when configuring interceptors within stateless. Below I describe the scenario:
Here a simple interceptor:
{code:java}
package it.vige.injection.interceptors;
import javax.interceptor.AroundInvoke;
import javax.interceptor.Interceptor;
import javax.interceptor.InvocationContext;
@Interceptor
public class OKInterceptor {
@AroundInvoke
public Object aroundInvoke(InvocationContext ic) throws Exception {
return ic.proceed();
}
}
{code}
Here an annotation used as interceptor binding:
{code:java}
package it.vige.injection.interceptors;
import static java.lang.annotation.ElementType.CONSTRUCTOR;
import static java.lang.annotation.ElementType.METHOD;
import static java.lang.annotation.ElementType.TYPE;
import static java.lang.annotation.RetentionPolicy.RUNTIME;
import java.lang.annotation.Retention;
import java.lang.annotation.Target;
import javax.interceptor.InterceptorBinding;
@Retention(RUNTIME)
@Target({ METHOD, TYPE, CONSTRUCTOR })
@InterceptorBinding
public @interface NotOK {
}
{code}
Here an interceptor annotated with the interceptor binding:
{code:java}
package it.vige.injection.interceptors;
import javax.interceptor.AroundInvoke;
import javax.interceptor.Interceptor;
import javax.interceptor.InvocationContext;
@Interceptor
@NotOK
public class NotOKInterceptor {
@AroundInvoke
public Object aroundInvoke(InvocationContext ic) throws Exception {
return ic.proceed();
}
}
{code}
Here the stateless service configured with both the interceptors:
{code:java}
package it.vige.injection.interceptors;
import javax.ejb.Stateless;
import javax.interceptor.Interceptors;
@Stateless
public class SimpleService {
@Interceptors({ OKInterceptor.class })
public void ok() {
}
@NotOK
public void notOk() {
}
}
{code}
This service must have two methods, one attached to the simple interceptor and the other attached to the interceptor binding.
Here the beans.xml configuration:
{code:java}
<beans xmlns="http://xmlns.jcp.org/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
http://xmlns.jcp.org/xml/ns/javaee/beans_2_0.xsd"
version="2.0" bean-discovery-mode="all">
<interceptors>
<class>it.vige.injection.interceptors.OKInterceptor</class>
<class>it.vige.injection.interceptors.NotOKInterceptor</class>
</interceptors>
</beans>
{code}
And in the end the client who call the service:
{code:java}
....
@Inject
private SimpleService simpleService;
...
// this call works:
simpleService.ok();
// this call starts a NullPointerException:
simpleService.notOk();
...
{code}
when I try to call the notOk method I get this exception:
{code:java}
javax.ejb.EJBException: java.lang.NullPointerException
at deployment.test.war//it.vige.injection.test.InterceptorsTestCase.testNotOk(InterceptorsTestCase.java:52)
Caused by: java.lang.NullPointerException
at deployment.test.war//it.vige.injection.test.InterceptorsTestCase.testNotOk(InterceptorsTestCase.java:52)
{code}
The same thing was tested on WildFly 11.0.0.Final and it was ok.
If on WildFfly 13.0.0.Final I remove the @Stateless annotation from the service it works
was:
I report a strange behavior on WildFly 13 when configuring interceptors within stateless. Below I describe the scenario:
Here a simple interceptor:
{code:java}
package it.vige.injection.interceptors;
import javax.interceptor.AroundInvoke;
import javax.interceptor.Interceptor;
import javax.interceptor.InvocationContext;
@Interceptor
public class OKInterceptor {
@AroundInvoke
public Object aroundInvoke(InvocationContext ic) throws Exception {
return ic.proceed();
}
}
{code}
Here an annotation used as interceptor binding:
{code:java}
package it.vige.injection.interceptors;
import static java.lang.annotation.ElementType.CONSTRUCTOR;
import static java.lang.annotation.ElementType.METHOD;
import static java.lang.annotation.ElementType.TYPE;
import static java.lang.annotation.RetentionPolicy.RUNTIME;
import java.lang.annotation.Retention;
import java.lang.annotation.Target;
import javax.interceptor.InterceptorBinding;
@Retention(RUNTIME)
@Target({ METHOD, TYPE, CONSTRUCTOR })
@InterceptorBinding
public @interface NotOK {
}
{code}
Here an interceptor annotated with the interceptor binding:
{code:java}
package it.vige.injection.interceptors;
import javax.interceptor.AroundInvoke;
import javax.interceptor.Interceptor;
import javax.interceptor.InvocationContext;
@Interceptor
@NotOK
public class NotOKInterceptor {
@AroundInvoke
public Object aroundInvoke(InvocationContext ic) throws Exception {
return ic.proceed();
}
}
{code}
Here the stateless service configured with both the interceptors:
{code:java}
package it.vige.injection.interceptors;
import javax.ejb.Stateless;
import javax.interceptor.Interceptors;
@Stateless
public class SimpleService {
@Interceptors({ OKInterceptor.class })
public void ok() {
}
@NotOK
public void notOk() {
}
}
{code}
This service must have two methods, one attached to the simple interceptor and the other attached to the interceptor binding.
Here the beans.xml configuration:
{code:java}
<beans xmlns="http://xmlns.jcp.org/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
http://xmlns.jcp.org/xml/ns/javaee/beans_2_0.xsd"
version="2.0" bean-discovery-mode="all">
<interceptors>
<class>it.vige.injection.interceptors.OKInterceptor</class>
<class>it.vige.injection.interceptors.NotOKInterceptor</class>
</interceptors>
</beans>
{code}
And in the end the client who call the service:
{code:java}
....
@Inject
private SimpleService simpleService;
...
// this call works:
simpleService.ok();
// this call starts a NullPointerException:
simpleService.notOk();
...
{code}
when I try to call the notOk method I get this exception:
{code:java}
javax.ejb.EJBException: java.lang.NullPointerException
at deployment.test.war//it.vige.injection.test.InterceptorsTestCase.testNotOk(InterceptorsTestCase.java:52)
Caused by: java.lang.NullPointerException
at deployment.test.war//it.vige.injection.test.InterceptorsTestCase.testNotOk(InterceptorsTestCase.java:52)
{code}
The same thing was tested on WildFly 12.0.0.Final and it was ok.
If on WildFfly 13.0.0.Final I remove the @Stateless annotation from the service it works
Workaround Description:
Do *not* declare the {{OKInterceptor}} in {{beans.xml}}.
According to spec, interceptors declared via {{@Interceptors}} annotation do not require this for activation anyway. Hence the interceptor will still get invoked and the error will disappear.
Workaround: Workaround Exists
Priority: Minor (was: Major)
Environment: WildFly 12.0.0.Final and newer (was: WildFly 13.0.0.Final and java 10.0.1)
> NullPointerException using Stateless with configured interceptors
> -----------------------------------------------------------------
>
> Key: WFLY-10754
> URL: https://issues.jboss.org/browse/WFLY-10754
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 13.0.0.Final
> Environment: WildFly 12.0.0.Final and newer
> Reporter: Luca Stancapiano
> Assignee: Matej Novotny
> Priority: Minor
>
> I report a strange behavior on WildFly 13 when configuring interceptors within stateless. Below I describe the scenario:
> Here a simple interceptor:
> {code:java}
> package it.vige.injection.interceptors;
> import javax.interceptor.AroundInvoke;
> import javax.interceptor.Interceptor;
> import javax.interceptor.InvocationContext;
> @Interceptor
> public class OKInterceptor {
> @AroundInvoke
> public Object aroundInvoke(InvocationContext ic) throws Exception {
> return ic.proceed();
> }
> }
> {code}
> Here an annotation used as interceptor binding:
> {code:java}
> package it.vige.injection.interceptors;
> import static java.lang.annotation.ElementType.CONSTRUCTOR;
> import static java.lang.annotation.ElementType.METHOD;
> import static java.lang.annotation.ElementType.TYPE;
> import static java.lang.annotation.RetentionPolicy.RUNTIME;
> import java.lang.annotation.Retention;
> import java.lang.annotation.Target;
> import javax.interceptor.InterceptorBinding;
> @Retention(RUNTIME)
> @Target({ METHOD, TYPE, CONSTRUCTOR })
> @InterceptorBinding
> public @interface NotOK {
> }
> {code}
> Here an interceptor annotated with the interceptor binding:
> {code:java}
> package it.vige.injection.interceptors;
> import javax.interceptor.AroundInvoke;
> import javax.interceptor.Interceptor;
> import javax.interceptor.InvocationContext;
> @Interceptor
> @NotOK
> public class NotOKInterceptor {
> @AroundInvoke
> public Object aroundInvoke(InvocationContext ic) throws Exception {
> return ic.proceed();
> }
> }
> {code}
> Here the stateless service configured with both the interceptors:
> {code:java}
> package it.vige.injection.interceptors;
> import javax.ejb.Stateless;
> import javax.interceptor.Interceptors;
> @Stateless
> public class SimpleService {
> @Interceptors({ OKInterceptor.class })
> public void ok() {
> }
> @NotOK
> public void notOk() {
> }
> }
> {code}
> This service must have two methods, one attached to the simple interceptor and the other attached to the interceptor binding.
> Here the beans.xml configuration:
> {code:java}
> <beans xmlns="http://xmlns.jcp.org/xml/ns/javaee"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
> http://xmlns.jcp.org/xml/ns/javaee/beans_2_0.xsd"
> version="2.0" bean-discovery-mode="all">
> <interceptors>
> <class>it.vige.injection.interceptors.OKInterceptor</class>
> <class>it.vige.injection.interceptors.NotOKInterceptor</class>
> </interceptors>
> </beans>
> {code}
> And in the end the client who call the service:
> {code:java}
> ....
> @Inject
> private SimpleService simpleService;
> ...
> // this call works:
> simpleService.ok();
> // this call starts a NullPointerException:
> simpleService.notOk();
> ...
> {code}
> when I try to call the notOk method I get this exception:
> {code:java}
> javax.ejb.EJBException: java.lang.NullPointerException
> at deployment.test.war//it.vige.injection.test.InterceptorsTestCase.testNotOk(InterceptorsTestCase.java:52)
> Caused by: java.lang.NullPointerException
> at deployment.test.war//it.vige.injection.test.InterceptorsTestCase.testNotOk(InterceptorsTestCase.java:52)
> {code}
> The same thing was tested on WildFly 11.0.0.Final and it was ok.
> If on WildFfly 13.0.0.Final I remove the @Stateless annotation from the service it works
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months