July 2015 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-741) Remove redundant XTS classes and code paths identified from coverage data

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-741?page=com.atlassian.jira.plugin.s... ] Tom Jenkinson reassigned JBTM-741: ---------------------------------- Assignee: Gytis Trikleris > Remove redundant XTS classes and code paths identified from coverage data > ------------------------------------------------------------------------- > > Key: JBTM-741 > URL: https://issues.jboss.org/browse/JBTM-741 > Project: JBoss Transaction Manager > Issue Type: Task > Components: XTS > Affects Versions: 4.11.0 > Reporter: Andrew Dinn > Assignee: Gytis Trikleris > > Coverage analysis of the XTS code base has idenitifed a lot of unexercised classes and code paths. These need pruning in order to simplify maintenance and testing. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-396) Provide one-phase commit optimization for WS-TX

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-396?page=com.atlassian.jira.plugin.s... ] Tom Jenkinson reassigned JBTM-396: ---------------------------------- Assignee: (was: Gytis Trikleris) > Provide one-phase commit optimization for WS-TX > ----------------------------------------------- > > Key: JBTM-396 > URL: https://issues.jboss.org/browse/JBTM-396 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: XTS > Affects Versions: 4.4.CR1 > Reporter: Mark Little > > WS-AT does not support 1PC optimization. WS-ACID from WS-CAF does. It would be good to provide a configurable option for WS-AT users to enable 1PC optimization. This obviously breaks interoperability, which is why the default should be to have it disabled. > Discussion currently happening here: https://community.jboss.org/message/831313 -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1953) Check other byteman_support scripts support message replay

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1953?page=com.atlassian.jira.plugin.... ] Tom Jenkinson closed JBTM-1953. ------------------------------- Fix Version/s: (was: 6.later) Resolution: Incomplete Description > Check other byteman_support scripts support message replay > ---------------------------------------------------------- > > Key: JBTM-1953 > URL: https://issues.jboss.org/browse/JBTM-1953 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing, XTS > Reporter: Paul Robinson > Assignee: Gytis Trikleris > > See comments towards end of here: JBTM-1919 -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1445) Ensure chained exceptions are used throughout XTS

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1445?page=com.atlassian.jira.plugin.... ] Tom Jenkinson closed JBTM-1445. ------------------------------- Fix Version/s: (was: 6.later) Resolution: Incomplete Description > Ensure chained exceptions are used throughout XTS > ------------------------------------------------- > > Key: JBTM-1445 > URL: https://issues.jboss.org/browse/JBTM-1445 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: XTS > Reporter: Paul Robinson > Labels: assign > > There should be a way of automating this, or at least reliably searching for every occurrence. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1415) TXFramework: Allow servlet-name to be anything in web.xml

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1415?page=com.atlassian.jira.plugin.... ] Tom Jenkinson closed JBTM-1415. ------------------------------- Fix Version/s: (was: 6.later) Resolution: Incomplete Description > TXFramework: Allow servlet-name to be anything in web.xml > --------------------------------------------------------- > > Key: JBTM-1415 > URL: https://issues.jboss.org/browse/JBTM-1415 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: TXFramework > Reporter: Paul Robinson > > Removes a restriction imposed by JBTM-1408. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 9 months

1
0
0 / 0

[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: -------------------------------- Issue Type: Task (was: Bug) > Investigate "still reachable" valgrind memory errors > ---------------------------------------------------- > > Key: JBTM-1666 > URL: https://issues.jboss.org/browse/JBTM-1666 > Project: JBoss Transaction Manager > Issue Type: Task > Components: BlackTie > Reporter: Tom Jenkinson > > 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 was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 9 months

1
0
0 / 0

[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: -------------------------------- Issue Type: Task (was: Bug) > Investigate "possibly lost" valgrind memory issues > -------------------------------------------------- > > Key: JBTM-1667 > URL: https://issues.jboss.org/browse/JBTM-1667 > Project: JBoss Transaction Manager > Issue Type: Task > Components: BlackTie > Reporter: Tom Jenkinson > > 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 was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2142) BlackTie does not have a unit test for services that interact with databases

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2142?page=com.atlassian.jira.plugin.... ] Tom Jenkinson closed JBTM-2142. ------------------------------- Resolution: Rejected We are going to use the quickstart txfooapp as an integration test > BlackTie does not have a unit test for services that interact with databases > ---------------------------------------------------------------------------- > > Key: JBTM-2142 > URL: https://issues.jboss.org/browse/JBTM-2142 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Affects Versions: 5.0.1 > Reporter: Michael Musgrove > > The only test we have for this is in the quickstarts - we need it in the unit/integration tests so that we pick up issues in a timely fashion. > Perhaps a similar approach to the one we use for JDBCStore testing in ArjunaCore/arjuna/pom.xml might work for BlackTie too. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1574) Allow C++ XATMI services deployed into the AS to use the existing JCA connections

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1574?page=com.atlassian.jira.plugin.... ] Tom Jenkinson closed JBTM-1574. ------------------------------- Resolution: Duplicate Issue Dup of JBTM-1576 > Allow C++ XATMI services deployed into the AS to use the existing JCA connections > --------------------------------------------------------------------------------- > > Key: JBTM-1574 > URL: https://issues.jboss.org/browse/JBTM-1574 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: BlackTie > Reporter: Tom Jenkinson > > Cache the JNIEnv* to use to callback on the datasources -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 9 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: -------------------------------- Description: 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). Cache the JNIEnv* to use to callback on the datasources - Allow C++ XATMI services deployed into the AS to use the existing JCA connections was: 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). > 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 > Components: BlackTie, Tooling > Reporter: Tom Jenkinson > 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). > Cache the JNIEnv* to use to callback on the datasources - Allow C++ XATMI services deployed into the AS to use the existing JCA connections -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 9 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 2015