[JBoss JIRA] (WFLY-6674) Infinispan subsystem cache configuration is lost when cache is created
by Ariel Carrera (JIRA)
[ https://issues.jboss.org/browse/WFLY-6674?page=com.atlassian.jira.plugin.... ]
Ariel Carrera updated WFLY-6674:
--------------------------------
Description:
Infinispan subsystem configuration is lost when cache is created.
If it is helpful, I made a simple test project to validate the problem. It is prepared to run with Wildfly 8 and 10.
https://github.com/arielcarrera/test-infinispan-wildfly10
After startup and created the cache, it is not configured with the specified settings in Wildfly's Infinispan Subsystem.
This can be verified by monitoring the jboss.infinispan nodes with JConsole retrieving the cache settings or running my simple test project.
Entities never expire/invalidate. The lifespan/max-entries are set to -1.
I found an old issue (https://issues.jboss.org/browse/WFLY-3858) about wildfly 8 but this problem talks about a security config problem and is a little different. It is a problem about wildfly 10 configuration and it is working OK on wildfly 8.2.
was:
Infinispan subsystem configuration is lost when cache is created.
If it is helpful.
After startup and created the cache, it is not configured with the specified settings in Wildfly's Infinispan Subsystem.
This can be verified by monitoring the jboss.infinispan nodes with JConsole retrieving the cache settings or running my simple test project.
Entities never expire/invalidate. The lifespan/max-entries are set to -1.
I made a simple test project to validate the problem. It is prepared to run with Wildfly 8 and 10.
https://github.com/arielcarrera/test-infinispan-wildfly10
I found an old issue (https://issues.jboss.org/browse/WFLY-3858) about wildfly 8 but this problem talks about a security config problem and is a little different. It is a problem about wildfly 10 configuration and it is working OK on wildfly 8.2.
> Infinispan subsystem cache configuration is lost when cache is created
> ----------------------------------------------------------------------
>
> Key: WFLY-6674
> URL: https://issues.jboss.org/browse/WFLY-6674
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Final
> Environment: Windows 10
> Wildfly 10.0.0.Final
> Java 8
> Reporter: Ariel Carrera
> Assignee: Paul Ferraro
> Labels: cache, configuration, infinispan
>
> Infinispan subsystem configuration is lost when cache is created.
> If it is helpful, I made a simple test project to validate the problem. It is prepared to run with Wildfly 8 and 10.
> https://github.com/arielcarrera/test-infinispan-wildfly10
> After startup and created the cache, it is not configured with the specified settings in Wildfly's Infinispan Subsystem.
> This can be verified by monitoring the jboss.infinispan nodes with JConsole retrieving the cache settings or running my simple test project.
> Entities never expire/invalidate. The lifespan/max-entries are set to -1.
> I found an old issue (https://issues.jboss.org/browse/WFLY-3858) about wildfly 8 but this problem talks about a security config problem and is a little different. It is a problem about wildfly 10 configuration and it is working OK on wildfly 8.2.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6674) Infinispan subsystem cache configuration is lost when cache is created
by Ariel Carrera (JIRA)
[ https://issues.jboss.org/browse/WFLY-6674?page=com.atlassian.jira.plugin.... ]
Ariel Carrera updated WFLY-6674:
--------------------------------
Steps to Reproduce:
1- Clone my test project from https://github.com/arielcarrera/test-infinispan-wildfly10
2- Install Wildfly 8 and Wildfly 10
3- Compile my test project.
5- Start wildfly 10.
6- Run my-project/config.cli to add infinispan subystem configuration to standalone-full.xml (or standalone.xml).
7- Restart wildfly.
8- Deploy my test project into wildfly 10
9- Test open a browser with this get url: http://localhost:8080/test-infinispan-wildfly10/test
10- Check the output.
11- Repeat the process with Wildfly 8.
12- Compare outputs (expected behavior like wildfly 8).
was:
1- Clone my test project from https://github.com/arielcarrera/test-infinispan-wildfly10
2- Install Wildfly 8 and Wildfly 10
3- Compile my test project.
5- Start wildfly 10.
6- Run my-project/config.cli to add infinispan subystem configuration to standalone-full.xml (or standalone.xml).
7- Restart wildfly.
8- Deploy my test project into wildfly 10
9- Test open a browser with this get url: http://localhost:8080/test-infinispan-wildfly10/test
10- Check the output steps.
11- Repeat the process with Wildfly 8.
12- Compare outputs (expected behavior like wildfly 8).
> Infinispan subsystem cache configuration is lost when cache is created
> ----------------------------------------------------------------------
>
> Key: WFLY-6674
> URL: https://issues.jboss.org/browse/WFLY-6674
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Final
> Environment: Windows 10
> Wildfly 10.0.0.Final
> Java 8
> Reporter: Ariel Carrera
> Assignee: Paul Ferraro
> Labels: cache, configuration, infinispan
>
> Infinispan subsystem configuration is lost when cache is created.
> If it is helpful.
> After startup and created the cache, it is not configured with the specified settings in Wildfly's Infinispan Subsystem.
> This can be verified by monitoring the jboss.infinispan nodes with JConsole retrieving the cache settings or running my simple test project.
> Entities never expire/invalidate. The lifespan/max-entries are set to -1.
> I made a simple test project to validate the problem. It is prepared to run with Wildfly 8 and 10.
> https://github.com/arielcarrera/test-infinispan-wildfly10
> I found an old issue (https://issues.jboss.org/browse/WFLY-3858) about wildfly 8 but this problem talks about a security config problem and is a little different. It is a problem about wildfly 10 configuration and it is working OK on wildfly 8.2.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6674) Infinispan subsystem cache configuration is lost when cache is created
by Ariel Carrera (JIRA)
Ariel Carrera created WFLY-6674:
-----------------------------------
Summary: Infinispan subsystem cache configuration is lost when cache is created
Key: WFLY-6674
URL: https://issues.jboss.org/browse/WFLY-6674
Project: WildFly
Issue Type: Bug
Components: Clustering
Affects Versions: 10.0.0.Final
Environment: Windows 10
Wildfly 10.0.0.Final
Java 8
Reporter: Ariel Carrera
Assignee: Paul Ferraro
Infinispan subsystem configuration is lost when cache is created.
If it is helpful.
After startup and created the cache, it is not configured with the specified settings in Wildfly's Infinispan Subsystem.
This can be verified by monitoring the jboss.infinispan nodes with JConsole retrieving the cache settings or running my simple test project.
Entities never expire/invalidate. The lifespan/max-entries are set to -1.
I made a simple test project to validate the problem. It is prepared to run with Wildfly 8 and 10.
https://github.com/arielcarrera/test-infinispan-wildfly10
I found an old issue (https://issues.jboss.org/browse/WFLY-3858) about wildfly 8 but this problem talks about a security config problem and is a little different. It is a problem about wildfly 10 configuration and it is working OK on wildfly 8.2.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-3858) Infinispan cache configuration is not always applied to security-domain
by Ariel Carrera (JIRA)
[ https://issues.jboss.org/browse/WFLY-3858?page=com.atlassian.jira.plugin.... ]
Ariel Carrera edited comment on WFLY-3858 at 6/6/16 10:18 AM:
--------------------------------------------------------------
I have the same problem with Wildfly 10.0.0.Final but it seems not to be a problem with security, infinispan subsystem configuration is lost when cache is created.
If it is helpful, I made a simple test project to validate the problem. It is prepared to run with Wildfly 8 and 10.
https://github.com/arielcarrera/test-infinispan-wildfly10
was (Author: arielcarrera):
I have the same problem, infinispan subsystem configuration is lost when cache is created.
If it is helpful, I made a simple test project to validate the problem. It is prepared to run with Wildfly 8 and 10.
https://github.com/arielcarrera/test-infinispan-wildfly10
> Infinispan cache configuration is not always applied to security-domain
> -----------------------------------------------------------------------
>
> Key: WFLY-3858
> URL: https://issues.jboss.org/browse/WFLY-3858
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 8.1.0.Final
> Reporter: Robert Tuck
> Assignee: Darran Lofthouse
> Attachments: debugger output.txt
>
>
> On Wildfly 8.1.0.Final, I have the following standalone-ha.xml:
> <subsystem xmlns="urn:jboss:domain:infinispan:2.0">
> ...
> <cache-container name="security" default-cache="auth-cache" start="EAGER">
> <transport cluster="${cluster.name}_SEC" lock-timeout="60000"/>
> <replicated-cache name="auth-cache" batching="true" mode="ASYNC">
> <eviction strategy="LRU" max-entries="10000"/>
> <expiration lifespan="60000"/>
> </replicated-cache>
> </cache-container>
> </subsystem>
> ...
> <subsystem xmlns="urn:jboss:domain:security:1.2">
> <security-domains>
> ...
> <security-domain name="OAuth-Consumer" cache-type="infinispan">
> <authentication>
> <login-module code="com.idbs.ewb.server.auth.module.OAuthConsumerLoginModule" flag="sufficient"
> module="deployment.ewb-server-ear.ear">
> <module-option name="allowedConsumerAuthFailures" value="-1"/>
> <module-option name="consumerLoginFailureTimeoutMs" value="3000"/>
> </login-module>
> </authentication>
> </security-domain>
> </security-domains>
> </subsystem>
> After startup the OAuth-Consumer security domain cache "auth-cache" is not always configured with the specified settings (~50% of the time). This can be verified by monitoring the jboss.infinispan nodes with JConsole and retrieving the cache settings, and tracking the cache hits during logins. This shows that succesful logins are cached but do not expire after the expected 60s, and that the expiration lifespan is set to -1 rather than 60000, as are eviction max entries.
> After some debugging I have narrowed down the problem to some code that gets called from inside org.jboss.as.security.plugins.JNDIBasedSecurityManagement:
> public SecurityDomainContext createSecurityDomainContext(String securityDomain, Object cacheFactory) throws Exception {
> log.debugf("Creating SDC for domain=" + securityDomain);
> AuthenticationManager am = createAuthenticationManager(securityDomain);
> // create authentication cache
> if (cacheFactory instanceof EmbeddedCacheManager) {
> EmbeddedCacheManager cacheManager = EmbeddedCacheManager.class.cast(cacheFactory);
> @SuppressWarnings("rawtypes")
> Cache cache = null;
> if (cacheManager != null) {
> // TODO override global settings with security domain specific
> ConfigurationBuilder builder = new ConfigurationBuilder();
> Configuration baseCfg = cacheManager.getCacheConfiguration("auth-cache");
> ^^^^ This call here doesn’t always return the correct configuration, baseCfg is then null.
> if (baseCfg != null) {
> builder.read(baseCfg);
> }
> cacheManager.defineConfiguration(securityDomain, builder.build());
> cache = cacheManager.getCache(securityDomain);
> }
> if (cache != null && am instanceof CacheableManager) {
> @SuppressWarnings({ "unchecked", "rawtypes" })
> CacheableManager<Map, Principal> cm = (CacheableManager<Map, Principal>) am;
> cm.setCache(cache);
> }
> } else if (cacheFactory instanceof DefaultAuthenticationCacheFactory) {
> <…>
> }
> getCacheConfiguration(String) is implemented inside org.infinispan.manager.DefaultCacheManager:
> @Override
> public Configuration getCacheConfiguration(String name) {
> Configuration configuration = configurationOverrides.get(name);
> if (configuration == null && cacheExists(name)) {
> return defaultConfiguration;
> }
> return configuration;
> }
> Seems like the condition configuration == null occurs when the cache doesn’t exist, therefore it returns null. This appears to be a race condition between this code and where it gets registered in wireAndStartCache(String).
>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-3858) Infinispan cache configuration is not always applied to security-domain
by Ariel Carrera (JIRA)
[ https://issues.jboss.org/browse/WFLY-3858?page=com.atlassian.jira.plugin.... ]
Ariel Carrera commented on WFLY-3858:
-------------------------------------
I have the same problem, infinispan subsystem configuration is lost when cache is created.
If it is helpful, I made a simple test project to validate the problem. It is prepared to run with Wildfly 8 and 10.
https://github.com/arielcarrera/test-infinispan-wildfly10
> Infinispan cache configuration is not always applied to security-domain
> -----------------------------------------------------------------------
>
> Key: WFLY-3858
> URL: https://issues.jboss.org/browse/WFLY-3858
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 8.1.0.Final
> Reporter: Robert Tuck
> Assignee: Darran Lofthouse
> Attachments: debugger output.txt
>
>
> On Wildfly 8.1.0.Final, I have the following standalone-ha.xml:
> <subsystem xmlns="urn:jboss:domain:infinispan:2.0">
> ...
> <cache-container name="security" default-cache="auth-cache" start="EAGER">
> <transport cluster="${cluster.name}_SEC" lock-timeout="60000"/>
> <replicated-cache name="auth-cache" batching="true" mode="ASYNC">
> <eviction strategy="LRU" max-entries="10000"/>
> <expiration lifespan="60000"/>
> </replicated-cache>
> </cache-container>
> </subsystem>
> ...
> <subsystem xmlns="urn:jboss:domain:security:1.2">
> <security-domains>
> ...
> <security-domain name="OAuth-Consumer" cache-type="infinispan">
> <authentication>
> <login-module code="com.idbs.ewb.server.auth.module.OAuthConsumerLoginModule" flag="sufficient"
> module="deployment.ewb-server-ear.ear">
> <module-option name="allowedConsumerAuthFailures" value="-1"/>
> <module-option name="consumerLoginFailureTimeoutMs" value="3000"/>
> </login-module>
> </authentication>
> </security-domain>
> </security-domains>
> </subsystem>
> After startup the OAuth-Consumer security domain cache "auth-cache" is not always configured with the specified settings (~50% of the time). This can be verified by monitoring the jboss.infinispan nodes with JConsole and retrieving the cache settings, and tracking the cache hits during logins. This shows that succesful logins are cached but do not expire after the expected 60s, and that the expiration lifespan is set to -1 rather than 60000, as are eviction max entries.
> After some debugging I have narrowed down the problem to some code that gets called from inside org.jboss.as.security.plugins.JNDIBasedSecurityManagement:
> public SecurityDomainContext createSecurityDomainContext(String securityDomain, Object cacheFactory) throws Exception {
> log.debugf("Creating SDC for domain=" + securityDomain);
> AuthenticationManager am = createAuthenticationManager(securityDomain);
> // create authentication cache
> if (cacheFactory instanceof EmbeddedCacheManager) {
> EmbeddedCacheManager cacheManager = EmbeddedCacheManager.class.cast(cacheFactory);
> @SuppressWarnings("rawtypes")
> Cache cache = null;
> if (cacheManager != null) {
> // TODO override global settings with security domain specific
> ConfigurationBuilder builder = new ConfigurationBuilder();
> Configuration baseCfg = cacheManager.getCacheConfiguration("auth-cache");
> ^^^^ This call here doesn’t always return the correct configuration, baseCfg is then null.
> if (baseCfg != null) {
> builder.read(baseCfg);
> }
> cacheManager.defineConfiguration(securityDomain, builder.build());
> cache = cacheManager.getCache(securityDomain);
> }
> if (cache != null && am instanceof CacheableManager) {
> @SuppressWarnings({ "unchecked", "rawtypes" })
> CacheableManager<Map, Principal> cm = (CacheableManager<Map, Principal>) am;
> cm.setCache(cache);
> }
> } else if (cacheFactory instanceof DefaultAuthenticationCacheFactory) {
> <…>
> }
> getCacheConfiguration(String) is implemented inside org.infinispan.manager.DefaultCacheManager:
> @Override
> public Configuration getCacheConfiguration(String name) {
> Configuration configuration = configurationOverrides.get(name);
> if (configuration == null && cacheExists(name)) {
> return defaultConfiguration;
> }
> return configuration;
> }
> Seems like the condition configuration == null occurs when the cache doesn’t exist, therefore it returns null. This appears to be a race condition between this code and where it gets registered in wireAndStartCache(String).
>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-5422) SSO is not destroyed after session timeout period of <distributable/> app.
by Juliano Carlos da Silva (JIRA)
[ https://issues.jboss.org/browse/WFLY-5422?page=com.atlassian.jira.plugin.... ]
Juliano Carlos da Silva commented on WFLY-5422:
-----------------------------------------------
For me this still happen on 10.0.0-Final
when i use mod_cluster + domain
the session timeout does not trigger.
> SSO is not destroyed after session timeout period of <distributable/> app.
> --------------------------------------------------------------------------
>
> Key: WFLY-5422
> URL: https://issues.jboss.org/browse/WFLY-5422
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Security
> Affects Versions: 10.0.0.CR2
> Reporter: Martin Choma
> Assignee: Paul Ferraro
> Priority: Critical
> Fix For: 10.0.0.CR5
>
>
> Using <distributable/> application cause SSO doesnt destroy after session timeout period. Base on [1], there is still active session, what is probably cause that SSO is not destroyed.
> Setting similar in EAP6 requires user to login after session timeout period.
> Setting priority to critical because of regression with security impacts.
> [1]
> [standalone@localhost:9990 /] /deployment=secured-webapp.war/subsystem=undertow:read-attribute(name=active-sessions)
> {
> "outcome" => "success",
> "result" => 0
> }
> [2]
> [standalone@localhost:9990 /] /deployment=secured-webapp.war/subsystem=undertow:read-attribute(name=active-sessions)
> {
> "outcome" => "success",
> "result" => 1
> }
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6673) JTA does not set transaction timeout for XAResource for propagated transactions
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/WFLY-6673?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on WFLY-6673:
-------------------------------------
I moved this to WFLY as it is likely the transaction timeout is not propagated by EJB remoting transport.
> 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
>
> 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
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6673) JTA does not set transaction timeout for XAResource for propagated transactions
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/WFLY-6673?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson moved JBTM-2674 to WFLY-6673:
-------------------------------------------
Project: WildFly (was: JBoss Transaction Manager)
Key: WFLY-6673 (was: JBTM-2674)
Component/s: EJB
Transactions
(was: JTA)
Affects Version/s: (was: 5.2.16.Final)
> 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
>
> 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
(v6.4.11#64026)
9 years, 11 months