July 2013 - jbossts-issues - Jboss List Archives

[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: -------------------------------- Fix Version/s: 5.0.0.M4 (was: 5.0.0.Final) > 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: Tom Jenkinson > Fix For: 5.0.0.M4 > > > 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

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1786) Change to TMFAIL for an ABORT on a non-prepared TX

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBTM-1786?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated JBTM-1786: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=978589, https://bugzilla.redhat.com/show_bug.cgi?id=986046, https://bugzilla.redhat.com/show_bug.cgi?id=987970 (was: https://bugzilla.redhat.com/show_bug.cgi?id=978589, https://bugzilla.redhat.com/show_bug.cgi?id=986046) > Change to TMFAIL for an ABORT on a non-prepared TX > -------------------------------------------------- > > Key: JBTM-1786 > URL: https://issues.jboss.org/browse/JBTM-1786 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JTA, JTS > Affects Versions: 4.16.4 > Reporter: Johnathon Lee > Assignee: Johnathon Lee > Fix For: 4.17.7, 5.0.0.M4 > > > An ABORT on a non-prepared TX should be calling end with TMFAIL. > It's more efficient in that the RM can return an RB* code immediately and short circuit the rollback internally if it likes. More importantly though the RM is less likely to object that it's still running tx activity on another thread and the concurrent TMSUCCESS therefore makes no sense to it. > Also the XAResourceRecord.topLevelAbort code should immediately continue on to calling rollback on the resource despite the failed end(). -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1860) Please document AtomicAction and TransactionStatusManager scanner.

by Tom Ross (JIRA)

Tom Ross created JBTM-1860: ------------------------------ Summary: Please document AtomicAction and TransactionStatusManager scanner. Key: JBTM-1860 URL: https://issues.jboss.org/browse/JBTM-1860 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: Transaction Core Environment: JBoss EAP 5.x and 6.x Reporter: Tom Ross Assignee: Tom Jenkinson JBossTM provides two scanners AtomicAction and TransactionStatusManager to scan for expired records in transaction object store. There is very little documentation that describes what they do and how to enable them. Please provide better documentation that describes thier functions, the differences between them and the dangers associated with their usage. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1859) Remove classname Strings from XTS subsystem

by Paul Robinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1859?page=com.atlassian.jira.plugin.... ] Paul Robinson updated JBTM-1859: -------------------------------- Fix Version/s: 5.0.0.M5 (was: 5.0.0.M4) > Remove classname Strings from XTS subsystem > ------------------------------------------- > > Key: JBTM-1859 > URL: https://issues.jboss.org/browse/JBTM-1859 > Project: JBoss Transaction Manager > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Application Server Integration, XTS > Reporter: Paul Robinson > Assignee: Paul Robinson > Fix For: 5.0.0.M5 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > THe XTS SubSystem has many classnames passed to Jandex as raw Strings. It would be better to use Class#getName as it is type-safe. > When this code was written, this was not possible, due to the nature of the order in which class-loading was done and the fact that the code in question was executed very early in the server boot. I don't remember the specific details. > However, something seems to have changed in WildFly, such that we can now use Class#getName on the classes we require. This issue it to replace all the classname Strings with Class#getName() and to also simplify the code under org.jboss.as.xts.jandex, as a lot of that verbose code was added to to cope with the limitation of not being able to use Class#getName(). -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1859) Remove classname Strings from XTS subsystem

by Paul Robinson (JIRA)

Paul Robinson created JBTM-1859: ----------------------------------- Summary: Remove classname Strings from XTS subsystem Key: JBTM-1859 URL: https://issues.jboss.org/browse/JBTM-1859 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: Application Server Integration, XTS Reporter: Paul Robinson Assignee: Paul Robinson Fix For: 5.0.0.M4 THe XTS SubSystem has many classnames passed to Jandex as raw Strings. It would be better to use Class#getName as it is type-safe. When this code was written, this was not possible, due to the nature of the order in which class-loading was done and the fact that the code in question was executed very early in the server boot. I don't remember the specific details. However, something seems to have changed in WildFly, such that we can now use Class#getName on the classes we require. This issue it to replace all the classname Strings with Class#getName() and to also simplify the code under org.jboss.as.xts.jandex, as a lot of that verbose code was added to to cope with the limitation of not being able to use Class#getName(). -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1847) Update blacktie build to test with standalone-blacktie.xml

by Amos Feng (JIRA)

