[JBoss JIRA] (WFLY-9951) EJBException: Failed to read session create response during the stress test
by Michal Vinkler (JIRA)
Michal Vinkler created WFLY-9951:
------------------------------------
Summary: EJBException: Failed to read session create response during the stress test
Key: WFLY-9951
URL: https://issues.jboss.org/browse/WFLY-9951
Project: WildFly
Issue Type: Bug
Components: Clustering, EJB
Affects Versions: 12.0.0.Beta1
Reporter: Michal Vinkler
Assignee: Paul Ferraro
Affected scenario: stress-ejbremote-repl-sync
If you need the scenario description let me know.
When increasing number of clients from 5600 to 6000, one of the newly created clients logged:
{code}
2018/03/01 09:06:52:118 EST [ERROR][Runner - 1165] HOST dev220.mw.lab.eng.bos.redhat.com:rootProcess:c - Lookup failed: javax.naming.CommunicationException: EJBCLIENT000062: Failed to look up "clusterbench-ee7/clusterbench-ee7-ejb//RemoteStatefulSBImpl!org.jboss.test.clusterbench.ejb.stateful.RemoteStatefulSB?stateful" [Root exception is javax.ejb.EJBException: Failed to read session create response]
2018/03/01 09:06:52:118 EST [WARN ][Runner - 1165] HOST dev220.mw.lab.eng.bos.redhat.com:rootProcess:c - Error sampling data: <org.jboss.smartfrog.loaddriver.RequestProcessingException: Could not lookup session bean.>
2018/03/01 09:06:52:118 EST [WARN ][Runner - 1165] SFCORE_LOG - Error sampling data: <org.jboss.smartfrog.loaddriver.RequestProcessingException: Could not lookup session bean.>
org.jboss.smartfrog.loaddriver.RequestProcessingException: Could not lookup session bean.
at org.jboss.smartfrog.clustering.ejb3.StatefulSBProcessorFactoryImpl$EJB3RequestProcessor.initSession(StatefulSBProcessorFactoryImpl.java:225)
at org.jboss.smartfrog.clustering.ejb3.StatefulSBProcessorFactoryImpl$EJB3RequestProcessor.processRequest(StatefulSBProcessorFactoryImpl.java:71)
at org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:52)
at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:103)
at java.lang.Thread.run(Thread.java:748)
Caused by: javax.naming.CommunicationException: EJBCLIENT000062: Failed to look up "clusterbench-ee7/clusterbench-ee7-ejb//RemoteStatefulSBImpl!org.jboss.test.clusterbench.ejb.stateful.RemoteStatefulSB?stateful" [Root exception is javax.ejb.EJBException: Failed to read session create response]
at org.jboss.ejb.client.EJBRootContext.lookupNative(EJBRootContext.java:160)
at org.wildfly.naming.client.AbstractContext.lookup(AbstractContext.java:84)
at org.wildfly.naming.client.WildFlyRootContext.lookup(WildFlyRootContext.java:144)
at javax.naming.InitialContext.lookup(InitialContext.java:417)
at org.jboss.smartfrog.clustering.ejb3.StatefulSBProcessorFactoryImpl$EJB3RequestProcessor.initSession(StatefulSBProcessorFactoryImpl.java:211)
... 4 more
Caused by: javax.ejb.EJBException: Failed to read session create response
at org.jboss.ejb.protocol.remote.EJBClientChannel$SessionOpenInvocation.getResult(EJBClientChannel.java:869)
at org.jboss.ejb.protocol.remote.EJBClientChannel.openSession(EJBClientChannel.java:623)
at org.jboss.ejb.protocol.remote.RemoteEJBReceiver.createSession(RemoteEJBReceiver.java:149)
at org.jboss.ejb.client.EJBSessionCreationInvocationContext.proceed(EJBSessionCreationInvocationContext.java:63)
at org.jboss.ejb.protocol.remote.RemotingEJBClientInterceptor.handleSessionCreation(RemotingEJBClientInterceptor.java:66)
at org.jboss.ejb.client.EJBSessionCreationInvocationContext.proceed(EJBSessionCreationInvocationContext.java:70)
at org.jboss.ejb.client.TransactionPostDiscoveryInterceptor.handleSessionCreation(TransactionPostDiscoveryInterceptor.java:102)
at org.jboss.ejb.client.EJBSessionCreationInvocationContext.proceed(EJBSessionCreationInvocationContext.java:70)
at org.jboss.ejb.client.DiscoveryEJBClientInterceptor.handleSessionCreation(DiscoveryEJBClientInterceptor.java:138)
at org.jboss.ejb.client.EJBSessionCreationInvocationContext.proceed(EJBSessionCreationInvocationContext.java:70)
at org.jboss.ejb.client.NamingEJBClientInterceptor.handleSessionCreation(NamingEJBClientInterceptor.java:92)
at org.jboss.ejb.client.EJBSessionCreationInvocationContext.proceed(EJBSessionCreationInvocationContext.java:70)
at org.jboss.ejb.client.TransactionInterceptor.handleSessionCreation(TransactionInterceptor.java:100)
at org.jboss.ejb.client.EJBSessionCreationInvocationContext.proceed(EJBSessionCreationInvocationContext.java:70)
at org.jboss.ejb.client.EJBClientContext.createSession(EJBClientContext.java:835)
at org.jboss.ejb.client.EJBClient.createSessionProxy(EJBClient.java:198)
at org.jboss.ejb.client.EJBRootContext.lookupNative(EJBRootContext.java:158)
... 8 more
Caused by: java.lang.ClassNotFoundException: org.infinispan.util.concurrent.TimeoutException
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:335)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:348)
at org.jboss.marshalling.AbstractClassResolver.loadClass(AbstractClassResolver.java:123)
at org.jboss.marshalling.AbstractClassResolver.resolveClass(AbstractClassResolver.java:104)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:1025)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1354)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:275)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:223)
at org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1856)
at org.jboss.marshalling.river.RiverObjectInputStream.defaultReadObject(RiverObjectInputStream.java:81)
at java.lang.Throwable.readObject(Throwable.java:914)
at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.jboss.marshalling.reflect.SerializableClass.callReadObject(SerializableClass.java:317)
at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1748)
at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1717)
at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1717)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1397)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:275)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:223)
at org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1856)
at org.jboss.marshalling.river.RiverObjectInputStream.defaultReadObject(RiverObjectInputStream.java:81)
at java.lang.Throwable.readObject(Throwable.java:914)
at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.jboss.marshalling.reflect.SerializableClass.callReadObject(SerializableClass.java:317)
at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1748)
at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1717)
at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1717)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1397)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:275)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:223)
at org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1856)
at org.jboss.marshalling.river.RiverObjectInputStream.defaultReadObject(RiverObjectInputStream.java:81)
at java.lang.Throwable.readObject(Throwable.java:914)
at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.jboss.marshalling.reflect.SerializableClass.callReadObject(SerializableClass.java:317)
at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1748)
at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1717)
at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1717)
at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1717)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1397)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:275)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:223)
at org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1856)
at org.jboss.marshalling.river.RiverObjectInputStream.defaultReadObject(RiverObjectInputStream.java:81)
at java.lang.Throwable.readObject(Throwable.java:914)
at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.jboss.marshalling.reflect.SerializableClass.callReadObject(SerializableClass.java:317)
at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1748)
at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1717)
at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1717)
at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1717)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1397)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:275)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:208)
at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:76)
at org.jboss.ejb.protocol.remote.EJBClientChannel$SessionOpenInvocation.getResult(EJBClientChannel.java:816)
... 24 more
{code}
Server logs are full of timeout exceptions (WFLY-9890), not sure if it is directly related.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-9890) "ISPN000476: Timed out waiting for responses for request X from node Y" immediately after node Y rejoins the cluster (failover)
by Michal Vinkler (JIRA)
[ https://issues.jboss.org/browse/WFLY-9890?page=com.atlassian.jira.plugin.... ]
Michal Vinkler commented on WFLY-9890:
--------------------------------------
This affects also performance scenarios, although there is seemingly no impact on the client, the server logs are full of timeout exceptions. There is no failover in these scenarios, so the requests go every time to the primary owner.
Example: Link to serverlog: http://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/eap-7x-stress-ejb...
> "ISPN000476: Timed out waiting for responses for request X from node Y" immediately after node Y rejoins the cluster (failover)
> -------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-9890
> URL: https://issues.jboss.org/browse/WFLY-9890
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 12.0.0.Beta1
> Reporter: Michal Vinkler
> Assignee: Paul Ferraro
> Priority: Critical
>
> Seen in SF failover tests - scenarios:
> failover-http-granular-shutdown-repl-sync (replication granularity is set to ATTRIBUTE level)
> failover-http-session-jvmkill-repl-sync (replication granularity is set to SESSION level)
> Description: In the failover test, each server is shut down and after some time it rejoins the cluster. After joining the cluster again, the load is distributed to this node. It seems that first request for some session handled by that node produces ERROR in the log of some other server until the time another cluster topology change occurs.
> Stacktrace of the error:
> {code}
> [JBossINF] [0m[31m10:18:00,256 ERROR [org.infinispan.interceptors.impl.InvocationContextInterceptor] (timeout-thread--p12-t1) ISPN000136: Error executing command PrepareCommand, writing keys [SessionCreationMetaDataKey(f25_wwXXpvtNC9QTHZUtSwhmEUmg-wI77RL_17b9), SessionAccessMetaDataKey(f25_wwXXpvtNC9QTHZUtSwhmEUmg-wI77RL_17b9), SessionAttributeKey(f25_wwXXpvtNC9QTHZUtSwhmEUmg-wI77RL_17b9[1])]: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 30250 from perf18
> [JBossINF] at org.infinispan.remoting.transport.impl.MultiTargetRequest.onTimeout(MultiTargetRequest.java:163)
> [JBossINF] at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:86)
> [JBossINF] at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:21)
> [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)
> {code}
> Client gets the stale data:
> {code}
> 2018/02/21 10:18:00:272 EST [WARN ][Runner - 16] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Error sampling data: <org.jboss.smartfrog.loaddriver.RequestProcessingException: Stale session data received. Expected 60, received 59, Runner: 16>
> org.jboss.smartfrog.loaddriver.RequestProcessingException: Stale session data received. Expected 60, received 59, Runner: 16
> at org.jboss.smartfrog.loaddriver.http.AbstractSerialNumberValidatorFactoryImpl$SerialNumberValidator.processRequest(AbstractSerialNumberValidatorFactoryImpl.java:133)
> at org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:52)
> at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:103)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> Example - timeline:
> {code}
> 4 servers are running, 2000 clients, no issue in the beggining
> 2018/02/21 10:16:43:234 EST [INFO ][TestController] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Node 0 (perf18) is down.
> - still no issues
> 2018/02/21 10:17:43:234 EST [INFO ][TestController] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Bringing back node 0 (perf18)
> 2018/02/21 10:17:55:611 EST [INFO ][TestController] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Node 0 (perf18) is up.
> 2018/02/21 10:18:00:272 EST [WARN ][Runner - 16] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Error sampling data: <org.jboss.smartfrog.loaddriver.RequestProcessingException: Stale session data received. Expected 60, received 59, Runner: 16>
> {code}
> perf20 started logging the errors meanwhile and stopped only after perf19 was shut down:
> {code}
> [JBossINF] [0m[0m10:17:50,227 INFO [org.infinispan.CLUSTER] (thread-19,ejb,perf20) ISPN000094: Received new cluster view for channel ejb: [perf19|5] (4) [perf19, perf20, perf21, perf18]
> [JBossINF] [0m[0m10:17:50,228 INFO [org.infinispan.CLUSTER] (thread-19,ejb,perf20) ISPN100000: Node perf18 joined the cluster
> [JBossINF] [0m[31m10:18:00,256 ERROR [org.infinispan.interceptors.impl.InvocationContextInterceptor] (timeout-thread--p12-t1) ISPN000136: Error executing command PrepareCommand, writing keys [SessionCreationMetaDataKey(f25_wwXXpvtNC9QTHZUtSwhmEUmg-wI77RL_17b9), SessionAccessMetaDataKey(f25_wwXXpvtNC9QTHZUtSwhmEUmg-wI77RL_17b9), SessionAttributeKey(f25_wwXXpvtNC9QTHZUtSwhmEUmg-wI77RL_17b9[1])]: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 30250 from perf18
> [JBossINF] at org.infinispan.remoting.transport.impl.MultiTargetRequest.onTimeout(MultiTargetRequest.java:163)
> [JBossINF] at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:86)
> [JBossINF] at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:21)
> [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)
> [JBossINF]
> {code}
> There were no issues in this scenario in EAP 7.1.0.GA.
> Links:
> Clients: http://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/perflab_eap-7x-fa...
> perf18: http://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/perflab_eap-7x-fa...
> perf20: http://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/perflab_eap-7x-fa...
> Another test:
> perf19: http://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/perflab_eap-7x-fa...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-6673) JTA does not set transaction timeout for XAResource for propagated transactions
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-6673?page=com.atlassian.jira.plugin.... ]
David Lloyd resolved WFLY-6673.
-------------------------------
Fix Version/s: 11.0.0.Final
Resolution: Done
> JTA does not set transaction timeout for XAResource for propagated transactions
> -------------------------------------------------------------------------------
>
> Key: WFLY-6673
> URL: https://issues.jboss.org/browse/WFLY-6673
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Transactions
> Reporter: Ondra Chaloupka
> Assignee: David Lloyd
> Fix For: 11.0.0.Final
>
>
> I can see a fact that transaction timeout is not provided by subordinate transaction when passed by ejb remote call when JTA transaction are used.
> Even when transaction timeout is defined (it could be seen that timeout is used when xaresources is used on client) the server where transaction is propagated shows xa resources using the default timeou value.
> Client server (caller) - timeout is _6 seconds_
> {code}
> 2016-05-19 11:50:51,461 TRACE [com.arjuna.ats.jta] (default task-18) XAResourceRecord.topLevelCommit for XAResourceRecord < resource:TestXAResource(TestXAResourceCommon(id:483, xid:< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff7f000001:57a802d4:573d8c57:11, node_name=1, branch_uid=0:ffff7f000001:57a802d4:573d8c57:20, subordinatenodename=null, eis_name=java:/TestXAResource-483 >, timeout:6, prepareReturn:0)), txid:< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff7f000001:57a802d4:573d8c57:11, node_name=1, branch_uid=0:ffff7f000001:57a802d4:573d8c57:20, subordinatenodename=null, eis_name=java:/TestXAResource-483 >, heuristic: TwoPhaseOutcome.FINISH_OK, product: Crash Recovery Test/EAP Test, jndiName: java:/TestXAResource-483 com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord@7b44816f >, record id=0:ffff7f000001:57a802d4:573d8c57:21
> {code}
> Server (callee) - uses timeout _0 seconds_
> {code}
> 2016-05-19 11:50:39,374 TRACE [com.arjuna.ats.jta] (default task-12) XAResourceRecord.topLevelPrepare for XAResourceRecord < resource:TestXAResource(TestXAResourceCommon(id:502, xid:< formatId=131077, gtrid_length=29, bqual_length=37, tx_uid=0:ffff7f000001:57a802d4:573d8c57:11, node_name=1, branch_uid=0:ffff7f000001:3b603de1:573d8c5f:17, subordinatenodename=2, eis_name=java:/TestXAResource-502 >, timeout:0, prepareReturn:0)), txid:< formatId=131077, gtrid_length=29, bqual_length=37, tx_uid=0:ffff7f000001:57a802d4:573d8c57:11, node_name=1, branch_uid=0:ffff7f000001:3b603de1:573d8c5f:17, subordinatenodename=2, eis_name=java:/TestXAResource-502 >, heuristic: TwoPhaseOutcome.FINISH_OK, product: Crash Recovery Test/EAP Test, jndiName: java:/TestXAResource-502 com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord@4f35ed3f >, record id=0:ffff7f000001:3b603de1:573d8c5f:18
> {code}
> Scenario that I'm running is
> # enlist jms xa resource on client
> # call to second server, it means enlist ejb remoting xa resource to transaction
> # enlist test xa on server
> # enlist jms xa resource on server
> # enlist test xa on client
> # starting 2PC
> # prepare jms xa resource on server
> # prepare ejb remoting xa resource on server
> # prepare test xa resource on client
> # transaction timeout is hit
> # if underlying jms resource timeouts then XAResource.prepare call fails with XAER_NOTA and the whole transaction is rolled back
> #
> _(attaching server.log files for EAP 7.0.0/Narayana 5.2.16.Final where jbossts is caller and jbossts2 is callee)_
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (JGRP-2255) Message Bundling in TUNNEL mode
by Bharad S (JIRA)
[ https://issues.jboss.org/browse/JGRP-2255?page=com.atlassian.jira.plugin.... ]
Bharad S updated JGRP-2255:
---------------------------
Issue Type: Feature Request (was: Bug)
> Message Bundling in TUNNEL mode
> -------------------------------
>
> Key: JGRP-2255
> URL: https://issues.jboss.org/browse/JGRP-2255
> Project: JGroups
> Issue Type: Feature Request
> Affects Versions: 3.6.4
> Reporter: Bharad S
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 4.0.11
>
>
> Hi, I'm using JGroups v3.6.4 and it is working great. I have a quick question --
> TUNNEL.java's 'send' method clearly says -- "// we don't currently support message bundling in TUNNEL"
> If I wish to use 'SenderSendsWithTimerBundler' (i.e., bundle and send when queued messages are 64K or 20ms have passed), could you please let me know what options I have? E.g., whether I need to use a later version that supports bundling with TUNNEL or is there some other option. Thanks!
> Regards,
> -Bharad
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-9949) Wildfly 12 : jboss-cli.sh in infinite loop
by Ståle Pedersen (JIRA)
[ https://issues.jboss.org/browse/WFLY-9949?page=com.atlassian.jira.plugin.... ]
Ståle Pedersen commented on WFLY-9949:
--------------------------------------
also, can you run these commands and print out their output?
tty, stty -a and infocmp
thanks!
> Wildfly 12 : jboss-cli.sh in infinite loop
> -------------------------------------------
>
> Key: WFLY-9949
> URL: https://issues.jboss.org/browse/WFLY-9949
> Project: WildFly
> Issue Type: Bug
> Components: CLI
> Affects Versions: 12.0.0.Final
> Environment: ubuntu 16.06 lxd container
> java version "1.8.0_161" oracle
> v12 migrated from v11
> Reporter: Gaétan QUENTIN
> Assignee: Jean-Francois Denise
> Labels: regression
> Attachments: jboss-cli-logging.properties, jboss-cli.25300
>
>
> i cannot use anymore the jboss-cli.sh to connect to the contoller since i migrated from v11 to with wildfly 12:
>
> wildfly@java2:/opt/Wildfly$ ls -la
> drwxr-xr-x 1 root root 156 Mar 3 20:36 jboss-server-migration
> drwxr-xr-x 1 root root 454 Mar 4 00:09 overlays
> drwxr-xr-x 1 root root 166 Mar 4 11:43 scripts
> drwxr-xr-x 1 root root 236 Oct 24 05:30 wildfly-11.0.0.Final
> drwxr-xr-x 1 root root 236 Mar 1 07:29 wildfly-12.0.0.Final
> lrwxrwxrwx 1 root root 20 Mar 4 12:49 wildfly-current -> wildfly-12.0.0.Final
>
>
> my wildfly management console is on 172.20.12.192.
> v12 has been migrated from v11 with the jboss-server-migration tool. Applications and app manager works fine and the wildfly instance controller is well binded on the requested ip.
>
>
> with wildfly-current link on -> wildfly-11.0.0.Final:
>
> this works perfectly:
> (cd /opt/Wildfly/wildfly-current/bin && ./jboss-cli.sh -c -u=xx -p=xx --controller=http-remoting://172.20.12.192:9990)
>
>
> with wildfly-current -> wildfly-12.0.0.Final:
> this go in infinite loop until crash :
> (cd /opt/Wildfly/wildfly-current/bin && ./jboss-cli.sh -c -u=xx -p=xx --controller=http-remoting://172.20.12.192:9990)
>
> output:
>
> '[standalone@172.20.12.192:9990' is not a valid operation name.
> [standalone@172.20.12.192:9990 /] '[standalone@172.20.12.192:9990' is not a valid operation name.
> ''[standalone@172.20.12.192:9990'' is not a valid operation name.
> [standalone@172.20.12.192:9990 /] [standalone@172.20.12.192:9990 /] ''[standalone@172.20.12.192:9990'' is not a valid operation name.
> '[standalone@172.20.12.192:9990' is not a valid operation name.
> [standalone@172.20.12.192:9990 /] '''[standalone@172.20.12.192:9990''' is not a valid operation name.
> ''''[standalone@172.20.12.192:9990'''' is not a valid operation name.
> [standalone@172.20.12.192:9990 /] [standalone@172.20.12.192:9990 /] [standalone@172.20.12.192:9990 /] [standalone@172.20.12.192:9990 /] ''[standalone@172.20.12.192:9990'' is not a valid oper is not a valid operation name.
> '[standalone@172.20.12.192:9990' is not a valid operation name.
> [standalone@172.20.12.192:9990 /] '''''[standalone@172.20.12.192:9990''''' is not a valid operation name.
> ''''''[standalone@172.20.12.192:9990'''''' is not a valid operation name.
> attached is a strace capture file (one of thousands) of jboss-cli .
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (JGRP-2255) Message Bundling in TUNNEL mode
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2255?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2255:
---------------------------
Fix Version/s: 4.0.11
> Message Bundling in TUNNEL mode
> -------------------------------
>
> Key: JGRP-2255
> URL: https://issues.jboss.org/browse/JGRP-2255
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.4
> Reporter: Bharad S
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 4.0.11
>
>
> Hi, I'm using JGroups v3.6.4 and it is working great. I have a quick question --
> TUNNEL.java's 'send' method clearly says -- "// we don't currently support message bundling in TUNNEL"
> If I wish to use 'SenderSendsWithTimerBundler' (i.e., bundle and send when queued messages are 64K or 20ms have passed), could you please let me know what options I have? E.g., whether I need to use a later version that supports bundling with TUNNEL or is there some other option. Thanks!
> Regards,
> -Bharad
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (JGRP-2255) Message Bundling in TUNNEL mode
by Bharad S (JIRA)
Bharad S created JGRP-2255:
------------------------------
Summary: Message Bundling in TUNNEL mode
Key: JGRP-2255
URL: https://issues.jboss.org/browse/JGRP-2255
Project: JGroups
Issue Type: Bug
Affects Versions: 3.6.4
Reporter: Bharad S
Assignee: Bela Ban
Priority: Minor
Hi, I'm using JGroups v3.6.4 and it is working great. I have a quick question --
TUNNEL.java's 'send' method clearly says -- "// we don't currently support message bundling in TUNNEL"
If I wish to use 'SenderSendsWithTimerBundler' (i.e., bundle and send when queued messages are 64K or 20ms have passed), could you please let me know what options I have? E.g., whether I need to use a later version that supports bundling with TUNNEL or is there some other option. Thanks!
Regards,
-Bharad
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months