from:"Jeremy Leung \(JIRA\)"

[jira] [Updated] (AMQCPP-534) Closing connection with setTransportListener to NULL may cause core dump

2015-02-15 Thread Jeremy Leung (JIRA)


 [ 
https://issues.apache.org/jira/browse/AMQCPP-534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Leung updated AMQCPP-534:

Attachment: AMQCPP-534.patch.txt

> Closing connection with setTransportListener to NULL may cause core dump
> 
>
> Key: AMQCPP-534
> URL: https://issues.apache.org/jira/browse/AMQCPP-534
> Project: ActiveMQ C++ Client
>  Issue Type: Bug
>  Components: Transports
>Affects Versions: 3.8.2
>Reporter: Jeremy Leung
>Assignee: Timothy Bish
> Fix For: 3.8.4, 3.9.0
>
> Attachments: AMQCPP-534.patch.txt
>
>
> This happen in random; and will cause core dump under Solaris 10.
> {panel:title=Core dump happened on thread #22 which is a thread for IO for 
> activemq|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#CE}
> {noformat}
> t@22 (l@22) terminated by signal SEGV (no mapping at the fault address)
> 0xfcbef02c: onCommand+0x0370:   movl (%edi),%eax
> (dbx) where -h
> current thread: t@22
> =>[1] 
> activemq::transport::failover::FailoverTransportListener::onCommand(0x1c20d280,
>  0xfa567ce0), at 0xfcbef02c
>   [2] activemq::transport::TransportFilter::onCommand(0x116c3700, 
> 0xfa567d20), at 0xfcb7ae15
>   [3] 
> activemq::wireformat::openwire::OpenWireFormatNegotiator::onCommand(0x116c3700,
>  0xfa567d70), at 0xfcc5ff05
>   [4] activemq::transport::TransportFilter::onCommand(0x10bdaaa0, 
> 0xfa567de0), at 0xfcb7ae15
>   [5] 
> activemq::transport::inactivity::InactivityMonitor::onCommand(0x10bdaaa0, 
> 0xfa567e40), at 0xfcbf69f7
>   [6] activemq::transport::TransportFilter::onCommand(0x1027cbc0, 
> 0xfa567e90), at 0xfcb7ae15
>   [7] activemq::transport::IOTransport::fire(0x1bbc4ab8, 0xfa567ef0), at 
> 0xfcb78a49
>   [8] activemq::transport::IOTransport::run(0x1bbc4ab8), at 0xfcb79827
>   [9] decaf::lang::Thread::run(0x1c2080a0), at 0xfcd58512
>   [10] __unnamed_syh4P47F8S2uD::runCallback(0x1c21c138), at 0xfcd1cc2f
>   [11] __unnamed_syh4P47F8S2uD::threadEntryMethod(0x1c21c138), at 0xfcd1cbc6
>   [12] _thr_setup(0xfac2a200), at 0xfc0771c0
>   [13] _lwp_start(), at 0xfc0774b0
> {noformat}
> {panel}
> {panel:title=Stack trace for the main 
> thread|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#CE}
> {noformat}
> -  lwp# 1 / thread# 1  
>  fc07750b __lwp_park (163995d8, 1bbc1e10, 8046358) + b
>  fc071d07 cond_wait_queue (163995d8, 1bbc1e10, 8046358) + 5e
>  fc072084 cond_wait_common (163995d8, 1bbc1e10, 8046358) + 1db
>  fc0722b6 _cond_timedwait (163995d8, 1bbc1e10, 80463c8) + 51
>  fc072321 cond_timedwait (163995d8, 1bbc1e10, 80463c8) + 24
>  fc07235d pthread_cond_timedwait (163995d8, 1bbc1e10, 80463c8) + 1e
>  fcd21550 bool 
> decaf::internal::util::concurrent::PlatformThread::interruptibleWaitOnCondition(_pthread_cond*,_pthread_mutex*,long
>  long,int,decaf::internal::util::concurrent::CompletionCondition&) (163995d8, 
> 1bbc1e10, 493e0, 0, 0, 8046434) + 110
>  fcd1f051 bool 
> decaf::internal::util::concurrent::Threading::join(decaf::internal::util::concurrent::ThreadHandle*,long
>  long,int) (1bbe5660, 493e0, 0, 0, fcd5877a) + 13d
>  fcd587a0 void decaf::lang::Thread::join(long long) (1c20d270, 493e0, 0) + 38
>  fcb61945 void activemq::threads::CompositeTaskRunner::shutdown(long long) 
> (f3b1730, 493e0, 0) + e5
>  fcbd26d3 void activemq::transport::failover::FailoverTransport::close() 
> (efde3f8) + 327
>  fcb7b799 void activemq::transport::TransportFilter::close() (118b49e0) + 191
>  fc940003 void activemq::core::ActiveMQConnection::disconnect(long long) 
> (eef0fb8, 0, 0) + 52f
>  fc93c3f3 void activemq::core::ActiveMQConnection::close() (eef0fb8) + b47
>  0888e6ec main (7, 80475dc, 80475fc) + 149
>  0888dd6a _start   (7, 9e7dafc, 804775d, 8047760, 8047769, 804777f) + 7a
> {noformat}
> {panel}
> This is happen only during the disconnect. So, what i suspected is that there 
> have an concurrent issue between the ActiveMQConnection, TransportFilter, 
> FailoverTransportListener.
> As i dig into the code, i see during the disconnection, the transport 
> listener will being set to NULL at the very first stage. However, the another 
> thread may have access to the pointer of the null transport listener as the 
> NULL check is not thread safe.
> {noformat}
> void ActiveMQConnection::disconnect(long long lastDeliveredSequenceId) {
> try {
> // Clear the listener, we don't care about async errors at this point.
> this->config->transport->setTransportListener(NULL);
> [...]
> {noformat}
> {noformat}
> void FailoverTransportListener::onCommand(const Pointer command) {
> if (command == NULL) {
> return;
> }
> if (command->isResponse()) {
> Pointer response = command.dynamicCast();
> parent->processR

[jira] [Updated] (AMQCPP-534) Closing connection with setTransportListener to NULL may cause core dump

2015-02-12 Thread Jeremy Leung (JIRA)


 [ 
https://issues.apache.org/jira/browse/AMQCPP-534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Leung updated AMQCPP-534:

Attachment: (was: AMQCPP-534.patch.txt)

> Closing connection with setTransportListener to NULL may cause core dump
> 
>
> Key: AMQCPP-534
> URL: https://issues.apache.org/jira/browse/AMQCPP-534
> Project: ActiveMQ C++ Client
>  Issue Type: Bug
>  Components: Transports
>Affects Versions: 3.8.2
>Reporter: Jeremy Leung
>Assignee: Timothy Bish
>
> This happen in random; and will cause core dump under Solaris 10.
> {panel:title=Core dump happened on thread #22 which is a thread for IO for 
> activemq|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#CE}
> {noformat}
> t@22 (l@22) terminated by signal SEGV (no mapping at the fault address)
> 0xfcbef02c: onCommand+0x0370:   movl (%edi),%eax
> (dbx) where -h
> current thread: t@22
> =>[1] 
> activemq::transport::failover::FailoverTransportListener::onCommand(0x1c20d280,
>  0xfa567ce0), at 0xfcbef02c
>   [2] activemq::transport::TransportFilter::onCommand(0x116c3700, 
> 0xfa567d20), at 0xfcb7ae15
>   [3] 
> activemq::wireformat::openwire::OpenWireFormatNegotiator::onCommand(0x116c3700,
>  0xfa567d70), at 0xfcc5ff05
>   [4] activemq::transport::TransportFilter::onCommand(0x10bdaaa0, 
> 0xfa567de0), at 0xfcb7ae15
>   [5] 
> activemq::transport::inactivity::InactivityMonitor::onCommand(0x10bdaaa0, 
> 0xfa567e40), at 0xfcbf69f7
>   [6] activemq::transport::TransportFilter::onCommand(0x1027cbc0, 
> 0xfa567e90), at 0xfcb7ae15
>   [7] activemq::transport::IOTransport::fire(0x1bbc4ab8, 0xfa567ef0), at 
> 0xfcb78a49
>   [8] activemq::transport::IOTransport::run(0x1bbc4ab8), at 0xfcb79827
>   [9] decaf::lang::Thread::run(0x1c2080a0), at 0xfcd58512
>   [10] __unnamed_syh4P47F8S2uD::runCallback(0x1c21c138), at 0xfcd1cc2f
>   [11] __unnamed_syh4P47F8S2uD::threadEntryMethod(0x1c21c138), at 0xfcd1cbc6
>   [12] _thr_setup(0xfac2a200), at 0xfc0771c0
>   [13] _lwp_start(), at 0xfc0774b0
> {noformat}
> {panel}
> {panel:title=Stack trace for the main 
> thread|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#CE}
> {noformat}
> -  lwp# 1 / thread# 1  
>  fc07750b __lwp_park (163995d8, 1bbc1e10, 8046358) + b
>  fc071d07 cond_wait_queue (163995d8, 1bbc1e10, 8046358) + 5e
>  fc072084 cond_wait_common (163995d8, 1bbc1e10, 8046358) + 1db
>  fc0722b6 _cond_timedwait (163995d8, 1bbc1e10, 80463c8) + 51
>  fc072321 cond_timedwait (163995d8, 1bbc1e10, 80463c8) + 24
>  fc07235d pthread_cond_timedwait (163995d8, 1bbc1e10, 80463c8) + 1e
>  fcd21550 bool 
> decaf::internal::util::concurrent::PlatformThread::interruptibleWaitOnCondition(_pthread_cond*,_pthread_mutex*,long
>  long,int,decaf::internal::util::concurrent::CompletionCondition&) (163995d8, 
> 1bbc1e10, 493e0, 0, 0, 8046434) + 110
>  fcd1f051 bool 
> decaf::internal::util::concurrent::Threading::join(decaf::internal::util::concurrent::ThreadHandle*,long
>  long,int) (1bbe5660, 493e0, 0, 0, fcd5877a) + 13d
>  fcd587a0 void decaf::lang::Thread::join(long long) (1c20d270, 493e0, 0) + 38
>  fcb61945 void activemq::threads::CompositeTaskRunner::shutdown(long long) 
> (f3b1730, 493e0, 0) + e5
>  fcbd26d3 void activemq::transport::failover::FailoverTransport::close() 
> (efde3f8) + 327
>  fcb7b799 void activemq::transport::TransportFilter::close() (118b49e0) + 191
>  fc940003 void activemq::core::ActiveMQConnection::disconnect(long long) 
> (eef0fb8, 0, 0) + 52f
>  fc93c3f3 void activemq::core::ActiveMQConnection::close() (eef0fb8) + b47
>  0888e6ec main (7, 80475dc, 80475fc) + 149
>  0888dd6a _start   (7, 9e7dafc, 804775d, 8047760, 8047769, 804777f) + 7a
> {noformat}
> {panel}
> This is happen only during the disconnect. So, what i suspected is that there 
> have an concurrent issue between the ActiveMQConnection, TransportFilter, 
> FailoverTransportListener.
> As i dig into the code, i see during the disconnection, the transport 
> listener will being set to NULL at the very first stage. However, the another 
> thread may have access to the pointer of the null transport listener as the 
> NULL check is not thread safe.
> {noformat}
> void ActiveMQConnection::disconnect(long long lastDeliveredSequenceId) {
> try {
> // Clear the listener, we don't care about async errors at this point.
> this->config->transport->setTransportListener(NULL);
> [...]
> {noformat}
> {noformat}
> void FailoverTransportListener::onCommand(const Pointer command) {
> if (command == NULL) {
> return;
> }
> if (command->isResponse()) {
> Pointer response = command.dynamicCast();
> parent->processResponse(response);
> }
> if (!parent->isInitialized()) {
>

[jira] [Updated] (AMQCPP-534) Closing connection with setTransportListener to NULL may cause core dump

2015-02-12 Thread Jeremy Leung (JIRA)


 [ 
https://issues.apache.org/jira/browse/AMQCPP-534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Leung updated AMQCPP-534:

Attachment: AMQCPP-534.patch.txt

> Closing connection with setTransportListener to NULL may cause core dump
> 
>
> Key: AMQCPP-534
> URL: https://issues.apache.org/jira/browse/AMQCPP-534
> Project: ActiveMQ C++ Client
>  Issue Type: Bug
>  Components: Transports
>Affects Versions: 3.8.2
>Reporter: Jeremy Leung
>Assignee: Timothy Bish
> Attachments: AMQCPP-534.patch.txt
>
>
> This happen in random; and will cause core dump under Solaris 10.
> {panel:title=Core dump happened on thread #22 which is a thread for IO for 
> activemq|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#CE}
> {noformat}
> t@22 (l@22) terminated by signal SEGV (no mapping at the fault address)
> 0xfcbef02c: onCommand+0x0370:   movl (%edi),%eax
> (dbx) where -h
> current thread: t@22
> =>[1] 
> activemq::transport::failover::FailoverTransportListener::onCommand(0x1c20d280,
>  0xfa567ce0), at 0xfcbef02c
>   [2] activemq::transport::TransportFilter::onCommand(0x116c3700, 
> 0xfa567d20), at 0xfcb7ae15
>   [3] 
> activemq::wireformat::openwire::OpenWireFormatNegotiator::onCommand(0x116c3700,
>  0xfa567d70), at 0xfcc5ff05
>   [4] activemq::transport::TransportFilter::onCommand(0x10bdaaa0, 
> 0xfa567de0), at 0xfcb7ae15
>   [5] 
> activemq::transport::inactivity::InactivityMonitor::onCommand(0x10bdaaa0, 
> 0xfa567e40), at 0xfcbf69f7
>   [6] activemq::transport::TransportFilter::onCommand(0x1027cbc0, 
> 0xfa567e90), at 0xfcb7ae15
>   [7] activemq::transport::IOTransport::fire(0x1bbc4ab8, 0xfa567ef0), at 
> 0xfcb78a49
>   [8] activemq::transport::IOTransport::run(0x1bbc4ab8), at 0xfcb79827
>   [9] decaf::lang::Thread::run(0x1c2080a0), at 0xfcd58512
>   [10] __unnamed_syh4P47F8S2uD::runCallback(0x1c21c138), at 0xfcd1cc2f
>   [11] __unnamed_syh4P47F8S2uD::threadEntryMethod(0x1c21c138), at 0xfcd1cbc6
>   [12] _thr_setup(0xfac2a200), at 0xfc0771c0
>   [13] _lwp_start(), at 0xfc0774b0
> {noformat}
> {panel}
> {panel:title=Stack trace for the main 
> thread|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#CE}
> {noformat}
> -  lwp# 1 / thread# 1  
>  fc07750b __lwp_park (163995d8, 1bbc1e10, 8046358) + b
>  fc071d07 cond_wait_queue (163995d8, 1bbc1e10, 8046358) + 5e
>  fc072084 cond_wait_common (163995d8, 1bbc1e10, 8046358) + 1db
>  fc0722b6 _cond_timedwait (163995d8, 1bbc1e10, 80463c8) + 51
>  fc072321 cond_timedwait (163995d8, 1bbc1e10, 80463c8) + 24
>  fc07235d pthread_cond_timedwait (163995d8, 1bbc1e10, 80463c8) + 1e
>  fcd21550 bool 
> decaf::internal::util::concurrent::PlatformThread::interruptibleWaitOnCondition(_pthread_cond*,_pthread_mutex*,long
>  long,int,decaf::internal::util::concurrent::CompletionCondition&) (163995d8, 
> 1bbc1e10, 493e0, 0, 0, 8046434) + 110
>  fcd1f051 bool 
> decaf::internal::util::concurrent::Threading::join(decaf::internal::util::concurrent::ThreadHandle*,long
>  long,int) (1bbe5660, 493e0, 0, 0, fcd5877a) + 13d
>  fcd587a0 void decaf::lang::Thread::join(long long) (1c20d270, 493e0, 0) + 38
>  fcb61945 void activemq::threads::CompositeTaskRunner::shutdown(long long) 
> (f3b1730, 493e0, 0) + e5
>  fcbd26d3 void activemq::transport::failover::FailoverTransport::close() 
> (efde3f8) + 327
>  fcb7b799 void activemq::transport::TransportFilter::close() (118b49e0) + 191
>  fc940003 void activemq::core::ActiveMQConnection::disconnect(long long) 
> (eef0fb8, 0, 0) + 52f
>  fc93c3f3 void activemq::core::ActiveMQConnection::close() (eef0fb8) + b47
>  0888e6ec main (7, 80475dc, 80475fc) + 149
>  0888dd6a _start   (7, 9e7dafc, 804775d, 8047760, 8047769, 804777f) + 7a
> {noformat}
> {panel}
> This is happen only during the disconnect. So, what i suspected is that there 
> have an concurrent issue between the ActiveMQConnection, TransportFilter, 
> FailoverTransportListener.
> As i dig into the code, i see during the disconnection, the transport 
> listener will being set to NULL at the very first stage. However, the another 
> thread may have access to the pointer of the null transport listener as the 
> NULL check is not thread safe.
> {noformat}
> void ActiveMQConnection::disconnect(long long lastDeliveredSequenceId) {
> try {
> // Clear the listener, we don't care about async errors at this point.
> this->config->transport->setTransportListener(NULL);
> [...]
> {noformat}
> {noformat}
> void FailoverTransportListener::onCommand(const Pointer command) {
> if (command == NULL) {
> return;
> }
> if (command->isResponse()) {
> Pointer response = command.dynamicCast();
> parent->processResponse(response);
> }
> if (!

[jira] [Updated] (AMQCPP-534) Closing connection with setTransportListener to NULL may cause core dump

2015-02-12 Thread Jeremy Leung (JIRA)


 [ 
https://issues.apache.org/jira/browse/AMQCPP-534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Leung updated AMQCPP-534:

Patch Info: Patch Available

> Closing connection with setTransportListener to NULL may cause core dump
> 
>
> Key: AMQCPP-534
> URL: https://issues.apache.org/jira/browse/AMQCPP-534
> Project: ActiveMQ C++ Client
>  Issue Type: Bug
>  Components: Transports
>Affects Versions: 3.8.2
>Reporter: Jeremy Leung
>Assignee: Timothy Bish
>
> This happen in random; and will cause core dump under Solaris 10.
> {panel:title=Core dump happened on thread #22 which is a thread for IO for 
> activemq|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#CE}
> {noformat}
> t@22 (l@22) terminated by signal SEGV (no mapping at the fault address)
> 0xfcbef02c: onCommand+0x0370:   movl (%edi),%eax
> (dbx) where -h
> current thread: t@22
> =>[1] 
> activemq::transport::failover::FailoverTransportListener::onCommand(0x1c20d280,
>  0xfa567ce0), at 0xfcbef02c
>   [2] activemq::transport::TransportFilter::onCommand(0x116c3700, 
> 0xfa567d20), at 0xfcb7ae15
>   [3] 
> activemq::wireformat::openwire::OpenWireFormatNegotiator::onCommand(0x116c3700,
>  0xfa567d70), at 0xfcc5ff05
>   [4] activemq::transport::TransportFilter::onCommand(0x10bdaaa0, 
> 0xfa567de0), at 0xfcb7ae15
>   [5] 
> activemq::transport::inactivity::InactivityMonitor::onCommand(0x10bdaaa0, 
> 0xfa567e40), at 0xfcbf69f7
>   [6] activemq::transport::TransportFilter::onCommand(0x1027cbc0, 
> 0xfa567e90), at 0xfcb7ae15
>   [7] activemq::transport::IOTransport::fire(0x1bbc4ab8, 0xfa567ef0), at 
> 0xfcb78a49
>   [8] activemq::transport::IOTransport::run(0x1bbc4ab8), at 0xfcb79827
>   [9] decaf::lang::Thread::run(0x1c2080a0), at 0xfcd58512
>   [10] __unnamed_syh4P47F8S2uD::runCallback(0x1c21c138), at 0xfcd1cc2f
>   [11] __unnamed_syh4P47F8S2uD::threadEntryMethod(0x1c21c138), at 0xfcd1cbc6
>   [12] _thr_setup(0xfac2a200), at 0xfc0771c0
>   [13] _lwp_start(), at 0xfc0774b0
> {noformat}
> {panel}
> {panel:title=Stack trace for the main 
> thread|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#CE}
> {noformat}
> -  lwp# 1 / thread# 1  
>  fc07750b __lwp_park (163995d8, 1bbc1e10, 8046358) + b
>  fc071d07 cond_wait_queue (163995d8, 1bbc1e10, 8046358) + 5e
>  fc072084 cond_wait_common (163995d8, 1bbc1e10, 8046358) + 1db
>  fc0722b6 _cond_timedwait (163995d8, 1bbc1e10, 80463c8) + 51
>  fc072321 cond_timedwait (163995d8, 1bbc1e10, 80463c8) + 24
>  fc07235d pthread_cond_timedwait (163995d8, 1bbc1e10, 80463c8) + 1e
>  fcd21550 bool 
> decaf::internal::util::concurrent::PlatformThread::interruptibleWaitOnCondition(_pthread_cond*,_pthread_mutex*,long
>  long,int,decaf::internal::util::concurrent::CompletionCondition&) (163995d8, 
> 1bbc1e10, 493e0, 0, 0, 8046434) + 110
>  fcd1f051 bool 
> decaf::internal::util::concurrent::Threading::join(decaf::internal::util::concurrent::ThreadHandle*,long
>  long,int) (1bbe5660, 493e0, 0, 0, fcd5877a) + 13d
>  fcd587a0 void decaf::lang::Thread::join(long long) (1c20d270, 493e0, 0) + 38
>  fcb61945 void activemq::threads::CompositeTaskRunner::shutdown(long long) 
> (f3b1730, 493e0, 0) + e5
>  fcbd26d3 void activemq::transport::failover::FailoverTransport::close() 
> (efde3f8) + 327
>  fcb7b799 void activemq::transport::TransportFilter::close() (118b49e0) + 191
>  fc940003 void activemq::core::ActiveMQConnection::disconnect(long long) 
> (eef0fb8, 0, 0) + 52f
>  fc93c3f3 void activemq::core::ActiveMQConnection::close() (eef0fb8) + b47
>  0888e6ec main (7, 80475dc, 80475fc) + 149
>  0888dd6a _start   (7, 9e7dafc, 804775d, 8047760, 8047769, 804777f) + 7a
> {noformat}
> {panel}
> This is happen only during the disconnect. So, what i suspected is that there 
> have an concurrent issue between the ActiveMQConnection, TransportFilter, 
> FailoverTransportListener.
> As i dig into the code, i see during the disconnection, the transport 
> listener will being set to NULL at the very first stage. However, the another 
> thread may have access to the pointer of the null transport listener as the 
> NULL check is not thread safe.
> {noformat}
> void ActiveMQConnection::disconnect(long long lastDeliveredSequenceId) {
> try {
> // Clear the listener, we don't care about async errors at this point.
> this->config->transport->setTransportListener(NULL);
> [...]
> {noformat}
> {noformat}
> void FailoverTransportListener::onCommand(const Pointer command) {
> if (command == NULL) {
> return;
> }
> if (command->isResponse()) {
> Pointer response = command.dynamicCast();
> parent->processResponse(response);
> }
> if (!parent->isInitialized()) {
> parent->setIni

[jira] [Updated] (AMQCPP-562) Reduce memory delete and allocation in ArrayList

2015-01-29 Thread Jeremy Leung (JIRA)


 [ 
https://issues.apache.org/jira/browse/AMQCPP-562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Leung updated AMQCPP-562:

Attachment: AMQCPP-562.patch.txt

> Reduce memory delete and allocation in ArrayList
> 
>
> Key: AMQCPP-562
> URL: https://issues.apache.org/jira/browse/AMQCPP-562
> Project: ActiveMQ C++ Client
>  Issue Type: Improvement
>  Components: Decaf
>Affects Versions: 3.8.3
>Reporter: Jeremy Leung
>Assignee: Timothy Bish
>Priority: Minor
> Attachments: AMQCPP-562.patch.txt
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (AMQCPP-562) Reduce memory delete and allocation in ArrayList

2015-01-29 Thread Jeremy Leung (JIRA)

Jeremy Leung created AMQCPP-562:
---

 Summary: Reduce memory delete and allocation in ArrayList
 Key: AMQCPP-562
 URL: https://issues.apache.org/jira/browse/AMQCPP-562
 Project: ActiveMQ C++ Client
  Issue Type: Improvement
  Components: Decaf
Affects Versions: 3.8.3
Reporter: Jeremy Leung
Assignee: Timothy Bish
Priority: Minor






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (AMQCPP-561) Memory Leak in ActiveMQConsumerKernel while calling deliverAcks

2015-01-28 Thread Jeremy Leung (JIRA)

Jeremy Leung created AMQCPP-561:
---

 Summary: Memory Leak in ActiveMQConsumerKernel while calling 
deliverAcks
 Key: AMQCPP-561
 URL: https://issues.apache.org/jira/browse/AMQCPP-561
 Project: ActiveMQ C++ Client
  Issue Type: Bug
  Components: Other C++ Clients
Affects Versions: 3.8.3
Reporter: Jeremy Leung
Assignee: Timothy Bish






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (AMQCPP-561) Memory Leak in ActiveMQConsumerKernel while calling deliverAcks

2015-01-28 Thread Jeremy Leung (JIRA)


 [ 
https://issues.apache.org/jira/browse/AMQCPP-561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Leung closed AMQCPP-561.
---
Resolution: Duplicate

> Memory Leak in ActiveMQConsumerKernel while calling deliverAcks
> ---
>
> Key: AMQCPP-561
> URL: https://issues.apache.org/jira/browse/AMQCPP-561
> Project: ActiveMQ C++ Client
>  Issue Type: Bug
>  Components: Other C++ Clients
>Affects Versions: 3.8.3
>Reporter: Jeremy Leung
>Assignee: Timothy Bish
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (AMQCPP-556) setMessageListener on active session may leads to deadlock

2014-12-01 Thread Jeremy Leung (JIRA)


 [ 
https://issues.apache.org/jira/browse/AMQCPP-556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Leung updated AMQCPP-556:

Summary: setMessageListener on active session may leads to deadlock  (was: 
Stop ActiveMQSessionKernel should also stop the ActiveMQConsumerKernel)

> setMessageListener on active session may leads to deadlock
> --
>
> Key: AMQCPP-556
> URL: https://issues.apache.org/jira/browse/AMQCPP-556
> Project: ActiveMQ C++ Client
>  Issue Type: Bug
>  Components: CMS Impl
>Affects Versions: 3.8.3
>Reporter: Jeremy Leung
>Assignee: Timothy Bish
> Attachments: AMQCPP-556.patch
>
>
> When we create a new *MessageConsumer* with a *MessageListener* from a 
> session, the session will be stopped before the updates of the message 
> listener and restarted afterward if the session already started.
> However, if there have more than one consumers already started; calling 
> *ActiveMQSessionKernel::stop()* may goes into a deadlock if there have many 
> messages coming in.
> {panel:title=Stack Trace when the sample program run into deadlock}
> 26989:  ./SimpleAsyncConsumer
> -  lwp# 1 / thread# 1  
> {color:red} fdb29379 lwp_park (0, 0, 0)
>  fdb23b6b cond_wait_queue (8078ef0, 808bc28, 0) + 5e
>  fdb2403f _cond_wait (8078ef0, 808bc28) + 64
>  fdb24081 cond_wait (8078ef0, 808bc28) + 21
>  fdb240ba pthread_cond_wait (8078ef0, 808bc28) + 1b
>  fe7217b6 void 
> decaf::internal::util::concurrent::PlatformThread::interruptibleWaitOnCondition(_pthread_cond*,_pthread_mutex*,decaf::internal::util::concurrent::CompletionCondition&)
>  (8078ef0, 808bc28, 8046e14) + 36
>  fe71f400 bool 
> decaf::internal::util::concurrent::Threading::join(decaf::internal::util::concurrent::ThreadHandle*,long
>  long,int) (808f8d0, 0, 0, 0, fe758acd) + 160
>  fe758aeb void decaf::lang::Thread::join() (808ea18) + 2b
>  fe56b727 void activemq::threads::DedicatedTaskRunner::shutdown() (808f788) + 
> f7
>  fe3f417a void activemq::core::ActiveMQSessionExecutor::stop() (808cb30) + 2da
>  fe48af48 void activemq::core::kernels::ActiveMQSessionKernel::stop() 
> (808c240) + 18
>  fe44362a void 
> activemq::core::kernels::ActiveMQConsumerKernel::setMessageListener(cms::MessageListener*)
>  (80917d8, 8047384) + f2
>  fe3aa8c3 void 
> activemq::core::ActiveMQConsumer::setMessageListener(cms::MessageListener*) 
> (808f4e8, 8047384) + 73{color}
>  08055170 void SimpleAsyncConsumer::runConsumer() (8047380) + 610
>  080530d3 main (1, 80474b8, 80474c0) + 2a3
>  08052d5a _start   (1, 8047618, 0, 804762e, 804763a, 8047674) + 7a
> -  lwp# 10 / thread# 10  
> {color:red} fdb29379 lwp_park (0, 0, 0)
>  fdb23b6b cond_wait_queue (808f188, 808bc48, 0) + 5e
>  fdb2403f _cond_wait (808f188, 808bc48) + 64
>  fdb24081 cond_wait (808f188, 808bc48) + 21
>  fdb240ba pthread_cond_wait (808f188, 808bc48) + 1b
>  fe721666 void 
> decaf::internal::util::concurrent::PlatformThread::waitOnCondition(_pthread_cond*,_pthread_mutex*)
>  (808f188, 808bc48) + 1e
>  fe71dab3 void 
> __unnamed_syh4PZ6vdUWCx::doMonitorEnter(decaf::internal::util::concurrent::MonitorHandle*,decaf::internal::util::concurrent::ThreadHandle*)
>  (806c740, 808f8d0) + 8f
>  fe71fd0b void 
> decaf::internal::util::concurrent::Threading::enterMonitor(decaf::internal::util::concurrent::MonitorHandle*)
>  (806c740) + 27
>  fe7aaa78 void decaf::util::concurrent::Mutex::lock() (808ec34) + 4c
>  fe7aa2d4 void decaf::util::concurrent::Lock::lock() (fd71fb84) + 2c
>  fe7aa023 decaf::util::concurrent::Lock::Lock #Nvariant 
> 1(decaf::util::concurrent::Synchronizable*,const bool) (fd71fb84, 808ec34, 1) 
> + 43
>  fe44b7a4 void 
> activemq::core::kernels::ActiveMQConsumerKernel::dispatch(const 
> decaf::lang::Pointer&)
>  (808ebb8, fd71feb0) + 49c
>  fe3f4371 void activemq::core::ActiveMQSessionExecutor::dispatch(const 
> decaf::lang::Pointer&)
>  (808cb30, fd71feb0) + 11d
>  fe3f45be bool activemq::core::ActiveMQSessionExecutor::iterate() (808cb30) + 
> a2
>  fe56b88a void activemq::threads::DedicatedTaskRunner::run() (808f788) + 
> 8e{color}
>  fe75889e void decaf::lang::Thread::run() (808ea18) + 1a
>  fe71cfbb void __unnamed_syh4PZ6vdUWCx::runCallback(void*) (808f8d0) + 2b
>  fe71cf52 void*__unnamed_syh4PZ6vdUWCx::threadEntryMethod(void*) (808f8d0) + 
> ee
>  fdb28ffb _thr_setup (fd814200) + 4e
>  fdb29300 _lwp_start (fd814200, 0, 0, fd71fff8, fdb29300, fd814200)
> -  lwp# 11 / thread# 11  
> {color:red} fdb29379 lwp_park (0, 0, 0)
>  fdb23b6b cond_wait_queue (808f5d8, 808bbc8, 0) + 5e
>  fdb2403f _cond_wait (808f5d8, 808bbc8) + 64
>  fdb24081 cond_wait (808f5d8, 808bbc8) + 21
>  fdb240ba pthread_cond_wait (808f5d8, 808bbc8) + 1b
>  fe721666 void 
> decaf::internal::util::concurren

[jira] [Updated] (AMQCPP-556) Stop ActiveMQSessionKernel should also stop the ActiveMQConsumerKernel

2014-12-01 Thread Jeremy Leung (JIRA)


 [ 
https://issues.apache.org/jira/browse/AMQCPP-556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Leung updated AMQCPP-556:

Attachment: (was: AMQCPP-556.patch)

> Stop ActiveMQSessionKernel should also stop the ActiveMQConsumerKernel
> --
>
> Key: AMQCPP-556
> URL: https://issues.apache.org/jira/browse/AMQCPP-556
> Project: ActiveMQ C++ Client
>  Issue Type: Bug
>  Components: CMS Impl
>Affects Versions: 3.8.3
>Reporter: Jeremy Leung
>Assignee: Timothy Bish
> Attachments: AMQCPP-556.patch
>
>
> When we create a new *MessageConsumer* with a *MessageListener* from a 
> session, the session will be stopped before the updates of the message 
> listener and restarted afterward if the session already started.
> However, if there have more than one consumers already started; calling 
> *ActiveMQSessionKernel::stop()* may goes into a deadlock if there have many 
> messages coming in.
> {panel:title=Stack Trace when the sample program run into deadlock}
> 26989:  ./SimpleAsyncConsumer
> -  lwp# 1 / thread# 1  
> {color:red} fdb29379 lwp_park (0, 0, 0)
>  fdb23b6b cond_wait_queue (8078ef0, 808bc28, 0) + 5e
>  fdb2403f _cond_wait (8078ef0, 808bc28) + 64
>  fdb24081 cond_wait (8078ef0, 808bc28) + 21
>  fdb240ba pthread_cond_wait (8078ef0, 808bc28) + 1b
>  fe7217b6 void 
> decaf::internal::util::concurrent::PlatformThread::interruptibleWaitOnCondition(_pthread_cond*,_pthread_mutex*,decaf::internal::util::concurrent::CompletionCondition&)
>  (8078ef0, 808bc28, 8046e14) + 36
>  fe71f400 bool 
> decaf::internal::util::concurrent::Threading::join(decaf::internal::util::concurrent::ThreadHandle*,long
>  long,int) (808f8d0, 0, 0, 0, fe758acd) + 160
>  fe758aeb void decaf::lang::Thread::join() (808ea18) + 2b
>  fe56b727 void activemq::threads::DedicatedTaskRunner::shutdown() (808f788) + 
> f7
>  fe3f417a void activemq::core::ActiveMQSessionExecutor::stop() (808cb30) + 2da
>  fe48af48 void activemq::core::kernels::ActiveMQSessionKernel::stop() 
> (808c240) + 18
>  fe44362a void 
> activemq::core::kernels::ActiveMQConsumerKernel::setMessageListener(cms::MessageListener*)
>  (80917d8, 8047384) + f2
>  fe3aa8c3 void 
> activemq::core::ActiveMQConsumer::setMessageListener(cms::MessageListener*) 
> (808f4e8, 8047384) + 73{color}
>  08055170 void SimpleAsyncConsumer::runConsumer() (8047380) + 610
>  080530d3 main (1, 80474b8, 80474c0) + 2a3
>  08052d5a _start   (1, 8047618, 0, 804762e, 804763a, 8047674) + 7a
> -  lwp# 10 / thread# 10  
> {color:red} fdb29379 lwp_park (0, 0, 0)
>  fdb23b6b cond_wait_queue (808f188, 808bc48, 0) + 5e
>  fdb2403f _cond_wait (808f188, 808bc48) + 64
>  fdb24081 cond_wait (808f188, 808bc48) + 21
>  fdb240ba pthread_cond_wait (808f188, 808bc48) + 1b
>  fe721666 void 
> decaf::internal::util::concurrent::PlatformThread::waitOnCondition(_pthread_cond*,_pthread_mutex*)
>  (808f188, 808bc48) + 1e
>  fe71dab3 void 
> __unnamed_syh4PZ6vdUWCx::doMonitorEnter(decaf::internal::util::concurrent::MonitorHandle*,decaf::internal::util::concurrent::ThreadHandle*)
>  (806c740, 808f8d0) + 8f
>  fe71fd0b void 
> decaf::internal::util::concurrent::Threading::enterMonitor(decaf::internal::util::concurrent::MonitorHandle*)
>  (806c740) + 27
>  fe7aaa78 void decaf::util::concurrent::Mutex::lock() (808ec34) + 4c
>  fe7aa2d4 void decaf::util::concurrent::Lock::lock() (fd71fb84) + 2c
>  fe7aa023 decaf::util::concurrent::Lock::Lock #Nvariant 
> 1(decaf::util::concurrent::Synchronizable*,const bool) (fd71fb84, 808ec34, 1) 
> + 43
>  fe44b7a4 void 
> activemq::core::kernels::ActiveMQConsumerKernel::dispatch(const 
> decaf::lang::Pointer&)
>  (808ebb8, fd71feb0) + 49c
>  fe3f4371 void activemq::core::ActiveMQSessionExecutor::dispatch(const 
> decaf::lang::Pointer&)
>  (808cb30, fd71feb0) + 11d
>  fe3f45be bool activemq::core::ActiveMQSessionExecutor::iterate() (808cb30) + 
> a2
>  fe56b88a void activemq::threads::DedicatedTaskRunner::run() (808f788) + 
> 8e{color}
>  fe75889e void decaf::lang::Thread::run() (808ea18) + 1a
>  fe71cfbb void __unnamed_syh4PZ6vdUWCx::runCallback(void*) (808f8d0) + 2b
>  fe71cf52 void*__unnamed_syh4PZ6vdUWCx::threadEntryMethod(void*) (808f8d0) + 
> ee
>  fdb28ffb _thr_setup (fd814200) + 4e
>  fdb29300 _lwp_start (fd814200, 0, 0, fd71fff8, fdb29300, fd814200)
> -  lwp# 11 / thread# 11  
> {color:red} fdb29379 lwp_park (0, 0, 0)
>  fdb23b6b cond_wait_queue (808f5d8, 808bbc8, 0) + 5e
>  fdb2403f _cond_wait (808f5d8, 808bbc8) + 64
>  fdb24081 cond_wait (808f5d8, 808bbc8) + 21
>  fdb240ba pthread_cond_wait (808f5d8, 808bbc8) + 1b
>  fe721666 void 
> decaf::internal::util::concurrent::PlatformThread::waitOnCondition(_pthread_cond*,_pthread_mutex*)
>  (808f5d8, 808b

[jira] [Updated] (AMQCPP-556) Stop ActiveMQSessionKernel should also stop the ActiveMQConsumerKernel

2014-12-01 Thread Jeremy Leung (JIRA)


 [ 
https://issues.apache.org/jira/browse/AMQCPP-556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Leung updated AMQCPP-556:

Attachment: AMQCPP-556.patch

> Stop ActiveMQSessionKernel should also stop the ActiveMQConsumerKernel
> --
>
> Key: AMQCPP-556
> URL: https://issues.apache.org/jira/browse/AMQCPP-556
> Project: ActiveMQ C++ Client
>  Issue Type: Bug
>  Components: CMS Impl
>Affects Versions: 3.8.3
>Reporter: Jeremy Leung
>Assignee: Timothy Bish
> Attachments: AMQCPP-556.patch
>
>
> When we create a new *MessageConsumer* with a *MessageListener* from a 
> session, the session will be stopped before the updates of the message 
> listener and restarted afterward if the session already started.
> However, if there have more than one consumers already started; calling 
> *ActiveMQSessionKernel::stop()* may goes into a deadlock if there have many 
> messages coming in.
> {panel:title=Stack Trace when the sample program run into deadlock}
> 26989:  ./SimpleAsyncConsumer
> -  lwp# 1 / thread# 1  
> {color:red} fdb29379 lwp_park (0, 0, 0)
>  fdb23b6b cond_wait_queue (8078ef0, 808bc28, 0) + 5e
>  fdb2403f _cond_wait (8078ef0, 808bc28) + 64
>  fdb24081 cond_wait (8078ef0, 808bc28) + 21
>  fdb240ba pthread_cond_wait (8078ef0, 808bc28) + 1b
>  fe7217b6 void 
> decaf::internal::util::concurrent::PlatformThread::interruptibleWaitOnCondition(_pthread_cond*,_pthread_mutex*,decaf::internal::util::concurrent::CompletionCondition&)
>  (8078ef0, 808bc28, 8046e14) + 36
>  fe71f400 bool 
> decaf::internal::util::concurrent::Threading::join(decaf::internal::util::concurrent::ThreadHandle*,long
>  long,int) (808f8d0, 0, 0, 0, fe758acd) + 160
>  fe758aeb void decaf::lang::Thread::join() (808ea18) + 2b
>  fe56b727 void activemq::threads::DedicatedTaskRunner::shutdown() (808f788) + 
> f7
>  fe3f417a void activemq::core::ActiveMQSessionExecutor::stop() (808cb30) + 2da
>  fe48af48 void activemq::core::kernels::ActiveMQSessionKernel::stop() 
> (808c240) + 18
>  fe44362a void 
> activemq::core::kernels::ActiveMQConsumerKernel::setMessageListener(cms::MessageListener*)
>  (80917d8, 8047384) + f2
>  fe3aa8c3 void 
> activemq::core::ActiveMQConsumer::setMessageListener(cms::MessageListener*) 
> (808f4e8, 8047384) + 73{color}
>  08055170 void SimpleAsyncConsumer::runConsumer() (8047380) + 610
>  080530d3 main (1, 80474b8, 80474c0) + 2a3
>  08052d5a _start   (1, 8047618, 0, 804762e, 804763a, 8047674) + 7a
> -  lwp# 10 / thread# 10  
> {color:red} fdb29379 lwp_park (0, 0, 0)
>  fdb23b6b cond_wait_queue (808f188, 808bc48, 0) + 5e
>  fdb2403f _cond_wait (808f188, 808bc48) + 64
>  fdb24081 cond_wait (808f188, 808bc48) + 21
>  fdb240ba pthread_cond_wait (808f188, 808bc48) + 1b
>  fe721666 void 
> decaf::internal::util::concurrent::PlatformThread::waitOnCondition(_pthread_cond*,_pthread_mutex*)
>  (808f188, 808bc48) + 1e
>  fe71dab3 void 
> __unnamed_syh4PZ6vdUWCx::doMonitorEnter(decaf::internal::util::concurrent::MonitorHandle*,decaf::internal::util::concurrent::ThreadHandle*)
>  (806c740, 808f8d0) + 8f
>  fe71fd0b void 
> decaf::internal::util::concurrent::Threading::enterMonitor(decaf::internal::util::concurrent::MonitorHandle*)
>  (806c740) + 27
>  fe7aaa78 void decaf::util::concurrent::Mutex::lock() (808ec34) + 4c
>  fe7aa2d4 void decaf::util::concurrent::Lock::lock() (fd71fb84) + 2c
>  fe7aa023 decaf::util::concurrent::Lock::Lock #Nvariant 
> 1(decaf::util::concurrent::Synchronizable*,const bool) (fd71fb84, 808ec34, 1) 
> + 43
>  fe44b7a4 void 
> activemq::core::kernels::ActiveMQConsumerKernel::dispatch(const 
> decaf::lang::Pointer&)
>  (808ebb8, fd71feb0) + 49c
>  fe3f4371 void activemq::core::ActiveMQSessionExecutor::dispatch(const 
> decaf::lang::Pointer&)
>  (808cb30, fd71feb0) + 11d
>  fe3f45be bool activemq::core::ActiveMQSessionExecutor::iterate() (808cb30) + 
> a2
>  fe56b88a void activemq::threads::DedicatedTaskRunner::run() (808f788) + 
> 8e{color}
>  fe75889e void decaf::lang::Thread::run() (808ea18) + 1a
>  fe71cfbb void __unnamed_syh4PZ6vdUWCx::runCallback(void*) (808f8d0) + 2b
>  fe71cf52 void*__unnamed_syh4PZ6vdUWCx::threadEntryMethod(void*) (808f8d0) + 
> ee
>  fdb28ffb _thr_setup (fd814200) + 4e
>  fdb29300 _lwp_start (fd814200, 0, 0, fd71fff8, fdb29300, fd814200)
> -  lwp# 11 / thread# 11  
> {color:red} fdb29379 lwp_park (0, 0, 0)
>  fdb23b6b cond_wait_queue (808f5d8, 808bbc8, 0) + 5e
>  fdb2403f _cond_wait (808f5d8, 808bbc8) + 64
>  fdb24081 cond_wait (808f5d8, 808bbc8) + 21
>  fdb240ba pthread_cond_wait (808f5d8, 808bbc8) + 1b
>  fe721666 void 
> decaf::internal::util::concurrent::PlatformThread::waitOnCondition(_pthread_cond*,_pthread_mutex*)
>  (808f5d8, 808bbc8) + 1e
>

[jira] [Updated] (AMQCPP-556) Stop ActiveMQSessionKernel should also stop the ActiveMQConsumerKernel

2014-11-30 Thread Jeremy Leung (JIRA)


 [ 
https://issues.apache.org/jira/browse/AMQCPP-556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Leung updated AMQCPP-556:

Description: 
When we create a new *MessageConsumer* with a *MessageListener* from a session, 
the session will be stopped before the updates of the message listener and 
restarted afterward if the session already started.
However, if there have more than one consumers already started; calling 
*ActiveMQSessionKernel::stop()* may goes into a deadlock if there have many 
messages coming in.

{panel:title=Stack Trace when the sample program run into deadlock}
26989:  ./SimpleAsyncConsumer
-  lwp# 1 / thread# 1  
{color:red} fdb29379 lwp_park (0, 0, 0)
 fdb23b6b cond_wait_queue (8078ef0, 808bc28, 0) + 5e
 fdb2403f _cond_wait (8078ef0, 808bc28) + 64
 fdb24081 cond_wait (8078ef0, 808bc28) + 21
 fdb240ba pthread_cond_wait (8078ef0, 808bc28) + 1b
 fe7217b6 void 
decaf::internal::util::concurrent::PlatformThread::interruptibleWaitOnCondition(_pthread_cond*,_pthread_mutex*,decaf::internal::util::concurrent::CompletionCondition&)
 (8078ef0, 808bc28, 8046e14) + 36
 fe71f400 bool 
decaf::internal::util::concurrent::Threading::join(decaf::internal::util::concurrent::ThreadHandle*,long
 long,int) (808f8d0, 0, 0, 0, fe758acd) + 160
 fe758aeb void decaf::lang::Thread::join() (808ea18) + 2b
 fe56b727 void activemq::threads::DedicatedTaskRunner::shutdown() (808f788) + f7
 fe3f417a void activemq::core::ActiveMQSessionExecutor::stop() (808cb30) + 2da
 fe48af48 void activemq::core::kernels::ActiveMQSessionKernel::stop() (808c240) 
+ 18
 fe44362a void 
activemq::core::kernels::ActiveMQConsumerKernel::setMessageListener(cms::MessageListener*)
 (80917d8, 8047384) + f2
 fe3aa8c3 void 
activemq::core::ActiveMQConsumer::setMessageListener(cms::MessageListener*) 
(808f4e8, 8047384) + 73{color}
 08055170 void SimpleAsyncConsumer::runConsumer() (8047380) + 610
 080530d3 main (1, 80474b8, 80474c0) + 2a3
 08052d5a _start   (1, 8047618, 0, 804762e, 804763a, 8047674) + 7a
-  lwp# 10 / thread# 10  
{color:red} fdb29379 lwp_park (0, 0, 0)
 fdb23b6b cond_wait_queue (808f188, 808bc48, 0) + 5e
 fdb2403f _cond_wait (808f188, 808bc48) + 64
 fdb24081 cond_wait (808f188, 808bc48) + 21
 fdb240ba pthread_cond_wait (808f188, 808bc48) + 1b
 fe721666 void 
decaf::internal::util::concurrent::PlatformThread::waitOnCondition(_pthread_cond*,_pthread_mutex*)
 (808f188, 808bc48) + 1e
 fe71dab3 void 
__unnamed_syh4PZ6vdUWCx::doMonitorEnter(decaf::internal::util::concurrent::MonitorHandle*,decaf::internal::util::concurrent::ThreadHandle*)
 (806c740, 808f8d0) + 8f
 fe71fd0b void 
decaf::internal::util::concurrent::Threading::enterMonitor(decaf::internal::util::concurrent::MonitorHandle*)
 (806c740) + 27
 fe7aaa78 void decaf::util::concurrent::Mutex::lock() (808ec34) + 4c
 fe7aa2d4 void decaf::util::concurrent::Lock::lock() (fd71fb84) + 2c
 fe7aa023 decaf::util::concurrent::Lock::Lock #Nvariant 
1(decaf::util::concurrent::Synchronizable*,const bool) (fd71fb84, 808ec34, 1) + 
43
 fe44b7a4 void activemq::core::kernels::ActiveMQConsumerKernel::dispatch(const 
decaf::lang::Pointer&)
 (808ebb8, fd71feb0) + 49c
 fe3f4371 void activemq::core::ActiveMQSessionExecutor::dispatch(const 
decaf::lang::Pointer&)
 (808cb30, fd71feb0) + 11d
 fe3f45be bool activemq::core::ActiveMQSessionExecutor::iterate() (808cb30) + a2
 fe56b88a void activemq::threads::DedicatedTaskRunner::run() (808f788) + 
8e{color}
 fe75889e void decaf::lang::Thread::run() (808ea18) + 1a
 fe71cfbb void __unnamed_syh4PZ6vdUWCx::runCallback(void*) (808f8d0) + 2b
 fe71cf52 void*__unnamed_syh4PZ6vdUWCx::threadEntryMethod(void*) (808f8d0) + ee
 fdb28ffb _thr_setup (fd814200) + 4e
 fdb29300 _lwp_start (fd814200, 0, 0, fd71fff8, fdb29300, fd814200)
-  lwp# 11 / thread# 11  
{color:red} fdb29379 lwp_park (0, 0, 0)
 fdb23b6b cond_wait_queue (808f5d8, 808bbc8, 0) + 5e
 fdb2403f _cond_wait (808f5d8, 808bbc8) + 64
 fdb24081 cond_wait (808f5d8, 808bbc8) + 21
 fdb240ba pthread_cond_wait (808f5d8, 808bbc8) + 1b
 fe721666 void 
decaf::internal::util::concurrent::PlatformThread::waitOnCondition(_pthread_cond*,_pthread_mutex*)
 (808f5d8, 808bbc8) + 1e
 fe71dab3 void 
__unnamed_syh4PZ6vdUWCx::doMonitorEnter(decaf::internal::util::concurrent::MonitorHandle*,decaf::internal::util::concurrent::ThreadHandle*)
 (806c7a0, 8093c18) + 8f
 fe71fd0b void 
decaf::internal::util::concurrent::Threading::enterMonitor(decaf::internal::util::concurrent::MonitorHandle*)
 (806c7a0) + 27
 fe7aaa78 void decaf::util::concurrent::Mutex::lock() (80798b0) + 4c
 fe7aa2d4 void decaf::util::concurrent::Lock::lock() (fd73fda4) + 2c
 fe7aa023 decaf::util::concurrent::Lock::Lock #Nvariant 
1(decaf::util::concurrent::Synchronizable*,const bool) (fd73fda4, 80798b0, 1) + 
43
 fe434d3d 
decaf::lang::Pointeractivemq::core::SimplePriorityMessageDispatchChann

[jira] [Updated] (AMQCPP-556) Stop ActiveMQSessionKernel should also stop the ActiveMQConsumerKernel

2014-11-30 Thread Jeremy Leung (JIRA)


 [ 
https://issues.apache.org/jira/browse/AMQCPP-556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Leung updated AMQCPP-556:

Description: 
When we create a new *MessageConsumer* with a *MessageListener* from a session, 
the session will be stopped before the updates of the message listener and 
restarted afterward if the session already started.
However, if there have more than one consumers already started; calling 
*ActiveMQSessionKernel::stop()* may goes into a deadlock if there have many 
messages coming in.

> Stop ActiveMQSessionKernel should also stop the ActiveMQConsumerKernel
> --
>
> Key: AMQCPP-556
> URL: https://issues.apache.org/jira/browse/AMQCPP-556
> Project: ActiveMQ C++ Client
>  Issue Type: Bug
>  Components: CMS Impl
>Affects Versions: 3.8.3
>Reporter: Jeremy Leung
>Assignee: Timothy Bish
> Attachments: AMQCPP-556.patch
>
>
> When we create a new *MessageConsumer* with a *MessageListener* from a 
> session, the session will be stopped before the updates of the message 
> listener and restarted afterward if the session already started.
> However, if there have more than one consumers already started; calling 
> *ActiveMQSessionKernel::stop()* may goes into a deadlock if there have many 
> messages coming in.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (AMQCPP-556) Stop ActiveMQSessionKernel should also stop the ActiveMQConsumerKernel

2014-11-30 Thread Jeremy Leung (JIRA)


 [ 
https://issues.apache.org/jira/browse/AMQCPP-556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Leung updated AMQCPP-556:

Attachment: AMQCPP-556.patch

> Stop ActiveMQSessionKernel should also stop the ActiveMQConsumerKernel
> --
>
> Key: AMQCPP-556
> URL: https://issues.apache.org/jira/browse/AMQCPP-556
> Project: ActiveMQ C++ Client
>  Issue Type: Bug
>  Components: CMS Impl
>Affects Versions: 3.8.3
>Reporter: Jeremy Leung
>Assignee: Timothy Bish
> Attachments: AMQCPP-556.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (AMQCPP-556) Stop ActiveMQSessionKernel should also stop the ActiveMQConsumerKernel

2014-11-30 Thread Jeremy Leung (JIRA)

Jeremy Leung created AMQCPP-556:
---

 Summary: Stop ActiveMQSessionKernel should also stop the 
ActiveMQConsumerKernel
 Key: AMQCPP-556
 URL: https://issues.apache.org/jira/browse/AMQCPP-556
 Project: ActiveMQ C++ Client
  Issue Type: Bug
  Components: CMS Impl
Affects Versions: 3.8.3
Reporter: Jeremy Leung
Assignee: Timothy Bish






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (AMQCPP-548) Too many temporary std::string in Mutex and decaf::lang::Integer::toString(int)

2014-08-06 Thread Jeremy Leung (JIRA)


 [ 
https://issues.apache.org/jira/browse/AMQCPP-548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Leung updated AMQCPP-548:


Attachment: AMQCPP-548-1.patch

I think we no longer need the variable length as the vector buffer already 
contains such information.

> Too many  temporary std::string in Mutex and 
> decaf::lang::Integer::toString(int)
> 
>
> Key: AMQCPP-548
> URL: https://issues.apache.org/jira/browse/AMQCPP-548
> Project: ActiveMQ C++ Client
>  Issue Type: Improvement
>  Components: Decaf
>Affects Versions: 3.8.2
>Reporter: Jeremy Leung
>Assignee: Timothy Bish
> Fix For: 3.8.4, 3.9.0
>
> Attachments: AMQCPP-548-1.patch, AMQCPP-548.patch
>
>
> Every Mutex will associated with a MutexProperties and the name of the Mutex 
> is actually generated by the DEFAULT_NAME_PREFIX plus a call to 
> Integer::toString( ++id ).
> From the profiling of our application (highly multi-threaded), we found that 
> many times are spent in the std::basic_string allocation and deallocation 
> inside the functions decaf::lang::Integer::toString(int) and 
> decaf::lang::Integer::toString(int, int).



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (AMQCPP-548) Too many temporary std::string in Mutex and decaf::lang::Integer::toString(int)

2014-08-05 Thread Jeremy Leung (JIRA)


[ 
https://issues.apache.org/jira/browse/AMQCPP-548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14086029#comment-14086029
 ] 

Jeremy Leung commented on AMQCPP-548:
-

The chagnes for RVO is mainly in favor to SunStudio 11 compiler which doesn't 
support NRVO

> Too many  temporary std::string in Mutex and 
> decaf::lang::Integer::toString(int)
> 
>
> Key: AMQCPP-548
> URL: https://issues.apache.org/jira/browse/AMQCPP-548
> Project: ActiveMQ C++ Client
>  Issue Type: Improvement
>  Components: Decaf
>Affects Versions: 3.8.2
>Reporter: Jeremy Leung
>Assignee: Timothy Bish
> Attachments: AMQCPP-548.patch
>
>
> Every Mutex will associated with a MutexProperties and the name of the Mutex 
> is actually generated by the DEFAULT_NAME_PREFIX plus a call to 
> Integer::toString( ++id ).
> From the profiling of our application (highly multi-threaded), we found that 
> many times are spent in the std::basic_string allocation and deallocation 
> inside the functions decaf::lang::Integer::toString(int) and 
> decaf::lang::Integer::toString(int, int).



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (AMQCPP-548) Too many temporary std::string in Mutex and decaf::lang::Integer::toString(int)

2014-08-05 Thread Jeremy Leung (JIRA)


 [ 
https://issues.apache.org/jira/browse/AMQCPP-548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Leung updated AMQCPP-548:


Summary: Too many  temporary std::string in Mutex and 
decaf::lang::Integer::toString(int)  (was: Too many std::string copy in 
decaf::lang::Integer::toString(int))

> Too many  temporary std::string in Mutex and 
> decaf::lang::Integer::toString(int)
> 
>
> Key: AMQCPP-548
> URL: https://issues.apache.org/jira/browse/AMQCPP-548
> Project: ActiveMQ C++ Client
>  Issue Type: Improvement
>  Components: Decaf
>Affects Versions: 3.8.2
>Reporter: Jeremy Leung
>Assignee: Timothy Bish
> Attachments: AMQCPP-548.patch
>
>
> Every Mutex will associated with a MutexProperties and the name of the Mutex 
> is actually generated by the DEFAULT_NAME_PREFIX plus a call to 
> Integer::toString( ++id ).
> From the profiling of our application (highly multi-threaded), we found that 
> many times are spent in the std::basic_string allocation and deallocation 
> inside the functions decaf::lang::Integer::toString(int) and 
> decaf::lang::Integer::toString(int, int).



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (AMQCPP-548) Too many std::string copy in decaf::lang::Integer::toString(int)

2014-08-05 Thread Jeremy Leung (JIRA)


 [ 
https://issues.apache.org/jira/browse/AMQCPP-548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Leung updated AMQCPP-548:


Patch Info: Patch Available

> Too many std::string copy in decaf::lang::Integer::toString(int)
> 
>
> Key: AMQCPP-548
> URL: https://issues.apache.org/jira/browse/AMQCPP-548
> Project: ActiveMQ C++ Client
>  Issue Type: Improvement
>  Components: Decaf
>Affects Versions: 3.8.2
>Reporter: Jeremy Leung
>Assignee: Timothy Bish
> Attachments: AMQCPP-548.patch
>
>
> Every Mutex will associated with a MutexProperties and the name of the Mutex 
> is actually generated by the DEFAULT_NAME_PREFIX plus a call to 
> Integer::toString( ++id ).
> From the profiling of our application (highly multi-threaded), we found that 
> many times are spent in the std::basic_string allocation and deallocation 
> inside the functions decaf::lang::Integer::toString(int) and 
> decaf::lang::Integer::toString(int, int).



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (AMQCPP-548) Too many std::string copy in decaf::lang::Integer::toString(int)

2014-08-05 Thread Jeremy Leung (JIRA)


 [ 
https://issues.apache.org/jira/browse/AMQCPP-548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Leung updated AMQCPP-548:


Attachment: AMQCPP-548.patch

> Too many std::string copy in decaf::lang::Integer::toString(int)
> 
>
> Key: AMQCPP-548
> URL: https://issues.apache.org/jira/browse/AMQCPP-548
> Project: ActiveMQ C++ Client
>  Issue Type: Improvement
>  Components: Decaf
>Affects Versions: 3.8.2
>Reporter: Jeremy Leung
>Assignee: Timothy Bish
> Attachments: AMQCPP-548.patch
>
>
> Every Mutex will associated with a MutexProperties and the name of the Mutex 
> is actually generated by the DEFAULT_NAME_PREFIX plus a call to 
> Integer::toString( ++id ).
> From the profiling of our application (highly multi-threaded), we found that 
> many times are spent in the std::basic_string allocation and deallocation 
> inside the functions decaf::lang::Integer::toString(int) and 
> decaf::lang::Integer::toString(int, int).



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (AMQCPP-548) Too many std::string copy in decaf::lang::Integer::toString(int)

2014-07-17 Thread Jeremy Leung (JIRA)

Jeremy Leung created AMQCPP-548:
---

 Summary: Too many std::string copy in 
decaf::lang::Integer::toString(int)
 Key: AMQCPP-548
 URL: https://issues.apache.org/jira/browse/AMQCPP-548
 Project: ActiveMQ C++ Client
  Issue Type: Improvement
  Components: Decaf
Affects Versions: 3.8.2
Reporter: Jeremy Leung
Assignee: Timothy Bish


Every Mutex will associated with a MutexProperties and the name of the Mutex is 
actually generated by the DEFAULT_NAME_PREFIX plus a call to Integer::toString( 
++id ).

>From the profiling of our application (highly multi-threaded), we found that 
>many times are spent in the std::basic_string allocation and deallocation 
>inside the functions decaf::lang::Integer::toString(int) and 
>decaf::lang::Integer::toString(int, int).



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (AMQCPP-534) Closing connection with setTransportListener to NULL may cause core dump

2014-02-19 Thread Jeremy Leung (JIRA)


 [ 
https://issues.apache.org/jira/browse/AMQCPP-534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Leung updated AMQCPP-534:


Description: 
This happen in random; and will cause core dump under Solaris 10.

{panel:title=Core dump happened on thread #22 which is a thread for IO for 
activemq|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#CE}
{noformat}
t@22 (l@22) terminated by signal SEGV (no mapping at the fault address)
0xfcbef02c: onCommand+0x0370:   movl (%edi),%eax
(dbx) where -h
current thread: t@22
=>[1] 
activemq::transport::failover::FailoverTransportListener::onCommand(0x1c20d280, 
0xfa567ce0), at 0xfcbef02c
  [2] activemq::transport::TransportFilter::onCommand(0x116c3700, 0xfa567d20), 
at 0xfcb7ae15
  [3] 
activemq::wireformat::openwire::OpenWireFormatNegotiator::onCommand(0x116c3700, 
0xfa567d70), at 0xfcc5ff05
  [4] activemq::transport::TransportFilter::onCommand(0x10bdaaa0, 0xfa567de0), 
at 0xfcb7ae15
  [5] activemq::transport::inactivity::InactivityMonitor::onCommand(0x10bdaaa0, 
0xfa567e40), at 0xfcbf69f7
  [6] activemq::transport::TransportFilter::onCommand(0x1027cbc0, 0xfa567e90), 
at 0xfcb7ae15
  [7] activemq::transport::IOTransport::fire(0x1bbc4ab8, 0xfa567ef0), at 
0xfcb78a49
  [8] activemq::transport::IOTransport::run(0x1bbc4ab8), at 0xfcb79827
  [9] decaf::lang::Thread::run(0x1c2080a0), at 0xfcd58512
  [10] __unnamed_syh4P47F8S2uD::runCallback(0x1c21c138), at 0xfcd1cc2f
  [11] __unnamed_syh4P47F8S2uD::threadEntryMethod(0x1c21c138), at 0xfcd1cbc6
  [12] _thr_setup(0xfac2a200), at 0xfc0771c0
  [13] _lwp_start(), at 0xfc0774b0
{noformat}
{panel}

{panel:title=Stack trace for the main 
thread|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#CE}
{noformat}
-  lwp# 1 / thread# 1  
 fc07750b __lwp_park (163995d8, 1bbc1e10, 8046358) + b
 fc071d07 cond_wait_queue (163995d8, 1bbc1e10, 8046358) + 5e
 fc072084 cond_wait_common (163995d8, 1bbc1e10, 8046358) + 1db
 fc0722b6 _cond_timedwait (163995d8, 1bbc1e10, 80463c8) + 51
 fc072321 cond_timedwait (163995d8, 1bbc1e10, 80463c8) + 24
 fc07235d pthread_cond_timedwait (163995d8, 1bbc1e10, 80463c8) + 1e
 fcd21550 bool 
decaf::internal::util::concurrent::PlatformThread::interruptibleWaitOnCondition(_pthread_cond*,_pthread_mutex*,long
 long,int,decaf::internal::util::concurrent::CompletionCondition&) (163995d8, 
1bbc1e10, 493e0, 0, 0, 8046434) + 110
 fcd1f051 bool 
decaf::internal::util::concurrent::Threading::join(decaf::internal::util::concurrent::ThreadHandle*,long
 long,int) (1bbe5660, 493e0, 0, 0, fcd5877a) + 13d
 fcd587a0 void decaf::lang::Thread::join(long long) (1c20d270, 493e0, 0) + 38
 fcb61945 void activemq::threads::CompositeTaskRunner::shutdown(long long) 
(f3b1730, 493e0, 0) + e5
 fcbd26d3 void activemq::transport::failover::FailoverTransport::close() 
(efde3f8) + 327
 fcb7b799 void activemq::transport::TransportFilter::close() (118b49e0) + 191
 fc940003 void activemq::core::ActiveMQConnection::disconnect(long long) 
(eef0fb8, 0, 0) + 52f
 fc93c3f3 void activemq::core::ActiveMQConnection::close() (eef0fb8) + b47
 0888e6ec main (7, 80475dc, 80475fc) + 149
 0888dd6a _start   (7, 9e7dafc, 804775d, 8047760, 8047769, 804777f) + 7a
{noformat}
{panel}

This is happen only during the disconnect. So, what i suspected is that there 
have an concurrent issue between the ActiveMQConnection, TransportFilter, 
FailoverTransportListener.

As i dig into the code, i see during the disconnection, the transport listener 
will being set to NULL at the very first stage. However, the another thread may 
have access to the pointer of the null transport listener as the NULL check is 
not thread safe.

{noformat}
void ActiveMQConnection::disconnect(long long lastDeliveredSequenceId) {

try {

// Clear the listener, we don't care about async errors at this point.
this->config->transport->setTransportListener(NULL);

[...]
{noformat}

{noformat}
void FailoverTransportListener::onCommand(const Pointer command) {

if (command == NULL) {
return;
}

if (command->isResponse()) {
Pointer response = command.dynamicCast();
parent->processResponse(response);
}

if (!parent->isInitialized()) {
parent->setInitialized(true);
}

if (command->isConnectionControl()) {
parent->handleConnectionControl(command);
}

if (parent->getTransportListener() != NULL) {
parent->getTransportListener()->onCommand(command);
}
}
{noformat}

{noformat}
void TransportFilter::onCommand(const Pointer command) {

if (!this->impl->started.get() || this->impl->closed.get()) {
return;
}

try {
if (this->listener != NULL) {
this->listener->onCommand(command);
}
} catch (...) {
}
}
{noformat}


  was:
This happen in random; and will cause core dump under Solaris 10.

{panel:title=

[jira] [Updated] (AMQCPP-534) Closing connection with setTransportListener to NULL may cause core dump

2014-02-19 Thread Jeremy Leung (JIRA)


 [ 
https://issues.apache.org/jira/browse/AMQCPP-534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Leung updated AMQCPP-534:


Description: 
This happen in random; and will cause core dump under Solaris 10.

{panel:title=Core dump happened on thread #22 which is a thread for IO for 
activemq|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#CE}
{noformat}
t@22 (l@22) terminated by signal SEGV (no mapping at the fault address)
0xfcbef02c: onCommand+0x0370:   movl (%edi),%eax
(dbx) where -h
current thread: t@22
=>[1] 
activemq::transport::failover::FailoverTransportListener::onCommand(0x1c20d280, 
0xfa567ce0), at 0xfcbef02c
  [2] activemq::transport::TransportFilter::onCommand(0x116c3700, 0xfa567d20), 
at 0xfcb7ae15
  [3] 
activemq::wireformat::openwire::OpenWireFormatNegotiator::onCommand(0x116c3700, 
0xfa567d70), at 0xfcc5ff05
  [4] activemq::transport::TransportFilter::onCommand(0x10bdaaa0, 0xfa567de0), 
at 0xfcb7ae15
  [5] activemq::transport::inactivity::InactivityMonitor::onCommand(0x10bdaaa0, 
0xfa567e40), at 0xfcbf69f7
  [6] activemq::transport::TransportFilter::onCommand(0x1027cbc0, 0xfa567e90), 
at 0xfcb7ae15
  [7] activemq::transport::IOTransport::fire(0x1bbc4ab8, 0xfa567ef0), at 
0xfcb78a49
  [8] activemq::transport::IOTransport::run(0x1bbc4ab8), at 0xfcb79827
  [9] decaf::lang::Thread::run(0x1c2080a0), at 0xfcd58512
  [10] __unnamed_syh4P47F8S2uD::runCallback(0x1c21c138), at 0xfcd1cc2f
  [11] __unnamed_syh4P47F8S2uD::threadEntryMethod(0x1c21c138), at 0xfcd1cbc6
  [12] _thr_setup(0xfac2a200), at 0xfc0771c0
  [13] _lwp_start(), at 0xfc0774b0
{noformat}
{panel}

{panel:title=Stack trace for the main 
thread|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#CE}
{noformat}
-  lwp# 1 / thread# 1  
 fc07750b __lwp_park (163995d8, 1bbc1e10, 8046358) + b
 fc071d07 cond_wait_queue (163995d8, 1bbc1e10, 8046358) + 5e
 fc072084 cond_wait_common (163995d8, 1bbc1e10, 8046358) + 1db
 fc0722b6 _cond_timedwait (163995d8, 1bbc1e10, 80463c8) + 51
 fc072321 cond_timedwait (163995d8, 1bbc1e10, 80463c8) + 24
 fc07235d pthread_cond_timedwait (163995d8, 1bbc1e10, 80463c8) + 1e
 fcd21550 bool 
decaf::internal::util::concurrent::PlatformThread::interruptibleWaitOnCondition(_pthread_cond*,_pthread_mutex*,long
 long,int,decaf::internal::util::concurrent::CompletionCondition&) (163995d8, 
1bbc1e10, 493e0, 0, 0, 8046434) + 110
 fcd1f051 bool 
decaf::internal::util::concurrent::Threading::join(decaf::internal::util::concurrent::ThreadHandle*,long
 long,int) (1bbe5660, 493e0, 0, 0, fcd5877a) + 13d
 fcd587a0 void decaf::lang::Thread::join(long long) (1c20d270, 493e0, 0) + 38
 fcb61945 void activemq::threads::CompositeTaskRunner::shutdown(long long) 
(f3b1730, 493e0, 0) + e5
 fcbd26d3 void activemq::transport::failover::FailoverTransport::close() 
(efde3f8) + 327
 fcb7b799 void activemq::transport::TransportFilter::close() (118b49e0) + 191
 fc940003 void activemq::core::ActiveMQConnection::disconnect(long long) 
(eef0fb8, 0, 0) + 52f
 fc93c3f3 void activemq::core::ActiveMQConnection::close() (eef0fb8) + b47
 0888e6ec main (7, 80475dc, 80475fc) + 149
 0888dd6a _start   (7, 9e7dafc, 804775d, 8047760, 8047769, 804777f) + 7a
{noformat}
{panel}

This is happen only during the disconnect. So, what i suspected is that there 
have an concurrent issue between the ActiveMQConnection and the TransportFilter.
As i dig into the code, i see during the disconnection, the transport listener 
will being set to NULL at the very first stage.

{noformat}
void ActiveMQConnection::disconnect(long long lastDeliveredSequenceId) {

try {

// Clear the listener, we don't care about async errors at this point.
this->config->transport->setTransportListener(NULL);

[...]
{noformat}



> Closing connection with setTransportListener to NULL may cause core dump
> 
>
> Key: AMQCPP-534
> URL: https://issues.apache.org/jira/browse/AMQCPP-534
> Project: ActiveMQ C++ Client
>  Issue Type: Bug
>  Components: Transports
>Affects Versions: 3.8.2
>Reporter: Jeremy Leung
>Assignee: Timothy Bish
>
> This happen in random; and will cause core dump under Solaris 10.
> {panel:title=Core dump happened on thread #22 which is a thread for IO for 
> activemq|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#CE}
> {noformat}
> t@22 (l@22) terminated by signal SEGV (no mapping at the fault address)
> 0xfcbef02c: onCommand+0x0370:   movl (%edi),%eax
> (dbx) where -h
> current thread: t@22
> =>[1] 
> activemq::transport::failover::FailoverTransportListener::onCommand(0x1c20d280,
>  0xfa567ce0), at 0xfcbef02c
>   [2] activemq::transport::TransportFilter::onCommand(0x116c3700, 
> 0xfa567d20), at 0xfcb7ae15
>   [3] 
> active

[jira] [Created] (AMQCPP-534) Closing connection with setTransportListener to NULL may cause core dump

2014-02-19 Thread Jeremy Leung (JIRA)

Jeremy Leung created AMQCPP-534:
---

 Summary: Closing connection with setTransportListener to NULL may 
cause core dump
 Key: AMQCPP-534
 URL: https://issues.apache.org/jira/browse/AMQCPP-534
 Project: ActiveMQ C++ Client
  Issue Type: Bug
  Components: Transports
Affects Versions: 3.8.2
Reporter: Jeremy Leung
Assignee: Timothy Bish






--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Updated] (AMQCPP-515) Stomp frame mishandled duplicate headers

2013-10-07 Thread Jeremy Leung (JIRA)


 [ 
https://issues.apache.org/jira/browse/AMQCPP-515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Leung updated AMQCPP-515:


Attachment: AMQCPP-515.patch

> Stomp frame mishandled duplicate headers
> 
>
> Key: AMQCPP-515
> URL: https://issues.apache.org/jira/browse/AMQCPP-515
> Project: ActiveMQ C++ Client
>  Issue Type: Bug
>  Components: Stomp
>Affects Versions: 3.8.0
>Reporter: Jeremy Leung
>Assignee: Timothy Bish
> Attachments: AMQCPP-515.patch
>
>
> http://stomp.github.io/stomp-specification-1.1.html#Repeated_Header_Entries



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (AMQCPP-515) Stomp frame mishandled duplicate headers

2013-10-07 Thread Jeremy Leung (JIRA)


 [ 
https://issues.apache.org/jira/browse/AMQCPP-515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Leung updated AMQCPP-515:


Patch Info: Patch Available

> Stomp frame mishandled duplicate headers
> 
>
> Key: AMQCPP-515
> URL: https://issues.apache.org/jira/browse/AMQCPP-515
> Project: ActiveMQ C++ Client
>  Issue Type: Bug
>  Components: Stomp
>Affects Versions: 3.8.0
>Reporter: Jeremy Leung
>Assignee: Timothy Bish
>
> http://stomp.github.io/stomp-specification-1.1.html#Repeated_Header_Entries



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (AMQCPP-515) Stomp frame mishandled duplicate headers

2013-10-07 Thread Jeremy Leung (JIRA)


 [ 
https://issues.apache.org/jira/browse/AMQCPP-515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Leung updated AMQCPP-515:


Description: 
http://stomp.github.io/stomp-specification-1.1.html#Repeated_Header_Entries

> Stomp frame mishandled duplicate headers
> 
>
> Key: AMQCPP-515
> URL: https://issues.apache.org/jira/browse/AMQCPP-515
> Project: ActiveMQ C++ Client
>  Issue Type: Bug
>  Components: Stomp
>Affects Versions: 3.8.0
>Reporter: Jeremy Leung
>Assignee: Timothy Bish
>
> http://stomp.github.io/stomp-specification-1.1.html#Repeated_Header_Entries



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Created] (AMQCPP-515) Stomp frame mishandled duplicate headers

2013-10-07 Thread Jeremy Leung (JIRA)

Jeremy Leung created AMQCPP-515:
---

 Summary: Stomp frame mishandled duplicate headers
 Key: AMQCPP-515
 URL: https://issues.apache.org/jira/browse/AMQCPP-515
 Project: ActiveMQ C++ Client
  Issue Type: Bug
  Components: Stomp
Affects Versions: 3.8.0
Reporter: Jeremy Leung
Assignee: Timothy Bish






--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (AMQCPP-489) Compilation Error Fix for Sun Studio under Solaris 10

2013-06-10 Thread Jeremy Leung (JIRA)


 [ 
https://issues.apache.org/jira/browse/AMQCPP-489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Leung updated AMQCPP-489:


Attachment: patch.AMQCPP-489.txt

> Compilation Error Fix for Sun Studio under Solaris 10
> -
>
> Key: AMQCPP-489
> URL: https://issues.apache.org/jira/browse/AMQCPP-489
> Project: ActiveMQ C++ Client
>  Issue Type: Bug
>  Components: Decaf, Example Code
>Affects Versions: 3.7.0
> Environment: Solaris 10
>Reporter: Jeremy Leung
>Assignee: Timothy Bish
>Priority: Blocker
> Attachments: patch.AMQCPP-489.txt
>
>
> Some errors affect the compilation of the library under Solaris 10 with Sun 
> Studio

--
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

[jira] [Updated] (AMQCPP-489) Fix for Sun Studio

2013-06-10 Thread Jeremy Leung (JIRA)


 [ 
https://issues.apache.org/jira/browse/AMQCPP-489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Leung updated AMQCPP-489:


Description: Some errors affect the compilation of the library under 
Solaris 10 with Sun Studio

> Fix for Sun Studio
> --
>
> Key: AMQCPP-489
> URL: https://issues.apache.org/jira/browse/AMQCPP-489
> Project: ActiveMQ C++ Client
>  Issue Type: Bug
>  Components: Decaf, Example Code
>Affects Versions: 3.7.0
> Environment: Solaris 10
>Reporter: Jeremy Leung
>Assignee: Timothy Bish
>Priority: Blocker
>
> Some errors affect the compilation of the library under Solaris 10 with Sun 
> Studio

--
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

[jira] [Updated] (AMQCPP-489) Compilation Error Fix for Sun Studio under Solaris 10

2013-06-10 Thread Jeremy Leung (JIRA)


 [ 
https://issues.apache.org/jira/browse/AMQCPP-489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Leung updated AMQCPP-489:


Summary: Compilation Error Fix for Sun Studio under Solaris 10  (was: Fix 
for Sun Studio)

> Compilation Error Fix for Sun Studio under Solaris 10
> -
>
> Key: AMQCPP-489
> URL: https://issues.apache.org/jira/browse/AMQCPP-489
> Project: ActiveMQ C++ Client
>  Issue Type: Bug
>  Components: Decaf, Example Code
>Affects Versions: 3.7.0
> Environment: Solaris 10
>Reporter: Jeremy Leung
>Assignee: Timothy Bish
>Priority: Blocker
>
> Some errors affect the compilation of the library under Solaris 10 with Sun 
> Studio

--
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

[jira] [Created] (AMQCPP-489) Fix for Sun Studio

2013-06-10 Thread Jeremy Leung (JIRA)

Jeremy Leung created AMQCPP-489:
---

 Summary: Fix for Sun Studio
 Key: AMQCPP-489
 URL: https://issues.apache.org/jira/browse/AMQCPP-489
 Project: ActiveMQ C++ Client
  Issue Type: Bug
  Components: Decaf, Example Code
Affects Versions: 3.7.0
 Environment: Solaris 10
Reporter: Jeremy Leung
Assignee: Timothy Bish
Priority: Blocker




--
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

[jira] [Commented] (AMQCPP-476) Reading of Stomp Frame with content length may throw excecption

2013-05-01 Thread Jeremy Leung (JIRA)


[ 
https://issues.apache.org/jira/browse/AMQCPP-476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13647152#comment-13647152
 ] 

Jeremy Leung commented on AMQCPP-476:
-

Thanks Timothy. Overlooked that there have a readFully function.

> Reading of Stomp Frame with content length may throw excecption
> ---
>
> Key: AMQCPP-476
> URL: https://issues.apache.org/jira/browse/AMQCPP-476
> Project: ActiveMQ C++ Client
>  Issue Type: Bug
>  Components: Stomp
>Affects Versions: 3.6.0
> Environment: Solaris 10
> Apollo
> AMQ
>Reporter: Jeremy Leung
>Assignee: Timothy Bish
> Fix For: 3.7.0
>
> Attachments: consumer.cpp, Publisher.java, StompFrame.cpp.patch.txt, 
> unit_test.txt
>
>
> -- HOW TO REPRODUCE --
> 1) Setup a consumer to listen for messages on Topic XXX using CMS with stomp.
> 2) Setup a publisher to send a messages from java JMS interface to Topic XXX 
> continually. (with org.fusesource.stomp.jms.*)
> 3) An exception is thrown in consumer from StompWireFormat::readStompBody() 
> with description "Read Content Length, and no trailing null"
> -- BLOCK DIAGRAM --
> All components are in different hosts and all run under Solaris 10 
> environment.
> | C++ CONSUMER | <- | APOLLO 1.6 / AMQ 5.4.2 | <- | JAVA PUBLISHER |
> or
> | C++ CONSUMER | <- | APOLLO 1.6 / AMQ 5.4.2 | <- | C++ PUBLISHER |

--
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

[jira] [Commented] (AMQCPP-476) Reading of Stomp Frame with content length may throw excecption

2013-04-30 Thread Jeremy Leung (JIRA)


[ 
https://issues.apache.org/jira/browse/AMQCPP-476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13645433#comment-13645433
 ] 

Jeremy Leung commented on AMQCPP-476:
-

Is the fix okay?

> Reading of Stomp Frame with content length may throw excecption
> ---
>
> Key: AMQCPP-476
> URL: https://issues.apache.org/jira/browse/AMQCPP-476
> Project: ActiveMQ C++ Client
>  Issue Type: Bug
>  Components: Stomp
>Affects Versions: 3.6.0
> Environment: Solaris 10
> Apollo
> AMQ
>Reporter: Jeremy Leung
>Assignee: Timothy Bish
> Attachments: consumer.cpp, Publisher.java, StompFrame.cpp.patch.txt, 
> unit_test.txt
>
>
> -- HOW TO REPRODUCE --
> 1) Setup a consumer to listen for messages on Topic XXX using CMS with stomp.
> 2) Setup a publisher to send a messages from java JMS interface to Topic XXX 
> continually. (with org.fusesource.stomp.jms.*)
> 3) An exception is thrown in consumer from StompWireFormat::readStompBody() 
> with description "Read Content Length, and no trailing null"
> -- BLOCK DIAGRAM --
> All components are in different hosts and all run under Solaris 10 
> environment.
> | C++ CONSUMER | <- | APOLLO 1.6 / AMQ 5.4.2 | <- | JAVA PUBLISHER |
> or
> | C++ CONSUMER | <- | APOLLO 1.6 / AMQ 5.4.2 | <- | C++ PUBLISHER |

--
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

[jira] [Updated] (AMQCPP-476) Reading of Stomp Frame with content length may throw excecption

2013-04-11 Thread Jeremy Leung (JIRA)


 [ 
https://issues.apache.org/jira/browse/AMQCPP-476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Leung updated AMQCPP-476:


Environment: 
Solaris 10
Apollo
AMQ

  was:Solaris 10


> Reading of Stomp Frame with content length may throw excecption
> ---
>
> Key: AMQCPP-476
> URL: https://issues.apache.org/jira/browse/AMQCPP-476
> Project: ActiveMQ C++ Client
>  Issue Type: Bug
>  Components: Stomp
>Affects Versions: 3.6.0
> Environment: Solaris 10
> Apollo
> AMQ
>Reporter: Jeremy Leung
>Assignee: Timothy Bish
> Attachments: consumer.cpp, Publisher.java, StompFrame.cpp.patch.txt, 
> unit_test.txt
>
>
> -- HOW TO REPRODUCE --
> 1) Setup a consumer to listen for messages on Topic XXX using CMS with stomp.
> 2) Setup a publisher to send a messages from java JMS interface to Topic XXX 
> continually. (with org.fusesource.stomp.jms.*)
> 3) An exception is thrown in consumer from StompWireFormat::readStompBody() 
> with description "Read Content Length, and no trailing null"
> -- BLOCK DIAGRAM --
> All components are in different hosts and all run under Solaris 10 
> environment.
> | C++ CONSUMER | <- | APOLLO 1.6 / AMQ 5.4.2 | <- | JAVA PUBLISHER |
> or
> | C++ CONSUMER | <- | APOLLO 1.6 / AMQ 5.4.2 | <- | C++ PUBLISHER |

--
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

[jira] [Updated] (AMQCPP-476) Reading of Stomp Frame with content length may throw excecption

2013-04-11 Thread Jeremy Leung (JIRA)


 [ 
https://issues.apache.org/jira/browse/AMQCPP-476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Leung updated AMQCPP-476:


Description: 
-- HOW TO REPRODUCE --
1) Setup a consumer to listen for messages on Topic XXX using CMS with stomp.
2) Setup a publisher to send a messages from java JMS interface to Topic XXX 
continually. (with org.fusesource.stomp.jms.*)
3) An exception is thrown in consumer from StompWireFormat::readStompBody() 
with description "Read Content Length, and no trailing null"

-- BLOCK DIAGRAM --
All components are in different hosts and all run under Solaris 10 environment.

| C++ CONSUMER | <- | APOLLO 1.6 / AMQ 5.4.2 | <- | JAVA PUBLISHER |

or

| C++ CONSUMER | <- | APOLLO 1.6 / AMQ 5.4.2 | <- | C++ PUBLISHER |


  was:
-- HOW TO REPRODUCE --
1) Setup a consumer to listen for messages on Topic XXX using CMS with stomp.
2) Setup a publisher to send a messages from java JMS interface to Topic XXX 
continually. (with org.fusesource.stomp.jms.*)
3) An exception is thrown in consumer from StompWireFormat::readStompBody() 
with description "Read Content Length, and no trailing null"

-- BLOCK DIAGRAM --
All components are in different hosts and all run under Solaris 10 environment.

| C++ CONSUMER | <- | APOLLO 1.6 | <- | JAVA PUBLISHER |

or

| C++ CONSUMER | <- | APOLLO 1.6 | <- | C++ PUBLISHER |



> Reading of Stomp Frame with content length may throw excecption
> ---
>
> Key: AMQCPP-476
> URL: https://issues.apache.org/jira/browse/AMQCPP-476
> Project: ActiveMQ C++ Client
>  Issue Type: Bug
>  Components: Stomp
>Affects Versions: 3.6.0
> Environment: Solaris 10
>Reporter: Jeremy Leung
>Assignee: Timothy Bish
> Attachments: consumer.cpp, Publisher.java, StompFrame.cpp.patch.txt, 
> unit_test.txt
>
>
> -- HOW TO REPRODUCE --
> 1) Setup a consumer to listen for messages on Topic XXX using CMS with stomp.
> 2) Setup a publisher to send a messages from java JMS interface to Topic XXX 
> continually. (with org.fusesource.stomp.jms.*)
> 3) An exception is thrown in consumer from StompWireFormat::readStompBody() 
> with description "Read Content Length, and no trailing null"
> -- BLOCK DIAGRAM --
> All components are in different hosts and all run under Solaris 10 
> environment.
> | C++ CONSUMER | <- | APOLLO 1.6 / AMQ 5.4.2 | <- | JAVA PUBLISHER |
> or
> | C++ CONSUMER | <- | APOLLO 1.6 / AMQ 5.4.2 | <- | C++ PUBLISHER |

--
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

[jira] [Comment Edited] (AMQCPP-476) Reading of Stomp Frame with content length may throw excecption

2013-04-11 Thread Jeremy Leung (JIRA)


[ 
https://issues.apache.org/jira/browse/AMQCPP-476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13628784#comment-13628784
 ] 

Jeremy Leung edited comment on AMQCPP-476 at 4/11/13 9:32 AM:
--

I forgot this can be reproduced easily by using the BytesMessage instead of 
TextMessage.

I have added the Bulk send test for stomp with BytesMessage and can reproduce 
the problems.

activemq::test::stomp::StompSimpleRollbackTest::testRollbacks. : OK
activemq::test::stomp::StompTransactionTest::testSendReceiveTransactedBatches. 
: OK
activemq::test::stomp::StompTransactionTest::testSendRollback. : OK
activemq::test::stomp::StompTransactionTest::testWithTTLSet. : OK
activemq::test::stomp::StompSlowListenerTest::testSlowListener. : OK
activemq::test::stomp::StompSimpleTest::testAutoAck. : OK
activemq::test::stomp::StompSimpleTest::testClientAck. : OK
activemq::test::stomp::StompSimpleTest::testProducerWithNullDestination. : OK
activemq::test::stomp::StompSimpleTest::testSyncReceive. : OK
activemq::test::stomp::StompSimpleTest::testSyncReceiveClientAck. : OK
activemq::test::stomp::StompSimpleTest::testMultipleConnections. : OK
activemq::test::stomp::StompSimpleTest::testMultipleSessions. : OK
activemq::test::stomp::StompSimpleTest::testReceiveAlreadyInQueue. : OK
activemq::test::stomp::StompSimpleTest::testQuickCreateAndDestroy. : OK
activemq::test::stomp::StompExpirationTest::testExpired. : OK
activemq::test::stomp::StompExpirationTest::testNotExpired. : OK
activemq::test::stomp::StompDurableTest::testDurableConsumer. : assertionF
activemq::test::stomp::StompCmsConnectionStartStopTest::testStoppedConsumerHoldsMessagesTillStarted.
 : OK
activemq::test::stomp::StompCmsConnectionStartStopTest::testMultipleConnectionStops.
 : OK
activemq::test::stomp::StompCmsConnectionStartStopTest::testConcurrentSessionCreateWithStart.
 : OK
activemq::test::stomp::StompCmsTemplateTest::testBasics. : OK
activemq::test::stomp::StompCmsTemplateTest::testReceiveException. : OK
activemq::test::stomp::StompCmsTemplateTest::testSendException. : OK
activemq::test::stomp::StompBulkMessageTest::testBulkMessageSendReceive. : 
assertionF
activemq::test::stomp::StompAsyncSenderTest::testAsyncSends. : OK



!!!FAILURES!!!
Test Results:
Run:  25   Failures: 2   Errors: 0


1) test: activemq::test::stomp::StompDurableTest::testDurableConsumer (F) line: 
75 activemq/test/DurableTest.cpp
assertion failed
- Expression: received.get() != NULL
- Failed to receive all messages in batch


2) test: 
activemq::test::stomp::StompBulkMessageTest::testBulkMessageSendReceive (F) 
line: 108 activemq/test/BulkMessageTest.cpp
unexpected exception caught
- Caught: cms::CMSException
- What(): StompWireFormat::readStompBody: Read Content Length, and no trailing 
null





  was (Author: jeremyleung):
I forgot this can be reproduced easily by using the BytesMessage instead of 
TextMessage.

I have added the Bulk send test for stomp with BytesMessage and can reproduce 
the problems.

activemq::test::stomp::StompSimpleRollbackTest::testRollbacks. : OK
activemq::test::stomp::StompTransactionTest::testSendReceiveTransactedBatches. 
: OK
activemq::test::stomp::StompTransactionTest::testSendRollback. : OK
activemq::test::stomp::StompTransactionTest::testWithTTLSet. : OK
activemq::test::stomp::StompSlowListenerTest::testSlowListener. : OK
activemq::test::stomp::StompSimpleTest::testAutoAck. : OK
activemq::test::stomp::StompSimpleTest::testClientAck. : OK
activemq::test::stomp::StompSimpleTest::testProducerWithNullDestination. : OK
activemq::test::stomp::StompSimpleTest::testSyncReceive. : OK
activemq::test::stomp::StompSimpleTest::testSyncReceiveClientAck. : OK
activemq::test::stomp::StompSimpleTest::testMultipleConnections. : OK
activemq::test::stomp::StompSimpleTest::testMultipleSessions. : OK
activemq::test::stomp::StompSimpleTest::testReceiveAlreadyInQueue. : OK
activemq::test::stomp::StompSimpleTest::testQuickCreateAndDestroy. : OK
activemq::test::stomp::StompExpirationTest::testExpired. : OK
activemq::test::stomp::StompExpirationTest::testNotExpired. : OK
activemq::test::stomp::StompDurableTest::testDurableConsumer. : assertionF
activemq::test::stomp::StompCmsConnectionStartStopTest::testStoppedConsumerHoldsMessagesTillStarted.
 : OK
activemq::test::stomp::StompCmsConnectionStartStopTest::testMultipleConnectionStops.
 : OK
activemq::test::stomp::StompCmsConnectionStartStopTest::testConcurrentSessionCreateWithStart.
 : OK
activemq::test::stomp::StompCmsTemplateTest::testBasics. : OK
activemq::test::stomp::StompCmsTemplateTest::testReceiveException. : OK
activemq::test::stomp::StompCmsTemplateTest::testSendException. : OK
activemq::test::stomp::StompBulkMessageTest::testBulkMessageSendReceive. : OK
activemq::test::stomp::StompAsyncSenderTest::testAsyncSends. : OK



!!!FAILURES!!!
Test Results:
Run:  25   Failures: 1   Errors: 0


1) test: acti

[jira] [Comment Edited] (AMQCPP-476) Reading of Stomp Frame with content length may throw excecption

2013-04-11 Thread Jeremy Leung (JIRA)


[ 
https://issues.apache.org/jira/browse/AMQCPP-476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13628784#comment-13628784
 ] 

Jeremy Leung edited comment on AMQCPP-476 at 4/11/13 9:29 AM:
--

I forgot this can be reproduced easily by using the BytesMessage instead of 
TextMessage.

I have added the Bulk send test for stomp with BytesMessage and can reproduce 
the problems.

activemq::test::stomp::StompSimpleRollbackTest::testRollbacks. : OK
activemq::test::stomp::StompTransactionTest::testSendReceiveTransactedBatches. 
: OK
activemq::test::stomp::StompTransactionTest::testSendRollback. : OK
activemq::test::stomp::StompTransactionTest::testWithTTLSet. : OK
activemq::test::stomp::StompSlowListenerTest::testSlowListener. : OK
activemq::test::stomp::StompSimpleTest::testAutoAck. : OK
activemq::test::stomp::StompSimpleTest::testClientAck. : OK
activemq::test::stomp::StompSimpleTest::testProducerWithNullDestination. : OK
activemq::test::stomp::StompSimpleTest::testSyncReceive. : OK
activemq::test::stomp::StompSimpleTest::testSyncReceiveClientAck. : OK
activemq::test::stomp::StompSimpleTest::testMultipleConnections. : OK
activemq::test::stomp::StompSimpleTest::testMultipleSessions. : OK
activemq::test::stomp::StompSimpleTest::testReceiveAlreadyInQueue. : OK
activemq::test::stomp::StompSimpleTest::testQuickCreateAndDestroy. : OK
activemq::test::stomp::StompExpirationTest::testExpired. : OK
activemq::test::stomp::StompExpirationTest::testNotExpired. : OK
activemq::test::stomp::StompDurableTest::testDurableConsumer. : assertionF
activemq::test::stomp::StompCmsConnectionStartStopTest::testStoppedConsumerHoldsMessagesTillStarted.
 : OK
activemq::test::stomp::StompCmsConnectionStartStopTest::testMultipleConnectionStops.
 : OK
activemq::test::stomp::StompCmsConnectionStartStopTest::testConcurrentSessionCreateWithStart.
 : OK
activemq::test::stomp::StompCmsTemplateTest::testBasics. : OK
activemq::test::stomp::StompCmsTemplateTest::testReceiveException. : OK
activemq::test::stomp::StompCmsTemplateTest::testSendException. : OK
activemq::test::stomp::StompBulkMessageTest::testBulkMessageSendReceive. : OK
activemq::test::stomp::StompAsyncSenderTest::testAsyncSends. : OK



!!!FAILURES!!!
Test Results:
Run:  25   Failures: 1   Errors: 0


1) test: activemq::test::stomp::StompDurableTest::testDurableConsumer (F) line: 
75 activemq/test/DurableTest.cpp
assertion failed
- Expression: received.get() != NULL
- Failed to receive all messages in batch



  was (Author: jeremyleung):
I forgot this can be reproduced by using the BytesMessage instead of 
TextMessage.

activemq::test::stomp::StompSimpleRollbackTest::testRollbacks. : OK
activemq::test::stomp::StompTransactionTest::testSendReceiveTransactedBatches. 
: OK
activemq::test::stomp::StompTransactionTest::testSendRollback. : OK
activemq::test::stomp::StompTransactionTest::testWithTTLSet. : OK
activemq::test::stomp::StompSlowListenerTest::testSlowListener. : OK
activemq::test::stomp::StompSimpleTest::testAutoAck. : OK
activemq::test::stomp::StompSimpleTest::testClientAck. : OK
activemq::test::stomp::StompSimpleTest::testProducerWithNullDestination. : OK
activemq::test::stomp::StompSimpleTest::testSyncReceive. : OK
activemq::test::stomp::StompSimpleTest::testSyncReceiveClientAck. : OK
activemq::test::stomp::StompSimpleTest::testMultipleConnections. : OK
activemq::test::stomp::StompSimpleTest::testMultipleSessions. : OK
activemq::test::stomp::StompSimpleTest::testReceiveAlreadyInQueue. : OK
activemq::test::stomp::StompSimpleTest::testQuickCreateAndDestroy. : OK
activemq::test::stomp::StompExpirationTest::testExpired. : OK
activemq::test::stomp::StompExpirationTest::testNotExpired. : OK
activemq::test::stomp::StompDurableTest::testDurableConsumer. : assertionF
activemq::test::stomp::StompCmsConnectionStartStopTest::testStoppedConsumerHoldsMessagesTillStarted.
 : OK
activemq::test::stomp::StompCmsConnectionStartStopTest::testMultipleConnectionStops.
 : OK
activemq::test::stomp::StompCmsConnectionStartStopTest::testConcurrentSessionCreateWithStart.
 : OK
activemq::test::stomp::StompCmsTemplateTest::testBasics. : OK
activemq::test::stomp::StompCmsTemplateTest::testReceiveException. : OK
activemq::test::stomp::StompCmsTemplateTest::testSendException. : OK
activemq::test::stomp::StompBulkMessageTest::testBulkMessageSendReceive. : 
assertionF
activemq::test::stomp::StompAsyncSenderTest::testAsyncSends. : OK



!!!FAILURES!!!
Test Results:
Run:  25   Failures: 1   Errors: 0


1) test: 
activemq::test::stomp::StompBulkMessageTest::testBulkMessageSendReceive (F) 
line: 108 activemq/test/BulkMessageTest.cpp
unexpected exception caught
- Caught: cms::CMSException
- What(): StompWireFormat::readStompBody: Read Content Length, and no trailing 
null

  
> Reading of Stomp Frame with content length may throw excecption
> --

[jira] [Issue Comment Deleted] (AMQCPP-476) Reading of Stomp Frame with content length may throw excecption

2013-04-11 Thread Jeremy Leung (JIRA)


 [ 
https://issues.apache.org/jira/browse/AMQCPP-476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Leung updated AMQCPP-476:


Comment: was deleted

(was: The problems can't reproduce with C++ publisher and consumer.
Attached the test programs. )

> Reading of Stomp Frame with content length may throw excecption
> ---
>
> Key: AMQCPP-476
> URL: https://issues.apache.org/jira/browse/AMQCPP-476
> Project: ActiveMQ C++ Client
>  Issue Type: Bug
>  Components: Stomp
>Affects Versions: 3.6.0
> Environment: Solaris 10
>Reporter: Jeremy Leung
>Assignee: Timothy Bish
> Attachments: consumer.cpp, Publisher.java, StompFrame.cpp.patch.txt, 
> unit_test.txt
>
>
> -- HOW TO REPRODUCE --
> 1) Setup a consumer to listen for messages on Topic XXX using CMS with stomp.
> 2) Setup a publisher to send a messages from java JMS interface to Topic XXX 
> continually. (with org.fusesource.stomp.jms.*)
> 3) An exception is thrown in consumer from StompWireFormat::readStompBody() 
> with description "Read Content Length, and no trailing null"
> -- BLOCK DIAGRAM --
> All components are in different hosts and all run under Solaris 10 
> environment.
> | C++ CONSUMER | <- | APOLLO 1.6 | <- | JAVA PUBLISHER |

--
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

[jira] [Updated] (AMQCPP-476) Reading of Stomp Frame with content length may throw excecption

2013-04-11 Thread Jeremy Leung (JIRA)


 [ 
https://issues.apache.org/jira/browse/AMQCPP-476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Leung updated AMQCPP-476:


Description: 
-- HOW TO REPRODUCE --
1) Setup a consumer to listen for messages on Topic XXX using CMS with stomp.
2) Setup a publisher to send a messages from java JMS interface to Topic XXX 
continually. (with org.fusesource.stomp.jms.*)
3) An exception is thrown in consumer from StompWireFormat::readStompBody() 
with description "Read Content Length, and no trailing null"

-- BLOCK DIAGRAM --
All components are in different hosts and all run under Solaris 10 environment.

| C++ CONSUMER | <- | APOLLO 1.6 | <- | JAVA PUBLISHER |

or

| C++ CONSUMER | <- | APOLLO 1.6 | <- | C++ PUBLISHER |


  was:
-- HOW TO REPRODUCE --
1) Setup a consumer to listen for messages on Topic XXX using CMS with stomp.
2) Setup a publisher to send a messages from java JMS interface to Topic XXX 
continually. (with org.fusesource.stomp.jms.*)
3) An exception is thrown in consumer from StompWireFormat::readStompBody() 
with description "Read Content Length, and no trailing null"

-- BLOCK DIAGRAM --
All components are in different hosts and all run under Solaris 10 environment.

| C++ CONSUMER | <- | APOLLO 1.6 | <- | JAVA PUBLISHER |



> Reading of Stomp Frame with content length may throw excecption
> ---
>
> Key: AMQCPP-476
> URL: https://issues.apache.org/jira/browse/AMQCPP-476
> Project: ActiveMQ C++ Client
>  Issue Type: Bug
>  Components: Stomp
>Affects Versions: 3.6.0
> Environment: Solaris 10
>Reporter: Jeremy Leung
>Assignee: Timothy Bish
> Attachments: consumer.cpp, Publisher.java, StompFrame.cpp.patch.txt, 
> unit_test.txt
>
>
> -- HOW TO REPRODUCE --
> 1) Setup a consumer to listen for messages on Topic XXX using CMS with stomp.
> 2) Setup a publisher to send a messages from java JMS interface to Topic XXX 
> continually. (with org.fusesource.stomp.jms.*)
> 3) An exception is thrown in consumer from StompWireFormat::readStompBody() 
> with description "Read Content Length, and no trailing null"
> -- BLOCK DIAGRAM --
> All components are in different hosts and all run under Solaris 10 
> environment.
> | C++ CONSUMER | <- | APOLLO 1.6 | <- | JAVA PUBLISHER |
> or
> | C++ CONSUMER | <- | APOLLO 1.6 | <- | C++ PUBLISHER |

--
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

[jira] [Updated] (AMQCPP-476) Reading of Stomp Frame with content length may throw excecption

2013-04-11 Thread Jeremy Leung (JIRA)


 [ 
https://issues.apache.org/jira/browse/AMQCPP-476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Leung updated AMQCPP-476:


Attachment: unit_test.txt

> Reading of Stomp Frame with content length may throw excecption
> ---
>
> Key: AMQCPP-476
> URL: https://issues.apache.org/jira/browse/AMQCPP-476
> Project: ActiveMQ C++ Client
>  Issue Type: Bug
>  Components: Stomp
>Affects Versions: 3.6.0
> Environment: Solaris 10
>Reporter: Jeremy Leung
>Assignee: Timothy Bish
> Attachments: consumer.cpp, Publisher.java, StompFrame.cpp.patch.txt, 
> unit_test.txt
>
>
> -- HOW TO REPRODUCE --
> 1) Setup a consumer to listen for messages on Topic XXX using CMS with stomp.
> 2) Setup a publisher to send a messages from java JMS interface to Topic XXX 
> continually. (with org.fusesource.stomp.jms.*)
> 3) An exception is thrown in consumer from StompWireFormat::readStompBody() 
> with description "Read Content Length, and no trailing null"
> -- BLOCK DIAGRAM --
> All components are in different hosts and all run under Solaris 10 
> environment.
> | C++ CONSUMER | <- | APOLLO 1.6 | <- | JAVA PUBLISHER |

--
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

[jira] [Commented] (AMQCPP-476) Reading of Stomp Frame with content length may throw excecption

2013-04-11 Thread Jeremy Leung (JIRA)


[ 
https://issues.apache.org/jira/browse/AMQCPP-476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13628784#comment-13628784
 ] 

Jeremy Leung commented on AMQCPP-476:
-

I forgot this can be reproduced by using the BytesMessage instead of 
TextMessage.

activemq::test::stomp::StompSimpleRollbackTest::testRollbacks. : OK
activemq::test::stomp::StompTransactionTest::testSendReceiveTransactedBatches. 
: OK
activemq::test::stomp::StompTransactionTest::testSendRollback. : OK
activemq::test::stomp::StompTransactionTest::testWithTTLSet. : OK
activemq::test::stomp::StompSlowListenerTest::testSlowListener. : OK
activemq::test::stomp::StompSimpleTest::testAutoAck. : OK
activemq::test::stomp::StompSimpleTest::testClientAck. : OK
activemq::test::stomp::StompSimpleTest::testProducerWithNullDestination. : OK
activemq::test::stomp::StompSimpleTest::testSyncReceive. : OK
activemq::test::stomp::StompSimpleTest::testSyncReceiveClientAck. : OK
activemq::test::stomp::StompSimpleTest::testMultipleConnections. : OK
activemq::test::stomp::StompSimpleTest::testMultipleSessions. : OK
activemq::test::stomp::StompSimpleTest::testReceiveAlreadyInQueue. : OK
activemq::test::stomp::StompSimpleTest::testQuickCreateAndDestroy. : OK
activemq::test::stomp::StompExpirationTest::testExpired. : OK
activemq::test::stomp::StompExpirationTest::testNotExpired. : OK
activemq::test::stomp::StompDurableTest::testDurableConsumer. : assertionF
activemq::test::stomp::StompCmsConnectionStartStopTest::testStoppedConsumerHoldsMessagesTillStarted.
 : OK
activemq::test::stomp::StompCmsConnectionStartStopTest::testMultipleConnectionStops.
 : OK
activemq::test::stomp::StompCmsConnectionStartStopTest::testConcurrentSessionCreateWithStart.
 : OK
activemq::test::stomp::StompCmsTemplateTest::testBasics. : OK
activemq::test::stomp::StompCmsTemplateTest::testReceiveException. : OK
activemq::test::stomp::StompCmsTemplateTest::testSendException. : OK
activemq::test::stomp::StompBulkMessageTest::testBulkMessageSendReceive. : 
assertionF
activemq::test::stomp::StompAsyncSenderTest::testAsyncSends. : OK



!!!FAILURES!!!
Test Results:
Run:  25   Failures: 1   Errors: 0


1) test: 
activemq::test::stomp::StompBulkMessageTest::testBulkMessageSendReceive (F) 
line: 108 activemq/test/BulkMessageTest.cpp
unexpected exception caught
- Caught: cms::CMSException
- What(): StompWireFormat::readStompBody: Read Content Length, and no trailing 
null


> Reading of Stomp Frame with content length may throw excecption
> ---
>
> Key: AMQCPP-476
> URL: https://issues.apache.org/jira/browse/AMQCPP-476
> Project: ActiveMQ C++ Client
>  Issue Type: Bug
>  Components: Stomp
>Affects Versions: 3.6.0
> Environment: Solaris 10
>Reporter: Jeremy Leung
>Assignee: Timothy Bish
> Attachments: consumer.cpp, Publisher.java, StompFrame.cpp.patch.txt
>
>
> -- HOW TO REPRODUCE --
> 1) Setup a consumer to listen for messages on Topic XXX using CMS with stomp.
> 2) Setup a publisher to send a messages from java JMS interface to Topic XXX 
> continually. (with org.fusesource.stomp.jms.*)
> 3) An exception is thrown in consumer from StompWireFormat::readStompBody() 
> with description "Read Content Length, and no trailing null"
> -- BLOCK DIAGRAM --
> All components are in different hosts and all run under Solaris 10 
> environment.
> | C++ CONSUMER | <- | APOLLO 1.6 | <- | JAVA PUBLISHER |

--
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

[jira] [Commented] (AMQCPP-476) Reading of Stomp Frame with content length may throw excecption

2013-04-10 Thread Jeremy Leung (JIRA)


[ 
https://issues.apache.org/jira/browse/AMQCPP-476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13628534#comment-13628534
 ] 

Jeremy Leung commented on AMQCPP-476:
-

The problems can't reproduce with C++ publisher and consumer.
Attached the test programs. 

> Reading of Stomp Frame with content length may throw excecption
> ---
>
> Key: AMQCPP-476
> URL: https://issues.apache.org/jira/browse/AMQCPP-476
> Project: ActiveMQ C++ Client
>  Issue Type: Bug
>  Components: Stomp
>Affects Versions: 3.6.0
> Environment: Solaris 10
>Reporter: Jeremy Leung
>Assignee: Timothy Bish
> Attachments: consumer.cpp, Publisher.java, StompFrame.cpp.patch.txt
>
>
> -- HOW TO REPRODUCE --
> 1) Setup a consumer to listen for messages on Topic XXX using CMS with stomp.
> 2) Setup a publisher to send a messages from java JMS interface to Topic XXX 
> continually. (with org.fusesource.stomp.jms.*)
> 3) An exception is thrown in consumer from StompWireFormat::readStompBody() 
> with description "Read Content Length, and no trailing null"
> -- BLOCK DIAGRAM --
> All components are in different hosts and all run under Solaris 10 
> environment.
> | C++ CONSUMER | <- | APOLLO 1.6 | <- | JAVA PUBLISHER |

--
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

[jira] [Updated] (AMQCPP-476) Reading of Stomp Frame with content length may throw excecption

2013-04-09 Thread Jeremy Leung (JIRA)


 [ 
https://issues.apache.org/jira/browse/AMQCPP-476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Leung updated AMQCPP-476:


Attachment: Publisher.java

> Reading of Stomp Frame with content length may throw excecption
> ---
>
> Key: AMQCPP-476
> URL: https://issues.apache.org/jira/browse/AMQCPP-476
> Project: ActiveMQ C++ Client
>  Issue Type: Bug
>  Components: Stomp
>Affects Versions: 3.6.0
> Environment: Solaris 10
>Reporter: Jeremy Leung
>Assignee: Timothy Bish
> Attachments: consumer.cpp, Publisher.java, StompFrame.cpp.patch.txt
>
>
> -- HOW TO REPRODUCE --
> 1) Setup a consumer to listen for messages on Topic XXX using CMS with stomp.
> 2) Setup a publisher to send a messages from java JMS interface to Topic XXX 
> continually. (with org.fusesource.stomp.jms.*)
> 3) An exception is thrown in consumer from StompWireFormat::readStompBody() 
> with description "Read Content Length, and no trailing null"
> -- BLOCK DIAGRAM --
> All components are in different hosts and all run under Solaris 10 
> environment.
> | C++ CONSUMER | <- | APOLLO 1.6 | <- | JAVA PUBLISHER |

--
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

[jira] [Updated] (AMQCPP-476) Reading of Stomp Frame with content length may throw excecption

2013-04-09 Thread Jeremy Leung (JIRA)


 [ 
https://issues.apache.org/jira/browse/AMQCPP-476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Leung updated AMQCPP-476:


Attachment: consumer.cpp

> Reading of Stomp Frame with content length may throw excecption
> ---
>
> Key: AMQCPP-476
> URL: https://issues.apache.org/jira/browse/AMQCPP-476
> Project: ActiveMQ C++ Client
>  Issue Type: Bug
>  Components: Stomp
>Affects Versions: 3.6.0
> Environment: Solaris 10
>Reporter: Jeremy Leung
>Assignee: Timothy Bish
> Attachments: consumer.cpp, StompFrame.cpp.patch.txt
>
>
> -- HOW TO REPRODUCE --
> 1) Setup a consumer to listen for messages on Topic XXX using CMS with stomp.
> 2) Setup a publisher to send a messages from java JMS interface to Topic XXX 
> continually. (with org.fusesource.stomp.jms.*)
> 3) An exception is thrown in consumer from StompWireFormat::readStompBody() 
> with description "Read Content Length, and no trailing null"
> -- BLOCK DIAGRAM --
> All components are in different hosts and all run under Solaris 10 
> environment.
> | C++ CONSUMER | <- | APOLLO 1.6 | <- | JAVA PUBLISHER |

--
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

[jira] [Updated] (AMQCPP-476) Reading of Stomp Frame with content length may throw excecption

2013-04-09 Thread Jeremy Leung (JIRA)


 [ 
https://issues.apache.org/jira/browse/AMQCPP-476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Leung updated AMQCPP-476:


Description: 
-- HOW TO REPRODUCE --
1) Setup a consumer to listen for messages on Topic XXX using CMS with stomp.
2) Setup a publisher to send a messages from java JMS interface to Topic XXX 
continually. (with org.fusesource.stomp.jms.*)
3) An exception is thrown in consumer from StompWireFormat::readStompBody() 
with description "Read Content Length, and no trailing null"

-- BLOCK DIAGRAM --
All components are in different hosts and all run under Solaris 10 environment.

X--XXXXX
| C++ CONSUMER | <- | APOLLO 1.6 | <- | JAVA PUBLISHER |
X--XXXXX


  was:
To Reproduce
1) Setup a consumer to listen for messages on Topic XXX using CMS with stomp.
2) Setup a publisher to send a messages from java JMS interface to Topic XXX 
continually. (with org.fusesource.stomp.jms.*)
3) An exception is thrown in consumer from StompWireFormat::readStompBody() 
with description "Read Content Length, and no trailing null"






> Reading of Stomp Frame with content length may throw excecption
> ---
>
> Key: AMQCPP-476
> URL: https://issues.apache.org/jira/browse/AMQCPP-476
> Project: ActiveMQ C++ Client
>  Issue Type: Bug
>  Components: Stomp
>Affects Versions: 3.6.0
> Environment: Solaris 10
>Reporter: Jeremy Leung
>Assignee: Timothy Bish
> Attachments: StompFrame.cpp.patch.txt
>
>
> -- HOW TO REPRODUCE --
> 1) Setup a consumer to listen for messages on Topic XXX using CMS with stomp.
> 2) Setup a publisher to send a messages from java JMS interface to Topic XXX 
> continually. (with org.fusesource.stomp.jms.*)
> 3) An exception is thrown in consumer from StompWireFormat::readStompBody() 
> with description "Read Content Length, and no trailing null"
> -- BLOCK DIAGRAM --
> All components are in different hosts and all run under Solaris 10 
> environment.
> X--XXXXX
> | C++ CONSUMER | <- | APOLLO 1.6 | <- | JAVA PUBLISHER |
> X--XXXXX

--
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

[jira] [Updated] (AMQCPP-476) Reading of Stomp Frame with content length may throw excecption

2013-04-09 Thread Jeremy Leung (JIRA)


 [ 
https://issues.apache.org/jira/browse/AMQCPP-476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Leung updated AMQCPP-476:


Description: 
-- HOW TO REPRODUCE --
1) Setup a consumer to listen for messages on Topic XXX using CMS with stomp.
2) Setup a publisher to send a messages from java JMS interface to Topic XXX 
continually. (with org.fusesource.stomp.jms.*)
3) An exception is thrown in consumer from StompWireFormat::readStompBody() 
with description "Read Content Length, and no trailing null"

-- BLOCK DIAGRAM --
All components are in different hosts and all run under Solaris 10 environment.

| C++ CONSUMER | <- | APOLLO 1.6 | <- | JAVA PUBLISHER |


  was:
-- HOW TO REPRODUCE --
1) Setup a consumer to listen for messages on Topic XXX using CMS with stomp.
2) Setup a publisher to send a messages from java JMS interface to Topic XXX 
continually. (with org.fusesource.stomp.jms.*)
3) An exception is thrown in consumer from StompWireFormat::readStompBody() 
with description "Read Content Length, and no trailing null"