[ https://issues.jboss.org/browse/JBTM-1847?page=com.atlassian.jira.plugin.... ] Amos Feng updated JBTM-1847: ---------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Update blacktie build to test with standalone-blacktie.xml > ---------------------------------------------------------- > > Key: JBTM-1847 > URL: https://issues.jboss.org/browse/JBTM-1847 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: BlackTie, Build System, Demonstrator > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.0.0.M4 > > Original Estimate: 3 days > Remaining Estimate: 3 days > > when JBTM-1568 resolved, it can start jboss-as with the configuration standalone-blacktie.xml which has blacktie subsystem. It should not deploy the blacktie-stompconnect as it has been moved into wildfly codebase. > also it needs to change initializeJBoss.xml to copy this configuration and replace with 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

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1568) Install the StompConnect component of BlackTie as an WildFly subsystem module

by Amos Feng (JIRA)

[ https://issues.jboss.org/browse/JBTM-1568?page=com.atlassian.jira.plugin.... ] Amos Feng resolved JBTM-1568. ----------------------------- Resolution: Done > Install the StompConnect component of BlackTie as an WildFly subsystem module > ----------------------------------------------------------------------------- > > Key: JBTM-1568 > URL: https://issues.jboss.org/browse/JBTM-1568 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: BlackTie > Reporter: Tom Jenkinson > Assignee: Amos Feng > Fix For: 5.0.0.M4 > > Attachments: consoleText > > Original Estimate: 2 weeks > Time Spent: 1 week, 1 day > Remaining Estimate: 4 days > > Apparently there is a way to deploy a war as a module coming soon, wait till this is available possibly. Though, in the meantime, you could merge the stompconnect ear and blacktie-admin-servers ear into a single ear. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1565) Allow callback server to open on a random port and override from the system property

by Crispin Boylan (JIRA)

[ https://issues.jboss.org/browse/JBTM-1565?page=com.atlassian.jira.plugin.... ] Crispin Boylan commented on JBTM-1565: -------------------------------------- resubmitted the pull req: https://github.com/jbosstm/narayana/pull/387 > Allow callback server to open on a random port and override from the system property > ------------------------------------------------------------------------------------ > > Key: JBTM-1565 > URL: https://issues.jboss.org/browse/JBTM-1565 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: BlackTie > Affects Versions: 5.0.0.M2 > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.0.0.Final > > > currently the client can only use the port defined for <SOCKETSERVER> in the btconfig.xml and multi clients can not run together. > we need to allow callback server to open the random port when <SOCKETSERVER PORT="0"> or a range <SOCKETSERVER "12340-12350"> and they could be overridden by socketserver_port and socketserver_host environment variables. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1665) Remove dependency on TAO

by Crispin Boylan (JIRA)

[ https://issues.jboss.org/browse/JBTM-1665?page=com.atlassian.jira.plugin.... ] Crispin Boylan commented on JBTM-1665: -------------------------------------- correction, it's here (had to jiggle things about a bit - new to github!) https://github.com/cris-b/narayana/commit/d76a4d215050172e0984d5d7ed730b9... > Remove dependency on TAO > ------------------------ > > Key: JBTM-1665 > URL: https://issues.jboss.org/browse/JBTM-1665 > Project: JBoss Transaction Manager > Issue Type: Task > Security Level: Public(Everyone can see) > Components: BlackTie > Reporter: Tom Jenkinson > Assignee: Amos Feng > Fix For: 5.0.0.Final > > > Part of the purpose of adding the socket server was to reduce the dependency on TAO, e.g.: > ==6038== 20 bytes in 1 blocks are still reachable in loss record 7 of 54 > ==6038== at 0x4026011: calloc (vg_replace_malloc.c:593) > ==6038== by 0x55C90A5: _dlerror_run (in /lib/libdl-2.12.so) > ==6038== by 0x55C8B70: dlopen@(a)GLIBC_2.1 (in /lib/libdl-2.12.so) > ==6038== by 0x40E2875: ACE_DLL_Handle::open(char const*, int, void*) (OS_NS_dlfcn.inl:124) > ==6038== by 0x40E2D2B: ACE_DLL_Manager::open_dll(char const*, int, void*) (DLL_Manager.cpp:575) > ==6038== by 0x40A3943: ACE_DLL::open_i(char const*, int, bool, void*) (DLL.cpp:167) > ==6038== by 0x40A3AAA: ACE_DLL::open(char const*, int, bool) (DLL.cpp:127) > ==6038== by 0x40A4C0A: ACE_Location_Node::open_dll(int&) (Parse_Node.cpp:479) > ==6038== by 0x40A4D4B: ACE_Function_Node::symbol(ACE_Service_Gestalt*, int&, void (**)(void*)) (Parse_Node.cpp:657) > ==6038== by 0x40A5627: ACE_Service_Type_Factory::make_service_type(ACE_Service_Gestalt*) const (Parse_Node.cpp:880) > ==6038== by 0x40ACEA6: ACE_Service_Gestalt::initialize(ACE_Service_Type_Factory const*, char const*) (Service_Gestalt.cpp:552) > ==6038== by 0x40A5555: ACE_Dynamic_Node::apply(ACE_Service_Gestalt*, int&) (Parse_Node.cpp:326) > ==6038== by 0x40B3302: ace_yyparse(void*) (Svc_Conf_y.cpp:1440) > ==6038== by 0x40AA5C7: ACE_Service_Gestalt::process_directives_i(ACE_Svc_Conf_Param*) (Service_Gestalt.cpp:800) > ==6038== by 0x40AD407: ACE_Service_Gestalt::process_directive(char const*) (Service_Gestalt.cpp:940) > ==6038== by 0x4287A65: TAO::ORB::open_global_services(int, char**) (Service_Config.inl:154) > ==6038== by 0x4247EB3: CORBA::ORB_init(int&, char**, char const*) (ORB.cpp:1254) > ==6038== by 0x49172F6: initOrb(char*) (OrbManagement.cxx:73) > ==6038== by 0x4AB97C4: atmibroker::tx::OTSTxManager::OTSTxManager(char*) (OTSTxManager.cxx:39) > ==6038== by 0x4ABA054: atmibroker::tx::OTSTxManager::create(char*) (OTSTxManager.cxx:57) > ==6038== by 0x4AB0BDC: atmibroker::tx::TxManager::get_instance() (TxManager.cxx:63) > ==6038== by 0x4AE7D06: txManager_open() (TxManagerAvoid.cxx:23) > ==6038== by 0x4AD74D4: tx_open (TxAvoid.cxx:53) > ==6038== by 0x804FF8D: TestXAStompConnection::test() (TestXAStompConnection.cxx:79) > ==6038== by 0x805945B: CppUnit::TestCaller<TestXAStompConnection>::runTest() (TestCaller.h:166) > ==6038== by 0xA5DC76: CppUnit::TestCaseMethodFunctor::operator()() const (TestCase.cpp:32) > ==6038== by 0xA4F53D: CppUnit::DefaultProtector::protect(CppUnit::Functor const&, CppUnit::ProtectorContext const&) (DefaultProtector.cpp:15) > ==6038== by 0xA59812: CppUnit::ProtectorChain::ProtectFunctor::operator()() const (ProtectorChain.cpp:20) > ==6038== by 0xA59544: CppUnit::ProtectorChain::protect(CppUnit::Functor const&, CppUnit::ProtectorContext const&) (ProtectorChain.cpp:77) > ==6038== by 0xA65EF0: CppUnit::TestResult::protect(CppUnit::Functor const&, CppUnit::Test*, std::string const&) (TestResult.cpp:178) > ==6038== by 0xA5D97C: CppUnit::TestCase::run(CppUnit::TestResult*) (TestCase.cpp:92) > ==6038== by 0xA5E2DE: CppUnit::TestComposite::doRunChildTests(CppUnit::TestResult*) (TestComposite.cpp:64) > ==6038== by 0xA5E219: CppUnit::TestComposite::run(CppUnit::TestResult*) (TestComposite.cpp:23) > ==6038== by 0xA5E2DE: CppUnit::TestComposite::doRunChildTests(CppUnit::TestResult*) (TestComposite.cpp:64) > ==6038== by 0xA5E219: CppUnit::TestComposite::run(CppUnit::TestResult*) (TestComposite.cpp:23) > ==6038== by 0xA6850F: CppUnit::TestRunner::WrappingSuite::run(CppUnit::TestResult*) (TestRunner.cpp:47) > ==6038== by 0xA65C89: CppUnit::TestResult::runTest(CppUnit::Test*) (TestResult.cpp:145) > ==6038== by 0xA6834F: CppUnit::TestRunner::run(CppUnit::TestResult&, std::string const&) (TestRunner.cpp:96) > ==6038== by 0xA6BA7A: CppUnit::TextTestRunner::run(CppUnit::TestResult&, std::string const&) (TextTestRunner.cpp:140) > ==6038== by 0xA6BAF4: CppUnit::TextTestRunner::run(std::string, bool, bool, bool) (TextTestRunner.cpp:64) -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1566) Expose timed delivery feature of hornetq in btenqueue

by Crispin Boylan (JIRA)

[ https://issues.jboss.org/browse/JBTM-1566?page=com.atlassian.jira.plugin.... ] Crispin Boylan updated JBTM-1566: --------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/386 A proposed fix for the issue > Expose timed delivery feature of hornetq in btenqueue > ----------------------------------------------------- > > Key: JBTM-1566 > URL: https://issues.jboss.org/browse/JBTM-1566 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: BlackTie > Affects Versions: 5.0.0.M2 > Reporter: Crispin Boylan > Assignee: Amos Feng > Fix For: 5.0.0.Final > > > It would be good to be able to specify a delivery time for the message (either relative or absolute) in the btenqueue. > on #jbossts it was discussed and apparently HornetQ does support this so it just needs to be exposed to the blacktie interface. -- 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, 10 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 July 2013