August 2013 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-1580) Embed JBTM into the BlackTie client library

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1580?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-1580: -------------------------------- Fix Version/s: 6.0.0.Final (was: 5.0.0.Final) > Embed JBTM into the BlackTie client library > ------------------------------------------- > > Key: JBTM-1580 > URL: https://issues.jboss.org/browse/JBTM-1580 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: BlackTie > Reporter: Tom Jenkinson > Assignee: Amos Feng > Priority: Minor > Fix For: 6.0.0.Final > > > So we don't need to call remotely for transaction manager if not required. -- 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

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1573) Transaction timeout incompatible with block forever

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1573?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-1573: -------------------------------- Fix Version/s: 6.0.0.Final (was: 5.0.0.Final) > Transaction timeout incompatible with block forever > --------------------------------------------------- > > Key: JBTM-1573 > URL: https://issues.jboss.org/browse/JBTM-1573 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: BlackTie > Reporter: Tom Jenkinson > Assignee: Amos Feng > Fix For: 6.0.0.Final > > Attachments: blocking call.log > > > Currently we set a transaction timeout (e.g. in TestRollbackOnly.cxx we call tx_set_transaction_timeout) > This ends up putting a timetolive on the message of the same duration. > Now, if this message is not received within the period of time it will expire. > However we also use a block forever waiting for the response. > This can lead to a call never returning. > i.e. > server advertises queue > client sends message with small timeout (e.g. 4) and then blocks forever waiting response > server gets round to advertising queue 5 seconds later but never sees the clients initial request > client is blocked forever > I realise that we are meant to block forever when a client issues a tpcall under transactional conditions but something needs to be done as this can easily happen on slow machines? > Perhaps we need to make use of the DLQ to wake up the blocked client with an error message?? > Perhaps the client doesn't block forever and just calls txrollback if nothing is heard back?? -- 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

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1576) Introduce a JBoss deployable artifact for the C++ XATMI services

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1576?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-1576: -------------------------------- Fix Version/s: 6.0.0.Final (was: 5.0.0.Final) > Introduce a JBoss deployable artifact for the C++ XATMI services > ---------------------------------------------------------------- > > Key: JBTM-1576 > URL: https://issues.jboss.org/browse/JBTM-1576 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: BlackTie, Tooling > Reporter: Tom Jenkinson > Assignee: Amos Feng > Fix For: 6.0.0.Final > > Attachments: onmessage.tgz > > Original Estimate: 1 week > Remaining Estimate: 1 week > > Currently the XATMI services must be deployed in the standalone "Server" CORBA container > It is expected to be advantageous to support the deployment of the services into JBoss for ease of management and performance. > It is expected that the user will deploy a .war file containing a btconfig.xml defining the .so/.dll (also contained in the .war). > BlackTie java code will read the btconfig.xml and calculate the path of the .so based on the place that AS7 unzips war files to during deployment PLUS the path defined in the users btconfig.xml > If AS7 does not explode war files during deployment, it will not be possible for the user to package their .so in their .war file (I don't think - please do investigate this) and so a java.native.library.path will need defining at boot time and the user will need to place all their jni code in there thereby not supporting hot deploy unfortunately but still gaining the benefits of performance (not requiring socket comms between java and C). -- 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

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1577) Create a quickstart that shows a transaction created in EJB being propagated to an XATMI service

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1577?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-1577: -------------------------------- Fix Version/s: 6.0.0.Final (was: 5.0.0.Final) > Create a quickstart that shows a transaction created in EJB being propagated to an XATMI service > ------------------------------------------------------------------------------------------------ > > Key: JBTM-1577 > URL: https://issues.jboss.org/browse/JBTM-1577 > Project: JBoss Transaction Manager > Issue Type: Task > Security Level: Public(Everyone can see) > Components: BlackTie, Demonstrator > Reporter: Tom Jenkinson > Assignee: Amos Feng > Fix For: 6.0.0.Final > > -- 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

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1674) btadmin.PauseDomainTest failed with command failure

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1674?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-1674: -------------------------------- Fix Version/s: 6.0.0.Final (was: 5.0.0.M5) > btadmin.PauseDomainTest failed with command failure > --------------------------------------------------- > > Key: JBTM-1674 > URL: https://issues.jboss.org/browse/JBTM-1674 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: BlackTie > Reporter: Amos Feng > Assignee: Amos Feng > Priority: Minor > Fix For: 6.0.0.Final > > > http://172.17.131.2/view/Narayana+BlackTie/job/blacktie-linux64-el5/1501 > {noformat} > ------------------------------------------------------------------------------- > Test set: org.jboss.narayana.blacktie.btadmin.PauseDomainTest > ------------------------------------------------------------------------------- > Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 83.154 sec <<< FAILURE! > testPauseDomainWithArg(org.jboss.narayana.blacktie.btadmin.PauseDomainTest) Time elapsed: 53.947 sec <<< FAILURE! > junit.framework.AssertionFailedError: Command failed > at junit.framework.Assert.fail(Assert.java:47) > at org.jboss.narayana.blacktie.btadmin.PauseDomainTest.setUp(PauseDomainTest.java:48) > at junit.framework.TestCase.runBare(TestCase.java:125) > at junit.framework.TestResult$1.protect(TestResult.java:106) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.framework.TestResult.run(TestResult.java:109) > at junit.framework.TestCase.run(TestCase.java:118) > at junit.framework.TestSuite.runTest(TestSuite.java:208) > at junit.framework.TestSuite.run(TestSuite.java:203) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:98) > at org.apache.maven.surefire.junit.JUnit3Provider.executeTestSet(JUnit3Provider.java:107) > at org.apache.maven.surefire.junit.JUnit3Provider.invoke(JUnit3Provider.java:84) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.apache.maven.surefire.booter.ProviderFactory$ClassLoaderProxy.invoke(ProviderFactory.java:103) > at com.sun.proxy.$Proxy0.invoke(Unknown Source) > at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:150) > at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcess(SurefireStarter.java:91) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69) > {noformat} -- 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

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1862) C++ XATMI Implementation tests crashed

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1862?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-1862: -------------------------------- Fix Version/s: 6.0.0.Final (was: 5.0.0.M5) > C++ XATMI Implementation tests crashed > -------------------------------------- > > Key: JBTM-1862 > URL: https://issues.jboss.org/browse/JBTM-1862 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: BlackTie > Reporter: Gytis Trikleris > Assignee: Amos Feng > Priority: Minor > Fix For: 6.0.0.Final > > > http://172.17.131.2/view/Narayana+BlackTie/job/narayana/205/TESTS=BLACKTI... -- 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

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1675) integration-tests test 215 failed

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1675?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-1675: -------------------------------- Fix Version/s: 6.0.0.Final (was: 5.0.0.Final) > integration-tests test 215 failed > --------------------------------- > > Key: JBTM-1675 > URL: https://issues.jboss.org/browse/JBTM-1675 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: BlackTie > Reporter: Amos Feng > Assignee: Amos Feng > Priority: Minor > Fix For: 6.0.0.Final > > Attachments: test-215-130503092057-out.txt > > > http://172.17.131.2/view/Narayana+BlackTie/job/blacktie-linux64-el5/1502 -- 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

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1718) Resolve the ParticipantCompletion race condition

