Re: [AMQ-CPP] Issues with 3.2.1
Hi Tim, I will try this in the afternoon. I also did some tests yesterday (cf. same post on the activemq users mailing list). I'll keep you informed. On Saturday, July 17, 2010, Timothy Bish wrote: > On Fri, 2010-07-16 at 11:48 +0800, Romain CHANU wrote: >> Hi, >> >> I am currently upgrading my client from 3.1.0 to 3.2.1. >> >> The environment used is very broad: >> >> - Centos 5.3 (gcc 4.1.2, APR 1.3.9, APR-util 1.3.9) >> - Debian 5.0 (gcc 4.3.2, APR 1.3.5, APR-util 1.3.7) >> - Fedora 11 (gcc 4.4.0, APR 1.3.5, APR-util 1.3.9) >> - Ubuntu 10.04 (gcc 4.4.3, APR 1.3.8, APR-util 1.3.9) >> >> The compilation works whatever the environment used :-) >> >> However, I am facing major issues: >> >> 1) On Centos 5.3 and Debian 5.0, "make check" fails: >> >> (error reported from Centos 5.3) >> >> g++ -DHAVE_CONFIG_H -I. -I../.. -ansi -pedantic -DLINUX=2 -D_REENTRANT >> -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -I/usr/local/apr/include/apr-1 >> -I/usr/local/apr/include/apr-1 -W -Wall -Wextra -Wconversion -fPIC >> -fstrict-aliasing -Wstrict-aliasing=2 -Wno-long-long -DLINUX=2 >> -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE >> -I/usr/local/apr/include/apr-1 -I/usr/local/apr/include/apr-1 >> -Wno-non-virtual-dtor -Wno-unused-parameter -Wno-uninitialized -I./../main >> -I/usr/local/include -g -O2 -pthread -MT >> activemq/test/activemq_test_integration-MessageCompressionTest.o -MD -MP -MF >> activemq/test/.deps/activemq_test_integration-MessageCompressionTest.Tpo -c >> -o activemq/test/activemq_test_integration-MessageCompressionTest.o `test -f >> 'activemq/test/MessageCompressionTest.cpp' || echo >> './'`activemq/test/MessageCompressionTest.cpp >> activemq/test/MessageCompressionTest.cpp:63: error: integer constant is too >> large for ‘long’ type >> activemq/test/MessageCompressionTest.cpp:69: error: integer constant is too >> large for ‘long’ type >> >> >> 2) I tried to run the examples provided in the package: >> >> - On Centos 5.3 and Debian 5.0, none of the examples worked... I got a >> "segmentation fault" >> >> - On Fedora 11 and Ubuntu 10.04, all the examples worked. >> >> >> Do you have any idea on what's going on? >> >> >> Thank you. >> >> Regards, >> >> Romain > > Can you try with the latest code in the ActiveMQ-CPP 3.2.x fixes branch > and let me know if its still segfaulting? > > The SVN location is here: > https://svn.apache.org/repos/asf/activemq/activemq-cpp/branches/activemq-cpp-3.2.x > > > Regards > > > -- > Tim Bish > > Open Source Integration: http://fusesource.com > ActiveMQ in Action: http://www.manning.com/snyder/ > > Follow me on Twitter: http://twitter.com/tabish121 > My Blog: http://timbish.blogspot.com/ > >
André Dittrich ist außer Haus.
Ich werde ab 17.07.2010 nicht im Büro sein. Ich kehre zurück am 26.07.2010.
[jira] Updated: (AMQ-2833) Fix to STOMP Transport fixing message type selection
[ https://issues.apache.org/activemq/browse/AMQ-2833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Eschbach updated AMQ-2833: --- Original Estimate: (was: 20 minutes) Remaining Estimate: (was: 20 minutes) I cleared the estimated time as I misunderstood what the field would indicate. > Fix to STOMP Transport fixing message type selection > > > Key: AMQ-2833 > URL: https://issues.apache.org/activemq/browse/AMQ-2833 > Project: ActiveMQ > Issue Type: Improvement > Components: Transport > Environment: STOMP clients which always sets the content-length > header in out going messages >Reporter: Mark Eschbach >Priority: Minor > Attachments: stomp-msg-type.patch > > > Ruby's STOMP client always sets the content-length header and does not > provide a mechanism to override the behavior. In addition, the 1.0 STOMP > specification states the content-length header is optional but recommended. > I implemented the feature discussed in AMQ-739 utilizing the 'amq-msg-type' > header to select the message type. I've only implemented 'text' and 'byte' > message types. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (AMQ-2833) Fix to STOMP Transport fixing message type selection
[ https://issues.apache.org/activemq/browse/AMQ-2833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Eschbach updated AMQ-2833: --- Attachment: stomp-msg-type.patch This patch provides the describe 'amq-msg-type' feature. > Fix to STOMP Transport fixing message type selection > > > Key: AMQ-2833 > URL: https://issues.apache.org/activemq/browse/AMQ-2833 > Project: ActiveMQ > Issue Type: Improvement > Components: Transport > Environment: STOMP clients which always sets the content-length > header in out going messages >Reporter: Mark Eschbach >Priority: Minor > Attachments: stomp-msg-type.patch > > Original Estimate: 20 minutes > Remaining Estimate: 20 minutes > > Ruby's STOMP client always sets the content-length header and does not > provide a mechanism to override the behavior. In addition, the 1.0 STOMP > specification states the content-length header is optional but recommended. > I implemented the feature discussed in AMQ-739 utilizing the 'amq-msg-type' > header to select the message type. I've only implemented 'text' and 'byte' > message types. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (AMQNET-263) Upgrade to NUnit 2.5.5
[ https://issues.apache.org/activemq/browse/AMQNET-263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=60713#action_60713 ] Timothy Bish commented on AMQNET-263: - Under Mono NUnit 2.5.5 doesn't seem usable. > Upgrade to NUnit 2.5.5 > -- > > Key: AMQNET-263 > URL: https://issues.apache.org/activemq/browse/AMQNET-263 > Project: ActiveMQ .Net > Issue Type: Test > Components: ActiveMQ, EMS, MSMQ, NMS, Stomp, WCF >Affects Versions: 1.4.0 >Reporter: Jim Gomes >Assignee: Jim Gomes > Fix For: 1.4.0 > > Original Estimate: 2 hours > Time Spent: 3 hours, 30 minutes > Remaining Estimate: 0 minutes > > Upgrade to the latest NUnit 2.5.5 libraries and APIs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (AMQ-2833) Fix to STOMP Transport fixing message type selection
Fix to STOMP Transport fixing message type selection Key: AMQ-2833 URL: https://issues.apache.org/activemq/browse/AMQ-2833 Project: ActiveMQ Issue Type: Improvement Components: Transport Environment: STOMP clients which always sets the content-length header in out going messages Reporter: Mark Eschbach Priority: Minor Ruby's STOMP client always sets the content-length header and does not provide a mechanism to override the behavior. In addition, the 1.0 STOMP specification states the content-length header is optional but recommended. I implemented the feature discussed in AMQ-739 utilizing the 'amq-msg-type' header to select the message type. I've only implemented 'text' and 'byte' message types. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (AMQNET-263) Upgrade to NUnit 2.5.5
[ https://issues.apache.org/activemq/browse/AMQNET-263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Gomes resolved AMQNET-263. -- Resolution: Fixed > Upgrade to NUnit 2.5.5 > -- > > Key: AMQNET-263 > URL: https://issues.apache.org/activemq/browse/AMQNET-263 > Project: ActiveMQ .Net > Issue Type: Test > Components: ActiveMQ, EMS, MSMQ, NMS, Stomp, WCF >Affects Versions: 1.4.0 >Reporter: Jim Gomes >Assignee: Jim Gomes > Fix For: 1.4.0 > > Original Estimate: 2 hours > Time Spent: 3 hours, 30 minutes > Remaining Estimate: 0 minutes > > Upgrade to the latest NUnit 2.5.5 libraries and APIs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Work logged: (AMQNET-263) Upgrade to NUnit 2.5.5
[ https://issues.apache.org/activemq/browse/AMQNET-263?page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#action_36922 ] Jim Gomes logged work on AMQNET-263: Author: Jim Gomes Created on: 16/Jul/10 06:10 PM Start Date: 16/Jul/10 06:10 PM Worklog Time Spent: 3 hours, 30 minutes Issue Time Tracking --- Remaining Estimate: 0 minutes (was: 2 hours) Time Spent: 3 hours, 30 minutes > Upgrade to NUnit 2.5.5 > -- > > Key: AMQNET-263 > URL: https://issues.apache.org/activemq/browse/AMQNET-263 > Project: ActiveMQ .Net > Issue Type: Test > Components: ActiveMQ, EMS, MSMQ, NMS, Stomp, WCF >Affects Versions: 1.4.0 >Reporter: Jim Gomes >Assignee: Jim Gomes > Fix For: 1.4.0 > > Original Estimate: 2 hours > Time Spent: 3 hours, 30 minutes > Remaining Estimate: 0 minutes > > Upgrade to the latest NUnit 2.5.5 libraries and APIs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [AMQ-CPP] Issues with 3.2.1
On Fri, 2010-07-16 at 11:48 +0800, Romain CHANU wrote: > Hi, > > I am currently upgrading my client from 3.1.0 to 3.2.1. > > The environment used is very broad: > > - Centos 5.3 (gcc 4.1.2, APR 1.3.9, APR-util 1.3.9) > - Debian 5.0 (gcc 4.3.2, APR 1.3.5, APR-util 1.3.7) > - Fedora 11 (gcc 4.4.0, APR 1.3.5, APR-util 1.3.9) > - Ubuntu 10.04 (gcc 4.4.3, APR 1.3.8, APR-util 1.3.9) > > The compilation works whatever the environment used :-) > > However, I am facing major issues: > > 1) On Centos 5.3 and Debian 5.0, "make check" fails: > > (error reported from Centos 5.3) > > g++ -DHAVE_CONFIG_H -I. -I../..-ansi -pedantic -DLINUX=2 -D_REENTRANT > -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -I/usr/local/apr/include/apr-1 > -I/usr/local/apr/include/apr-1 -W -Wall -Wextra -Wconversion -fPIC > -fstrict-aliasing -Wstrict-aliasing=2 -Wno-long-long -DLINUX=2 > -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE > -I/usr/local/apr/include/apr-1 -I/usr/local/apr/include/apr-1 > -Wno-non-virtual-dtor -Wno-unused-parameter -Wno-uninitialized -I./../main > -I/usr/local/include -g -O2 -pthread -MT > activemq/test/activemq_test_integration-MessageCompressionTest.o -MD -MP -MF > activemq/test/.deps/activemq_test_integration-MessageCompressionTest.Tpo -c > -o activemq/test/activemq_test_integration-MessageCompressionTest.o `test -f > 'activemq/test/MessageCompressionTest.cpp' || echo > './'`activemq/test/MessageCompressionTest.cpp > activemq/test/MessageCompressionTest.cpp:63: error: integer constant is too > large for ‘long’ type > activemq/test/MessageCompressionTest.cpp:69: error: integer constant is too > large for ‘long’ type > > > 2) I tried to run the examples provided in the package: > > - On Centos 5.3 and Debian 5.0, none of the examples worked... I got a > "segmentation fault" > > - On Fedora 11 and Ubuntu 10.04, all the examples worked. > > > Do you have any idea on what's going on? > > > Thank you. > > Regards, > > Romain Can you try with the latest code in the ActiveMQ-CPP 3.2.x fixes branch and let me know if its still segfaulting? The SVN location is here: https://svn.apache.org/repos/asf/activemq/activemq-cpp/branches/activemq-cpp-3.2.x Regards -- Tim Bish Open Source Integration: http://fusesource.com ActiveMQ in Action: http://www.manning.com/snyder/ Follow me on Twitter: http://twitter.com/tabish121 My Blog: http://timbish.blogspot.com/
[jira] Closed: (AMQCPP-297) Deadlock in ActiveMQSession::close
[
https://issues.apache.org/activemq/browse/AMQCPP-297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy Bish closed AMQCPP-297.
---
Resolution: Duplicate
Closing since this appears to be a duplicate of AMQCPP-277 and the user hasn't
reported back on whether its still an issue. If it reappears please reopen the
issue.
> Deadlock in ActiveMQSession::close
> --
>
> Key: AMQCPP-297
> URL: https://issues.apache.org/activemq/browse/AMQCPP-297
> Project: ActiveMQ C++ Client
> Issue Type: Bug
>Affects Versions: 3.1.2
> Environment: WinXP Pro, vs2008
>Reporter: Harry Storbacka
>Assignee: Timothy Bish
>
> There seems to be a deadlock when closing a session. This can be reproduced
> using the SimpleAsyncProducer example from version 3.1.2, with the following
> loop added to main():
> for (int i=0; i<1; i++)
> {
> consumer.runConsumer();
> std::cout << "i = " << i << std::endl;
> consumer.close();
> }
> And the used broker URI was as follows:
> std::string brokerURI =
> "failover:(tcp://192.168.0.23:61616"
> "?wireFormat=openwire";
> "&transport.useAsyncSend=true"
> // "&transport.commandTracingEnabled=true"
> // "&transport.tcpTracingEnabled=true";
> "&wireFormat.tightEncodingEnabled=true"
>")";
> The deadlock has usually appeared before the counter reaches 150. No messages
> are sent while the example runs.
> I'll try this again with version 3.2.1 when the windows build files are
> included. This example also reproduces the setMessageListener deadlock
> reported in another bug for version 3.1.2, except with only one message
> listener being set.
> Below are the callstacks of the threads when it's locked.
> ---
> ntdll.dll!7c90e514()
> [Frames below may be incorrect and/or missing, no symbols loaded for
> ntdll.dll]
> ntdll.dll!7c90df5a()
> kernel32.dll!7c8025db()
> kernel32.dll!7c802542()
>
> AsyncConsumer.exe!decaf::internal::util::concurrent::ConditionImpl::wait(decaf::util::concurrent::ConditionHandle
> * condition=0x011d6718, __int64 mills=4294967295, __int64 nanos=0) Line 110
> + 0x10 bytes C++
> AsyncConsumer.exe!decaf::util::concurrent::Mutex::wait(__int64
> millisecs=4294967295, int nanos=0) Line 124 + 0x20 bytesC++
> AsyncConsumer.exe!decaf::lang::Thread::join(__int64
> millisecs=4294967295, unsigned int nanos=0) Line 464 + 0x36 bytes C++
> AsyncConsumer.exe!decaf::lang::Thread::join() Line 421 C++
> AsyncConsumer.exe!activemq::threads::DedicatedTaskRunner::shutdown()
> Line 83 C++
> AsyncConsumer.exe!activemq::core::ActiveMQSessionExecutor::stop() Line
> 110 C++
> AsyncConsumer.exe!activemq::core::ActiveMQSession::stop() Line 807
> C++
> > AsyncConsumer.exe!activemq::core::ActiveMQSession::close() Line 126
> > C++
> AsyncConsumer.exe!SimpleAsyncConsumer::cleanup() Line 198 C++
> AsyncConsumer.exe!SimpleAsyncConsumer::close() Line 86 C++
> AsyncConsumer.exe!main(int argc=1, char * * argv=0x01036618) Line 280
> C++
> AsyncConsumer.exe!__tmainCRTStartup() Line 586 + 0x19 bytesC
> AsyncConsumer.exe!mainCRTStartup() Line 403C
>
> ntdll.dll!7c90e514()
> [Frames below may be incorrect and/or missing, no symbols loaded for
> ntdll.dll]
> ntdll.dll!7c90df5a()
> kernel32.dll!7c8025db()
> kernel32.dll!7c802542()
>
> AsyncConsumer.exe!decaf::internal::util::concurrent::ConditionImpl::wait(decaf::util::concurrent::ConditionHandle
> * condition=0x011d0430, __int64 mills=4294967295, __int64 nanos=0) Line 110
> + 0x10 bytes C++
>
> AsyncConsumer.exe!decaf::internal::util::concurrent::ConditionImpl::wait(decaf::util::concurrent::ConditionHandle
> * condition=0x011d0430) Line 71 + 0x11 bytes C++
> AsyncConsumer.exe!decaf::util::concurrent::Mutex::wait() Line 95 + 0xf
> bytes C++
> AsyncConsumer.exe!activemq::threads::CompositeTaskRunner::run() Line
> 119 C++
>
> AsyncConsumer.exe!decaf::lang::ThreadProperties::runCallback(decaf::lang::ThreadProperties
> * properties=0x011d0578) Line 133 + 0x11 bytes C++
> AsyncConsumer.exe!`anonymous namespace'::threadWorker(void *
> arg=0x011d0578) Line 204 + 0x9 bytes C++
> > msvcr90d.dll!_callthreadstartex() Line 348 + 0xf bytes C
> msvcr90d.dll!_threadstartex(void * ptd=0x011d0c90) Line 331C
> ---
> ntdll.dll!7c90e514()
> [Frames below may be incorrect and/or missing, no symbols loaded for
> ntdll.dll]
> ntdll.dll!7c90df5a()
> kernel32.dll!7c8025db()
> > msvcr90d.dll!
[jira] Resolved: (AMQCPP-304) SEGFAULT on shutdown
[
https://issues.apache.org/activemq/browse/AMQCPP-304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy Bish resolved AMQCPP-304.
-
Resolution: Fixed
Removed those global variables, not sure why they were there anyway.
> SEGFAULT on shutdown
>
>
> Key: AMQCPP-304
> URL: https://issues.apache.org/activemq/browse/AMQCPP-304
> Project: ActiveMQ C++ Client
> Issue Type: Bug
> Components: CMS Impl
>Affects Versions: 3.2.1
> Environment: Linux
>Reporter: Kevin Quick
>Assignee: Timothy Bish
>
> If application does not initialize (or use) ActiveMQ-CPP before exiting,
> global static elements will call apr functionality without initialization of
> same, resulting in a segfault.
> Similar issue to AMQCPP-303. This global static element is:
>activemq/commands/ActiveMQDestination.cpp:
>...
>util::ActiveMQProperties options;
> Test file (mqtest.cpp):
>#include
>// Normally comes from library include: explicit here facilitate problem
> demonstration
>#include
>int main(int, char**)
>{
> std::cout << "Hello" << std::endl;
>}
> To reproduce:
> $ gdb mqtest
> ...
> (gdb) r
> Starting program:
> /Mount/Work/per_mbus/persephone_trunk/pjs/nexus_handlers/mbus/mqtest
> [Thread debugging using libthread_db enabled]
> Hello
> Program received signal SIGSEGV, Segmentation fault.
> 0x080c0835 in mutex_hash (mem=0x80e386c) at atomic/unix/mutex.c:78
> 78 apr_thread_mutex_t *mutex = hash_mutex[ATOMIC_HASH(mem)];
> Current language: auto
> The current source language is "auto; currently c".
> (gdb) bt
> #0 0x080c0835 in mutex_hash (mem=0x80e386c) at atomic/unix/mutex.c:78
> #1 0x080c0864 in apr_atomic_add32 (mem=0x80e386c, val=4294967295) at
> atomic/unix/mutex.c:113
> #2 0x0808630c in
> decaf::util::concurrent::atomic::AtomicInteger::decrementAndGet
> (this=0x80e3868) at decaf/util/concurrent/atomic/AtomicInteger.cpp:69
> #3 0x08056e86 in decaf::util::concurrent::atomic::AtomicRefCounter::release
> (this=0x80e285c)
> at
> /Files/Compile/Sources/activemq-cpp-library-3.2.1/src/main/decaf/util/concurrent/atomic/AtomicRefCounter.h:68
> #4 0x0808450d in ~Pointer (this=0x80e285c, __in_chrg=)
> at ./decaf/lang/Pointer.h:143
> #5 0x0808151e in ~Properties (this=0x80e2854, __in_chrg= out>) at decaf/util/Properties.cpp:133
> #6 0x0805cae1 in ~ActiveMQProperties (this=0x80e2850, __in_chrg= optimized out>) at activemq/util/ActiveMQProperties.cpp:31
> #7 0x08054c00 in __tcf_17 () at
> /Files/Compile/Sources/activemq-cpp-library-3.2.1/src/main/activemq/commands/ActiveMQDestination.cpp:59
> #8 0xb7b2b529 in exit () from /System/Links/Libraries/libc.so.6
> (gdb)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (AMQCPP-304) SEGFAULT on shutdown
[
https://issues.apache.org/activemq/browse/AMQCPP-304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=60709#action_60709
]
Kevin Quick commented on AMQCPP-304:
Examples:
Cmdline argument parsing (e.g. getopt) detects an error: application exits
rather than attempting to do anything with bad input.
User requests a help/usage on the command line (e.g. --help). Application
displays help information, then exits without doing anything else.
etc...
> SEGFAULT on shutdown
>
>
> Key: AMQCPP-304
> URL: https://issues.apache.org/activemq/browse/AMQCPP-304
> Project: ActiveMQ C++ Client
> Issue Type: Bug
> Components: CMS Impl
>Affects Versions: 3.2.1
> Environment: Linux
>Reporter: Kevin Quick
>Assignee: Timothy Bish
>
> If application does not initialize (or use) ActiveMQ-CPP before exiting,
> global static elements will call apr functionality without initialization of
> same, resulting in a segfault.
> Similar issue to AMQCPP-303. This global static element is:
>activemq/commands/ActiveMQDestination.cpp:
>...
>util::ActiveMQProperties options;
> Test file (mqtest.cpp):
>#include
>// Normally comes from library include: explicit here facilitate problem
> demonstration
>#include
>int main(int, char**)
>{
> std::cout << "Hello" << std::endl;
>}
> To reproduce:
> $ gdb mqtest
> ...
> (gdb) r
> Starting program:
> /Mount/Work/per_mbus/persephone_trunk/pjs/nexus_handlers/mbus/mqtest
> [Thread debugging using libthread_db enabled]
> Hello
> Program received signal SIGSEGV, Segmentation fault.
> 0x080c0835 in mutex_hash (mem=0x80e386c) at atomic/unix/mutex.c:78
> 78 apr_thread_mutex_t *mutex = hash_mutex[ATOMIC_HASH(mem)];
> Current language: auto
> The current source language is "auto; currently c".
> (gdb) bt
> #0 0x080c0835 in mutex_hash (mem=0x80e386c) at atomic/unix/mutex.c:78
> #1 0x080c0864 in apr_atomic_add32 (mem=0x80e386c, val=4294967295) at
> atomic/unix/mutex.c:113
> #2 0x0808630c in
> decaf::util::concurrent::atomic::AtomicInteger::decrementAndGet
> (this=0x80e3868) at decaf/util/concurrent/atomic/AtomicInteger.cpp:69
> #3 0x08056e86 in decaf::util::concurrent::atomic::AtomicRefCounter::release
> (this=0x80e285c)
> at
> /Files/Compile/Sources/activemq-cpp-library-3.2.1/src/main/decaf/util/concurrent/atomic/AtomicRefCounter.h:68
> #4 0x0808450d in ~Pointer (this=0x80e285c, __in_chrg=)
> at ./decaf/lang/Pointer.h:143
> #5 0x0808151e in ~Properties (this=0x80e2854, __in_chrg= out>) at decaf/util/Properties.cpp:133
> #6 0x0805cae1 in ~ActiveMQProperties (this=0x80e2850, __in_chrg= optimized out>) at activemq/util/ActiveMQProperties.cpp:31
> #7 0x08054c00 in __tcf_17 () at
> /Files/Compile/Sources/activemq-cpp-library-3.2.1/src/main/activemq/commands/ActiveMQDestination.cpp:59
> #8 0xb7b2b529 in exit () from /System/Links/Libraries/libc.so.6
> (gdb)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (AMQ-1715) Still getting STOMP Client connect error in AMQ 5.1.0 Release
[ https://issues.apache.org/activemq/browse/AMQ-1715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish closed AMQ-1715. - Resolution: Cannot Reproduce I've tested some simillar problem reports this week and cannot reproduce this using the latest AMQ broker and NMS clients. If the problem is still present then a Test case and instructions for reproducing the error would be helpful. > Still getting STOMP Client connect error in AMQ 5.1.0 Release > -- > > Key: AMQ-1715 > URL: https://issues.apache.org/activemq/browse/AMQ-1715 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.1.0 > Environment: Sun Solaris 10 >Reporter: vik dhawan > Fix For: NEEDS_REVIEWED > > > I started getting this following error again in AMQ 5.1.0 stable release. I > used to get this error on 4.1.0 and 5.0.0. This error disapeard for a while > in AMQ 4.1.2 but came back again in 5.1.0. > My client also gets this exception. at the AMQ side it shows up as a WARN but > to the C STOMP client it goes an ugly java stacktrace. > AMQ Log: > javax.jms.InvalidClientIDException: Broker: localhost - Client: > WRK_batch01_9121 already connected from /xx.xxx.xxx.xx:51577 > at > org.apache.activemq.broker.region.RegionBroker.addConnection(RegionBroker.java:211) > at > org.apache.activemq.broker.BrokerFilter.addConnection(BrokerFilter.java:81) > at > org.apache.activemq.advisory.AdvisoryBroker.addConnection(AdvisoryBroker.java:75) > at > org.apache.activemq.broker.BrokerFilter.addConnection(BrokerFilter.java:81) > at > org.apache.activemq.broker.MutableBrokerFilter.addConnection(MutableBrokerFilter.java:88) > at > org.apache.activemq.broker.TransportConnection.processAddConnection(TransportConnection.java:662) > at > org.apache.activemq.broker.jmx.ManagedTransportConnection.processAddConnection(ManagedTransportConnection.java:86) > at > org.apache.activemq.command.ConnectionInfo.visit(ConnectionInfo.java:125) > at > org.apache.activemq.broker.TransportConnection.service(TransportConnection.java:292) > at > org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:180) > at > org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:68) > at > org.apache.activemq.transport.stomp.StompTransportFilter.sendToActiveMQ(StompTransportFilter.java:80) > at > org.apache.activemq.transport.stomp.ProtocolConverter.sendToActiveMQ(ProtocolConverter.java:134) > at > org.apache.activemq.transport.stomp.ProtocolConverter.onStompConnect(ProtocolConverter.java:461) > at > org.apache.activemq.transport.stomp.ProtocolConverter.onStompCommad(ProtocolConverter.java:186) > at > org.apache.activemq.transport.stomp.StompTransportFilter.onCommand(StompTransportFilter.java:70) > at > org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:84) > at > org.apache.activemq.transport.tcp.TcpTransport.doRun(TcpTransport.java:196) > at > org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:183) > at java.lang.Thread.run(Thread.java:619) > C STOMP Client END: > Response: ERROR, javax.jms.InvalidClientIDException: Broker: localhost - > Client: WRK_batch01_9121 already connected from /xx.xxx.xxx.xx:51577 > at > org.apache.activemq.broker.region.RegionBroker.addConnection(RegionBroker.java:211) > at > org.apache.activemq.broker.BrokerFilter.addConnection(BrokerFilter.java:81) > at > org.apache.activemq.advisory.AdvisoryBroker.addConnection(AdvisoryBroker.java:75) > at > org.apache.activemq.broker.BrokerFilter.addConnection(BrokerFilter.java:81) > at > org.apache.activemq.broker.MutableBrokerFilter.addConnection(MutableBrokerFilter.java:88) > at > org.apache.activemq.broker.TransportConnection.processAddConnection(TransportConnection.java:662) > at > org.apache.activemq.broker.jmx.ManagedTransportConnection.processAddConnection(ManagedTransportConnection.java:86) >at > org.apache.activemq.command.ConnectionInfo.visit(ConnectionInfo.java:125) > at > org.apache.activemq.broker.TransportConnection.service(TransportConnection.java:292) > at > org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:180) > at > org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:68) > at > org.apache.activemq.transport.stomp.StompTransportFilter.sendToActiveMQ(StompTransportFilter.java:80) > at > org.apache.activemq.transport.stomp.ProtocolConverter.sendToActiveMQ(ProtocolConverter.java:134) > at > org.apache.activemq.transport.stomp.ProtocolConverter.onStompConnect(Pr
[jira] Resolved: (AMQCPP-303) SEGFAULT on startup (before main)
[ https://issues.apache.org/activemq/browse/AMQCPP-303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved AMQCPP-303. - Resolution: Fixed Fixed in trunk and the 3.2.x fixes branch > SEGFAULT on startup (before main) > - > > Key: AMQCPP-303 > URL: https://issues.apache.org/activemq/browse/AMQCPP-303 > Project: ActiveMQ C++ Client > Issue Type: Bug > Components: CMS Impl >Affects Versions: 3.2.1 > Environment: Linux SMP >Reporter: Kevin Quick >Assignee: Timothy Bish >Priority: Blocker > Fix For: 3.2.2 > > > Application linked with activemq-cpp library crashes on startup before > reaching main. > The issue is that static globals are being initialized and calling apr > library functions during that initialization before apr initialization is > called (via DecafRuntime()). The DecafRuntime object has a singleton > initialization pattern which appears to be invoked from > Runtime::initializeRuntime(), which is invoked from > ActiveMQCPP::initializeLibrary() in turn from the main routine with stdargs. > To fix this, static initializers should contrive to call at least > Runtime::getRuntime() (and possibly other initializers invoked by > initializeRuntime()) before internally initializing. Alternatively, static > const elements could be handled via the singleton initialization pattern as > well such that they aren't initialized until needed... presumably after > ActiveMQCPP::initializeLibrary() has been invoked in a deterministic manner. > The offending static initializers in this case are from > decaf/net/InetAddress.cpp: > const InetAddress InetAddress::LOOPBACK( Inet4Address( "localhost", > InetAddress::loopbackBytes, 4 ) ); > const InetAddress InetAddress::ANY( Inet4Address( InetAddress::anyBytes, 4 ) > ); > The corresponding traceback showing this error: > $ gdb mqtest > GNU gdb (GDB) 7.0 > ... > (gdb) b main > Breakpoint 1 at 0x8085286: file mqtest.cpp line 83 > (gdb) r > Starting program: mqtest > [Thread debugging using libthread_db enabled] > Program received signal SIGSEGV, Segmentation fault. > 0x08567955 in mutex_hash (mem=0x86c7a64) at atomic/unix/mutex.c:78 > 78 apr_thread_mutex_t *mutex = hash_mutex[ATOMIC_HASH(mem)]; > Current language: auto > The current source language is "auto; currently c". > (gdb) bt > #0 0x08567955 in mutex_hash (mem=0x86c7a64) at atomic/unix/mutex.c:78 > #1 0x08567984 in apr_atomic_add32 (mem=0x86c7a64, val=4294967295) at > atomic/unix/mutex.c:113 > #2 0x0814c9a8 in > decaf::util::concurrent::atomic::AtomicInteger::decrementAndGet > (this=0x86c7a60) at decaf/util/concurrent/atomic/AtomicInteger.cpp:69 > #3 0x080e3094 in decaf::util::concurrent::atomic::AtomicRefCounter::release > (this=0xbfffaed4) at ./decaf/util/concurrent/atomic/AtomicRefCounter.h:68 > #4 0x082af1bd in ~ArrayPointer (this=0xbfffaed4, __in_chrg= out>) at ./decaf/lang/ArrayPointer.h:154 > #5 0x082afbd6 in decaf::lang::ArrayPointer decaf::util::concurrent::atomic::AtomicRefCounter>::reset (this=0xbfffaf7c, > value=0x86c8400 "\177", size=4) > at ./decaf/lang/ArrayPointer.h:171 > #6 0x082aec27 in InetAddress (this=0xbfffaf70, hostname=..., > ipAddress=0x8585c01 "\177", numBytes=4) at decaf/net/InetAddress.cpp:79 > #7 0x084dbf54 in Inet4Address (this=0xbfffaf70, hostname=..., > ipAddress=0x8585c01 "\177", numBytes=4) at decaf/net/Inet4Address.cpp:34 > #8 0x082adec3 in __static_initialization_and_destruction_0 > (__initialize_p=1, __priority=65535) at decaf/net/InetAddress.cpp:39 > #9 0x082ae005 in global constructors keyed to > _ZN5decaf3net11InetAddress13loopbackBytesE () at decaf/net/InetAddress.cpp:191 > #10 0x0856b445 in __do_global_ctors_aux () > #11 0x080746e5 in _init () > #12 0x0856b2d7 in __libc_csu_init () > (gdb) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (AMQCPP-304) SEGFAULT on shutdown
[
https://issues.apache.org/activemq/browse/AMQCPP-304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=60706#action_60706
]
Timothy Bish commented on AMQCPP-304:
-
Why would you link to the AMQCPP code and then not use it?
> SEGFAULT on shutdown
>
>
> Key: AMQCPP-304
> URL: https://issues.apache.org/activemq/browse/AMQCPP-304
> Project: ActiveMQ C++ Client
> Issue Type: Bug
> Components: CMS Impl
>Affects Versions: 3.2.1
> Environment: Linux
>Reporter: Kevin Quick
>Assignee: Timothy Bish
>
> If application does not initialize (or use) ActiveMQ-CPP before exiting,
> global static elements will call apr functionality without initialization of
> same, resulting in a segfault.
> Similar issue to AMQCPP-303. This global static element is:
>activemq/commands/ActiveMQDestination.cpp:
>...
>util::ActiveMQProperties options;
> Test file (mqtest.cpp):
>#include
>// Normally comes from library include: explicit here facilitate problem
> demonstration
>#include
>int main(int, char**)
>{
> std::cout << "Hello" << std::endl;
>}
> To reproduce:
> $ gdb mqtest
> ...
> (gdb) r
> Starting program:
> /Mount/Work/per_mbus/persephone_trunk/pjs/nexus_handlers/mbus/mqtest
> [Thread debugging using libthread_db enabled]
> Hello
> Program received signal SIGSEGV, Segmentation fault.
> 0x080c0835 in mutex_hash (mem=0x80e386c) at atomic/unix/mutex.c:78
> 78 apr_thread_mutex_t *mutex = hash_mutex[ATOMIC_HASH(mem)];
> Current language: auto
> The current source language is "auto; currently c".
> (gdb) bt
> #0 0x080c0835 in mutex_hash (mem=0x80e386c) at atomic/unix/mutex.c:78
> #1 0x080c0864 in apr_atomic_add32 (mem=0x80e386c, val=4294967295) at
> atomic/unix/mutex.c:113
> #2 0x0808630c in
> decaf::util::concurrent::atomic::AtomicInteger::decrementAndGet
> (this=0x80e3868) at decaf/util/concurrent/atomic/AtomicInteger.cpp:69
> #3 0x08056e86 in decaf::util::concurrent::atomic::AtomicRefCounter::release
> (this=0x80e285c)
> at
> /Files/Compile/Sources/activemq-cpp-library-3.2.1/src/main/decaf/util/concurrent/atomic/AtomicRefCounter.h:68
> #4 0x0808450d in ~Pointer (this=0x80e285c, __in_chrg=)
> at ./decaf/lang/Pointer.h:143
> #5 0x0808151e in ~Properties (this=0x80e2854, __in_chrg= out>) at decaf/util/Properties.cpp:133
> #6 0x0805cae1 in ~ActiveMQProperties (this=0x80e2850, __in_chrg= optimized out>) at activemq/util/ActiveMQProperties.cpp:31
> #7 0x08054c00 in __tcf_17 () at
> /Files/Compile/Sources/activemq-cpp-library-3.2.1/src/main/activemq/commands/ActiveMQDestination.cpp:59
> #8 0xb7b2b529 in exit () from /System/Links/Libraries/libc.so.6
> (gdb)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (AMQCPP-304) SEGFAULT on shutdown
SEGFAULT on shutdown
Key: AMQCPP-304
URL: https://issues.apache.org/activemq/browse/AMQCPP-304
Project: ActiveMQ C++ Client
Issue Type: Bug
Components: CMS Impl
Affects Versions: 3.2.1
Environment: Linux
Reporter: Kevin Quick
Assignee: Timothy Bish
If application does not initialize (or use) ActiveMQ-CPP before exiting, global
static elements will call apr functionality without initialization of same,
resulting in a segfault.
Similar issue to AMQCPP-303. This global static element is:
activemq/commands/ActiveMQDestination.cpp:
...
util::ActiveMQProperties options;
Test file (mqtest.cpp):
#include
// Normally comes from library include: explicit here facilitate problem
demonstration
#include
int main(int, char**)
{
std::cout << "Hello" << std::endl;
}
To reproduce:
$ gdb mqtest
...
(gdb) r
Starting program:
/Mount/Work/per_mbus/persephone_trunk/pjs/nexus_handlers/mbus/mqtest
[Thread debugging using libthread_db enabled]
Hello
Program received signal SIGSEGV, Segmentation fault.
0x080c0835 in mutex_hash (mem=0x80e386c) at atomic/unix/mutex.c:78
78 apr_thread_mutex_t *mutex = hash_mutex[ATOMIC_HASH(mem)];
Current language: auto
The current source language is "auto; currently c".
(gdb) bt
#0 0x080c0835 in mutex_hash (mem=0x80e386c) at atomic/unix/mutex.c:78
#1 0x080c0864 in apr_atomic_add32 (mem=0x80e386c, val=4294967295) at
atomic/unix/mutex.c:113
#2 0x0808630c in
decaf::util::concurrent::atomic::AtomicInteger::decrementAndGet
(this=0x80e3868) at decaf/util/concurrent/atomic/AtomicInteger.cpp:69
#3 0x08056e86 in decaf::util::concurrent::atomic::AtomicRefCounter::release
(this=0x80e285c)
at
/Files/Compile/Sources/activemq-cpp-library-3.2.1/src/main/decaf/util/concurrent/atomic/AtomicRefCounter.h:68
#4 0x0808450d in ~Pointer (this=0x80e285c, __in_chrg=) at
./decaf/lang/Pointer.h:143
#5 0x0808151e in ~Properties (this=0x80e2854, __in_chrg=)
at decaf/util/Properties.cpp:133
#6 0x0805cae1 in ~ActiveMQProperties (this=0x80e2850, __in_chrg=) at activemq/util/ActiveMQProperties.cpp:31
#7 0x08054c00 in __tcf_17 () at
/Files/Compile/Sources/activemq-cpp-library-3.2.1/src/main/activemq/commands/ActiveMQDestination.cpp:59
#8 0xb7b2b529 in exit () from /System/Links/Libraries/libc.so.6
(gdb)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (AMQ-2574) Try to stop OSGi bundle when closing application context
[
https://issues.apache.org/activemq/browse/AMQ-2574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dejan Bosanac resolved AMQ-2574.
Resolution: Fixed
Fixed with svn revision 964847
Incidentally, destroyApplicationContextOnStop and
destroyApplicationContextOnShutdown broker attributes became obsolete and we
should use shutdown hooks instead, like
{code}
http://www.springframework.org/schema/beans"; id="hook"
class="org.apache.activemq.hooks.SpringContextHook" />
{code}
More stuff for blueprint support, refactorings and documentation is coming.
> Try to stop OSGi bundle when closing application context
>
>
> Key: AMQ-2574
> URL: https://issues.apache.org/activemq/browse/AMQ-2574
> Project: ActiveMQ
> Issue Type: Improvement
> Components: Broker
>Affects Versions: 5.3.0
>Reporter: Dejan Bosanac
>Assignee: Dejan Bosanac
> Fix For: 5.4.0, 5.3.1
>
>
> When using destroyApplicationContextOnShutdown="true", ActiveMQ will try to
> close application context when error such as database down is encountered.
> This will allow it to be cleanly stopped in an environment such as
> ServiceMix. However, when the broker is started as an OSGi bundle, the bundle
> will be left in status "started" event when the context is destroyed. We
> should try to stop the appropriate bundle in this case.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (AMQCPP-303) SEGFAULT on startup (before main)
[ https://issues.apache.org/activemq/browse/AMQCPP-303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish updated AMQCPP-303: Fix Version/s: 3.2.2 Good find, forgot those were even there. > SEGFAULT on startup (before main) > - > > Key: AMQCPP-303 > URL: https://issues.apache.org/activemq/browse/AMQCPP-303 > Project: ActiveMQ C++ Client > Issue Type: Bug > Components: CMS Impl >Affects Versions: 3.2.1 > Environment: Linux SMP >Reporter: Kevin Quick >Assignee: Timothy Bish >Priority: Blocker > Fix For: 3.2.2 > > > Application linked with activemq-cpp library crashes on startup before > reaching main. > The issue is that static globals are being initialized and calling apr > library functions during that initialization before apr initialization is > called (via DecafRuntime()). The DecafRuntime object has a singleton > initialization pattern which appears to be invoked from > Runtime::initializeRuntime(), which is invoked from > ActiveMQCPP::initializeLibrary() in turn from the main routine with stdargs. > To fix this, static initializers should contrive to call at least > Runtime::getRuntime() (and possibly other initializers invoked by > initializeRuntime()) before internally initializing. Alternatively, static > const elements could be handled via the singleton initialization pattern as > well such that they aren't initialized until needed... presumably after > ActiveMQCPP::initializeLibrary() has been invoked in a deterministic manner. > The offending static initializers in this case are from > decaf/net/InetAddress.cpp: > const InetAddress InetAddress::LOOPBACK( Inet4Address( "localhost", > InetAddress::loopbackBytes, 4 ) ); > const InetAddress InetAddress::ANY( Inet4Address( InetAddress::anyBytes, 4 ) > ); > The corresponding traceback showing this error: > $ gdb mqtest > GNU gdb (GDB) 7.0 > ... > (gdb) b main > Breakpoint 1 at 0x8085286: file mqtest.cpp line 83 > (gdb) r > Starting program: mqtest > [Thread debugging using libthread_db enabled] > Program received signal SIGSEGV, Segmentation fault. > 0x08567955 in mutex_hash (mem=0x86c7a64) at atomic/unix/mutex.c:78 > 78 apr_thread_mutex_t *mutex = hash_mutex[ATOMIC_HASH(mem)]; > Current language: auto > The current source language is "auto; currently c". > (gdb) bt > #0 0x08567955 in mutex_hash (mem=0x86c7a64) at atomic/unix/mutex.c:78 > #1 0x08567984 in apr_atomic_add32 (mem=0x86c7a64, val=4294967295) at > atomic/unix/mutex.c:113 > #2 0x0814c9a8 in > decaf::util::concurrent::atomic::AtomicInteger::decrementAndGet > (this=0x86c7a60) at decaf/util/concurrent/atomic/AtomicInteger.cpp:69 > #3 0x080e3094 in decaf::util::concurrent::atomic::AtomicRefCounter::release > (this=0xbfffaed4) at ./decaf/util/concurrent/atomic/AtomicRefCounter.h:68 > #4 0x082af1bd in ~ArrayPointer (this=0xbfffaed4, __in_chrg= out>) at ./decaf/lang/ArrayPointer.h:154 > #5 0x082afbd6 in decaf::lang::ArrayPointer decaf::util::concurrent::atomic::AtomicRefCounter>::reset (this=0xbfffaf7c, > value=0x86c8400 "\177", size=4) > at ./decaf/lang/ArrayPointer.h:171 > #6 0x082aec27 in InetAddress (this=0xbfffaf70, hostname=..., > ipAddress=0x8585c01 "\177", numBytes=4) at decaf/net/InetAddress.cpp:79 > #7 0x084dbf54 in Inet4Address (this=0xbfffaf70, hostname=..., > ipAddress=0x8585c01 "\177", numBytes=4) at decaf/net/Inet4Address.cpp:34 > #8 0x082adec3 in __static_initialization_and_destruction_0 > (__initialize_p=1, __priority=65535) at decaf/net/InetAddress.cpp:39 > #9 0x082ae005 in global constructors keyed to > _ZN5decaf3net11InetAddress13loopbackBytesE () at decaf/net/InetAddress.cpp:191 > #10 0x0856b445 in __do_global_ctors_aux () > #11 0x080746e5 in _init () > #12 0x0856b2d7 in __libc_csu_init () > (gdb) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (AMQCPP-303) SEGFAULT on startup (before main)
SEGFAULT on startup (before main) - Key: AMQCPP-303 URL: https://issues.apache.org/activemq/browse/AMQCPP-303 Project: ActiveMQ C++ Client Issue Type: Bug Components: CMS Impl Affects Versions: 3.2.1 Environment: Linux SMP Reporter: Kevin Quick Assignee: Timothy Bish Priority: Blocker Application linked with activemq-cpp library crashes on startup before reaching main. The issue is that static globals are being initialized and calling apr library functions during that initialization before apr initialization is called (via DecafRuntime()). The DecafRuntime object has a singleton initialization pattern which appears to be invoked from Runtime::initializeRuntime(), which is invoked from ActiveMQCPP::initializeLibrary() in turn from the main routine with stdargs. To fix this, static initializers should contrive to call at least Runtime::getRuntime() (and possibly other initializers invoked by initializeRuntime()) before internally initializing. Alternatively, static const elements could be handled via the singleton initialization pattern as well such that they aren't initialized until needed... presumably after ActiveMQCPP::initializeLibrary() has been invoked in a deterministic manner. The offending static initializers in this case are from decaf/net/InetAddress.cpp: const InetAddress InetAddress::LOOPBACK( Inet4Address( "localhost", InetAddress::loopbackBytes, 4 ) ); const InetAddress InetAddress::ANY( Inet4Address( InetAddress::anyBytes, 4 ) ); The corresponding traceback showing this error: $ gdb mqtest GNU gdb (GDB) 7.0 ... (gdb) b main Breakpoint 1 at 0x8085286: file mqtest.cpp line 83 (gdb) r Starting program: mqtest [Thread debugging using libthread_db enabled] Program received signal SIGSEGV, Segmentation fault. 0x08567955 in mutex_hash (mem=0x86c7a64) at atomic/unix/mutex.c:78 78 apr_thread_mutex_t *mutex = hash_mutex[ATOMIC_HASH(mem)]; Current language: auto The current source language is "auto; currently c". (gdb) bt #0 0x08567955 in mutex_hash (mem=0x86c7a64) at atomic/unix/mutex.c:78 #1 0x08567984 in apr_atomic_add32 (mem=0x86c7a64, val=4294967295) at atomic/unix/mutex.c:113 #2 0x0814c9a8 in decaf::util::concurrent::atomic::AtomicInteger::decrementAndGet (this=0x86c7a60) at decaf/util/concurrent/atomic/AtomicInteger.cpp:69 #3 0x080e3094 in decaf::util::concurrent::atomic::AtomicRefCounter::release (this=0xbfffaed4) at ./decaf/util/concurrent/atomic/AtomicRefCounter.h:68 #4 0x082af1bd in ~ArrayPointer (this=0xbfffaed4, __in_chrg=) at ./decaf/lang/ArrayPointer.h:154 #5 0x082afbd6 in decaf::lang::ArrayPointer::reset (this=0xbfffaf7c, value=0x86c8400 "\177", size=4) at ./decaf/lang/ArrayPointer.h:171 #6 0x082aec27 in InetAddress (this=0xbfffaf70, hostname=..., ipAddress=0x8585c01 "\177", numBytes=4) at decaf/net/InetAddress.cpp:79 #7 0x084dbf54 in Inet4Address (this=0xbfffaf70, hostname=..., ipAddress=0x8585c01 "\177", numBytes=4) at decaf/net/Inet4Address.cpp:34 #8 0x082adec3 in __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535) at decaf/net/InetAddress.cpp:39 #9 0x082ae005 in global constructors keyed to _ZN5decaf3net11InetAddress13loopbackBytesE () at decaf/net/InetAddress.cpp:191 #10 0x0856b445 in __do_global_ctors_aux () #11 0x080746e5 in _init () #12 0x0856b2d7 in __libc_csu_init () (gdb) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (AMQNET-261) NMS URI handling in URISupport needs improvement.
[
https://issues.apache.org/activemq/browse/AMQNET-261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy Bish resolved AMQNET-261.
-
Resolution: Fixed
Fixed in trunk. Can now handle a wider range of Composite Uri formats. All
the Connection options specified on the Uri are now applied even when failover
is used.
> NMS URI handling in URISupport needs improvement.
> -
>
> Key: AMQNET-261
> URL: https://issues.apache.org/activemq/browse/AMQNET-261
> Project: ActiveMQ .Net
> Issue Type: Improvement
>Affects Versions: 1.3.0
>Reporter: Timothy Bish
>Assignee: Timothy Bish
> Fix For: 1.4.0
>
>
> The URI handling in NMS that allows for composite URIs and for setting
> options via the URI needs some work.
> 1. When setting options for the connection when a Failover URI is specified
> you receive and exception because the options aren't filter out based on the
> prefix, so for instance a value of connection=asyncSend=true will cause an
> exception in the failover URI case but not in a plain TCP uri case. Example:
> The following URI additional test case added to NMSConnectionFactoryTest
> should work, but it gives an exception.
> {noformat}
>
> [Row("activemq:failover:(tcp://${activemqhost}:61616)?connection.asyncSend=true")]
> {noformat}
> 2. Those referring to the AMQ docs will assume that URIs like the one's below
> should work but will get an exception instead.
> {noformat}
>
> failover://(tcp://localhost:61616,tcp://remotehost:61616)?initialReconnectDelay=100
> failover://tcp://primary:61616
> {noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (AMQ-2832) Possible replay of old messages post index recovery from journal - data files containing acks reclaimed/cleaned up in error
Possible replay of old messages post index recovery from journal - data files containing acks reclaimed/cleaned up in error --- Key: AMQ-2832 URL: https://issues.apache.org/activemq/browse/AMQ-2832 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.3.2 Reporter: Gary Tully Assignee: Gary Tully Fix For: 5.4.0 With long lived messages and outstanding acks, ack distribution can be sparse across data files. If a data file is in use (still has unreferenced messages, the data files containing acks for all those messages also need to be maintained to ensure a replay of the journal replays the corresponding acks. Currently it is possible that data files with no unreferenced messages but with acks pertinent to an in use data file can get deleted. The result is duplicate or relay of old messages after journal recovery (following a crash/restart) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (AMQ-2826) Look at the possibility of incorporating a cassandra persistence adapter from http://github.com/ticktock/qsandra
[ https://issues.apache.org/activemq/browse/AMQ-2826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=60700#action_60700 ] Scott Clasen commented on AMQ-2826: --- Could take that jdk 1.6 profile a step further, and have a seperate profile where the whole module is included only in the 1.6 profile Sort of like ...normal modules... org.apache.maven.plugins maven-compiler-plugin 1.5 1.5 1.5 jdk1.6 1.6 .all normal modles... activemq-cassandra-store org.apache.maven.plugins maven-compiler-plugin 1.6 1.6 1.6 OR just have the module sit off to the side in svn, like activemq-blaze or activemq-protobuf In the meantime I'll create a branch and pull in the cassandra thrift sources and try and build against 1.5 and run the tests against an external cassandra instance > Look at the possibility of incorporating a cassandra persistence adapter from > http://github.com/ticktock/qsandra > - > > Key: AMQ-2826 > URL: https://issues.apache.org/activemq/browse/AMQ-2826 > Project: ActiveMQ > Issue Type: New Feature > Components: Message Store >Affects Versions: 5.3.2 >Reporter: Scott Clasen > > I am the author of http://github.com/ticktock/qsandra, which is a cassandra > persistence adapter for activemq. I am willing to donate it if it is > something that is of interest to ActiveMQ.. > Only current trouble with that is it needs JDK 1.6, so it would probably need > to wait until (if and when) ActiveMQ 5.x is built with JDK 6. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (AMQ-2829) HealthCheck for hardware loadbalancers
[ https://issues.apache.org/activemq/browse/AMQ-2829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=60685#action_60685 ] Dirk Alexander Schäfer edited comment on AMQ-2829 at 7/16/10 7:59 AM: -- so we could say: it's not a bug, it's a feature... ;) was (Author: dialsc): so we could say: it's not a bug, it's feature... ;) > HealthCheck for hardware loadbalancers > -- > > Key: AMQ-2829 > URL: https://issues.apache.org/activemq/browse/AMQ-2829 > Project: ActiveMQ > Issue Type: New Feature > Components: Broker > Environment: ALL >Reporter: Dirk Alexander Schäfer >Assignee: Gary Tully >Priority: Minor > Fix For: 5.4.0 > > Attachments: com.swisscom.ei.commons.activemq.zip, jetty.xml > > > hi there, > we had the problem that we were not able to integrate our network of brokers > in our cluster setup where a hardware loadbalancer was in front of the > cluster. as the loadbalancer needs to run health checks against each node in > the cluster, we needed to find a way to offer an endpoint the loadbalancer > could send its probe requests to. > we decided to develope a little web application that returns "pong" if the > jms provider is available, "offline" else. we've created a webapp that can be > deployed in the jetty that comes with activemq. i attach the whole eclipse > project ziped to this issue. i haven't cleaned it so it will not fitt into > the activemq package hierarchy but it should be enough to get an idea of how > we did it. i also attach the modified jetty.xml were we added the webapp in > order to become it loaded. > it might look a bit oversized as it is based upon spring web mvc, spring > security and tiles but our intention was to be able to put further > administrative functionality into the web app once needed. > how it works: a consumer as well as a producer are being created during the > startup of the app. the consumer makes sure that messages get dispatched and > do not fill the queue, allthough the messages are marked none-persistence and > have a ttl of 5 secs, just to be sure. if a check request comes in > (/lbProbe/ping.htm) the app tries to put a message into the queue (the queue > name is configurable through spring). if this succeeds, the OK-result will be > returned, otherwise the NOT-OK-result. both are configurable through spring. > known bugs: if one deletes the queue the app is using through e.g. the admin > web app, the check will strill return OK. > things to beware of: the name of the queue the webapp uses should be > configured in the excludes of the networkConnector settings ;) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (AMQ-2831) Set ClientID - InvalidClientIDException with http transport
[ https://issues.apache.org/activemq/browse/AMQ-2831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Coombo Marco updated AMQ-2831: -- Attachment: broker-config.xml Broker configuration > Set ClientID - InvalidClientIDException with http transport > --- > > Key: AMQ-2831 > URL: https://issues.apache.org/activemq/browse/AMQ-2831 > Project: ActiveMQ > Issue Type: Bug > Components: Transport >Affects Versions: 5.3.2 >Reporter: Coombo Marco > Fix For: 5.4.0 > > Attachments: broker-config.xml, TestVaseClientID.zip > > > I have a client that do a durable subscriptio to a topic. > It register with a static client id. > After a connectivity loss (an so a new re-connection), this exception is > thrown and connection cannot be > re-established: > 2010-07-15 13:49:04,700 ERROR - javax.jms.InvalidClientIDException: Broker: > localhost - Client: (SchedulerId = '1') already connected from > blockingQueue_8461294 > at > org.apache.activemq.broker.region.RegionBroker.addConnection(RegionBroker.java:216) > at > org.apache.activemq.broker.BrokerFilter.addConnection(BrokerFilter.java:82) > at > org.apache.activemq.broker.BrokerFilter.addConnection(BrokerFilter.java:82) > at > org.apache.activemq.advisory.AdvisoryBroker.addConnection(AdvisoryBroker.java:77) > at > org.apache.activemq.broker.BrokerFilter.addConnection(BrokerFilter.java:82) > at > org.apache.activemq.broker.BrokerFilter.addConnection(BrokerFilter.java:82) > > This is not possible, because is the only client with that name and previos > connection was closed . .close(). > If I kill all the clients an I leave active only the broker, > If I try to reconnect using http (or tcp) I get the same error. > So client is not de-registered. > This appens also if I use failover protocol. After client kill/restart. Same > exception is raised (javax.jms.InvalidClientIDException - with the clientID > of the killed client). > I have to restart broker in order to register again the client. > A test case is attached. > If you connect to http the first time, connection is ok. > If you kill the JVM and the try to restart the test case, 'myclid already > connected from blockingQueue_' is always raised. Also after some hours. I > have to restart the broker in order to have a new conection with that client > id. > This test simulate a JVM crash with no resource cleanup. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (AMQ-2831) Set ClientID - InvalidClientIDException with http transport
[ https://issues.apache.org/activemq/browse/AMQ-2831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Coombo Marco updated AMQ-2831: -- Attachment: TestVaseClientID.zip Test case class > Set ClientID - InvalidClientIDException with http transport > --- > > Key: AMQ-2831 > URL: https://issues.apache.org/activemq/browse/AMQ-2831 > Project: ActiveMQ > Issue Type: Bug > Components: Transport >Affects Versions: 5.3.2 >Reporter: Coombo Marco > Fix For: 5.4.0 > > Attachments: TestVaseClientID.zip > > > I have a client that do a durable subscriptio to a topic. > It register with a static client id. > After a connectivity loss (an so a new re-connection), this exception is > thrown and connection cannot be > re-established: > 2010-07-15 13:49:04,700 ERROR - javax.jms.InvalidClientIDException: Broker: > localhost - Client: (SchedulerId = '1') already connected from > blockingQueue_8461294 > at > org.apache.activemq.broker.region.RegionBroker.addConnection(RegionBroker.java:216) > at > org.apache.activemq.broker.BrokerFilter.addConnection(BrokerFilter.java:82) > at > org.apache.activemq.broker.BrokerFilter.addConnection(BrokerFilter.java:82) > at > org.apache.activemq.advisory.AdvisoryBroker.addConnection(AdvisoryBroker.java:77) > at > org.apache.activemq.broker.BrokerFilter.addConnection(BrokerFilter.java:82) > at > org.apache.activemq.broker.BrokerFilter.addConnection(BrokerFilter.java:82) > > This is not possible, because is the only client with that name and previos > connection was closed . .close(). > If I kill all the clients an I leave active only the broker, > If I try to reconnect using http (or tcp) I get the same error. > So client is not de-registered. > This appens also if I use failover protocol. After client kill/restart. Same > exception is raised (javax.jms.InvalidClientIDException - with the clientID > of the killed client). > I have to restart broker in order to register again the client. > A test case is attached. > If you connect to http the first time, connection is ok. > If you kill the JVM and the try to restart the test case, 'myclid already > connected from blockingQueue_' is always raised. Also after some hours. I > have to restart the broker in order to have a new conection with that client > id. > This test simulate a JVM crash with no resource cleanup. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (AMQ-2831) Set ClientID - InvalidClientIDException with http transport
Set ClientID - InvalidClientIDException with http transport --- Key: AMQ-2831 URL: https://issues.apache.org/activemq/browse/AMQ-2831 Project: ActiveMQ Issue Type: Bug Components: Transport Affects Versions: 5.3.2 Reporter: Coombo Marco Fix For: 5.4.0 Attachments: TestVaseClientID.zip I have a client that do a durable subscriptio to a topic. It register with a static client id. After a connectivity loss (an so a new re-connection), this exception is thrown and connection cannot be re-established: 2010-07-15 13:49:04,700 ERROR - javax.jms.InvalidClientIDException: Broker: localhost - Client: (SchedulerId = '1') already connected from blockingQueue_8461294 at org.apache.activemq.broker.region.RegionBroker.addConnection(RegionBroker.java:216) at org.apache.activemq.broker.BrokerFilter.addConnection(BrokerFilter.java:82) at org.apache.activemq.broker.BrokerFilter.addConnection(BrokerFilter.java:82) at org.apache.activemq.advisory.AdvisoryBroker.addConnection(AdvisoryBroker.java:77) at org.apache.activemq.broker.BrokerFilter.addConnection(BrokerFilter.java:82) at org.apache.activemq.broker.BrokerFilter.addConnection(BrokerFilter.java:82) This is not possible, because is the only client with that name and previos connection was closed . .close(). If I kill all the clients an I leave active only the broker, If I try to reconnect using http (or tcp) I get the same error. So client is not de-registered. This appens also if I use failover protocol. After client kill/restart. Same exception is raised (javax.jms.InvalidClientIDException - with the clientID of the killed client). I have to restart broker in order to register again the client. A test case is attached. If you connect to http the first time, connection is ok. If you kill the JVM and the try to restart the test case, 'myclid already connected from blockingQueue_' is always raised. Also after some hours. I have to restart the broker in order to have a new conection with that client id. This test simulate a JVM crash with no resource cleanup. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (AMQCPP-302) Compilation issue with older GCC versions in MessageCompressionTest.cpp
[ https://issues.apache.org/activemq/browse/AMQCPP-302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved AMQCPP-302. - Resolution: Fixed Fixed in trunk and 3.2.x fixes branch > Compilation issue with older GCC versions in MessageCompressionTest.cpp > --- > > Key: AMQCPP-302 > URL: https://issues.apache.org/activemq/browse/AMQCPP-302 > Project: ActiveMQ C++ Client > Issue Type: Bug > Components: Integration Tests >Affects Versions: 3.2.1 > Environment: CentOS 5.3 GCC 4.1.2 >Reporter: Timothy Bish >Assignee: Timothy Bish >Priority: Trivial > Fix For: 3.2.2, 3.3.0 > > > Constant value not tagged with the 'LL' marker to indicate it should be a > long causes the error: > nteger constant is too large for 'long' type -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (AMQCPP-302) Compilation issue with older GCC versions in MessageCompressionTest.cpp
Compilation issue with older GCC versions in MessageCompressionTest.cpp --- Key: AMQCPP-302 URL: https://issues.apache.org/activemq/browse/AMQCPP-302 Project: ActiveMQ C++ Client Issue Type: Bug Components: Integration Tests Affects Versions: 3.2.1 Environment: CentOS 5.3 GCC 4.1.2 Reporter: Timothy Bish Assignee: Timothy Bish Priority: Trivial Fix For: 3.2.2, 3.3.0 Constant value not tagged with the 'LL' marker to indicate it should be a long causes the error: nteger constant is too large for 'long' type -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (AMQ-2830) KahaDB configuration of properties archiveDataLogs & directoryArchive
[
https://issues.apache.org/activemq/browse/AMQ-2830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Tully resolved AMQ-2830.
-
Assignee: Gary Tully
Fix Version/s: 5.4.0
Resolution: Fixed
These attributes are exposed in version 5.4 - try a 5.4-SNAPSHOT - I updated
the doc page to indicate same
> KahaDB configuration of properties archiveDataLogs & directoryArchive
> -
>
> Key: AMQ-2830
> URL: https://issues.apache.org/activemq/browse/AMQ-2830
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
>Affects Versions: 5.3.2
> Environment: Windows 7,
>Reporter: Sougandh M Golla
>Assignee: Gary Tully
> Fix For: 5.4.0
>
> Original Estimate: 2 hours
> Remaining Estimate: 2 hours
>
> Test Config:
>
>journalMaxFileLength="32mb"
> archiveDataLogs="true"
> directoryArchive="${activemq.base}/archivedmsgs"
> maxAsyncJobs="1"
> databaseLockedWaitDelay="1"/>
>
> Unable to configure archiveDataLogs="true",
> directoryArchive="${activemq.base}/archivedmsgs",
> databaseLockedWaitDelay="1"
> Throws similar errors for all the mentioned attributes.
> Keeps throwing th below error.
> 0_20\jre
> Heap sizes: current=15872k free=14582k max=506816k
> JVM args: -Dcom.sun.management.jmxremote -Xmx512M
> -Dorg.apache.activemq.UseD
> edicatedTaskRunner=true -Djava.util.logging.config.file=logging.properties
> -Dact
> ivemq.classpath=C:\Program Files (x86)\apache-activemq-5.3.2\bin\../conf;
> -Dacti
> vemq.home=C:\Program Files (x86)\apache-activemq-5.3.2\bin\..
> -Dactivemq.base=C:
> \Program Files (x86)\apache-activemq-5.3.2\bin\..
> ACTIVEMQ_HOME: C:\Program Files (x86)\apache-activemq-5.3.2\bin\..
> ACTIVEMQ_BASE: C:\Program Files (x86)\apache-activemq-5.3.2\bin\..
> Loading message broker from:
> xbean:file:C:/Program%20Files%20(x86)/apache-active
> mq-5.3.2/conf/activemq-stomp1.xml
> ERROR: java.lang.RuntimeException: Failed to execute start task. Reason:
> org.spr
> ingframework.beans.factory.BeanCreationException: Error creating bean with
> name
> 'org.apache.activemq.xbean.XBeanBrokerService#0' defined in URL
> [file:C:/Program
> Files (x86)/apache-activemq-5.3.2/conf/activemq-stomp1.xml]: Cannot create
> inne
> r bean '(inner bean)' of type
> [org.apache.activemq.store.kahadb.KahaDBPersistenc
> eAdapter] while setting bean property 'persistenceAdapter'; nested exception
> is
> org.springframework.beans.factory.BeanCreationException: Error creating bean
> wit
> h name '(inner bean)#1' defined in URL [file:C:/Program Files
> (x86)/apache-activ
> emq-5.3.2/conf/activemq-stomp1.xml]: Error setting property values; nested
> excep
> tion is org.springframework.beans.NotWritablePropertyException: Invalid
> property
> 'directoryArchive' of bean class
> [org.apache.activemq.store.kahadb.KahaDBPersis
> tenceAdapter]: Bean property 'directoryArchive' is not writable or has an
> invali
> d setter method. Does the parameter type of the setter match the return type
> of
> the getter?
> java.lang.RuntimeException: Failed to execute start task. Reason:
> org.springfram
> ework.beans.factory.BeanCreationException: Error creating bean with name
> 'org.ap
> ache.activemq.xbean.XBeanBrokerService#0' defined in URL [file:C:/Program
> Files
> (x86)/apache-activemq-5.3.2/conf/activemq-stomp1.xml]: Cannot create inner
> bean
> '(inner bean)' of type
> [org.apache.activemq.store.kahadb.KahaDBPersistenceAdapte
> r] while setting bean property 'persistenceAdapter'; nested exception is
> org.spr
> ingframework.beans.factory.BeanCreationException: Error creating bean with
> name
> '(inner bean)#1' defined in URL [file:C:/Program Files
> (x86)/apache-activemq-5.3
> .2/conf/activemq-stomp1.xml]: Error setting property values; nested exception
> is
> org.springframework.beans.NotWritablePropertyException: Invalid property
> 'direc
> toryArchive' of bean class
> [org.apache.activemq.store.kahadb.KahaDBPersistenceAd
> apter]: Bean property 'directoryArchive' is not writable or has an invalid
> sette
> r method. Does the parameter type of the setter match the return type of the
> get
> ter?
> at
> org.apache.activemq.console.command.StartCommand.runTask(StartCommand
> .java:98)
> at
> org.apache.activemq.console.command.AbstractCommand.execute(AbstractC
> ommand.java:57)
> at
> org.apache.activemq.console.command.ShellCommand.runTask(ShellCommand
> .java:136)
> at
> org.apache.activemq.console.command.AbstractCommand.execute(AbstractC
> ommand.java:57)
> at
> org.apache.activemq.console.command.ShellCommand.main(ShellCommand.ja
> va:82)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Nati
Re: [AMQ-CPP] Issues with 3.2.1
On Fri, 2010-07-16 at 11:48 +0800, Romain CHANU wrote: > Hi, > > I am currently upgrading my client from 3.1.0 to 3.2.1. > > The environment used is very broad: > > - Centos 5.3 (gcc 4.1.2, APR 1.3.9, APR-util 1.3.9) > - Debian 5.0 (gcc 4.3.2, APR 1.3.5, APR-util 1.3.7) > - Fedora 11 (gcc 4.4.0, APR 1.3.5, APR-util 1.3.9) > - Ubuntu 10.04 (gcc 4.4.3, APR 1.3.8, APR-util 1.3.9) > > The compilation works whatever the environment used :-) > > However, I am facing major issues: > > 1) On Centos 5.3 and Debian 5.0, "make check" fails: > > (error reported from Centos 5.3) > > g++ -DHAVE_CONFIG_H -I. -I../..-ansi -pedantic -DLINUX=2 -D_REENTRANT > -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -I/usr/local/apr/include/apr-1 > -I/usr/local/apr/include/apr-1 -W -Wall -Wextra -Wconversion -fPIC > -fstrict-aliasing -Wstrict-aliasing=2 -Wno-long-long -DLINUX=2 > -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE > -I/usr/local/apr/include/apr-1 -I/usr/local/apr/include/apr-1 > -Wno-non-virtual-dtor -Wno-unused-parameter -Wno-uninitialized -I./../main > -I/usr/local/include -g -O2 -pthread -MT > activemq/test/activemq_test_integration-MessageCompressionTest.o -MD -MP -MF > activemq/test/.deps/activemq_test_integration-MessageCompressionTest.Tpo -c > -o activemq/test/activemq_test_integration-MessageCompressionTest.o `test -f > 'activemq/test/MessageCompressionTest.cpp' || echo > './'`activemq/test/MessageCompressionTest.cpp > activemq/test/MessageCompressionTest.cpp:63: error: integer constant is too > large for ‘long’ type > activemq/test/MessageCompressionTest.cpp:69: error: integer constant is too > large for ‘long’ type > > > 2) I tried to run the examples provided in the package: > > - On Centos 5.3 and Debian 5.0, none of the examples worked... I got a > "segmentation fault" > > - On Fedora 11 and Ubuntu 10.04, all the examples worked. > > > Do you have any idea on what's going on? > If you could attach the stack trace from the segfault that would be useful otherwise its hard to say what it could be. I can install a CentOS 5.3 VM and try it out myself, but it would take some time to setup and I still might not get something that matches your environment exactly. Regards -- Tim Bish Open Source Integration: http://fusesource.com ActiveMQ in Action: http://www.manning.com/snyder/ Follow me on Twitter: http://twitter.com/tabish121 My Blog: http://timbish.blogspot.com/
[jira] Created: (AMQ-2830) KahaDB configuration of properties archiveDataLogs & directoryArchive
KahaDB configuration of properties archiveDataLogs & directoryArchive
-
Key: AMQ-2830
URL: https://issues.apache.org/activemq/browse/AMQ-2830
Project: ActiveMQ
Issue Type: Bug
Components: Broker
Affects Versions: 5.3.2
Environment: Windows 7,
Reporter: Sougandh M Golla
Test Config:
Unable to configure archiveDataLogs="true",
directoryArchive="${activemq.base}/archivedmsgs",
databaseLockedWaitDelay="1"
Throws similar errors for all the mentioned attributes.
Keeps throwing th below error.
0_20\jre
Heap sizes: current=15872k free=14582k max=506816k
JVM args: -Dcom.sun.management.jmxremote -Xmx512M -Dorg.apache.activemq.UseD
edicatedTaskRunner=true -Djava.util.logging.config.file=logging.properties -Dact
ivemq.classpath=C:\Program Files (x86)\apache-activemq-5.3.2\bin\../conf; -Dacti
vemq.home=C:\Program Files (x86)\apache-activemq-5.3.2\bin\.. -Dactivemq.base=C:
\Program Files (x86)\apache-activemq-5.3.2\bin\..
ACTIVEMQ_HOME: C:\Program Files (x86)\apache-activemq-5.3.2\bin\..
ACTIVEMQ_BASE: C:\Program Files (x86)\apache-activemq-5.3.2\bin\..
Loading message broker from: xbean:file:C:/Program%20Files%20(x86)/apache-active
mq-5.3.2/conf/activemq-stomp1.xml
ERROR: java.lang.RuntimeException: Failed to execute start task. Reason: org.spr
ingframework.beans.factory.BeanCreationException: Error creating bean with name
'org.apache.activemq.xbean.XBeanBrokerService#0' defined in URL [file:C:/Program
Files (x86)/apache-activemq-5.3.2/conf/activemq-stomp1.xml]: Cannot create inne
r bean '(inner bean)' of type [org.apache.activemq.store.kahadb.KahaDBPersistenc
eAdapter] while setting bean property 'persistenceAdapter'; nested exception is
org.springframework.beans.factory.BeanCreationException: Error creating bean wit
h name '(inner bean)#1' defined in URL [file:C:/Program Files (x86)/apache-activ
emq-5.3.2/conf/activemq-stomp1.xml]: Error setting property values; nested excep
tion is org.springframework.beans.NotWritablePropertyException: Invalid property
'directoryArchive' of bean class [org.apache.activemq.store.kahadb.KahaDBPersis
tenceAdapter]: Bean property 'directoryArchive' is not writable or has an invali
d setter method. Does the parameter type of the setter match the return type of
the getter?
java.lang.RuntimeException: Failed to execute start task. Reason: org.springfram
ework.beans.factory.BeanCreationException: Error creating bean with name 'org.ap
ache.activemq.xbean.XBeanBrokerService#0' defined in URL [file:C:/Program Files
(x86)/apache-activemq-5.3.2/conf/activemq-stomp1.xml]: Cannot create inner bean
'(inner bean)' of type [org.apache.activemq.store.kahadb.KahaDBPersistenceAdapte
r] while setting bean property 'persistenceAdapter'; nested exception is org.spr
ingframework.beans.factory.BeanCreationException: Error creating bean with name
'(inner bean)#1' defined in URL [file:C:/Program Files (x86)/apache-activemq-5.3
.2/conf/activemq-stomp1.xml]: Error setting property values; nested exception is
org.springframework.beans.NotWritablePropertyException: Invalid property 'direc
toryArchive' of bean class [org.apache.activemq.store.kahadb.KahaDBPersistenceAd
apter]: Bean property 'directoryArchive' is not writable or has an invalid sette
r method. Does the parameter type of the setter match the return type of the get
ter?
at org.apache.activemq.console.command.StartCommand.runTask(StartCommand
.java:98)
at org.apache.activemq.console.command.AbstractCommand.execute(AbstractC
ommand.java:57)
at org.apache.activemq.console.command.ShellCommand.runTask(ShellCommand
.java:136)
at org.apache.activemq.console.command.AbstractCommand.execute(AbstractC
ommand.java:57)
at org.apache.activemq.console.command.ShellCommand.main(ShellCommand.ja
va:82)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.activemq.console.Main.runTaskClass(Main.java:251)
at org.apache.activemq.console.Main.main(Main.java:107)
Caused by: org.springframework.beans.factory.BeanCreationException: Error creati
ng bean with name 'org.apache.activemq.xbean.XBeanBrokerService#0' defined in UR
L [file:C:/Program Files (x86)/apache-activemq-5.3.2/conf/activemq-stomp1.xml]:
Cannot create inner bean '(inner bean)' of type [org.apache.activemq.store.kahad
b.KahaDBPersistenceAdapter] while setting bean property 'persistenceAdapter'; ne
sted exception is org.springframework.beans.factory.BeanCreationException: Error
creating bean with name '(inner bean)#1' defined in URL [file:C:/Program Files
(x86)/apache-active
[jira] Commented: (AMQ-2826) Look at the possibility of incorporating a cassandra persistence adapter from http://github.com/ticktock/qsandra
[ https://issues.apache.org/activemq/browse/AMQ-2826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=60690#action_60690 ] Gary Tully commented on AMQ-2826: - The CI tests for jdbc use an embedded derby, there are not external process dependencies in the CI runs at the moment. Wonder if adding the tests with an exclusion via a property in surefire will work and have a 1.6jdk profile that redefines that property such that the tests are run when it is enabled would work. > Look at the possibility of incorporating a cassandra persistence adapter from > http://github.com/ticktock/qsandra > - > > Key: AMQ-2826 > URL: https://issues.apache.org/activemq/browse/AMQ-2826 > Project: ActiveMQ > Issue Type: New Feature > Components: Message Store >Affects Versions: 5.3.2 >Reporter: Scott Clasen > > I am the author of http://github.com/ticktock/qsandra, which is a cassandra > persistence adapter for activemq. I am willing to donate it if it is > something that is of interest to ActiveMQ.. > Only current trouble with that is it needs JDK 1.6, so it would probably need > to wait until (if and when) ActiveMQ 5.x is built with JDK 6. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (AMQNET-262) NMS cannot be used if installed in the GAC
[
https://issues.apache.org/activemq/browse/AMQNET-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=60688#action_60688
]
Daniel Ellis commented on AMQNET-262:
-
I first tried Assembly.Load but that failed because it will not load a file
from the GAC unless the full assembly name is specified (name, version, key).
LoadWithPartialName did load the assembly from the GAC. However, I failed to
notice it was deprecated. A quick look finds this blog entry which explains
their reasoning: http://blogs.msdn.com/b/suzcook/archive/2003/05/30/57159.aspx
So either way, currently there is not a suitable solution for this, because
ultimately if using the GAC, we must specify the exact version that is
required, in order to handle different apps putting different versions of NMS
in the GAC.
I can think of two solutions:-
1. Specify the full assembly name in the NMS config file.
2. Specify the full assembly name in the built in list of known assemblies.
And I think I would prefer option 2, because it is actually specifying which
versions of NMS connectors are compatible with the core NMS interface.
E.g. Apache.NMS 1.3.0.0 would be compatible with Apache.NMS.ActiveMQ 1.3.0.0
only.
This would mean that minor fixes should not change the "AssemblyVersion", but
it would be fine to update the "AssemblyFileVersion".
> NMS cannot be used if installed in the GAC
> --
>
> Key: AMQNET-262
> URL: https://issues.apache.org/activemq/browse/AMQNET-262
> Project: ActiveMQ .Net
> Issue Type: Improvement
> Components: NMS
>Affects Versions: 1.3.0
> Environment: Windows .NET 2.0
>Reporter: Daniel Ellis
>Assignee: Jim Gomes
>Priority: Minor
> Fix For: 1.4.0
>
> Attachments: NMS GAC.patch
>
> Time Spent: 45 minutes
> Remaining Estimate: 0 minutes
>
> If you install {{Apache.NMS.dll}} and {{Apache.NMS.ActiveMQ.dll}} in the GAC
> then NMS is not able to load {{Apache.NMS.ActiveMQ.dll}}.
> {{NMSConnectionFactory.cs}} is storing the pre-defined connection factories
> in _schemaProviderFactoryMap_, but is storing the DLL file names to locate
> the assemblies.
> One solution would be to store the _AssemblyQualifiedName_ instead and leave
> the assembly loading to the system.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
