July 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-6224) IllegalStateException "transaction is not in a valid state" during a 2clusters test

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-6224?page=com.atlassian.jira.plugin.... ] Jason Greene updated WFLY-6224: ------------------------------- Fix Version/s: 10.1.0.Final (was: 10.1.0.CR1) > IllegalStateException "transaction is not in a valid state" during a 2clusters 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 > Reporter: Ladislav Thon > Assignee: Paul Ferraro > Fix For: 10.1.0.Final > > > 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 (v6.4.11#64026)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6021) Default transaction timeout is not applied for EJB bean when set for second time

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-6021?page=com.atlassian.jira.plugin.... ] Jason Greene updated WFLY-6021: ------------------------------- Fix Version/s: 10.1.0.Final (was: 10.1.0.CR1) > Default transaction timeout is not applied for EJB bean when set for second time > -------------------------------------------------------------------------------- > > Key: WFLY-6021 > URL: https://issues.jboss.org/browse/WFLY-6021 > Project: WildFly > Issue Type: Bug > Components: EJB, Transactions > Reporter: Ondra Chaloupka > Assignee: Fedor Gavrilov > Fix For: 10.1.0.Final > > > It seems that transaction subsystem attribute {{default-timeout}} does not have any effect for EJB if it's redefined. It means if I set the default transaction timeout in transaction subystem for second (and next) time it's not applied for EJB beans. It's used the firstly set value. > The transaction timeout is not changed for EJB when server is reloaded. When server is restarted it refreshes all settings and EJB starts using the expected value for timeout settings. > If the value is read from subsystem > {{/subsystem=transactions:read-attribute(name=default-timeout)}} > it shows correct value (that one set for second time). But EJB seems not applying it. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6006) org.jboss.as.security-api module should be deprecated

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-6006?page=com.atlassian.jira.plugin.... ] Jason Greene updated WFLY-6006: ------------------------------- Fix Version/s: 10.1.0.Final (was: 10.1.0.CR1) > org.jboss.as.security-api module should be deprecated > ----------------------------------------------------- > > Key: WFLY-6006 > URL: https://issues.jboss.org/browse/WFLY-6006 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 10.1.0.Final > > > According to Eng, PM and QA inputs in [Module Classification doc|https://mojo.redhat.com/docs/DOC-1053168] there seems to be agreement to change visibility of this module back to deprecated. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6445) Upgrade to JBoss Negotiation 3.0.2.Final

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-6445?page=com.atlassian.jira.plugin.... ] Jason Greene updated WFLY-6445: ------------------------------- Fix Version/s: 10.1.0.Final (was: 10.1.0.CR1) > Upgrade to JBoss Negotiation 3.0.2.Final > ---------------------------------------- > > Key: WFLY-6445 > URL: https://issues.jboss.org/browse/WFLY-6445 > Project: WildFly > Issue Type: Component Upgrade > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 10.1.0.Final > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6349) JMSXGroupId has no effect on JMSProducer

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-6349?page=com.atlassian.jira.plugin.... ] Jason Greene updated WFLY-6349: ------------------------------- Fix Version/s: 10.1.0.Final (was: 10.1.0.CR1) > JMSXGroupId has no effect on JMSProducer > ---------------------------------------- > > Key: WFLY-6349 > URL: https://issues.jboss.org/browse/WFLY-6349 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 10.0.0.Final > Reporter: Harald Wellmann > Assignee: Jeff Mesnil > Fix For: 10.1.0.Final > > > h3. Scenario > I'm setting the {{JMSXGroupID}} on a {{JMSProducer}} to achieve message delivery in the correct order. The consumer is a message-driven bean. > {code} > JMSProducer producer = context.createProducer(); > producer = producer.setProperty("JMSXGroupID", "sequential"); > producer = producer.setProperty("foo", "bar"); > for (int i = 0; i < 50; i++) { > msgNumber++; > String text = "This is message " + msgNumber; > producer.send(queue, text); > } > {code} > h3. Expected Behaviour > The messages are received in the correct order, the properties {{JMSXGroupID}} and {{foo}} are set on the receiver side. > h3. Actual Behaviour > The messages are received in random order. Property {{foo}} is set, but property {{JMSXGroupID}} is null on the receiver side. > h3. Workaround > Create a {{TextMessage}} and set the properties on the message, not on the producer. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6290) XTS does not work with jbossws.undefined.host in WS config

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-6290?page=com.atlassian.jira.plugin.... ] Jason Greene updated WFLY-6290: ------------------------------- Fix Version/s: 10.1.0.Final (was: 10.1.0.CR1) > XTS does not work with jbossws.undefined.host in WS config > ---------------------------------------------------------- > > Key: WFLY-6290 > URL: https://issues.jboss.org/browse/WFLY-6290 > Project: WildFly > Issue Type: Bug > Components: XTS > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 10.1.0.Final > > > XTS uses ServerConfig to initialise it's configuration. However, we should rely on jboss.bind.address instead, because wsdl-host could take "jbossws.undefined.host" as a value. > "jbossws.undefined.host" will cause UnknownHostException, because address rewriting is not executed in XTS. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6890) Add Weld SPI dependency to the transactions module

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-6890?page=com.atlassian.jira.plugin.... ] Jason Greene updated WFLY-6890: ------------------------------- Fix Version/s: 10.1.0.Final (was: 10.1.0.CR1) > Add Weld SPI dependency to the transactions module > -------------------------------------------------- > > Key: WFLY-6890 > URL: https://issues.jboss.org/browse/WFLY-6890 > Project: WildFly > Issue Type: Task > Components: Transactions > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 10.1.0.Final > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6896) Upgrade HAL to 2.8.27.Final

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-6896?page=com.atlassian.jira.plugin.... ] Jason Greene updated WFLY-6896: ------------------------------- Fix Version/s: 10.1.0.Final (was: 10.1.0.CR1) > Upgrade HAL to 2.8.27.Final > --------------------------- > > Key: WFLY-6896 > URL: https://issues.jboss.org/browse/WFLY-6896 > Project: WildFly > Issue Type: Component Upgrade > Components: Web Console > Reporter: Harald Pehl > Assignee: Harald Pehl > Priority: Blocker > Fix For: 10.1.0.Final, 11.0.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6808) DistributableSession validate method throw misleading exception message

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-6808?page=com.atlassian.jira.plugin.... ] Jason Greene updated WFLY-6808: ------------------------------- Fix Version/s: 10.1.0.Final (was: 10.1.0.CR1) > DistributableSession validate method throw misleading exception message > ----------------------------------------------------------------------- > > Key: WFLY-6808 > URL: https://issues.jboss.org/browse/WFLY-6808 > Project: WildFly > Issue Type: Enhancement > Components: Clustering > Affects Versions: 10.0.0.Final > Reporter: Mathieu Lachance > Assignee: Paul Ferraro > Fix For: 10.1.0.Final > > > In DistributableSession the validate method is getting called for any underlying undertow session access to make sure we are not touching an already invalidated session (which totally make sense): > {code} > public class DistributableSession implements io.undertow.server.session.Session { > private static void validate(Session<LocalSessionContext> session) { > if (!session.isValid()) { > throw UndertowMessages.MESSAGES.sessionNotFound(session.getId()); > } > } > } > {code} > The problem though is the exception message that is thrown is really misleading because in reality the session actually exists but is currently invalid and/or getting invalidated. This can happen especially when running in optimistic mode where we can have many differents threads accessing the very same session. > I would recommend we do instead: > {code} > if (!session.isValid()) { > throw UndertowMessages.MESSAGES.sessionAlreadyInvalidated(); > } > {code} > or even better: > {code} > if (!session.isValid()) { > throw UndertowMessages.MESSAGES.sessionAlreadyInvalidated(session.getId()); > } > {code} > but it will require also a change in Undertow to actually template/parametize the sessionAlreadyInvalidated message. > Thanks, -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6647) JNDI access control problem stack traces are excessive

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-6647?page=com.atlassian.jira.plugin.... ] Jason Greene updated WFLY-6647: ------------------------------- Fix Version/s: 10.1.0.Final (was: 10.1.0.CR1) > JNDI access control problem stack traces are excessive > ------------------------------------------------------ > > Key: WFLY-6647 > URL: https://issues.jboss.org/browse/WFLY-6647 > Project: WildFly > Issue Type: Bug > Components: Naming > Reporter: David Lloyd > Assignee: David Lloyd > Priority: Trivial > Fix For: 10.1.0.Final, 11.0.0.Alpha1 > > > JNDI lookups which trip access control issues can result in massive "Caused by" chains. A simple fix can stop this. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 9 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira July 2016