-- BLOCK DIAGRAM --
All components are in different hosts and all run under Solaris 10 environment.

X--XXXXX
| C++ CONSUMER | <- | APOLLO 1.6 | <- | JAVA PUBLISHER |
X--XXXXX



> Reading of Stomp Frame with content length may throw excecption
> ---
>
> Key: AMQCPP-476
> URL: https://issues.apache.org/jira/browse/AMQCPP-476
> Project: ActiveMQ C++ Client
>  Issue Type: Bug
>  Components: Stomp
>Affects Versions: 3.6.0
> Environment: Solaris 10
>Reporter: Jeremy Leung
>Assignee: Timothy Bish
> Attachments: StompFrame.cpp.patch.txt
>
>
> -- HOW TO REPRODUCE --
> 1) Setup a consumer to listen for messages on Topic XXX using CMS with stomp.
> 2) Setup a publisher to send a messages from java JMS interface to Topic XXX 
> continually. (with org.fusesource.stomp.jms.*)
> 3) An exception is thrown in consumer from StompWireFormat::readStompBody() 
> with description "Read Content Length, and no trailing null"
> -- BLOCK DIAGRAM --
> All components are in different hosts and all run under Solaris 10 
> environment.
> | C++ CONSUMER | <- | APOLLO 1.6 | <- | JAVA PUBLISHER |

