[JBoss JIRA] (JBTM-1820) Integrate with Camel to support XA Transaction
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1820?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-1820:
--------------------------------
Fix Version/s: 6.0.0.Final
(was: 5.0.0.Final)
> Integrate with Camel to support XA Transaction
> ----------------------------------------------
>
> Key: JBTM-1820
> URL: https://issues.jboss.org/browse/JBTM-1820
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Application Server Integration
> Reporter: Amos Feng
> Assignee: Amos Feng
> Fix For: 6.0.0.Final
>
>
> From Ning Jiang (njiang(a)redhat.com)
> {noformat}
> Camel is using Spring TransactionTemplates to implement the Transactional Client pattern[1].
> As the Spring PlatformTransactionManager cannot manage the multiple resources, we are using the atomikos to show the user how to manage the transactions between JMS and DB resource. It could great if we can replace the atomikos with narayana, then we can promote this example as reference to SA who can sale the solution to the customer.
> Another interesting task could be using the narayana JTA wrapper classes to replace the Spring TransactionTemplate in Camel. As we don't want to build out products on top of Spring framework, using narayana could help us to get ride of Spring and introduce the narayana to integration customer.
> [1]http://camel.apache.org/transactional-client.html
> {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
[JBoss JIRA] (JBTM-1683) btadmin tests on windows failed with "Could not start the server"
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1683?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-1683:
--------------------------------
Fix Version/s: 6.0.0.Final
(was: 5.0.0.Final)
> btadmin tests on windows failed with "Could not start the server"
> -----------------------------------------------------------------
>
> Key: JBTM-1683
> URL: https://issues.jboss.org/browse/JBTM-1683
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: BlackTie
> Reporter: Amos Feng
> Assignee: Amos Feng
> Fix For: 6.0.0.Final
>
>
> http://172.17.131.2/job/blacktie-windows2008-taconic/272
> {code}
> Failed tests:
> testResumeResumeDomain(org.jboss.narayana.blacktie.btadmin.ResumeDomainTest): Command was not successful
> testResumeDomainWithArg(org.jboss.narayana.blacktie.btadmin.ResumeDomainTest): Could not start the server
> testShutdownWithId(org.jboss.narayana.blacktie.btadmin.ShutdownTest): Could not start the server
> testShutdownWithoutId(org.jboss.narayana.blacktie.btadmin.ShutdownTest): Could not start the server
> testShutdownWithInvalidId(org.jboss.narayana.blacktie.btadmin.ShutdownTest): Could not start the server
> testStartup(org.jboss.narayana.blacktie.btadmin.StartupTest): Command was unsuccessful
> testUnadvertiseWithoutServer(org.jboss.narayana.blacktie.btadmin.UnadvertiseTest): Could not start the server
> testUnadvertiseNoArgs(org.jboss.narayana.blacktie.btadmin.UnadvertiseTest): Could not start the server
> testAdvertiseNotAdvertised(org.jboss.narayana.blacktie.btadmin.UnadvertiseTest): Could not start the server
> testUnadvertise(org.jboss.narayana.blacktie.btadmin.UnadvertiseTest): Could not start the server
> testUnadvertiseWithoutService(org.jboss.narayana.blacktie.btadmin.UnadvertiseTest): Could not start the server
> {code}
--
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
[JBoss JIRA] (JBTM-1561) Cannot create a user defined XATMI service
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1561?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-1561:
--------------------------------
Fix Version/s: 6.0.0.Final
(was: 5.0.0.Final)
> Cannot create a user defined XATMI service
> ------------------------------------------
>
> Key: JBTM-1561
> URL: https://issues.jboss.org/browse/JBTM-1561
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: BlackTie, Documentation
> Affects Versions: 5.0.0.M1
> Reporter: Michael Musgrove
> Assignee: Amos Feng
> Fix For: 6.0.0.Final
>
>
> The administrative interface, btadmin, does not support the definition of user defined services. Perhaps this functionality was present in the old RHQ interface and was not ported to btadmin when RHQ support was dropped.
> The documentation set does not describe how to configure user defined services.
--
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
[JBoss JIRA] (JBTM-1666) Investigate "still reachable" valgrind memory errors
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1666?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-1666:
--------------------------------
Fix Version/s: 6.0.0.Final
(was: 5.0.0.Final)
> Investigate "still reachable" valgrind memory errors
> ----------------------------------------------------
>
> Key: JBTM-1666
> URL: https://issues.jboss.org/browse/JBTM-1666
> 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
>
>
> Most of the valgrind logs are full of:
> ==9548== 4 bytes in 1 blocks are still reachable in loss record 1 of 51
> ==9548== at 0x4027D17: operator new(unsigned int) (vg_replace_malloc.c:292)
> ==9548== by 0x4E633A8: google::protobuf::DescriptorPool::DescriptorPool(google::protobuf::DescriptorDatabase*, google::protobuf::DescriptorPool::ErrorCollector*) (descriptor.cc:770)
> ==9548== by 0x4E6346D: google::protobuf::(anonymous namespace)::InitGeneratedPool() (descriptor.cc:816)
> ==9548== by 0x546E8DF: pthread_once (in /lib/libpthread-2.12.so)
> ==9548== by 0x4E86E3F: google::protobuf::protobuf_AddDesc_google_2fprotobuf_2fdescriptor_2eproto() (descriptor.pb.cc:656)
> ==9548== by 0x4E8790C: __static_initialization_and_destruction_0(int, int) (descriptor.pb.cc:705)
> ==9548== by 0x4ED2495: ??? (in /home/hudson/workspace/blacktie-linux32/nbf/target/cxx/runtime/lib/libprotobuf.so.7)
> ==9548== by 0x4E4538C: ??? (in /home/hudson/workspace/blacktie-linux32/nbf/target/cxx/runtime/lib/libprotobuf.so.7)
> ==9548== by 0x400EFCE: _dl_init (in /lib/ld-2.12.so)
> ==9548== by 0x400088E: ??? (in /lib/ld-2.12.so)
> Please can you explain what this is and whether it is a leak and if so, try to resolve 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, 8 months
[JBoss JIRA] (JBTM-1665) Remove dependency on TAO
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1665?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-1665:
--------------------------------
Fix Version/s: 5.0.0.M5
(was: 5.0.0.Final)
> 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.M5
>
>
> 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, 8 months
[JBoss JIRA] (JBTM-1667) Investigate "possibly lost" valgrind memory issues
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1667?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-1667:
--------------------------------
Fix Version/s: 6.0.0.Final
(was: 5.0.0.Final)
> Investigate "possibly lost" valgrind memory issues
> --------------------------------------------------
>
> Key: JBTM-1667
> URL: https://issues.jboss.org/browse/JBTM-1667
> 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
>
>
> There are "possibly lost" memory issues when running BlackTie under valgrind:
> ==26112== 1,234 bytes in 21 blocks are possibly lost in loss record 56 of 58
> ==26112== at 0x4006355: operator new(unsigned int) (vg_replace_malloc.c:214)
> ==26112== by 0x1DC13A: std::string::_Rep::_S_create(unsigned int, unsigned int, std::allocator<char> const&) (in /usr/lib/libstdc++.so.6.0.8)
> ==26112== by 0x1DCCD7: std::string::_Rep::_M_clone(std::allocator<char> const&, unsigned int) (in /usr/lib/libstdc++.so.6.0.8)
> ==26112== by 0x1DD666: std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(std::string const&) (in /usr/lib/libstdc++.so.6.0.8)
> ==26112== by 0x4E00DBE: bool google::protobuf::InsertIfNotPresent<std::map<std::string, std::pair<void const*, int>, std::less<std::string>, std::allocator<std::pair<std::string const, std::pair<void const*, int> > > >, std::string, std::pair<void const*, int> >(std::map<std::string, std::pair<void const*, int>, std::less<std::string>, std::allocator<std::pair<std::string const, std::pair<void const*, int> > > >*, std::string const&, std::pair<void const*, int> const&) (stl_pair.h:85)
> ==26112== by 0x4E01BAF: google::protobuf::SimpleDescriptorDatabase::DescriptorIndex<std::pair<void const*, int> >::AddFile(google::protobuf::FileDescriptorProto const&, std::pair<void const*, int>) (descriptor_database.cc:56)
> ==26112== by 0x4DFC4E6: google::protobuf::EncodedDescriptorDatabase::Add(void const*, int) (descriptor_database.cc:312)
> ==26112== by 0x4DBC1FF: google::protobuf::DescriptorPool::InternalAddGeneratedFile(void const*, int) (descriptor.cc:862)
> ==26112== by 0x4DE4E3F: google::protobuf::protobuf_AddDesc_google_2fprotobuf_2fdescriptor_2eproto() (descriptor.pb.cc:656)
> ==26112== by 0x4DE590C: __static_initialization_and_destruction_0(int, int) (descriptor.pb.cc:705)
> ==26112== by 0x4E30495: ??? (in /home/hudson/workspace/blacktie-linux32/xatmi/target/cxx/runtime/lib/libprotobuf.so.7)
> ==26112== by 0x4DA338C: ??? (in /home/hudson/workspace/blacktie-linux32/xatmi/target/cxx/runtime/lib/libprotobuf.so.7)
> ==26112== by 0xAA5492: call_init (in /lib/ld-2.5.so)
> ==26112== by 0xAA55A2: _dl_init (in /lib/ld-2.5.so)
> ==26112== by 0xA9784E: ??? (in /lib/ld-2.5.so)
> ==26112==
> ==26112== 303,104 bytes in 37 blocks are possibly lost in loss record 58 of 58
> ==26112== at 0x4005B83: malloc (vg_replace_malloc.c:195)
> ==26112== by 0x489CBB0: apr_pool_create_ex (in /usr/lib/libapr-1.so.0.2.7)
> ==26112== by 0x489CDCE: apr_pool_initialize (in /usr/lib/libapr-1.so.0.2.7)
> ==26112== by 0x489DB0E: apr_initialize (in /usr/lib/libapr-1.so.0.2.7)
> ==26112== by 0x4C8EE54: log4cxx::helpers::APRInitializer::APRInitializer() (aprinitializer.cpp:41)
> ==26112== by 0x4C8EF39: log4cxx::helpers::APRInitializer::getInstance() (aprinitializer.cpp:57)
> ==26112== by 0x4C8F000: log4cxx::helpers::APRInitializer::initialize() (aprinitializer.cpp:63)
> ==26112== by 0x4C514E9: log4cxx::helpers::ObjectImpl::ObjectImpl() (objectimpl.cpp:30)
> ==26112== by 0x4C251EA: log4cxx::helpers::CharsetDecoder::CharsetDecoder() (charsetdecoder.cpp:413)
> ==26112== by 0x4C27339: log4cxx::helpers::LocaleCharsetDecoder::LocaleCharsetDecoder() (charsetdecoder.cpp:360)
> ==26112== by 0x4C25714: log4cxx::helpers::CharsetDecoder::createDefaultDecoder() (charsetdecoder.cpp:430)
> ==26112== by 0x4C25789: log4cxx::helpers::CharsetDecoder::getDefaultDecoder() (charsetdecoder.cpp:435)
> ==26112== by 0x4BFC72A: log4cxx::helpers::Transcoder::decode(std::string const&, std::string&) (transcoder.cpp:247)
> ==26112== by 0x4C185B7: log4cxx::LogManager::getLogger(std::string const&) (logmanager.cpp:120)
> ==26112== by 0x4CBD428: log4cxx::Logger::getLogger(char const*) (logger.cpp:496)
> ==26112== by 0x490E768: __static_initialization_and_destruction_0(int, int) (XsdValidator.cxx:21)
> ==26112== by 0x490E7A6: global constructors keyed to _ZN12XsdValidator6loggerE (XsdValidator.cxx:205)
> ==26112== by 0x4913665: ??? (in /home/hudson/workspace/blacktie-linux32/xatmi/target/cxx/runtime/lib/libblacktie-core.so)
> ==26112== by 0x48E4D60: ??? (in /home/hudson/workspace/blacktie-linux32/xatmi/target/cxx/runtime/lib/libblacktie-core.so)
> ==26112== by 0xAA5492: call_init (in /lib/ld-2.5.so)
> ==26112== by 0xAA55A2: _dl_init (in /lib/ld-2.5.so)
> ==26112== by 0xA9784E: ??? (in /lib/ld-2.5.so)
--
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
[JBoss JIRA] (JBTM-1585) Support embbed sql with oracle pro*c/c++
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1585?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-1585:
--------------------------------
Fix Version/s: 6.0.0.Final
(was: 5.0.0.Final)
> Support embbed sql with oracle pro*c/c++
> ----------------------------------------
>
> Key: JBTM-1585
> URL: https://issues.jboss.org/browse/JBTM-1585
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: BlackTie
> Reporter: Amos Feng
> Assignee: Amos Feng
> Priority: Minor
> Fix For: 6.0.0.Final
>
>
> oracle pro*c/c++ compiles the embbed sql into c/c++ files and we need to support a "fake" oracle dll which might proxy the database operations to the AS.
> this feather is useful for migration
> {quote}
> Is it possible to use BlackTie in this format:
> 1. JBoss AS (JTA, database connections, transaction manager)
> 2. BlackTie Services with embedded sql (oracle pro*c/c++)
> For example:
> AS open database connection, begin and commit transaction.
> In BlackTie Services execute DMLs (oracle pro*c/c++).
> {quote}
--
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