[JBoss JIRA] (JBTM-1712) perf problem in FileSystemStore.openAndLock
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1712?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-1712:
--------------------------------
Status: Pull Request Sent (was: Reopened)
Git Pull Request: https://github.com/jbosstm/narayana/pull/380
> perf problem in FileSystemStore.openAndLock
> -------------------------------------------
>
> Key: JBTM-1712
> URL: https://issues.jboss.org/browse/JBTM-1712
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Transaction Core
> Affects Versions: 4.16.4, 5.0.0.M2
> Reporter: Jonathan Halliday
> Assignee: Mark Little
> Fix For: 5.0.0.M3, 4.17.6
>
>
> if(!file.exits())
> {
> if(createHierarchy(file))
> incorrectly calls the expensive (because synchronized) createHierarchy method in the common case where the file does not exist (because it's a uniq named new tx record) but the directory hierarchy does (because it's the create-once hashed dir tree). This causes excessive contention on the FileSystemStore instance object monitor lock. Should probably be something more like
> if(!file.getParent().exists())
> {
> if(createHierarchy(file))
--
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
12 years, 8 months
[JBoss JIRA] (JBTM-1787) Compiliation failure for BlackTie on Fedora 18
by Michael Musgrove (JIRA)
[ https://issues.jboss.org/browse/JBTM-1787?page=com.atlassian.jira.plugin.... ]
Michael Musgrove updated JBTM-1787:
-----------------------------------
Comment: was deleted
(was: I have prebuilt binaries for log4cxx and ace that I got via a standard yum install on my F19 install. I will give these a go and if they work then we should probably go with them
Name : log4cxx
Arch : x86_64
Version : 0.10.0
Release : 14.fc19
Name : ace
Arch : x86_64
Version : 6.1.1
Release : 3.1
)
> Compiliation failure for BlackTie on Fedora 18
> ----------------------------------------------
>
> Key: JBTM-1787
> URL: https://issues.jboss.org/browse/JBTM-1787
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: BlackTie
> Reporter: Tom Jenkinson
> Assignee: Amos Feng
> Fix For: 5.0.0.Final
>
>
> test-compile:
> [mkdir] Created dir: /home/tom/projects/jbosstm/narayana/blacktie/core/target/cpp-test-classes
> [copy] Copying 5 files to /home/tom/projects/jbosstm/narayana/blacktie/core/target/cpp-test-classes
> [cc] 12 total files to be compiled.
> [cc] Starting link
> [cc] /usr/bin/ld: warning: libexpat.so.1, needed by /lib64/libaprutil-1.so.0, may conflict with libexpat.so.0
> [cc] /usr/bin/ld: warning: libexpat.so.1, needed by /lib64/libaprutil-1.so.0, may conflict with libexpat.so.0
> [cc] cpp-test-classes/TestSynchronizableObject.o:(.data.rel.ro._ZTV6Waiter[_ZTV6Waiter]+0x70): undefined reference to `ACE_Event_Handler::handle_signal(int, siginfo_t*, ucontext*)'
> [cc] /lib64/libaprutil-1.so.0: undefined reference to `apr_pool_pre_cleanup_register'
> [cc] collect2: error: ld returned 1 exit status
--
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
12 years, 8 months
[JBoss JIRA] (JBTM-1787) Compiliation failure for BlackTie on Fedora 18
by Michael Musgrove (JIRA)
[ https://issues.jboss.org/browse/JBTM-1787?page=com.atlassian.jira.plugin.... ]
Michael Musgrove commented on JBTM-1787:
----------------------------------------
I have prebuilt binaries for log4cxx and ace that I got via a standard yum install on my F19 install. I will give these a go and if they work then we should probably go with them
Name : log4cxx
Arch : x86_64
Version : 0.10.0
Release : 14.fc19
Name : ace
Arch : x86_64
Version : 6.1.1
Release : 3.1
> Compiliation failure for BlackTie on Fedora 18
> ----------------------------------------------
>
> Key: JBTM-1787
> URL: https://issues.jboss.org/browse/JBTM-1787
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: BlackTie
> Reporter: Tom Jenkinson
> Assignee: Amos Feng
> Fix For: 5.0.0.Final
>
>
> test-compile:
> [mkdir] Created dir: /home/tom/projects/jbosstm/narayana/blacktie/core/target/cpp-test-classes
> [copy] Copying 5 files to /home/tom/projects/jbosstm/narayana/blacktie/core/target/cpp-test-classes
> [cc] 12 total files to be compiled.
> [cc] Starting link
> [cc] /usr/bin/ld: warning: libexpat.so.1, needed by /lib64/libaprutil-1.so.0, may conflict with libexpat.so.0
> [cc] /usr/bin/ld: warning: libexpat.so.1, needed by /lib64/libaprutil-1.so.0, may conflict with libexpat.so.0
> [cc] cpp-test-classes/TestSynchronizableObject.o:(.data.rel.ro._ZTV6Waiter[_ZTV6Waiter]+0x70): undefined reference to `ACE_Event_Handler::handle_signal(int, siginfo_t*, ucontext*)'
> [cc] /lib64/libaprutil-1.so.0: undefined reference to `apr_pool_pre_cleanup_register'
> [cc] collect2: error: ld returned 1 exit status
--
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
12 years, 8 months
[JBoss JIRA] (JBTM-1787) Compiliation failure for BlackTie on Fedora 18
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1787?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-1787:
--------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/jbosstm/narayana/pull/379
> Compiliation failure for BlackTie on Fedora 18
> ----------------------------------------------
>
> Key: JBTM-1787
> URL: https://issues.jboss.org/browse/JBTM-1787
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: BlackTie
> Reporter: Tom Jenkinson
> Assignee: Amos Feng
> Fix For: 5.0.0.Final
>
>
> test-compile:
> [mkdir] Created dir: /home/tom/projects/jbosstm/narayana/blacktie/core/target/cpp-test-classes
> [copy] Copying 5 files to /home/tom/projects/jbosstm/narayana/blacktie/core/target/cpp-test-classes
> [cc] 12 total files to be compiled.
> [cc] Starting link
> [cc] /usr/bin/ld: warning: libexpat.so.1, needed by /lib64/libaprutil-1.so.0, may conflict with libexpat.so.0
> [cc] /usr/bin/ld: warning: libexpat.so.1, needed by /lib64/libaprutil-1.so.0, may conflict with libexpat.so.0
> [cc] cpp-test-classes/TestSynchronizableObject.o:(.data.rel.ro._ZTV6Waiter[_ZTV6Waiter]+0x70): undefined reference to `ACE_Event_Handler::handle_signal(int, siginfo_t*, ucontext*)'
> [cc] /lib64/libaprutil-1.so.0: undefined reference to `apr_pool_pre_cleanup_register'
> [cc] collect2: error: ld returned 1 exit status
--
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
12 years, 8 months
[JBoss JIRA] (JBTM-846) Allow transactional MSC and WildFly EJB container to operate with different configurations for transaction/recovery manager in a single JVM
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-846?page=com.atlassian.jira.plugin.s... ]
Paul Robinson updated JBTM-846:
-------------------------------
Description:
** This Jira is a work in progress - I (Paul) will update the details here once the requirements in https://community.jboss.org/message/828391 are clarified. **
The use case provided for this is to run a separate transaction/recovery manager for Transactional MSC to the one that WildFly is using for its (JTA/JTS) EJB container.
This will require removal of much of the static configuration state such as StateManager references to ObjectStore
was:
** This Jira is a work in progress - Paul to remove this message when description complete **
The use case provided for this is to run a separate transaction/recovery manager for Transactional MSC to the one that WildFly is using for its (JTA/JTS) EJB container.
This will require removal of much of the static configuration state such as StateManager references to ObjectStore
> Allow transactional MSC and WildFly EJB container to operate with different configurations for transaction/recovery manager in a single JVM
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBTM-846
> URL: https://issues.jboss.org/browse/JBTM-846
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: JTA, JTS, Recovery, Transaction Core, XTS
> Reporter: Tom Jenkinson
> Assignee: Paul Robinson
> Fix For: 5.0.0.Final
>
>
> ** This Jira is a work in progress - I (Paul) will update the details here once the requirements in https://community.jboss.org/message/828391 are clarified. **
> The use case provided for this is to run a separate transaction/recovery manager for Transactional MSC to the one that WildFly is using for its (JTA/JTS) EJB container.
> This will require removal of much of the static configuration state such as StateManager references to ObjectStore
--
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
12 years, 8 months
[JBoss JIRA] (JBTM-1641) EAP 6.1 CNFE org.jboss.tm.TxManager (from Module org.jboss.jboss-transaction-spi:main)
by Michael Musgrove (JIRA)
[ https://issues.jboss.org/browse/JBTM-1641?page=com.atlassian.jira.plugin.... ]
Michael Musgrove edited comment on JBTM-1641 at 7/18/13 7:54 AM:
-----------------------------------------------------------------
I was unable to duplicate the problem on jboss-as-8.0.0.Alpha1-SNAPSHOT. That said I agree that printing the stacktrace in this instance is excessively verbose. We are in the process of reworking the transactions SPI and as part of that work I will rationalise the debug logging, however we may not make the changes in time for wildfly 8 release.
I have added a link from JBTM-1699 (Changes to the transaction SPI) to make sure we don't loose sight of this JIRA.
Would you object to me closing this issue "as will not fix".
was (Author: mmusgrov):
I was unable to duplicate the problem on jboss-as-8.0.0.Alpha1-SNAPSHOT. That said I agree that printing the stacktrace in this instance is excessively verbose. We are in the process of reworking the transactions SPI and as part of that work I will rationalise the debug logging, however we may not make the changes in time for wildfly 8 release.
Would you object to me closing this issue "as will not fix".
> EAP 6.1 CNFE org.jboss.tm.TxManager (from Module org.jboss.jboss-transaction-spi:main)
> --------------------------------------------------------------------------------------
>
> Key: JBTM-1641
> URL: https://issues.jboss.org/browse/JBTM-1641
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Application Server Integration
> Affects Versions: 4.17.3
> Reporter: Darryl Miles
> Assignee: Michael Musgrove
> Fix For: 5.0.0.M4
>
> Original Estimate: 1 day
> Remaining Estimate: 1 day
>
> When enabling additional logging to system DEBUG on startup of standalone-full.xml it is possible to see:
> 07:15:40,780 DEBUG [org.jboss.tm.TransactionManagerLocator] (MSC service thread 1-2) Unable to lookup: java:/TransactionManager: javax.naming.NameNotFoundException: Error looking up TransactionManager, service service jboss.naming.context.java.TransactionManager is not started
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:132) [jboss-as-naming-7.2.0.Alpha1-redhat-4.jar:7.2.0.Alpha1-redhat-4]
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:80) [jboss-as-naming-7.2.0.Alpha1-redhat-4.jar:7.2.0.Alpha1-redhat-4]
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:197) [jboss-as-naming-7.2.0.Alpha1-redhat-4.jar:7.2.0.Alpha1-redhat-4]
> at org.jboss.as.naming.InitialContext.lookup(InitialContext.java:120) [jboss-as-naming-7.2.0.Alpha1-redhat-4.jar:7.2.0.Alpha1-redhat-4]
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:183) [jboss-as-naming-7.2.0.Alpha1-redhat-4.jar:7.2.0.Alpha1-redhat-4]
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:179) [jboss-as-naming-7.2.0.Alpha1-redhat-4.jar:7.2.0.Alpha1-redhat-4]
> at javax.naming.InitialContext.lookup(InitialContext.java:411) [rt.jar:1.7.0_17]
> at org.jboss.tm.TransactionManagerLocator.tryJNDI(TransactionManagerLocator.java:150) [jboss-transaction-spi-7.0.0.Final.jar:7.0.0.Final]
> at org.jboss.tm.TransactionManagerLocator.locate(TransactionManagerLocator.java:131) [jboss-transaction-spi-7.0.0.Final.jar:7.0.0.Final]
> at org.jboss.tm.TransactionManagerLocator.locateTransactionManager(TransactionManagerLocator.java:94) [jboss-transaction-spi-7.0.0.Final.jar:7.0.0.Final]
> at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.<init>(ServerVMClientUserTransaction.java:93) [jboss-transaction-spi-7.0.0.Final.jar:7.0.0.Final]
> at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.<clinit>(ServerVMClientUserTransaction.java:60) [jboss-transaction-spi-7.0.0.Final.jar:7.0.0.Final]
> at org.jboss.as.txn.service.ArjunaTransactionManagerService.start(ArjunaTransactionManagerService.java:115) [jboss-as-transactions-7.2.0.Alpha1-redhat-4.jar:7.2.0.Alpha1-redhat-4]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.4.GA.jar:1.0.4.GA]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.4.GA.jar:1.0.4.GA]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
> 07:15:40,786 DEBUG [org.jboss.tm.TransactionManagerLocator] (MSC service thread 1-2) Unable to instantiate legacy transaction manager: java.lang.ClassNotFoundException: org.jboss.tm.TxManager from [Module "org.jboss.jboss-transaction-spi:main" from local module loader @634f6b14 (finder: local module finder @72ff20fb (roots: F:\Devel\deps\jboss-eap-6.1\modules,F:\Devel\deps\jboss-eap-6.1\modules\system\layers\base))]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190) [jboss-modules.jar:1.2.0.CR1]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468) [jboss-modules.jar:1.2.0.CR1]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456) [jboss-modules.jar:1.2.0.CR1]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398) [jboss-modules.jar:1.2.0.CR1]
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120) [jboss-modules.jar:1.2.0.CR1]
> at java.lang.Class.forName0(Native Method) [rt.jar:1.7.0_17]
> at java.lang.Class.forName(Class.java:188) [rt.jar:1.7.0_17]
> at org.jboss.tm.TransactionManagerLocator.usePrivateAPI(TransactionManagerLocator.java:172) [jboss-transaction-spi-7.0.0.Final.jar:7.0.0.Final]
> at org.jboss.tm.TransactionManagerLocator.locate(TransactionManagerLocator.java:133) [jboss-transaction-spi-7.0.0.Final.jar:7.0.0.Final]
> at org.jboss.tm.TransactionManagerLocator.locateTransactionManager(TransactionManagerLocator.java:94) [jboss-transaction-spi-7.0.0.Final.jar:7.0.0.Final]
> at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.<init>(ServerVMClientUserTransaction.java:93) [jboss-transaction-spi-7.0.0.Final.jar:7.0.0.Final]
> at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.<clinit>(ServerVMClientUserTransaction.java:60) [jboss-transaction-spi-7.0.0.Final.jar:7.0.0.Final]
> at org.jboss.as.txn.service.ArjunaTransactionManagerService.start(ArjunaTransactionManagerService.java:115) [jboss-as-transactions-7.2.0.Alpha1-redhat-4.jar:7.2.0.Alpha1-redhat-4]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.4.GA.jar:1.0.4.GA]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.4.GA.jar:1.0.4.GA]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
--
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
12 years, 8 months