--
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

[jira] [Updated] (AMQCPP-476) Reading of Stomp Frame with content length may throw excecption

2013-04-09 Thread Jeremy Leung (JIRA)


 [ 
https://issues.apache.org/jira/browse/AMQCPP-476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Leung updated AMQCPP-476:


Patch Info: Patch Available

> Reading of Stomp Frame with content length may throw excecption
> ---
>
> Key: AMQCPP-476
> URL: https://issues.apache.org/jira/browse/AMQCPP-476
> Project: ActiveMQ C++ Client
>  Issue Type: Bug
>  Components: Stomp
>Affects Versions: 3.6.0
> Environment: Solaris 10
>Reporter: Jeremy Leung
>Assignee: Timothy Bish
> Attachments: StompFrame.cpp.patch.txt
>
>
> To Reproduce
> 1) Setup a consumer to listen for messages on Topic XXX using CMS with stomp.
> 2) Setup a publisher to send a messages from java JMS interface to Topic XXX 
> continually. (with org.fusesource.stomp.jms.*)
> 3) An exception is thrown in consumer from StompWireFormat::readStompBody() 
> with description "Read Content Length, and no trailing null"

--
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

[jira] [Updated] (AMQCPP-476) Reading of Stomp Frame with content length may throw excecption

2013-04-09 Thread Jeremy Leung (JIRA)


 [ 
https://issues.apache.org/jira/browse/AMQCPP-476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Leung updated AMQCPP-476:


Attachment: StompFrame.cpp.patch.txt

src/main/activemq/wireformat/stomp/StompFrame.cpp

> Reading of Stomp Frame with content length may throw excecption
> ---
>
> Key: AMQCPP-476
> URL: https://issues.apache.org/jira/browse/AMQCPP-476
> Project: ActiveMQ C++ Client
>  Issue Type: Bug
>  Components: Stomp
>Affects Versions: 3.6.0
> Environment: Solaris 10
>Reporter: Jeremy Leung
>Assignee: Timothy Bish
> Attachments: StompFrame.cpp.patch.txt
>
>
> To Reproduce
> 1) Setup a consumer to listen for messages on Topic XXX using CMS with stomp.
> 2) Setup a publisher to send a messages from java JMS interface to Topic XXX 
> continually. (with org.fusesource.stomp.jms.*)
> 3) An exception is thrown in consumer from StompWireFormat::readStompBody() 
> with description "Read Content Length, and no trailing null"

