[
https://issues.jboss.org/browse/WFLY-2454?page=com.atlassian.jira.plugin....
]
gui borland commented on WFLY-2454:
-----------------------------------
I've attached the jbossts-properties.xml file below. You'll need to uncomment the
VolatileStore to reproduce the problem.
I've set the com.arjuna.ats.arjuna.common.propertiesFile in the JAVA_OPTS environment
variable before launching jboss
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE properties SYSTEM "http://java.sun.com/dtd/properties.dtd">
<!--
JBoss, Home of Professional Open Source
Copyright 2009, Red Hat Middleware LLC, and individual contributors
as indicated by the @author tags.
See the copyright.txt in the distribution for a
full listing of individual contributors.
This copyrighted material is made available to anyone wishing to use,
modify, copy, or redistribute it subject to the terms and conditions
of the GNU Lesser General Public License, v. 2.1.
This program is distributed in the hope that it will be useful, but WITHOUT A
WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details.
You should have received a copy of the GNU Lesser General Public License,
v.2.1 along with this distribution; if not, write to the Free Software
Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
MA 02110-1301, USA.
(C) 2009,
@author JBoss, a division of Red Hat.
-->
<properties>
<!--
This is the JBossTS configuration file for running ArjunaJTS.
It should be called jbossts-properties.xml.
You need a different version for ArjunaCore or JTA usage.
***************************
Property values may be literals or be tokens of the form ${p1[,p2][:v]}
in which case the token values are substituted for the values of the corresponding
system
properties as follows:
- Any occurance of ${p} with the System.getProperty(p) value.
If there is no such property p defined, then the ${p} reference will remain
unchanged.
- If the property reference is of the form ${p:v} and there is no such property p,
then the default value v will be returned.
- If the property reference is of the form ${p1,p2} or ${p1,p2:v} then
the primary and the secondary properties will be tried in turn, before
returning either the unchanged input, or the default value.
The property ${/} is replaced with System.getProperty("file.separator")
value and the property ${:} is replaced with
System.getProperty("path.separator").
Note this substitution applies to property values only at the point they are read
from
the config file. Tokens in system properties won't be substituted.
-->
<!-- (default is YES) -->
<entry
key="CoordinatorEnvironmentBean.commitOnePhase">YES</entry>
<!-- default is under user.home - must be writeable!) -->
<entry
key="ObjectStoreEnvironmentBean.objectStoreDir">PutObjectStoreDirHere</entry>
<!-- Using volatile store make jboss shutdown fail (recovery can not get stopped
correctly
Also, this setting will be ignore if the use-hornetq option is selected in the
standalone-xml file. That will enable the hornetq- store no matter what
<entry
key="ObjectStoreEnvironmentBean.objectStoreType">com.arjuna.ats.internal.arjuna.objectstore.VolatileStore</entry>
-->
<entry
key="com.arjuna.ats.arjuna.allowMultipleLastResources">true</entry>
<entry
key="com.arjuna.ats.arjuna.disableMultipleLastResourcesWarning">true</entry>
<entry
key="ObjectStoreEnvironmentBean.objectStoreSync">OFF</entry>
<!-- (default is ON) -->
<entry
key="ObjectStoreEnvironmentBean.transactionSync">OFF</entry>
<!-- (Must be unique across all Arjuna instances.) -->
<entry key="CoreEnvironmentBean.nodeIdentifier">1</entry>
<!-- Which Xid types to recover -->
<entry key="JTAEnvironmentBean.xaRecoveryNodes">1</entry>
<entry key="JTAEnvironmentBean.xaResourceOrphanFilterClassNames">
com.arjuna.ats.internal.jta.recovery.arjunacore.JTATransactionLogXAResourceOrphanFilter
com.arjuna.ats.internal.jta.recovery.arjunacore.JTANodeNameXAResourceOrphanFilter
</entry>
<!--
Base port number for determining a unique number to associate with an instance of
the transaction service
(which is needed in order to support multiple instances on the same machine).
Use the value 0 to allow the system to select the first available port number.
If the port number is non-zero and the port is in use then the value will be
incremented until either a successful binding
to the loopback address is created or until the the maximum number of ports
(specified by the
CoreEnvironmentBean.socketProcessIdMaxPorts property) have been tried or until the
port number
reaches the maximum possible port number.
-->
<entry key="CoreEnvironmentBean.socketProcessIdPort">0</entry>
<!--
Periodic recovery modules to use. Invoked in the order they appear in the list.
Check
http://www.jboss.org/community/docs/DOC-10788 for more information
on recovery modules and their configuration when running in various
deployments.
-->
<entry key="RecoveryEnvironmentBean.recoveryModuleClassNames">
com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule
com.arjuna.ats.internal.txoj.recovery.TORecoveryModule
com.arjuna.ats.internal.jts.recovery.transactions.TopLevelTransactionRecoveryModule
com.arjuna.ats.internal.jts.recovery.transactions.ServerTransactionRecoveryModule
com.arjuna.ats.internal.jta.recovery.jts.XARecoveryModule
</entry>
<!-- Expiry scanners to use (order of invocation is random). -->
<entry key="RecoveryEnvironmentBean.expiryScannerClassNames">
com.arjuna.ats.internal.arjuna.recovery.ExpiredTransactionStatusManagerScanner
com.arjuna.ats.internal.jts.recovery.contact.ExpiredContactScanner
com.arjuna.ats.internal.jts.recovery.transactions.ExpiredToplevelScanner
com.arjuna.ats.internal.jts.recovery.transactions.ExpiredServerScanner
</entry>
<!--
Add the following to the set of expiryScannerClassNames above to move logs that
cannot be completed by failure recovery.
But be sure you know what you are doing and why!
com.arjuna.ats.internal.arjuna.recovery.AtomicActionExpiryScanner
-->
<!--
The address and port number on which the recovery manager listens
If running within an AS then the address the AS is bound to (jboss.bind.address)
takes precedence
-->
<entry key="RecoveryEnvironmentBean.recoveryPort">4712</entry>
<entry key="RecoveryEnvironmentBean.recoveryAddress"></entry>
<!--
Use this to fix the port on which the TransactionStatusManager listens,
The default behaviour is to use any free port.
-->
<entry
key="RecoveryEnvironmentBean.transactionStatusManagerPort">0</entry>
<!--
Use this to fix the address on which the TransactionStatusManager binds,
The default behaviour is to use the loopback address (ie localhost).
If running within an AS then the address the AS is bound to (jboss.bind.address)
takes precedence
-->
<entry
key="RecoveryEnvironmentBean.transactionStatusManagerAddress"></entry>
<!--
For cases where the recovery manager is in process with the transaction manager and
nothing else uses
the ObjectStore, it is possible to disable the socket based recovery listener by
setting this to NO.
Caution: use of this property can allow multiple recovery processes to run on the
same ObjectStore
if you are not careful. That in turn can lead to incorrect transaction processing.
Use with care.
-->
<entry
key="RecoveryEnvironmentBean.recoveryListener">NO</entry>
<!-- Recovery Activators to use. -->
<entry
key="RecoveryEnvironmentBean.recoveryActivatorClassNames">com.arjuna.ats.internal.jts.orbspecific.recovery.RecoveryEnablement</entry>
<entry
key="JTAEnvironmentBean.transactionManagerClassName">com.arjuna.ats.internal.jta.transaction.jts.TransactionManagerImple</entry>
<entry
key="JTAEnvironmentBean.userTransactionClassName">com.arjuna.ats.internal.jta.transaction.jts.UserTransactionImple</entry>
<entry
key="JTAEnvironmentBean.transactionSynchronizationRegistryClassName">com.arjuna.ats.internal.jta.transaction.jts.TransactionSynchronizationRegistryImple</entry>
<entry
key="OrbPortabilityEnvironmentBean.bindMechanism">CONFIGURATION_FILE</entry>
<entry
key="OrbPortabilityEnvironmentBean.orbInitializationProperties">
<!-- This class handles context propagation issues, and should never be
commented out or removed. -->
com.arjuna.orbportability.orb.PreInit1=com.arjuna.ats.internal.jts.context.ContextPropagationManager
<!-- This property ensures the JTS knows which ORB to use and should never be
commented out or removed -->
com.arjuna.orbportability.orb.PostInit=com.arjuna.ats.jts.utils.ORBSetup
<!-- This property ensures the crash recovery is initialised correctly and
should never be commented out or removed -->
com.arjuna.orbportability.orb.PostInit2=com.arjuna.ats.internal.jts.recovery.RecoveryInit
<!-- This property ensures the JTS knows which ORB to use and should never be
commented out or removed -->
com.arjuna.orbportability.orb.PostSet1=com.arjuna.ats.jts.utils.ORBSetup
</entry>
<!--
This property controls the port on which the Recovery ORB listens
-->
<entry
key="JTSEnvironmentBean.recoveryManagerPort">4711</entry>
<!--
This property controls the address on which the Recovery ORB binds - defaults to the
loopback connection
If running within an AS then the address the AS is bound to (jboss.bind.address)
takes precedence
-->
<entry key="JTSEnvironmentBean.recoveryManagerAddress"></entry>
</properties>
Cannot stop recovery manager when configured with volatile store
----------------------------------------------------------------
Key: WFLY-2454
URL:
https://issues.jboss.org/browse/WFLY-2454
Project: WildFly
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Transactions
Affects Versions: 8.0.0.Beta1
Reporter: gui borland
Assignee: Tom Jenkinson
When using jboss 5, i was able to configure a 'Volatile' action store. I
understand it's not the most robust store, but in my case performance is more
important than tx consistency.
I tried to configure the Volatile store in AS 7.1.3 as well (using a custom
jbossts-properties.xml file defined via the com.arjuna.ats.arjuna.common.propertiesFile
systemsetting ), but doing that breaks the recovery thread. It prints out a warning
message (Volatile storage does not support recovery blablabla...). That would be fine, but
this recovery issue also prevents jboss from shutting down cleanly. I have to kill it to
stop it.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:
http://www.atlassian.com/software/jira