by Paul Robinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1718?page=com.atlassian.jira.plugin.... ] Paul Robinson commented on JBTM-1718: ------------------------------------- Gytis, I agree that pushing this beyond 5.0.0.Final is the right thing to do. Given that there is no simple, un-invasive solution (to our knowledge), we should wait until people start complaining about needing Byteman to get the Compensations API to work without intermittent rollbacks. > Resolve the ParticipantCompletion race condition > ------------------------------------------------ > > Key: JBTM-1718 > URL: https://issues.jboss.org/browse/JBTM-1718 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: TXFramework > Reporter: Paul Robinson > Assignee: Gytis Trikleris > Fix For: 6.0.0.Final > > > This issue is documented here: JBTM-1429 > In the documentation for JBTM-1429, we state that this issue is unlikely to happen in a distributed environment. This is true, however, the Compensations API is designed to work local-only as well as distributed over WS-BA. Therefore it is much more likely to happen in a production environment. > Therefore we need to remove this race condition. It can be done in a proprietary mannor as we are not interoperating with another implementation ion local-only mode. When distributing the transaction we fall back to the standard protocol that is susceptible to the race condition. However, as we stated in the docs, this condition is unlikely to manifest in a distributed environment. -- 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

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1808) Investigate why QA tests take 5hrs to run per ORB

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1808?page=com.atlassian.jira.plugin.... ] Tom Jenkinson resolved JBTM-1808. --------------------------------- Resolution: Done Seems to be timeouts > Investigate why QA tests take 5hrs to run per ORB > ------------------------------------------------- > > Key: JBTM-1808 > URL: https://issues.jboss.org/browse/JBTM-1808 > Project: JBoss Transaction Manager > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Build System, Testing > Reporter: Paul Robinson > Assignee: Tom Jenkinson > Priority: Minor > Fix For: 5.0.0.M5 > > > Our full build and test suite takes 12hrs to run. This is causing severe strain on our CI resources. > Out of this 12hrs, 10hrs is consumed by the QA test suite (5hrs per orb). It would be good to understand where this time is spent so that we can hopefully bring the test time down. > If there is no reasonable way to bring the timing down, we could chop the tests up into 5 groups (per orb) taking 1hr each. This would make better use of our CI cluster during quiet periods, but will not eleviate the load during busy periods. It is also likely to be a poor usage of resources as I suspect the CPU utilisation of each job will be low. > I suspect the problem is that we have a lot of Thread.sleeps in the tests. Therefore we are likely to see long tests with low resource (CPU) utilisation. However, further investigation is required to understand where the time is spent. > As an initial investigation, it would be good to profile the CPU utilisation on one of the CI nodes (take it offline) whilst running these tests. Also, it would be handy to find out how much time is spent in a Thread.sleep call (assuming that is where the time is spent). > My understanding is that Thread.sleep is used to wait for certain background tasks to complete. It's likely that Byteman could be used to replace the sleeps. However, due to the number of tests this may not be feasible. Alternatively, we may discover that there is a common set of Byteman rules that could be applied to the majority of tests, which may prove "good enough". > Also, we may be able to run these tests in parallel. This could drive up CPU utilisation, but would probably also interfere with the timings of the tests meaning that the current thread.sleeps are no longer adequate. > To summarise, this is a general task to investigate why the tests take so long and to also come up with some candidate solutions to bring the total test duration down. -- 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

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1340) BeanPopulator overhead needs looking into

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1340?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-1340: -------------------------------- Fix Version/s: 6.0.0.Final (was: 5.0.0.M5) > BeanPopulator overhead needs looking into > ----------------------------------------- > > Key: JBTM-1340 > URL: https://issues.jboss.org/browse/JBTM-1340 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Common > Affects Versions: 4.17.2 > Environment: Mac OS 10.7 > Reporter: Mark Little > Assignee: Tom Jenkinson > Fix For: 6.0.0.Final > > > During profiling, BeanPopulator can represent a 7% overhead. It may not seem like a lot, but for something as relatively simple as what BeanPopulator should be doing, it seems to be quite a bit. > 6.9% - 4,477 ms - 10,000 inv. com.arjuna.ats.arjuna.coordinator.TxStats.enabled > 6.9% - 4,477 ms - 10,000 inv. com.arjuna.ats.arjuna.common.arjPropertyManager.getCoordinatorEnvironmentBean > 6.9% - 4,476 ms - 10,000 inv. com.arjuna.common.internal.util.propertyservice.BeanPopulator.getDefaultInstance > 6.9% - 4,476 ms - 10,000 inv. com.arjuna.common.internal.util.propertyservice.BeanPopulator.getNamedInstance > 2.5% - 1,587 ms - 10,000 inv. java.lang.StringBuilder.<init> > 2.3% - 1,507 ms - 10,000 inv. java.lang.StringBuilder.toString > 0.0% - 320 µs - 10,000 inv. java.util.concurrent.ConcurrentMap.containsKey > 0.0% - 61 µs - 10,000 inv. java.lang.Class.getName > 0.0% - 25 µs - 10,000 inv. java.util.concurrent.ConcurrentMap.get -- 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

10 years, 8 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues August 2013