--
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

[jira] [Updated] (AMQCPP-476) Reading of Stomp Frame with content length may throw excecption

2013-04-09 Thread Jeremy Leung (JIRA)


 [ 
https://issues.apache.org/jira/browse/AMQCPP-476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Leung updated AMQCPP-476:


Description: 
To Reproduce
1) Setup a consumer to listen for messages on Topic XXX using CMS with stomp.
2) Setup a publisher to send a messages from java JMS interface to Topic XXX 
continually. (with org.fusesource.stomp.jms.*)
3) An exception is thrown in consumer from StompWireFormat::readStompBody() 
with description "Read Content Length, and no trailing null"





> Reading of Stomp Frame with content length may throw excecption
> ---
>
> Key: AMQCPP-476
> URL: https://issues.apache.org/jira/browse/AMQCPP-476
> Project: ActiveMQ C++ Client
>  Issue Type: Bug
>  Components: Stomp
>Affects Versions: 3.6.0
> Environment: Solaris 10
>Reporter: Jeremy Leung
>Assignee: Timothy Bish
>
> To Reproduce
> 1) Setup a consumer to listen for messages on Topic XXX using CMS with stomp.
> 2) Setup a publisher to send a messages from java JMS interface to Topic XXX 
> continually. (with org.fusesource.stomp.jms.*)
> 3) An exception is thrown in consumer from StompWireFormat::readStompBody() 
> with description "Read Content Length, and no trailing null"

