November 2018 - jbossts-issues - Jboss List Archives

[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: -------------------------------- Priority: Minor (was: Major) > 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 > Priority: Minor > > 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 (v7.12.1#712002)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2069) Review BlackTie docs

by Tom Jenkinson (Jira)

[ https://issues.jboss.org/browse/JBTM-2069?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2069: -------------------------------- Priority: Minor (was: Major) > Review BlackTie docs > -------------------- > > Key: JBTM-2069 > URL: https://issues.jboss.org/browse/JBTM-2069 > Project: JBoss Transaction Manager > Issue Type: Task > Components: BlackTie, Documentation > Reporter: Tom Jenkinson > Priority: Minor > > Ensure no erroneous information > Update AS7 references to WildFly > For example: > run.sh -> standalone.sh (changed parameters too) > JBossAS->WildFly > paths, are they up-to-date (for example what apps should be deployed and where) -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1789) Simplify deploy plugin configuration and don't deploy uber (shaded) jars

by Ondra Chaloupka (Jira)

[ https://issues.jboss.org/browse/JBTM-1789?page=com.atlassian.jira.plugin.... ] Ondra Chaloupka reassigned JBTM-1789: ------------------------------------- Assignee: Ondra Chaloupka > Simplify deploy plugin configuration and don't deploy uber (shaded) jars > ------------------------------------------------------------------------ > > Key: JBTM-1789 > URL: https://issues.jboss.org/browse/JBTM-1789 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Build System > Reporter: Paul Gier > Assignee: Ondra Chaloupka > Priority: Major > Fix For: 6.later > > > There is currently configuration of the maven deploy plugin in several modules to either deploy or not deploy artifacts and poms to the Maven repo. The configuration could be simplified using properties, and the uber jars (generated by the shade plugin) should not be deployed to the Maven repository. > Here is the current deployment status and proposed for the modules. > ||Module Name||Current Deployment||Proposed|| > | Narayana: all | deployed | deployed | > | Narayana: common | deployed | deployed | > | Narayana: Arjunacore | deployed | deployed | > | Narayana: ArjunaCore arjuna | deployed | deployed | > | Narayana: ArjunaCore txoj | deployed | deployed | > | Narayana: ArjunaCore arjunacore | deployed | {color:red} skipped {color} | > | Narayana: ArjunaJTA | deployed | deployed | > | Narayana: ArjunaJTA jta | deployed | deployed | > | Narayana: ArjunaJTA cdi | skipped | {color:red} deployed {color} | > | Narayana: ArjunaJTA jdbc | skipped | {color:red} deployed {color} | > | Narayana: ArjunaJTA narayana-jta | deployed | {color:red} skipped {color} | > | Narayana: XTS | deployed | deployed | > | Narayana: XTS byteman_support | deployed | deployed | > | Narayana: XTS WSAS | skipped | skipped | > | Narayana: XTS WSAS xts-test-servlet | skipped | skipped | > | Narayana: XTS WS-C | skipped | skipped | > | Narayana: XTS WSCF | skipped | skipped | > | Narayana: XTS WS-T | skipped | skipped | > | Narayana: XTS WSTX | skipped | skipped | > | Narayana: XTS recovery | skipped | skipped | > | Narayana: XTS bridge | skipped | skipped | > | Narayana: XTS sar | skipped | skipped | > | Narayana: XTS jbossxts | deployed | deployed | > | Narayana: XTS localjunit | skipped | skipped | > | Narayana: XTS localjunit unit | skipped | skipped | > | Narayana: XTS WSTX11-interop | skipped | skipped | > | Narayana: XTS WSTFSC07-interop | skipped | skipped | > | Narayana: XTS localjunit xtstest | skipped | skipped | > | Narayana: XTS localjunit crash-recovery-tests | skipped | skipped | > | Narayana: ArjunaJTS | deployed | deployed | > | Narayana: ArjunaJTS idl | skipped | {color:red} deployed {color} | > | Narayana: ArjunaJTS idl jacorb | skipped | {color:red} deployed {color} | > | Narayana: ArjunaJTS orbportability | skipped | {color:red} deployed {color} | > | Narayana: ArjunaJTS jts | skipped | {color:red} deployed {color} | > | Narayana: ArjunaJTS jtax | skipped | {color:red} deployed {color} | > | Narayana: ArjuntaJTS narayana-jts-jacorb | deployed | {color:red} skipped {color} | > | Narayana: ArjunaJTS integration | deployed | deployed | > | Narayana: rest-tx | deployed | deployed | > | Narayana: rest-tx util | deployed | deployed | > | Narayana: rest-tx tx (RESTful API for Atomic Transactions) | deployed | deployed | > | Narayana: rest-tx webservice | skipped | skipped | > | Narayana: rest-tx integration | deployed | deployed | > | Narayana: txbridge | deployed | deployed | > | Narayana: fileio | deployed | deployed | > | Narayana: STM | skipped | skipped | > | Narayana: txframework | deployed | deployed | > | Narayana: narayana-full | skipped | skipped | > -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2137) Failed CI job because JDBCStore recovery was stalled

by Michael Musgrove (Jira)

[ https://issues.jboss.org/browse/JBTM-2137?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-2137: ----------------------------------- Summary: Failed CI job because JDBCStore recovery was stalled (was: JDBCStore recovery is too slow) > Failed CI job because JDBCStore recovery was stalled > ---------------------------------------------------- > > Key: JBTM-2137 > URL: https://issues.jboss.org/browse/JBTM-2137 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Recovery > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.later > > > The linked CI job failed because the STATESTOREJBOSSTSTXTABLE had too many entries (>600) and this caused the recovery pass to take about 15 minutes which in turn causes subsequent tests to time out. The reason for so many entries is covered by JBTM-2133 but this JIRA is for the poor performance when there are so many entries. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2137) JDBCStore recovery is too slow

by Michael Musgrove (Jira)

[ https://issues.jboss.org/browse/JBTM-2137?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-2137: ----------------------------------- Issue Type: Task (was: Enhancement) > JDBCStore recovery is too slow > ------------------------------ > > Key: JBTM-2137 > URL: https://issues.jboss.org/browse/JBTM-2137 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Recovery > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.later > > > The linked CI job failed because the STATESTOREJBOSSTSTXTABLE had too many entries (>600) and this caused the recovery pass to take about 15 minutes which in turn causes subsequent tests to time out. The reason for so many entries is covered by JBTM-2133 but this JIRA is for the poor performance when there are so many entries. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2137) JDBCStore recovery is too slow

by Michael Musgrove (Jira)

[ https://issues.jboss.org/browse/JBTM-2137?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-2137: ----------------------------------- Priority: Major (was: Minor) > JDBCStore recovery is too slow > ------------------------------ > > Key: JBTM-2137 > URL: https://issues.jboss.org/browse/JBTM-2137 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Recovery > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.later > > > The linked CI job failed because the STATESTOREJBOSSTSTXTABLE had too many entries (>600) and this caused the recovery pass to take about 15 minutes which in turn causes subsequent tests to time out. The reason for so many entries is covered by JBTM-2133 but this JIRA is for the poor performance when there are so many entries. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2777) Investigate the osgi test failure with the JDK 9

by Amos Feng (Jira)

[ https://issues.jboss.org/browse/JBTM-2777?page=com.atlassian.jira.plugin.... ] Amos Feng commented on JBTM-2777: --------------------------------- KARAF supports the jdk9+ since 4.2.0 > Investigate the osgi test failure with the JDK 9 > ------------------------------------------------ > > Key: JBTM-2777 > URL: https://issues.jboss.org/browse/JBTM-2777 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Build System > Reporter: Amos Feng > Assignee: Amos Feng > Priority: Minor > Labels: jdk9 > > The arquillian can not start the karaf. > {code} > -Djava.endorsed.dirs=/home/zhfeng/work/zhfeng/narayana-jdk9/osgi/jta/target/apache-karaf-minimal-4.0.5/lib/endorsed is not supported. Endorsed standards and standalone APIs > in modular form will be supported via the concept of upgradeable modules. > Error: Could not create the Java Virtual Machine. > Error: A fatal exception has occurred. Program will exit. > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3057) build javadoc failure

by Tom Jenkinson (Jira)

[ https://issues.jboss.org/browse/JBTM-3057?page=com.atlassian.jira.plugin.... ] Issue was automatically transitioned when Tom Jenkinson created pull request #1379 in GitHub -------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Reopened) > build javadoc failure > --------------------- > > Key: JBTM-3057 > URL: https://issues.jboss.org/browse/JBTM-3057 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Build System > Reporter: Amos Feng > Assignee: Amos Feng > Priority: Major > > I have to disable the maven-javadoc-plugin on the JDK9 and it needs more investigation. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3057) build javadoc failure

by Tom Jenkinson (Jira)

[ https://issues.jboss.org/browse/JBTM-3057?page=com.atlassian.jira.plugin.... ] Tom Jenkinson reopened JBTM-3057: --------------------------------- > build javadoc failure > --------------------- > > Key: JBTM-3057 > URL: https://issues.jboss.org/browse/JBTM-3057 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Build System > Reporter: Amos Feng > Assignee: Amos Feng > Priority: Major > > I have to disable the maven-javadoc-plugin on the JDK9 and it needs more investigation. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3020) Add ability for resources to indicate XA_RDONLY on end

by Ondra Chaloupka (Jira)

[ https://issues.jboss.org/browse/JBTM-3020?page=com.atlassian.jira.plugin.... ] Ondra Chaloupka commented on JBTM-3020: --------------------------------------- It's a way, just please read what [Jonathan talked about at the forum|https://developer.jboss.org/message/983601#983601] (LastResourceRecord, useAlternativeOrdering, etc.) > Add ability for resources to indicate XA_RDONLY on end > ------------------------------------------------------ > > Key: JBTM-3020 > URL: https://issues.jboss.org/browse/JBTM-3020 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Reporter: David Lloyd > Assignee: Ondra Chaloupka > Priority: Major > Fix For: 5.next > > > As discussed in WFLY-10258 and https://developer.jboss.org/message/982097, this request is to add the ability for an XAResource to indicate (on end) that it has no committable work, which would act as a hint to order that XAResource at an earlier point of prepare processing, which will in turn increase the chances of a 1PC optimization occurring. > As expressed in the forum thread, the mechanism should not interfere with compatibility. One possible way to do this would be to introduce an enhanced subinterface of XAResource which includes a method like this: > {code:java} > int endWithResult(Xid xid, int flags) throws XAException; > {code} > The method behaves semantically identically to {{XAResource#end}} , except it would be allowed to return {{XA_RDONLY}} or {{XA_OK}}. A value of {{XA_RDONLY}} would indicate that the resource expects to return {{XA_RDONLY}} in response to a {{prepare}} call, whereas a value of {{XA_OK}} indicates that the resource's future {{prepare}} result cannot yet be decided or will be {{XA_OK}}. An invalid result should probably behave equivalently to an {{XAException}} being thrown by the {{end}} method. {{XAER_RMERR}} seems like a reasonable error code for this case. An alternative strategy would be to treat an invalid return value as being equivalent to {{XA_OK}}. > Since it's a subinterface of {{XAResource}}, it could also define the following default method: > {code:java} > default void end(Xid xid, int flags) throws XAException { > endWithResult(xid, flags); > } > {code} > This method would not need to be called by the TM, but would correctly satisfy the {{XAResource}} contract without requiring the user to implement the redundant method. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 5 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 November 2018