--
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

[jira] [Created] (AMQCPP-476) Reading of Stomp Frame with content length may throw excecption

2013-04-09 Thread Jeremy Leung (JIRA)

Jeremy Leung created AMQCPP-476:
---

 Summary: Reading of Stomp Frame with content length may throw 
excecption
 Key: AMQCPP-476
 URL: https://issues.apache.org/jira/browse/AMQCPP-476
 Project: ActiveMQ C++ Client
  Issue Type: Bug
  Components: Stomp
Affects Versions: 3.6.0
 Environment: Solaris 10
Reporter: Jeremy Leung
Assignee: Timothy Bish




--
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

[jira] [Updated] (AMQCPP-475) Fix for Atomics Helper for Solaris 10

2013-04-08 Thread Jeremy Leung (JIRA)


 [ 
https://issues.apache.org/jira/browse/AMQCPP-475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Leung updated AMQCPP-475:


Labels: atomic solaris  (was: )

> Fix for Atomics Helper for Solaris 10
> -
>
> Key: AMQCPP-475
> URL: https://issues.apache.org/jira/browse/AMQCPP-475
> Project: ActiveMQ C++ Client
>  Issue Type: Bug
>  Components: Decaf
>Affects Versions: 3.6.0
> Environment: Solaris 10
>Reporter: Jeremy Leung
>Assignee: Timothy Bish
>Priority: Blocker
>  Labels: atomic, solaris
> Attachments: patchfile.txt
>
>
> activemq-cpp/src/main/decaf/internal/util/concurrent/unix/Atomics is not 
> compile-able under Solaris 10 with Sun Studio 11 (CC: Sun C++ 5.8 Patch 
> 121018-20).
> The Attached Patch Fixed:
> - Atomics::compareAndSet32 and Atomics::compareAndSet is not working as 
> expected and will caused the IOTransport not started correctly
> - CC Compiler Errors

--
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

[jira] [Updated] (AMQCPP-475) Fix for Atomics Helper for Solaris 10

2013-04-08 Thread Jeremy Leung (JIRA)


 [ 
https://issues.apache.org/jira/browse/AMQCPP-475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Leung updated AMQCPP-475:


Description: 
activemq-cpp/src/main/decaf/internal/util/concurrent/unix/Atomics is not 
compile-able under Solaris 10 with Sun Studio 11 (CC: Sun C++ 5.8 Patch 
121018-20).

The Attached Patch Fixed:
- Atomics::compareAndSet32 and Atomics::compareAndSet is not working as 
expected and will caused the IOTransport not started correctly
- CC Compiler Errors


> Fix for Atomics Helper for Solaris 10
> -
>
> Key: AMQCPP-475
> URL: https://issues.apache.org/jira/browse/AMQCPP-475
> Project: ActiveMQ C++ Client
>  Issue Type: Bug
>  Components: Decaf
>Affects Versions: 3.6.0
> Environment: Solaris 10
>Reporter: Jeremy Leung
>Assignee: Timothy Bish
>Priority: Blocker
> Attachments: patchfile.txt
>
>
> activemq-cpp/src/main/decaf/internal/util/concurrent/unix/Atomics is not 
> compile-able under Solaris 10 with Sun Studio 11 (CC: Sun C++ 5.8 Patch 
> 121018-20).
> The Attached Patch Fixed:
> - Atomics::compareAndSet32 and Atomics::compareAndSet is not working as 
> expected and will caused the IOTransport not started correctly
> - CC Compiler Errors

--
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

[jira] [Updated] (AMQCPP-475) Fix for Atomics Helper for Solaris 10

2013-04-08 Thread Jeremy Leung (JIRA)


 [ 
https://issues.apache.org/jira/browse/AMQCPP-475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Leung updated AMQCPP-475:


Patch Info: Patch Available

> Fix for Atomics Helper for Solaris 10
> -
>
> Key: AMQCPP-475
> URL: https://issues.apache.org/jira/browse/AMQCPP-475
> Project: ActiveMQ C++ Client
>  Issue Type: Bug
>  Components: Decaf
>Affects Versions: 3.6.0
> Environment: Solaris 10
>Reporter: Jeremy Leung
>Assignee: Timothy Bish
>Priority: Blocker
> Attachments: patchfile.txt
>
>
> activemq-cpp/src/main/decaf/internal/util/concurrent/unix/Atomics is not 
> compile-able under Solaris 10 with Sun Studio 11 (CC: Sun C++ 5.8 Patch 
> 121018-20).
> The Attached Patch Fixed:
> - Atomics::compareAndSet32 and Atomics::compareAndSet is not working as 
> expected and will caused the IOTransport not started correctly
> - CC Compiler Errors

--
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

[jira] [Updated] (AMQCPP-475) Fix for Atomics Helper for Solaris 10

2013-04-08 Thread Jeremy Leung (JIRA)


 [ 
https://issues.apache.org/jira/browse/AMQCPP-475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Leung updated AMQCPP-475:


Summary: Fix for Atomics Helper for Solaris 10  (was: Fix for Atomics 
Helper for Solaris)

> Fix for Atomics Helper for Solaris 10
> -
>
> Key: AMQCPP-475
> URL: https://issues.apache.org/jira/browse/AMQCPP-475
> Project: ActiveMQ C++ Client
>  Issue Type: Bug
>  Components: Decaf
>Affects Versions: 3.6.0
> Environment: Solaris 10
>Reporter: Jeremy Leung
>Assignee: Timothy Bish
>Priority: Blocker
> Attachments: patchfile.txt
>
>


--
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

[jira] [Updated] (AMQCPP-475) Fix for Atomics Helper for Solaris

2013-04-08 Thread Jeremy Leung (JIRA)


 [ 
https://issues.apache.org/jira/browse/AMQCPP-475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Leung updated AMQCPP-475:


Attachment: patchfile.txt

activemq-cpp/src/main/decaf/internal/util/concurrent/unix

> Fix for Atomics Helper for Solaris
> --
>
> Key: AMQCPP-475
> URL: https://issues.apache.org/jira/browse/AMQCPP-475
> Project: ActiveMQ C++ Client
>  Issue Type: Bug
>  Components: Decaf
>Affects Versions: 3.6.0
> Environment: Solaris 10
>Reporter: Jeremy Leung
>Assignee: Timothy Bish
>Priority: Blocker
> Attachments: patchfile.txt
>
>


--
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

[jira] [Created] (AMQCPP-475) Fix for Atomics Helper for Solaris

2013-04-08 Thread Jeremy Leung (JIRA)

Jeremy Leung created AMQCPP-475:
---

 Summary: Fix for Atomics Helper for Solaris
 Key: AMQCPP-475
 URL: https://issues.apache.org/jira/browse/AMQCPP-475
 Project: ActiveMQ C++ Client
  Issue Type: Bug
  Components: Decaf
Affects Versions: 3.6.0
 Environment: Solaris 10
Reporter: Jeremy Leung
Assignee: Timothy Bish
Priority: Blocker




--
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

57 matches

Mail list logo