[jira] Commented: (AMQCPP-59) Exception is thrown when destroying consumer after connection failure
[
https://issues.apache.org/activemq/browse/AMQCPP-59?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_38035
]
Albert Strasheim commented on AMQCPP-59:
I think you might be right. I varied the receive timeout and restarted the
broker at random and saw the C++ client get socket errors in various places,
but I wasn't able to reproduce the uncaught exception. I think we can resolve
this issue for now.
Exception is thrown when destroying consumer after connection failure
-
Key: AMQCPP-59
URL: https://issues.apache.org/activemq/browse/AMQCPP-59
Project: ActiveMQ C++ Client
Issue Type: Bug
Affects Versions: 2.0
Reporter: Albert Strasheim
Assigned To: Nathan Mittler
Fix For: 2.0
Brought over from AMQCPP-46.
In a program that reconnects when it detects a connection failure using an
exception listener, there seem to be two different places where exceptions
can originate.
In most cases when I shut down the broker and the exception listener fires
properly and I can clean up everything (without deletes throwing exceptions),
the stack trace that gets printed on the console looks like this:
{noformat}
WARNING: activemq::io::SocketInputStream::read - The connection is broken
FILE: ..\src\main\activemq\network\SocketInputStream.cpp, LINE: 137
FILE: ..\src\main\activemq\io\BufferedInputStream.cpp, LINE: 199
FILE: ..\src\main\activemq\io\BufferedInputStream.cpp, LINE: 83
FILE: ..\src\main\activemq\connector\stomp\StompCommandReader.cpp,
LINE: 216
FILE: ..\src\main\activemq\connector\stomp\StompCommandReader.cpp,
LINE: 120
FILE: ..\src\main\activemq\connector\stomp\StompCommandReader.cpp,
LINE: 71
FILE: ..\src\main\activemq\transport\IOTransport.cpp, LINE: 175
{noformat}
The message is printed twice with different tids, from the two threads that
are active.
Sometimes when I shut down the broker and the exception handler fires and I
clean up everything but then the consumer's destructor throws an exception.
In that case, the stack trace that is printed looks like this:
{noformat}
WARNING: activemq::io::SocketInputStream::read - An existing connection was
forcibly closed by the remote host.
FILE: ..\src\main\activemq\network\SocketInputStream.cpp, LINE: 145
FILE: ..\src\main\activemq\io\BufferedInputStream.cpp, LINE: 199
FILE: ..\src\main\activemq\io\BufferedInputStream.cpp, LINE: 83
FILE: ..\src\main\activemq\connector\stomp\StompCommandReader.cpp,
LINE: 216
FILE: ..\src\main\activemq\connector\stomp\StompCommandReader.cpp,
LINE: 120
FILE: ..\src\main\activemq\connector\stomp\StompCommandReader.cpp,
LINE: 71
FILE: ..\src\main\activemq\transport\IOTransport.cpp, LINE: 175
{noformat}
Again I see this message from both threads. Note the slightly different line
numbers in SocketInputStream.cpp and the slighty different error message
(this is on Windows XP SP2). In this case the failure of the socket is
probably being detected in a slightly different place.
If the socket failure happens in the second way, it seems that destructors of
consumers (and possibly producers and sessions) don't properly catch the
exception when being destroying, causing their destructors to throw an
exception, which isn't what we want.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (AMQCPP-59) Exception is thrown when destroying consumer after connection failure
[
https://issues.apache.org/activemq/browse/AMQCPP-59?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_38037
]
Albert Strasheim commented on AMQCPP-59:
Argh, still seeing this issue with our application. I'm investigating further.
By the way, the exception that is thrown from the destructor has some invalid
data at the top of its stack trace.
Exception is thrown when destroying consumer after connection failure
-
Key: AMQCPP-59
URL: https://issues.apache.org/activemq/browse/AMQCPP-59
Project: ActiveMQ C++ Client
Issue Type: Bug
Affects Versions: 2.0
Reporter: Albert Strasheim
Assigned To: Nathan Mittler
Fix For: 2.0
Brought over from AMQCPP-46.
In a program that reconnects when it detects a connection failure using an
exception listener, there seem to be two different places where exceptions
can originate.
In most cases when I shut down the broker and the exception listener fires
properly and I can clean up everything (without deletes throwing exceptions),
the stack trace that gets printed on the console looks like this:
{noformat}
WARNING: activemq::io::SocketInputStream::read - The connection is broken
FILE: ..\src\main\activemq\network\SocketInputStream.cpp, LINE: 137
FILE: ..\src\main\activemq\io\BufferedInputStream.cpp, LINE: 199
FILE: ..\src\main\activemq\io\BufferedInputStream.cpp, LINE: 83
FILE: ..\src\main\activemq\connector\stomp\StompCommandReader.cpp,
LINE: 216
FILE: ..\src\main\activemq\connector\stomp\StompCommandReader.cpp,
LINE: 120
FILE: ..\src\main\activemq\connector\stomp\StompCommandReader.cpp,
LINE: 71
FILE: ..\src\main\activemq\transport\IOTransport.cpp, LINE: 175
{noformat}
The message is printed twice with different tids, from the two threads that
are active.
Sometimes when I shut down the broker and the exception handler fires and I
clean up everything but then the consumer's destructor throws an exception.
In that case, the stack trace that is printed looks like this:
{noformat}
WARNING: activemq::io::SocketInputStream::read - An existing connection was
forcibly closed by the remote host.
FILE: ..\src\main\activemq\network\SocketInputStream.cpp, LINE: 145
FILE: ..\src\main\activemq\io\BufferedInputStream.cpp, LINE: 199
FILE: ..\src\main\activemq\io\BufferedInputStream.cpp, LINE: 83
FILE: ..\src\main\activemq\connector\stomp\StompCommandReader.cpp,
LINE: 216
FILE: ..\src\main\activemq\connector\stomp\StompCommandReader.cpp,
LINE: 120
FILE: ..\src\main\activemq\connector\stomp\StompCommandReader.cpp,
LINE: 71
FILE: ..\src\main\activemq\transport\IOTransport.cpp, LINE: 175
{noformat}
Again I see this message from both threads. Note the slightly different line
numbers in SocketInputStream.cpp and the slighty different error message
(this is on Windows XP SP2). In this case the failure of the socket is
probably being detected in a slightly different place.
If the socket failure happens in the second way, it seems that destructors of
consumers (and possibly producers and sessions) don't properly catch the
exception when being destroying, causing their destructors to throw an
exception, which isn't what we want.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (AMQCPP-61) CMSException::what returns c_str of temporary std::string
CMSException::what returns c_str of temporary std::string - Key: AMQCPP-61 URL: https://issues.apache.org/activemq/browse/AMQCPP-61 Project: ActiveMQ C++ Client Issue Type: Bug Components: CMS Impl Affects Versions: 2.0 Reporter: Albert Strasheim Assigned To: Nathan Mittler Priority: Minor Fix For: 2.0 In my debugging to figure out what's going on with AMQCPP-59, I'm sometimes seeing invalid stuff getting printed out when I do printStackTrace on some exceptions. I think this might be because CMSException::what returns getMessage().c_str(), i.e. it seems to be returning the c_str of a std::string that is allocated on the stack, since getMessage returns std::string. An example of where what() is being called that seems to be causing problems is on line 84 of ActiveMQConsumer.cpp. When I catch this exception later on and print its stack trace or call its getMessage, I get garbage. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (AMQCPP-59) Exception is thrown when destroying consumer after connection failure
[
https://issues.apache.org/activemq/browse/AMQCPP-59?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_38038
]
Albert Strasheim commented on AMQCPP-59:
Okay, figured it out. It was an error on our end. We have a class that contains
a connection, session and consumer to deal with the Stomp selector limitations
and we were calling close on this consumer in our class's destructor (this is
where the unexpected exception came from) instead of just deleting it so that
AMQCPP could handle the exception.
Exception is thrown when destroying consumer after connection failure
-
Key: AMQCPP-59
URL: https://issues.apache.org/activemq/browse/AMQCPP-59
Project: ActiveMQ C++ Client
Issue Type: Bug
Affects Versions: 2.0
Reporter: Albert Strasheim
Assigned To: Nathan Mittler
Fix For: 2.0
Brought over from AMQCPP-46.
In a program that reconnects when it detects a connection failure using an
exception listener, there seem to be two different places where exceptions
can originate.
In most cases when I shut down the broker and the exception listener fires
properly and I can clean up everything (without deletes throwing exceptions),
the stack trace that gets printed on the console looks like this:
{noformat}
WARNING: activemq::io::SocketInputStream::read - The connection is broken
FILE: ..\src\main\activemq\network\SocketInputStream.cpp, LINE: 137
FILE: ..\src\main\activemq\io\BufferedInputStream.cpp, LINE: 199
FILE: ..\src\main\activemq\io\BufferedInputStream.cpp, LINE: 83
FILE: ..\src\main\activemq\connector\stomp\StompCommandReader.cpp,
LINE: 216
FILE: ..\src\main\activemq\connector\stomp\StompCommandReader.cpp,
LINE: 120
FILE: ..\src\main\activemq\connector\stomp\StompCommandReader.cpp,
LINE: 71
FILE: ..\src\main\activemq\transport\IOTransport.cpp, LINE: 175
{noformat}
The message is printed twice with different tids, from the two threads that
are active.
Sometimes when I shut down the broker and the exception handler fires and I
clean up everything but then the consumer's destructor throws an exception.
In that case, the stack trace that is printed looks like this:
{noformat}
WARNING: activemq::io::SocketInputStream::read - An existing connection was
forcibly closed by the remote host.
FILE: ..\src\main\activemq\network\SocketInputStream.cpp, LINE: 145
FILE: ..\src\main\activemq\io\BufferedInputStream.cpp, LINE: 199
FILE: ..\src\main\activemq\io\BufferedInputStream.cpp, LINE: 83
FILE: ..\src\main\activemq\connector\stomp\StompCommandReader.cpp,
LINE: 216
FILE: ..\src\main\activemq\connector\stomp\StompCommandReader.cpp,
LINE: 120
FILE: ..\src\main\activemq\connector\stomp\StompCommandReader.cpp,
LINE: 71
FILE: ..\src\main\activemq\transport\IOTransport.cpp, LINE: 175
{noformat}
Again I see this message from both threads. Note the slightly different line
numbers in SocketInputStream.cpp and the slighty different error message
(this is on Windows XP SP2). In this case the failure of the socket is
probably being detected in a slightly different place.
If the socket failure happens in the second way, it seems that destructors of
consumers (and possibly producers and sessions) don't properly catch the
exception when being destroying, causing their destructors to throw an
exception, which isn't what we want.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (AMQCPP-58) Possible memory leak when reestablishing connection
[
https://issues.apache.org/activemq/browse/AMQCPP-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_38034
]
Albert Strasheim commented on AMQCPP-58:
Using the latest program you posted in AMQCPP-59 I'm still seeing many leaks if
I keep the program running as I start and stop the broker repeatedly. Have you
tried Valgrind? It's really useful. I run it like this:
{noformat}
valgrind \
--tool=memcheck \
--leak-check=yes \
--error-limit=no \
--num-callers=20 \
--freelist-vol=536870912 \
-v \
someprogram
{noformat}
Possible memory leak when reestablishing connection
---
Key: AMQCPP-58
URL: https://issues.apache.org/activemq/browse/AMQCPP-58
Project: ActiveMQ C++ Client
Issue Type: Bug
Affects Versions: 2.0
Reporter: Albert Strasheim
Assigned To: Nathan Mittler
Fix For: 2.0
Attachments: leaker.cpp, purify-example.txt, socketleak1.diff
Brought over from AMQCPP-46.
There seems to be a memory leak when running the example program from
AMQCPP-46 which reconnects whenever the broker goes down.
Valgrind says:
{noformat}
==15493== 149,520 (89,712 direct, 59,808 indirect) bytes in 1,869 blocks are
definitely lost in loss record 55 of 55
==15493==at 0x4A19DE3: operator new(unsigned long)
(vg_replace_malloc.c:168)
==15493==by 0x45DEDD:
activemq::network::SocketFactory::createSocket(activemq::util::Properties
const) (SocketFactory.cpp:96)
==15493==by 0x458D0C:
activemq::transport::TcpTransport::TcpTransport(activemq::util::Properties
const, activemq::transport::Transport*, bool) (TcpTransport.cpp:42)
==15493==by 0x42B3EE:
activemq::transport::TcpTransportFactory::createTransport(activemq::util::Properties
const) (TcpTransportFactory.cpp:55)
==15493==by 0x404CC0:
activemq::core::ActiveMQConnectionFactory::createConnection(std::string
const, std::string const, std::string const)
(ActiveMQConnectionFactory.cpp:130)
==15493==by 0x4042D5:
activemq::core::ActiveMQConnectionFactory::createConnection()
(ActiveMQConnectionFactory.cpp:69)
==15493==by 0x403D67: main (main.cpp:30)
{noformat}
Purify also seems to indicate that there is a link, along with with possibly
spurious leaks or leaks that might be related to the leak reported by
Valgrind.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (AMQCPP-56) GCC warnings and possible SocketFactory bug on 64-bit Linux
GCC warnings and possible SocketFactory bug on 64-bit Linux
---
Key: AMQCPP-56
URL: https://issues.apache.org/activemq/browse/AMQCPP-56
Project: ActiveMQ C++ Client
Issue Type: Bug
Affects Versions: 2.0
Reporter: Albert Strasheim
Assigned To: Nathan Mittler
Priority: Minor
Fix For: 2.0
When compiling on 64-bit Linux with GCC 4.0.3, I see the following warnings:
{noformat}
activemq/concurrent/PooledThread.cpp:56: warning: 'task$first' may be used
uninitialized in this function
activemq/concurrent/PooledThread.cpp:56: warning: 'task$second' may be used
uninitialized in this function
activemq/network/SocketFactory.cpp:46: warning: comparison is always false due
to limited range of data type
activemq/connector/openwire/marshal/v2/ConnectionControlMarshaller.cpp:82:
warning: unused variable 'info'
activemq/connector/openwire/marshal/v2/IntegerResponseMarshaller.cpp:60:
warning: unused variable 'info'
activemq/connector/openwire/marshal/v2/ReplayCommandMarshaller.cpp:61: warning:
unused variable 'info'
activemq/connector/openwire/marshal/v2/ResponseMarshaller.cpp:60: warning:
unused variable 'info'
{noformat}
The first three warnings probably need to be looked at, especially the one in
SocketFactory.
In my opinion, AMQCPP is using ints and unsigned ints in places where
std::size_t might be more appropriate. MSVC's warning level 3 catches many of
these issues, so we might consider upping the warning level and properly
dealing with the type conversion issues: mostly use std::size_t and static_cast
where we really intend to convert. I can prepare a few patches along these
lines if you think this is worthwhile.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Reopened: (AMQ-1082) Improve Kaha freeList
[
https://issues.apache.org/activemq/browse/AMQ-1082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Albert Strasheim reopened AMQ-1082:
---
Hope I have the right issue here.
When running our fast producer, slow consumer unit test for a while, I'm
getting the following stack trace. The missing file it is looking for has
indeed been deleted. There's still plenty of free space on the disk.
ERROR DataManagerImpl- Looking for key 1 but not found in
fileMap: {2=data-TopicSubscription-2 number = 2 , length = 33554006 refCount =
12755, 4=data-TopicSubscription-4 number = 4 , length = 33554158 refCount =
17435, 6=data-TopicSubscription-6 number = 6 , length = 20247053 refCount =
10538, 3=data-TopicSubscription-3 number = 3 , length = 33553411 refCount =
17037, 5=data-TopicSubscription-5 number = 5 , length = 33552256 refCount =
16291}
ERROR ListContainerImpl - Failed to get value for offset=102,
key=(-1, -1, 0), value=(1, 2001, 2022), previousItem=-1, nextItem=204
java.io.IOException: Could not locate data file data-TopicSubscription-1
at
org.apache.activemq.kaha.impl.data.DataManagerImpl.getDataFile(DataManagerImpl.java:121)
at
org.apache.activemq.kaha.impl.data.SyncDataFileReader.readItem(SyncDataFileReader.java:60)
at
org.apache.activemq.kaha.impl.data.DataManagerImpl.readItem(DataManagerImpl.java:130)
at
org.apache.activemq.kaha.impl.container.ListContainerImpl.getValue(ListContainerImpl.java:841)
at
org.apache.activemq.kaha.impl.container.ContainerValueCollectionIterator.next(ContainerValueCollectionIterator.java:48)
at
org.apache.activemq.broker.region.cursors.FilePendingMessageCursor.next(FilePendingMessageCursor.java:186)
at
org.apache.activemq.broker.region.TopicSubscription.dispatchMatched(TopicSubscription.java:347)
at
org.apache.activemq.broker.region.TopicSubscription.acknowledge(TopicSubscription.java:191)
at
org.apache.activemq.broker.region.AbstractRegion.acknowledge(AbstractRegion.java:312)
at
org.apache.activemq.broker.region.RegionBroker.acknowledge(RegionBroker.java:401)
at
org.apache.activemq.broker.TransactionBroker.acknowledge(TransactionBroker.java:181)
at
org.apache.activemq.broker.BrokerFilter.acknowledge(BrokerFilter.java:74)
at
org.apache.activemq.broker.BrokerFilter.acknowledge(BrokerFilter.java:74)
at
org.apache.activemq.broker.MutableBrokerFilter.acknowledge(MutableBrokerFilter.java:88)
at
org.apache.activemq.broker.TransportConnection.processMessageAck(TransportConnection.java:456)
at org.apache.activemq.command.MessageAck.visit(MessageAck.java:179)
at
org.apache.activemq.broker.TransportConnection.service(TransportConnection.java:258)
at
org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:164)
at
org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:95)
at
org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:65)
at
org.apache.activemq.transport.vm.VMTransport.syncOneWay(VMTransport.java:99)
at
org.apache.activemq.transport.vm.VMTransport.oneway(VMTransport.java:86)
at
org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:44)
at
org.apache.activemq.transport.ResponseCorrelator.oneway(ResponseCorrelator.java:60)
at
org.apache.activemq.ActiveMQConnection.asyncSendPacket(ActiveMQConnection.java:1165)
at
org.apache.activemq.ActiveMQSession.asyncSendPacket(ActiveMQSession.java:1647)
at
org.apache.activemq.ActiveMQMessageConsumer.ackLater(ActiveMQMessageConsumer.java:748)
at
org.apache.activemq.ActiveMQMessageConsumer.afterMessageIsConsumed(ActiveMQMessageConsumer.java:705)
at
org.apache.activemq.ActiveMQMessageConsumer.dispatch(ActiveMQMessageConsumer.java:871)
at
org.apache.activemq.ActiveMQSessionExecutor.dispatch(ActiveMQSessionExecutor.java:99)
at
org.apache.activemq.ActiveMQSessionExecutor.iterate(ActiveMQSessionExecutor.java:166)
at
org.apache.activemq.thread.PooledTaskRunner.runTask(PooledTaskRunner.java:111)
at
org.apache.activemq.thread.PooledTaskRunner.access$100(PooledTaskRunner.java:26)
at
org.apache.activemq.thread.PooledTaskRunner$1.run(PooledTaskRunner.java:44)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
at java.lang.Thread.run(Thread.java:595)
ERROR Service- Async error occurred:
org.apache.activemq.kaha.RuntimeStoreException: java.io.IOException: Could not
locate data file data-TopicSubscription-1
org.apache.activemq.kaha.RuntimeStoreException: java.io.IOException: Could not
locate data file
[jira] Created: (AMQCPP-57) Typo in names of delivery modes
Typo in names of delivery modes --- Key: AMQCPP-57 URL: https://issues.apache.org/activemq/browse/AMQCPP-57 Project: ActiveMQ C++ Client Issue Type: Improvement Components: CMS Impl Affects Versions: 2.0 Reporter: Albert Strasheim Assigned To: Nathan Mittler Priority: Trivial Fix For: 2.0 The delivery mode enums are spelled incorrectly, i.e. they should be PERSISTENT and NON_PERSISTENT, not PERSISTANT and NON_PERSISTANT. You might consider adding the -TENT versions in addition to the -TANT versions to avoid break backward compatibility. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (AMQCPP-58) Possible memory leak when reestablishing connection
Possible memory leak when reestablishing connection
---
Key: AMQCPP-58
URL: https://issues.apache.org/activemq/browse/AMQCPP-58
Project: ActiveMQ C++ Client
Issue Type: Bug
Affects Versions: 2.0
Reporter: Albert Strasheim
Assigned To: Nathan Mittler
Fix For: 2.0
Attachments: purify-example.txt
Brought over from AMQCPP-46.
There seems to be a memory leak when running the example program from AMQCPP-46
which reconnects whenever the broker goes down.
Valgrind says:
{noformat}
==15493== 149,520 (89,712 direct, 59,808 indirect) bytes in 1,869 blocks are
definitely lost in loss record 55 of 55
==15493==at 0x4A19DE3: operator new(unsigned long) (vg_replace_malloc.c:168)
==15493==by 0x45DEDD:
activemq::network::SocketFactory::createSocket(activemq::util::Properties
const) (SocketFactory.cpp:96)
==15493==by 0x458D0C:
activemq::transport::TcpTransport::TcpTransport(activemq::util::Properties
const, activemq::transport::Transport*, bool) (TcpTransport.cpp:42)
==15493==by 0x42B3EE:
activemq::transport::TcpTransportFactory::createTransport(activemq::util::Properties
const) (TcpTransportFactory.cpp:55)
==15493==by 0x404CC0:
activemq::core::ActiveMQConnectionFactory::createConnection(std::string const,
std::string const, std::string const) (ActiveMQConnectionFactory.cpp:130)
==15493==by 0x4042D5:
activemq::core::ActiveMQConnectionFactory::createConnection()
(ActiveMQConnectionFactory.cpp:69)
==15493==by 0x403D67: main (main.cpp:30)
{noformat}
Purify also seems to indicate that there is a link, along with with possibly
spurious leaks or leaks that might be related to the leak reported by Valgrind.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (AMQCPP-59) Exception is thrown when destroying consumer after connection failure
Exception is thrown when destroying consumer after connection failure
-
Key: AMQCPP-59
URL: https://issues.apache.org/activemq/browse/AMQCPP-59
Project: ActiveMQ C++ Client
Issue Type: Bug
Affects Versions: 2.0
Reporter: Albert Strasheim
Assigned To: Nathan Mittler
Fix For: 2.0
Brought over from AMQCPP-46.
In a program that reconnects when it detects a connection failure using an
exception listener, there seem to be two different places where exceptions can
originate.
In most cases when I shut down the broker and the exception listener fires
properly and I can clean up everything (without deletes throwing exceptions),
the stack trace that gets printed on the console looks like this:
{noformat}
WARNING: activemq::io::SocketInputStream::read - The connection is broken
FILE: ..\src\main\activemq\network\SocketInputStream.cpp, LINE: 137
FILE: ..\src\main\activemq\io\BufferedInputStream.cpp, LINE: 199
FILE: ..\src\main\activemq\io\BufferedInputStream.cpp, LINE: 83
FILE: ..\src\main\activemq\connector\stomp\StompCommandReader.cpp,
LINE: 216
FILE: ..\src\main\activemq\connector\stomp\StompCommandReader.cpp,
LINE: 120
FILE: ..\src\main\activemq\connector\stomp\StompCommandReader.cpp,
LINE: 71
FILE: ..\src\main\activemq\transport\IOTransport.cpp, LINE: 175
{noformat}
The message is printed twice with different tids, from the two threads that are
active.
Sometimes when I shut down the broker and the exception handler fires and I
clean up everything but then the consumer's destructor throws an exception. In
that case, the stack trace that is printed looks like this:
{noformat}
WARNING: activemq::io::SocketInputStream::read - An existing connection was
forcibly closed by the remote host.
FILE: ..\src\main\activemq\network\SocketInputStream.cpp, LINE: 145
FILE: ..\src\main\activemq\io\BufferedInputStream.cpp, LINE: 199
FILE: ..\src\main\activemq\io\BufferedInputStream.cpp, LINE: 83
FILE: ..\src\main\activemq\connector\stomp\StompCommandReader.cpp,
LINE: 216
FILE: ..\src\main\activemq\connector\stomp\StompCommandReader.cpp,
LINE: 120
FILE: ..\src\main\activemq\connector\stomp\StompCommandReader.cpp,
LINE: 71
FILE: ..\src\main\activemq\transport\IOTransport.cpp, LINE: 175
{noformat}
Again I see this message from both threads. Note the slightly different line
numbers in SocketInputStream.cpp and the slighty different error message (this
is on Windows XP SP2). In this case the failure of the socket is probably being
detected in a slightly different place.
If the socket failure happens in the second way, it seems that destructors of
consumers (and possibly producers and sessions) don't properly catch the
exception when being destroying, causing their destructors to throw an
exception, which isn't what we want.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (AMQCPP-46) ActiveMQConnection doesn't propagate exception listener to underlying connector
[
https://issues.apache.org/activemq/browse/AMQCPP-46?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_38011
]
Albert Strasheim commented on AMQCPP-46:
The memory leak an uncaught exception issues have been split out to AMQCPP-58
and AMQCPP-59, respectively.
ActiveMQConnection doesn't propagate exception listener to underlying
connector
---
Key: AMQCPP-46
URL: https://issues.apache.org/activemq/browse/AMQCPP-46
Project: ActiveMQ C++ Client
Issue Type: Bug
Affects Versions: 1.1
Reporter: Albert Strasheim
Assigned To: Nathan Mittler
Fix For: 2.0
Attachments: amqconn-exlistener.diff, main.cpp, purify-example.txt
My program is doing the following:
# Create connection using ActiveMQConnectionFactory
# Set a simple exception listener that sets a boolean flag
# Block in receive on consumer
If I then kill the broker, various exceptions happen, but they are never sent
to the exception listener, because the exception listener in StompConnector
is null. It seems to me that ActiveMQConnection should set and get its
exception listener on its underlying connector and probably doesn't have to
contain a pointer to the listener itself.
If I change ActiveMQConnection as in the attached patch to also set the
exception listener on the underlying connector, my exception listener gets
called when the broker dies.
Once I detect the failure, I delete the producer, consumer, session and
connection that failed. Looks like an uncaught exception is getting thrown
during the destruction of the producer (which is the first thing I delete
when cleaning up). The problem here is probably that the connection is trying
to close down a socket that is already broken and something goes awry. I'm
not quite sure how to fix this problem.
Stack trace (with useless bits stripped out):
{noformat}
kernel32.dll!7c812a5b()
[Frames below may be incorrect and/or missing, no symbols loaded for
kernel32.dll]
kernel32.dll!7c812a5b()
myapp.exe!std::vectorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int,std::allocatorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int
::_Ucopystd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int
*(std::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int *
_First=(..\src\main\activemq\connector\stomp\StompSessionManager.cpp,254),
std::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int * _Last=(Bad Ptr,14297048),
std::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int *
_Ptr=(..\src\main\activemq\connector\stomp\StompSessionManager.cpp,254))
Line 1105 + 0x18 bytes C++
myapp.exe!std::vectorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int,std::allocatorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int ::operator=(const
std::vectorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int,std::allocatorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int_Right={...}) Line 582 + 0x1d bytes C++
0012b920()
myapp.exe!activemq::core::ActiveMQConsumer::close() Line 84 + 0x34
bytes C++
msvcr80d.dll!102418b7()
...
kernel32.dll!7c812a5b()
myapp.exe!std::vectorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int,std::allocatorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int
::_Ucopystd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int
*(std::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int * _First=(Bad Ptr,-17891602),
std::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int * _Last=(Bad Ptr,-17891602),
std::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int * _Ptr=(Bad Ptr,1886220148)) Line 1105 + 0x18 bytes C++
myapp!std::vectorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int,std::allocatorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int ::operator=(const
std::vectorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int,std::allocatorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int_Right={...}) Line 582 + 0x1d bytes C++
0012bf74()
myapp.exe!activemq::core::ActiveMQSession::onDestroySessionResource(activemq::core::ActiveMQSessionResource
* resource=0x0001) Line 558 + 0x37 bytes C++
[jira] Commented: (AMQCPP-56) GCC warnings and possible SocketFactory bug on 64-bit Linux
[
https://issues.apache.org/activemq/browse/AMQCPP-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_38017
]
Albert Strasheim commented on AMQCPP-56:
GCC 4.1.1 doesn't seem to like the AMQCPP_UNUSED macro -- something about
__attribute__. You might consider simply leaving out the parameter name or
exception name. I think most compilers support that?
A few more warning I spotted:
{noformat}
activemq/io/DataInputStream.cpp:305: warning: comparison between signed and
unsigned integer expressions
activemq/io/BufferedOutputStream.cpp:92: warning: comparison between signed and
unsigned integer expressions
activemq/io/BufferedOutputStream.cpp:106: warning: comparison between signed
and unsigned integer expressions
activemq/connector/stomp/StompCommandReader.cpp:111: warning: comparison of
unsigned expression = 0 is always true
activemq/network/ServerSocket.cpp:157: warning: dereferencing type-punned
pointer might break strict-aliasing rules
activemq/network/ServerSocket.cpp:203: warning: dereferencing type-punned
pointer might break strict-aliasing rules
activemq/network/TcpSocket.cpp:190: warning: dereferencing type-punned pointer
might break strict-aliasing rules
activemq/network/SocketOutputStream.cpp:84: warning: comparison between signed
and unsigned integer expressions
{noformat}
Some of these might be inevitable signed-unsigned conversions, which probably
calls for some static_casts.
Not sure how to address those warnings in ServerSocket. I googled around a bit
but couldn't find a definite answer on how one should handle that cast.
GCC warnings and possible SocketFactory bug on 64-bit Linux
---
Key: AMQCPP-56
URL: https://issues.apache.org/activemq/browse/AMQCPP-56
Project: ActiveMQ C++ Client
Issue Type: Bug
Affects Versions: 2.0
Reporter: Albert Strasheim
Assigned To: Nathan Mittler
Priority: Minor
Fix For: 2.0
When compiling on 64-bit Linux with GCC 4.0.3, I see the following warnings:
{noformat}
activemq/concurrent/PooledThread.cpp:56: warning: 'task$first' may be used
uninitialized in this function
activemq/concurrent/PooledThread.cpp:56: warning: 'task$second' may be used
uninitialized in this function
activemq/network/SocketFactory.cpp:46: warning: comparison is always false
due to limited range of data type
activemq/connector/openwire/marshal/v2/ConnectionControlMarshaller.cpp:82:
warning: unused variable 'info'
activemq/connector/openwire/marshal/v2/IntegerResponseMarshaller.cpp:60:
warning: unused variable 'info'
activemq/connector/openwire/marshal/v2/ReplayCommandMarshaller.cpp:61:
warning: unused variable 'info'
activemq/connector/openwire/marshal/v2/ResponseMarshaller.cpp:60: warning:
unused variable 'info'
{noformat}
The first three warnings probably need to be looked at, especially the one in
SocketFactory.
In my opinion, AMQCPP is using ints and unsigned ints in places where
std::size_t might be more appropriate. MSVC's warning level 3 catches many of
these issues, so we might consider upping the warning level and properly
dealing with the type conversion issues: mostly use std::size_t and
static_cast where we really intend to convert. I can prepare a few patches
along these lines if you think this is worthwhile.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (AMQCPP-58) Possible memory leak when reestablishing connection
[
https://issues.apache.org/activemq/browse/AMQCPP-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Albert Strasheim updated AMQCPP-58:
---
Attachment: leaker.cpp
Program I'm using to check for leaks.
Possible memory leak when reestablishing connection
---
Key: AMQCPP-58
URL: https://issues.apache.org/activemq/browse/AMQCPP-58
Project: ActiveMQ C++ Client
Issue Type: Bug
Affects Versions: 2.0
Reporter: Albert Strasheim
Assigned To: Nathan Mittler
Fix For: 2.0
Attachments: leaker.cpp, purify-example.txt
Brought over from AMQCPP-46.
There seems to be a memory leak when running the example program from
AMQCPP-46 which reconnects whenever the broker goes down.
Valgrind says:
{noformat}
==15493== 149,520 (89,712 direct, 59,808 indirect) bytes in 1,869 blocks are
definitely lost in loss record 55 of 55
==15493==at 0x4A19DE3: operator new(unsigned long)
(vg_replace_malloc.c:168)
==15493==by 0x45DEDD:
activemq::network::SocketFactory::createSocket(activemq::util::Properties
const) (SocketFactory.cpp:96)
==15493==by 0x458D0C:
activemq::transport::TcpTransport::TcpTransport(activemq::util::Properties
const, activemq::transport::Transport*, bool) (TcpTransport.cpp:42)
==15493==by 0x42B3EE:
activemq::transport::TcpTransportFactory::createTransport(activemq::util::Properties
const) (TcpTransportFactory.cpp:55)
==15493==by 0x404CC0:
activemq::core::ActiveMQConnectionFactory::createConnection(std::string
const, std::string const, std::string const)
(ActiveMQConnectionFactory.cpp:130)
==15493==by 0x4042D5:
activemq::core::ActiveMQConnectionFactory::createConnection()
(ActiveMQConnectionFactory.cpp:69)
==15493==by 0x403D67: main (main.cpp:30)
{noformat}
Purify also seems to indicate that there is a link, along with with possibly
spurious leaks or leaks that might be related to the leak reported by
Valgrind.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (AMQCPP-58) Possible memory leak when reestablishing connection
[
https://issues.apache.org/activemq/browse/AMQCPP-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Albert Strasheim updated AMQCPP-58:
---
Attachment: socketleak1.diff
Patch for leak that happens when createConnection fails due to broker being
down.
This patch includes a type of fix for an issue that might also exist elsewhere
in the code: BufferedSocket wasn't properly initializing its pointer fields to
zero (and its other fields to useful default values), causing its destructor to
crash when deleting it (after connect had failed).
The program I attached previously still seems to leak when reestablishing
connections to the broker after it has been up and gone down. I just can't
figure out how this leaks yet.
Possible memory leak when reestablishing connection
---
Key: AMQCPP-58
URL: https://issues.apache.org/activemq/browse/AMQCPP-58
Project: ActiveMQ C++ Client
Issue Type: Bug
Affects Versions: 2.0
Reporter: Albert Strasheim
Assigned To: Nathan Mittler
Fix For: 2.0
Attachments: leaker.cpp, purify-example.txt, socketleak1.diff
Brought over from AMQCPP-46.
There seems to be a memory leak when running the example program from
AMQCPP-46 which reconnects whenever the broker goes down.
Valgrind says:
{noformat}
==15493== 149,520 (89,712 direct, 59,808 indirect) bytes in 1,869 blocks are
definitely lost in loss record 55 of 55
==15493==at 0x4A19DE3: operator new(unsigned long)
(vg_replace_malloc.c:168)
==15493==by 0x45DEDD:
activemq::network::SocketFactory::createSocket(activemq::util::Properties
const) (SocketFactory.cpp:96)
==15493==by 0x458D0C:
activemq::transport::TcpTransport::TcpTransport(activemq::util::Properties
const, activemq::transport::Transport*, bool) (TcpTransport.cpp:42)
==15493==by 0x42B3EE:
activemq::transport::TcpTransportFactory::createTransport(activemq::util::Properties
const) (TcpTransportFactory.cpp:55)
==15493==by 0x404CC0:
activemq::core::ActiveMQConnectionFactory::createConnection(std::string
const, std::string const, std::string const)
(ActiveMQConnectionFactory.cpp:130)
==15493==by 0x4042D5:
activemq::core::ActiveMQConnectionFactory::createConnection()
(ActiveMQConnectionFactory.cpp:69)
==15493==by 0x403D67: main (main.cpp:30)
{noformat}
Purify also seems to indicate that there is a link, along with with possibly
spurious leaks or leaks that might be related to the leak reported by
Valgrind.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (AMQCPP-58) Possible memory leak when reestablishing connection
[
https://issues.apache.org/activemq/browse/AMQCPP-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_38020
]
Albert Strasheim commented on AMQCPP-58:
After applying socketleak1.diff, I still see a leak when I start the broker,
then start leaker, then kill the broker, then start the broker. The
reconnection that happens at this points seems to cause a leak somehow.
Valgrind says:
{noformat}
==3855== 20,316 (28 direct, 20,288 indirect) bytes in 1 blocks are definitely
lost in loss record 29 of 60
==3855==at 0x4005BA5: operator new(unsigned) (vg_replace_malloc.c:163)
==3855==by 0x80A43E2:
activemq::network::SocketFactory::createSocket(activemq::util::Properties
const) (SocketFactory.cpp:96)
==3855==by 0x809EF05:
activemq::transport::TcpTransport::TcpTransport(activemq::util::Properties
const, activemq::transport::Transport*, bool) (TcpTransport.cpp:42)
==3855==by 0x80716E2:
activemq::transport::TcpTransportFactory::createTransport(activemq::util::Properties
const) (TcpTransportFactory.cpp:55)
==3855==by 0x804B4B5:
activemq::core::ActiveMQConnectionFactory::createConnection(std::string const,
std::string const, std::string const) (ActiveMQConnectionFactory.cpp:130)
==3855==by 0x804B2B5:
activemq::core::ActiveMQConnectionFactory::createConnection()
(ActiveMQConnectionFactory.cpp:69)
==3855==by 0x804AC5D: main (main.cpp:29)
{noformat}
Possible memory leak when reestablishing connection
---
Key: AMQCPP-58
URL: https://issues.apache.org/activemq/browse/AMQCPP-58
Project: ActiveMQ C++ Client
Issue Type: Bug
Affects Versions: 2.0
Reporter: Albert Strasheim
Assigned To: Nathan Mittler
Fix For: 2.0
Attachments: leaker.cpp, purify-example.txt, socketleak1.diff
Brought over from AMQCPP-46.
There seems to be a memory leak when running the example program from
AMQCPP-46 which reconnects whenever the broker goes down.
Valgrind says:
{noformat}
==15493== 149,520 (89,712 direct, 59,808 indirect) bytes in 1,869 blocks are
definitely lost in loss record 55 of 55
==15493==at 0x4A19DE3: operator new(unsigned long)
(vg_replace_malloc.c:168)
==15493==by 0x45DEDD:
activemq::network::SocketFactory::createSocket(activemq::util::Properties
const) (SocketFactory.cpp:96)
==15493==by 0x458D0C:
activemq::transport::TcpTransport::TcpTransport(activemq::util::Properties
const, activemq::transport::Transport*, bool) (TcpTransport.cpp:42)
==15493==by 0x42B3EE:
activemq::transport::TcpTransportFactory::createTransport(activemq::util::Properties
const) (TcpTransportFactory.cpp:55)
==15493==by 0x404CC0:
activemq::core::ActiveMQConnectionFactory::createConnection(std::string
const, std::string const, std::string const)
(ActiveMQConnectionFactory.cpp:130)
==15493==by 0x4042D5:
activemq::core::ActiveMQConnectionFactory::createConnection()
(ActiveMQConnectionFactory.cpp:69)
==15493==by 0x403D67: main (main.cpp:30)
{noformat}
Purify also seems to indicate that there is a link, along with with possibly
spurious leaks or leaks that might be related to the leak reported by
Valgrind.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (AMQCPP-46) ActiveMQConnection doesn't propagate exception listener to underlying connector
[
https://issues.apache.org/activemq/browse/AMQCPP-46?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_37999
]
Albert Strasheim commented on AMQCPP-46:
I did an svn update and got the fix you made to Set.h. I cleaned my solution
(release and debug) and did a batch build.
Still seeing the crash though. Here's how to reproduce it (I hope):
1. Don't run the broker yet.
2. Run the code I provided. It keeps trying to connect to the broker. It prints:
Got an exception: Socket::connect - A request to send or receive data was
disallowed because the socket is not connected and (when sending on a datagram
socket using a sendto call) no address was supplied.
3. Start the broker. The program stops printing.
4. Ctrl-C the broker or Close the command prompt window in which it runs.
5. Wait about 3 seconds.
6. Crash happens.
ActiveMQConnection doesn't propagate exception listener to underlying
connector
---
Key: AMQCPP-46
URL: https://issues.apache.org/activemq/browse/AMQCPP-46
Project: ActiveMQ C++ Client
Issue Type: Bug
Affects Versions: 1.1
Reporter: Albert Strasheim
Assigned To: Nathan Mittler
Fix For: 2.0
Attachments: amqconn-exlistener.diff, main.cpp
My program is doing the following:
# Create connection using ActiveMQConnectionFactory
# Set a simple exception listener that sets a boolean flag
# Block in receive on consumer
If I then kill the broker, various exceptions happen, but they are never sent
to the exception listener, because the exception listener in StompConnector
is null. It seems to me that ActiveMQConnection should set and get its
exception listener on its underlying connector and probably doesn't have to
contain a pointer to the listener itself.
If I change ActiveMQConnection as in the attached patch to also set the
exception listener on the underlying connector, my exception listener gets
called when the broker dies.
Once I detect the failure, I delete the producer, consumer, session and
connection that failed. Looks like an uncaught exception is getting thrown
during the destruction of the producer (which is the first thing I delete
when cleaning up). The problem here is probably that the connection is trying
to close down a socket that is already broken and something goes awry. I'm
not quite sure how to fix this problem.
Stack trace (with useless bits stripped out):
{noformat}
kernel32.dll!7c812a5b()
[Frames below may be incorrect and/or missing, no symbols loaded for
kernel32.dll]
kernel32.dll!7c812a5b()
myapp.exe!std::vectorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int,std::allocatorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int
::_Ucopystd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int
*(std::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int *
_First=(..\src\main\activemq\connector\stomp\StompSessionManager.cpp,254),
std::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int * _Last=(Bad Ptr,14297048),
std::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int *
_Ptr=(..\src\main\activemq\connector\stomp\StompSessionManager.cpp,254))
Line 1105 + 0x18 bytes C++
myapp.exe!std::vectorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int,std::allocatorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int ::operator=(const
std::vectorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int,std::allocatorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int_Right={...}) Line 582 + 0x1d bytes C++
0012b920()
myapp.exe!activemq::core::ActiveMQConsumer::close() Line 84 + 0x34
bytes C++
msvcr80d.dll!102418b7()
...
kernel32.dll!7c812a5b()
myapp.exe!std::vectorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int,std::allocatorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int
::_Ucopystd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int
*(std::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int * _First=(Bad Ptr,-17891602),
std::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int * _Last=(Bad Ptr,-17891602),
std::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int * _Ptr=(Bad Ptr,1886220148)) Line 1105 + 0x18 bytes C++
myapp!std::vectorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
[jira] Updated: (AMQCPP-46) ActiveMQConnection doesn't propagate exception listener to underlying connector
[
https://issues.apache.org/activemq/browse/AMQCPP-46?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Albert Strasheim updated AMQCPP-46:
---
Attachment: purify-example.txt
Purify output after letting the example I provided reconnect a few times (i.e.
I start and stop the broker). This is when running on Windows. Shows a few
possible memory leaks, but many of these might be false positives. I'll comment
now with what Valgrind says.
ActiveMQConnection doesn't propagate exception listener to underlying
connector
---
Key: AMQCPP-46
URL: https://issues.apache.org/activemq/browse/AMQCPP-46
Project: ActiveMQ C++ Client
Issue Type: Bug
Affects Versions: 1.1
Reporter: Albert Strasheim
Assigned To: Nathan Mittler
Fix For: 2.0
Attachments: amqconn-exlistener.diff, main.cpp, purify-example.txt
My program is doing the following:
# Create connection using ActiveMQConnectionFactory
# Set a simple exception listener that sets a boolean flag
# Block in receive on consumer
If I then kill the broker, various exceptions happen, but they are never sent
to the exception listener, because the exception listener in StompConnector
is null. It seems to me that ActiveMQConnection should set and get its
exception listener on its underlying connector and probably doesn't have to
contain a pointer to the listener itself.
If I change ActiveMQConnection as in the attached patch to also set the
exception listener on the underlying connector, my exception listener gets
called when the broker dies.
Once I detect the failure, I delete the producer, consumer, session and
connection that failed. Looks like an uncaught exception is getting thrown
during the destruction of the producer (which is the first thing I delete
when cleaning up). The problem here is probably that the connection is trying
to close down a socket that is already broken and something goes awry. I'm
not quite sure how to fix this problem.
Stack trace (with useless bits stripped out):
{noformat}
kernel32.dll!7c812a5b()
[Frames below may be incorrect and/or missing, no symbols loaded for
kernel32.dll]
kernel32.dll!7c812a5b()
myapp.exe!std::vectorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int,std::allocatorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int
::_Ucopystd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int
*(std::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int *
_First=(..\src\main\activemq\connector\stomp\StompSessionManager.cpp,254),
std::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int * _Last=(Bad Ptr,14297048),
std::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int *
_Ptr=(..\src\main\activemq\connector\stomp\StompSessionManager.cpp,254))
Line 1105 + 0x18 bytes C++
myapp.exe!std::vectorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int,std::allocatorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int ::operator=(const
std::vectorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int,std::allocatorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int_Right={...}) Line 582 + 0x1d bytes C++
0012b920()
myapp.exe!activemq::core::ActiveMQConsumer::close() Line 84 + 0x34
bytes C++
msvcr80d.dll!102418b7()
...
kernel32.dll!7c812a5b()
myapp.exe!std::vectorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int,std::allocatorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int
::_Ucopystd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int
*(std::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int * _First=(Bad Ptr,-17891602),
std::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int * _Last=(Bad Ptr,-17891602),
std::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int * _Ptr=(Bad Ptr,1886220148)) Line 1105 + 0x18 bytes C++
myapp!std::vectorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int,std::allocatorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int ::operator=(const
std::vectorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int,std::allocatorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int_Right={...}) Line 582 + 0x1d bytes C++
0012bf74()
[jira] Commented: (AMQCPP-46) ActiveMQConnection doesn't propagate exception listener to underlying connector
[
https://issues.apache.org/activemq/browse/AMQCPP-46?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_38004
]
Albert Strasheim commented on AMQCPP-46:
Example looks good on Windows and Linux for me.
Valgrind reports the following memory leak (only one, in contrast to all those
reported by Purify, which might all be from this one leak):
{noformat}
==15493== 149,520 (89,712 direct, 59,808 indirect) bytes in 1,869 blocks are
definitely lost in loss record 55 of 55
==15493==at 0x4A19DE3: operator new(unsigned long) (vg_replace_malloc.c:168)
==15493==by 0x45DEDD:
activemq::network::SocketFactory::createSocket(activemq::util::Properties
const) (SocketFactory.cpp:96)
==15493==by 0x458D0C:
activemq::transport::TcpTransport::TcpTransport(activemq::util::Properties
const, activemq::transport::Transport*, bool) (TcpTransport.cpp:42)
==15493==by 0x42B3EE:
activemq::transport::TcpTransportFactory::createTransport(activemq::util::Properties
const) (TcpTransportFactory.cpp:55)
==15493==by 0x404CC0:
activemq::core::ActiveMQConnectionFactory::createConnection(std::string const,
std::string const, std::string const) (ActiveMQConnectionFactory.cpp:130)
==15493==by 0x4042D5:
activemq::core::ActiveMQConnectionFactory::createConnection()
(ActiveMQConnectionFactory.cpp:69)
==15493==by 0x403D67: main (main.cpp:30)
{noformat}
This leak happens when I start and stop the broker repeatedly, causing the
example to reconnect a few times. I do a delete connection in the example, so
it would seem that something isn't cleaning up properly in its destructor?
Thanks very much for sorting out this issue. It's been a tough one! :-)
ActiveMQConnection doesn't propagate exception listener to underlying
connector
---
Key: AMQCPP-46
URL: https://issues.apache.org/activemq/browse/AMQCPP-46
Project: ActiveMQ C++ Client
Issue Type: Bug
Affects Versions: 1.1
Reporter: Albert Strasheim
Assigned To: Nathan Mittler
Fix For: 2.0
Attachments: amqconn-exlistener.diff, main.cpp, purify-example.txt
My program is doing the following:
# Create connection using ActiveMQConnectionFactory
# Set a simple exception listener that sets a boolean flag
# Block in receive on consumer
If I then kill the broker, various exceptions happen, but they are never sent
to the exception listener, because the exception listener in StompConnector
is null. It seems to me that ActiveMQConnection should set and get its
exception listener on its underlying connector and probably doesn't have to
contain a pointer to the listener itself.
If I change ActiveMQConnection as in the attached patch to also set the
exception listener on the underlying connector, my exception listener gets
called when the broker dies.
Once I detect the failure, I delete the producer, consumer, session and
connection that failed. Looks like an uncaught exception is getting thrown
during the destruction of the producer (which is the first thing I delete
when cleaning up). The problem here is probably that the connection is trying
to close down a socket that is already broken and something goes awry. I'm
not quite sure how to fix this problem.
Stack trace (with useless bits stripped out):
{noformat}
kernel32.dll!7c812a5b()
[Frames below may be incorrect and/or missing, no symbols loaded for
kernel32.dll]
kernel32.dll!7c812a5b()
myapp.exe!std::vectorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int,std::allocatorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int
::_Ucopystd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int
*(std::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int *
_First=(..\src\main\activemq\connector\stomp\StompSessionManager.cpp,254),
std::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int * _Last=(Bad Ptr,14297048),
std::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int *
_Ptr=(..\src\main\activemq\connector\stomp\StompSessionManager.cpp,254))
Line 1105 + 0x18 bytes C++
myapp.exe!std::vectorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int,std::allocatorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int ::operator=(const
std::vectorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int,std::allocatorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int_Right={...}) Line 582 + 0x1d bytes C++
0012b920()
myapp.exe!activemq::core::ActiveMQConsumer::close() Line 84 + 0x34
bytes
[jira] Commented: (AMQCPP-46) ActiveMQConnection doesn't propagate exception listener to underlying connector
[
https://issues.apache.org/activemq/browse/AMQCPP-46?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_37981
]
Albert Strasheim commented on AMQCPP-46:
Running the crashing program repeatedly sometimes makes it crash with the
following stack:
{noformat}
vs2005-activemq-example.exe!activemq::core::ActiveMQSession::getAcknowledgeMode()
Line 465 + 0x17 bytesC++
vs2005-activemq-example.exe!activemq::core::ActiveMQConsumer::dispatch(activemq::core::ActiveMQMessage
* message=0x00b42428) Line 395 + 0x19 bytes C++
vs2005-activemq-example.exe!activemq::core::ActiveMQConsumer::onActiveMQMessage(activemq::core::ActiveMQMessage
* message=0x00b42428) Line 449 + 0x1b bytesC++
vs2005-activemq-example.exe!activemq::core::ActiveMQConnection::onConsumerMessage(activemq::connector::ConsumerInfo
* consumer=0x00b40af0, activemq::core::ActiveMQMessage * message=0x00b42428)
Line 196 C++
vs2005-activemq-example.exe!activemq::connector::stomp::StompSessionManager::onStompCommand(activemq::connector::stomp::commands::StompCommand
* command=0x00b410d0) Line 329 C++
vs2005-activemq-example.exe!activemq::connector::stomp::StompConnector::onCommand(activemq::transport::Command
* command=0x00b410d4) Line 781 C++
vs2005-activemq-example.exe!activemq::transport::TransportFilter::fire(activemq::transport::Command
* command=0x00b410d4) Line 88 C++
vs2005-activemq-example.exe!activemq::transport::ResponseCorrelator::onCommand(activemq::transport::Command
* command=0x00b410d4) Line 168 C++
vs2005-activemq-example.exe!activemq::transport::TransportFilter::fire(activemq::transport::Command
* command=0x00b410d4) Line 88 C++
vs2005-activemq-example.exe!activemq::transport::TransportFilter::onCommand(activemq::transport::Command
* command=0x00b410d4) Line 127C++
vs2005-activemq-example.exe!activemq::transport::IOTransport::fire(activemq::transport::Command
* command=0x00b410d4) Line 125 + 0x17 bytesC++
vs2005-activemq-example.exe!activemq::transport::IOTransport::run()
Line 161 C++
vs2005-activemq-example.exe!activemq::concurrent::Thread::runCallback(void *
param=0x0035f2f8) Line 152 + 0x13 bytes C++
msvcr80d.dll!102047c1()
[Frames below may be incorrect and/or missing, no symbols loaded for
msvcr80d.dll]
msvcr80d.dll!10204767()
kernel32.dll!7c80b683()
{noformat}
Seems the threads are stepping on each other when shutting down.
ActiveMQConnection doesn't propagate exception listener to underlying
connector
---
Key: AMQCPP-46
URL: https://issues.apache.org/activemq/browse/AMQCPP-46
Project: ActiveMQ C++ Client
Issue Type: Bug
Affects Versions: 1.1
Reporter: Albert Strasheim
Assigned To: Nathan Mittler
Fix For: 2.0
Attachments: amqconn-exlistener.diff, main.cpp
My program is doing the following:
# Create connection using ActiveMQConnectionFactory
# Set a simple exception listener that sets a boolean flag
# Block in receive on consumer
If I then kill the broker, various exceptions happen, but they are never sent
to the exception listener, because the exception listener in StompConnector
is null. It seems to me that ActiveMQConnection should set and get its
exception listener on its underlying connector and probably doesn't have to
contain a pointer to the listener itself.
If I change ActiveMQConnection as in the attached patch to also set the
exception listener on the underlying connector, my exception listener gets
called when the broker dies.
Once I detect the failure, I delete the producer, consumer, session and
connection that failed. Looks like an uncaught exception is getting thrown
during the destruction of the producer (which is the first thing I delete
when cleaning up). The problem here is probably that the connection is trying
to close down a socket that is already broken and something goes awry. I'm
not quite sure how to fix this problem.
Stack trace (with useless bits stripped out):
{noformat}
kernel32.dll!7c812a5b()
[Frames below may be incorrect and/or missing, no symbols loaded for
kernel32.dll]
kernel32.dll!7c812a5b()
myapp.exe!std::vectorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int,std::allocatorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int
::_Ucopystd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int
*(std::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int *
[jira] Commented: (AMQCPP-46) ActiveMQConnection doesn't propagate exception listener to underlying connector
[
https://issues.apache.org/activemq/browse/AMQCPP-46?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_37984
]
Albert Strasheim commented on AMQCPP-46:
I don't know if this would be hard to implement, but it seems to me that one
might want to support closing of a session without having to close all its
consumers beforehand and closing of a connection without having to close all
its sessions beforehand.
I accept that one has to delete all the stuff you make in the reverse order
since data belonging to a session is shared by its consumers, etc. As you
noted, destruction will close the object being destroyed, but if it so happens
that the parent (be it a session for a consumer or a connection for a session)
has been closed, close in the destructor does nothing.
As far as I remember the JMS specification doesn't say anything about the order
in which one has to close stuff (I could be wrong here), so I'm thinking the
C++ implementation shouldn't impose a restriction either?
Are there fundamental reasons why close session to close all consumers and
close connection to close all sessions (which closes all consumers) can't or
shouldn't work?
Thanks!
ActiveMQConnection doesn't propagate exception listener to underlying
connector
---
Key: AMQCPP-46
URL: https://issues.apache.org/activemq/browse/AMQCPP-46
Project: ActiveMQ C++ Client
Issue Type: Bug
Affects Versions: 1.1
Reporter: Albert Strasheim
Assigned To: Nathan Mittler
Fix For: 2.0
Attachments: amqconn-exlistener.diff, main.cpp
My program is doing the following:
# Create connection using ActiveMQConnectionFactory
# Set a simple exception listener that sets a boolean flag
# Block in receive on consumer
If I then kill the broker, various exceptions happen, but they are never sent
to the exception listener, because the exception listener in StompConnector
is null. It seems to me that ActiveMQConnection should set and get its
exception listener on its underlying connector and probably doesn't have to
contain a pointer to the listener itself.
If I change ActiveMQConnection as in the attached patch to also set the
exception listener on the underlying connector, my exception listener gets
called when the broker dies.
Once I detect the failure, I delete the producer, consumer, session and
connection that failed. Looks like an uncaught exception is getting thrown
during the destruction of the producer (which is the first thing I delete
when cleaning up). The problem here is probably that the connection is trying
to close down a socket that is already broken and something goes awry. I'm
not quite sure how to fix this problem.
Stack trace (with useless bits stripped out):
{noformat}
kernel32.dll!7c812a5b()
[Frames below may be incorrect and/or missing, no symbols loaded for
kernel32.dll]
kernel32.dll!7c812a5b()
myapp.exe!std::vectorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int,std::allocatorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int
::_Ucopystd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int
*(std::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int *
_First=(..\src\main\activemq\connector\stomp\StompSessionManager.cpp,254),
std::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int * _Last=(Bad Ptr,14297048),
std::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int *
_Ptr=(..\src\main\activemq\connector\stomp\StompSessionManager.cpp,254))
Line 1105 + 0x18 bytes C++
myapp.exe!std::vectorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int,std::allocatorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int ::operator=(const
std::vectorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int,std::allocatorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int_Right={...}) Line 582 + 0x1d bytes C++
0012b920()
myapp.exe!activemq::core::ActiveMQConsumer::close() Line 84 + 0x34
bytes C++
msvcr80d.dll!102418b7()
...
kernel32.dll!7c812a5b()
myapp.exe!std::vectorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int,std::allocatorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int
::_Ucopystd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int
*(std::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int * _First=(Bad Ptr,-17891602),
[jira] Commented: (AMQCPP-46) ActiveMQConnection doesn't propagate exception listener to underlying connector
[
https://issues.apache.org/activemq/browse/AMQCPP-46?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_37987
]
Albert Strasheim commented on AMQCPP-46:
I realise that C++ isn't Java but it seems that close and the destructor have
different responsibilities. Closing a consumer prevents it from receiving any
more messages. Closing a session prevents all its consumers from receiving any
more messages. Closing a connection prevents all its sessions from receiving
any more messages. Deleting consumers, sessions and connections (in that
order), free the resources allocated for these objects.
Are there data structures inside a session that can only be deleted by close
(i.e. can't be left over until the destructor is called)?
I'm asking about these issues with a view to the Python wrappers I'm working
on. Boost.Python makes it very easy to control object lifetimes (e.g. keeping a
reference to a session as long as any consumers made from it are still
referenced), but it becomes a lot harder to enforce close order with the
library as it is currently. If close on a session must delete stuff that
invalidates consumers made from it, it would be very useful if the consumers
could at least throw an IllegalStateException when you try to close them
instead of crashing randomly.
Thanks again.
ActiveMQConnection doesn't propagate exception listener to underlying
connector
---
Key: AMQCPP-46
URL: https://issues.apache.org/activemq/browse/AMQCPP-46
Project: ActiveMQ C++ Client
Issue Type: Bug
Affects Versions: 1.1
Reporter: Albert Strasheim
Assigned To: Nathan Mittler
Fix For: 2.0
Attachments: amqconn-exlistener.diff, main.cpp
My program is doing the following:
# Create connection using ActiveMQConnectionFactory
# Set a simple exception listener that sets a boolean flag
# Block in receive on consumer
If I then kill the broker, various exceptions happen, but they are never sent
to the exception listener, because the exception listener in StompConnector
is null. It seems to me that ActiveMQConnection should set and get its
exception listener on its underlying connector and probably doesn't have to
contain a pointer to the listener itself.
If I change ActiveMQConnection as in the attached patch to also set the
exception listener on the underlying connector, my exception listener gets
called when the broker dies.
Once I detect the failure, I delete the producer, consumer, session and
connection that failed. Looks like an uncaught exception is getting thrown
during the destruction of the producer (which is the first thing I delete
when cleaning up). The problem here is probably that the connection is trying
to close down a socket that is already broken and something goes awry. I'm
not quite sure how to fix this problem.
Stack trace (with useless bits stripped out):
{noformat}
kernel32.dll!7c812a5b()
[Frames below may be incorrect and/or missing, no symbols loaded for
kernel32.dll]
kernel32.dll!7c812a5b()
myapp.exe!std::vectorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int,std::allocatorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int
::_Ucopystd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int
*(std::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int *
_First=(..\src\main\activemq\connector\stomp\StompSessionManager.cpp,254),
std::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int * _Last=(Bad Ptr,14297048),
std::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int *
_Ptr=(..\src\main\activemq\connector\stomp\StompSessionManager.cpp,254))
Line 1105 + 0x18 bytes C++
myapp.exe!std::vectorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int,std::allocatorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int ::operator=(const
std::vectorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int,std::allocatorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int_Right={...}) Line 582 + 0x1d bytes C++
0012b920()
myapp.exe!activemq::core::ActiveMQConsumer::close() Line 84 + 0x34
bytes C++
msvcr80d.dll!102418b7()
...
kernel32.dll!7c812a5b()
myapp.exe!std::vectorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int,std::allocatorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int
[jira] Commented: (AMQCPP-46) ActiveMQConnection doesn't propagate exception listener to underlying connector
[
https://issues.apache.org/activemq/browse/AMQCPP-46?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_37992
]
Albert Strasheim commented on AMQCPP-46:
Thanks very much. I'll try it out in our application tomorrow. According to
page 57 of the 1.1 spec, closing a connection should also cause consumers to
close (and those blocking on receive to return null or a message). Will it be
possible to add this as well?
ActiveMQConnection doesn't propagate exception listener to underlying
connector
---
Key: AMQCPP-46
URL: https://issues.apache.org/activemq/browse/AMQCPP-46
Project: ActiveMQ C++ Client
Issue Type: Bug
Affects Versions: 1.1
Reporter: Albert Strasheim
Assigned To: Nathan Mittler
Fix For: 2.0
Attachments: amqconn-exlistener.diff, main.cpp
My program is doing the following:
# Create connection using ActiveMQConnectionFactory
# Set a simple exception listener that sets a boolean flag
# Block in receive on consumer
If I then kill the broker, various exceptions happen, but they are never sent
to the exception listener, because the exception listener in StompConnector
is null. It seems to me that ActiveMQConnection should set and get its
exception listener on its underlying connector and probably doesn't have to
contain a pointer to the listener itself.
If I change ActiveMQConnection as in the attached patch to also set the
exception listener on the underlying connector, my exception listener gets
called when the broker dies.
Once I detect the failure, I delete the producer, consumer, session and
connection that failed. Looks like an uncaught exception is getting thrown
during the destruction of the producer (which is the first thing I delete
when cleaning up). The problem here is probably that the connection is trying
to close down a socket that is already broken and something goes awry. I'm
not quite sure how to fix this problem.
Stack trace (with useless bits stripped out):
{noformat}
kernel32.dll!7c812a5b()
[Frames below may be incorrect and/or missing, no symbols loaded for
kernel32.dll]
kernel32.dll!7c812a5b()
myapp.exe!std::vectorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int,std::allocatorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int
::_Ucopystd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int
*(std::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int *
_First=(..\src\main\activemq\connector\stomp\StompSessionManager.cpp,254),
std::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int * _Last=(Bad Ptr,14297048),
std::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int *
_Ptr=(..\src\main\activemq\connector\stomp\StompSessionManager.cpp,254))
Line 1105 + 0x18 bytes C++
myapp.exe!std::vectorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int,std::allocatorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int ::operator=(const
std::vectorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int,std::allocatorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int_Right={...}) Line 582 + 0x1d bytes C++
0012b920()
myapp.exe!activemq::core::ActiveMQConsumer::close() Line 84 + 0x34
bytes C++
msvcr80d.dll!102418b7()
...
kernel32.dll!7c812a5b()
myapp.exe!std::vectorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int,std::allocatorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int
::_Ucopystd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int
*(std::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int * _First=(Bad Ptr,-17891602),
std::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int * _Last=(Bad Ptr,-17891602),
std::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int * _Ptr=(Bad Ptr,1886220148)) Line 1105 + 0x18 bytes C++
myapp!std::vectorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int,std::allocatorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int ::operator=(const
std::vectorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int,std::allocatorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int_Right={...}) Line 582 + 0x1d bytes C++
0012bf74()
[jira] Commented: (AMQCPP-46) ActiveMQConnection doesn't propagate exception listener to underlying connector
[
https://issues.apache.org/activemq/browse/AMQCPP-46?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_37997
]
Albert Strasheim commented on AMQCPP-46:
Still seeing a crash on Windows when running the example I provided on 17 Jan.
Stack looks like this:
{noformat}
msvcr80d.dll!10202b13()
[Frames below may be incorrect and/or missing, no symbols loaded for
msvcr80d.dll]
msvcr80d.dll!1021866b()
...
kernel32.dll!7c812a5b()
vs2005-activemq-example.exe!std::vectorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int,std::allocatorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int
::_Ucopystd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int
*(std::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int * _First=0xe06d7363,
std::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int * _Last=0x0001,
std::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int * _Ptr=0x0003) Line 1105 + 0x18 bytes C++
msvcr80d.dll!10243990()
vs2005-activemq-example.exe!activemq::transport::IOTransport::close()
Line 145 + 0x37 bytesC++
msvcr80d.dll!102418b7()
...
msvcr80d.dll!10243990()
vs2005-activemq-example.exe!activemq::network::SocketOutputStream::write(const
unsigned char * buffer=0x00b73af8, int len=83) Line 90 + 0x58 bytes C++
vs2005-activemq-example.exe!activemq::io::BufferedOutputStream::emptyBuffer()
Line 76 C++
vs2005-activemq-example.exe!activemq::io::BufferedOutputStream::flush()
Line 86C++
vs2005-activemq-example.exe!activemq::io::BufferedOutputStream::close()
Line 67C++
vs2005-activemq-example.exe!activemq::transport::IOTransport::close()
Line 142 C++
vs2005-activemq-example.exe!activemq::transport::IOTransport::~IOTransport()
Line 49 C++
vs2005-activemq-example.exe!activemq::transport::IOTransport::`scalar
deleting destructor'() + 0xf bytes C++
vs2005-activemq-example.exe!activemq::transport::TransportFilter::~TransportFilter()
Line 115 + 0x23 bytes C++
vs2005-activemq-example.exe!activemq::transport::TcpTransport::~TcpTransport()
Line 72 + 0xf bytes C++
vs2005-activemq-example.exe!activemq::transport::TcpTransport::`scalar
deleting destructor'() + 0xf bytes C++
vs2005-activemq-example.exe!activemq::transport::TransportFilter::~TransportFilter()
Line 115 + 0x23 bytes C++
msvcr80d.dll!10243137()
...
kernel32.dll!7c812a5b()
vs2005-activemq-example.exe!std::vectorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int,std::allocatorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int
::_Ucopystd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int
*(std::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int * _First=0xe06d7363,
std::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int * _Last=0x0001,
std::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int * _Ptr=0x0003) Line 1105 + 0x18 bytes C++
msvcr80d.dll!10243990()
vs2005-activemq-example.exe!activemq::transport::IOTransport::close()
Line 145 + 0x37 bytesC++
msvcr80d.dll!102418b7()
...
msvcr80d.dll!10243990()
vs2005-activemq-example.exe!activemq::network::SocketOutputStream::write(const
unsigned char * buffer=0x00b73af8, int len=83) Line 90 + 0x58 bytes C++
vs2005-activemq-example.exe!activemq::io::BufferedOutputStream::emptyBuffer()
Line 76 C++
vs2005-activemq-example.exe!activemq::io::BufferedOutputStream::flush()
Line 86C++
vs2005-activemq-example.exe!activemq::io::BufferedOutputStream::close()
Line 67C++
vs2005-activemq-example.exe!activemq::transport::IOTransport::close()
Line 142 C++
vs2005-activemq-example.exe!activemq::transport::TransportFilter::close() Line
224 C++
vs2005-activemq-example.exe!activemq::transport::ResponseCorrelator::close()
Line 259 C++
vs2005-activemq-example.exe!activemq::transport::ResponseCorrelator::~ResponseCorrelator()
Line 61 C++
vs2005-activemq-example.exe!activemq::transport::ResponseCorrelator::`scalar
deleting destructor'() + 0xf bytesC++
vs2005-activemq-example.exe!activemq::core::ActiveMQConnectionData::close()
Line 123 + 0x38 bytes C++
vs2005-activemq-example.exe!activemq::core::ActiveMQConnectionData::~ActiveMQConnectionData()
Line 77 C++
[jira] Reopened: (AMQCPP-46) ActiveMQConnection doesn't propagate exception listener to underlying connector
[
https://issues.apache.org/activemq/browse/AMQCPP-46?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Albert Strasheim reopened AMQCPP-46:
ActiveMQConnection doesn't propagate exception listener to underlying
connector
---
Key: AMQCPP-46
URL: https://issues.apache.org/activemq/browse/AMQCPP-46
Project: ActiveMQ C++ Client
Issue Type: Bug
Affects Versions: 1.1
Reporter: Albert Strasheim
Assigned To: Nathan Mittler
Fix For: 2.0
Attachments: amqconn-exlistener.diff, main.cpp
My program is doing the following:
# Create connection using ActiveMQConnectionFactory
# Set a simple exception listener that sets a boolean flag
# Block in receive on consumer
If I then kill the broker, various exceptions happen, but they are never sent
to the exception listener, because the exception listener in StompConnector
is null. It seems to me that ActiveMQConnection should set and get its
exception listener on its underlying connector and probably doesn't have to
contain a pointer to the listener itself.
If I change ActiveMQConnection as in the attached patch to also set the
exception listener on the underlying connector, my exception listener gets
called when the broker dies.
Once I detect the failure, I delete the producer, consumer, session and
connection that failed. Looks like an uncaught exception is getting thrown
during the destruction of the producer (which is the first thing I delete
when cleaning up). The problem here is probably that the connection is trying
to close down a socket that is already broken and something goes awry. I'm
not quite sure how to fix this problem.
Stack trace (with useless bits stripped out):
{noformat}
kernel32.dll!7c812a5b()
[Frames below may be incorrect and/or missing, no symbols loaded for
kernel32.dll]
kernel32.dll!7c812a5b()
myapp.exe!std::vectorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int,std::allocatorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int
::_Ucopystd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int
*(std::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int *
_First=(..\src\main\activemq\connector\stomp\StompSessionManager.cpp,254),
std::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int * _Last=(Bad Ptr,14297048),
std::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int *
_Ptr=(..\src\main\activemq\connector\stomp\StompSessionManager.cpp,254))
Line 1105 + 0x18 bytes C++
myapp.exe!std::vectorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int,std::allocatorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int ::operator=(const
std::vectorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int,std::allocatorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int_Right={...}) Line 582 + 0x1d bytes C++
0012b920()
myapp.exe!activemq::core::ActiveMQConsumer::close() Line 84 + 0x34
bytes C++
msvcr80d.dll!102418b7()
...
kernel32.dll!7c812a5b()
myapp.exe!std::vectorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int,std::allocatorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int
::_Ucopystd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int
*(std::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int * _First=(Bad Ptr,-17891602),
std::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int * _Last=(Bad Ptr,-17891602),
std::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int * _Ptr=(Bad Ptr,1886220148)) Line 1105 + 0x18 bytes C++
myapp!std::vectorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int,std::allocatorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int ::operator=(const
std::vectorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int,std::allocatorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int_Right={...}) Line 582 + 0x1d bytes C++
0012bf74()
myapp.exe!activemq::core::ActiveMQSession::onDestroySessionResource(activemq::core::ActiveMQSessionResource
* resource=0x0001) Line 558 + 0x37 bytes C++
msvcr80d.dll!10241a10()
...
kernel32.dll!7c812a5b()
[jira] Created: (AMQCPP-51) Autoconf is not properly setting CXXFLAGS on Linux
Autoconf is not properly setting CXXFLAGS on Linux
--
Key: AMQCPP-51
URL: https://issues.apache.org/activemq/browse/AMQCPP-51
Project: ActiveMQ C++ Client
Issue Type: Bug
Affects Versions: 2.0
Reporter: Albert Strasheim
Assigned To: Nathan Mittler
I'm running Fedora Core 6 with autoconf 2.59 and automake 1.9.6.
It seems the CXXFLAGS stuff in configure.ac isn't actually setting CXXFLAGS
used to compile.
If you check the generated src/main/Makefile, you'll only see:
{noformat}
CXXFLAGS = -D HAVE_ACTIVEMQ_CONFIG
{noformat}
and when running make you get
{noformat}
make all-recursive
make[1]: Entering directory `/home/albert/work/activemq-cpp'
Making all in src/main
make[2]: Entering directory `/home/albert/work/activemq-cpp/src/main'
if g++ -DHAVE_CONFIG_H -I. -I. -I../.. -D HAVE_ACTIVEMQ_CONFIG -MT
ActiveMQConsumer.o -MD -MP -MF .deps/ActiveMQConsumer.Tpo -c -o
ActiveMQConsumer.o `test -f 'activemq/core/ActiveMQConsumer.cpp' || echo
'./'`activemq/core/ActiveMQConsumer.cpp; \
then mv -f .deps/ActiveMQConsumer.Tpo .deps/ActiveMQConsumer.Po;
else rm -f .deps/ActiveMQConsumer.Tpo; exit 1; fi
{noformat}
which is missing all the options specified in configure.ac.
By the way, you might consider adding -g and -O2.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (AMQCPP-52) Valgrind reports memory leaks when running PrimitiveMapTest
Valgrind reports memory leaks when running PrimitiveMapTest --- Key: AMQCPP-52 URL: https://issues.apache.org/activemq/browse/AMQCPP-52 Project: ActiveMQ C++ Client Issue Type: Bug Affects Versions: 2.0 Reporter: Albert Strasheim Assigned To: Nathan Mittler Priority: Minor Fix For: 2.0 Valgrind reports the following leaks when running PrimitiveMapTest from r499127. ==30238== 16 (12 direct, 4 indirect) bytes in 1 blocks are definitely lost in loss record 6 of 11 ==30238==at 0x4005BA5: operator new(unsigned) (vg_replace_malloc.c:163) ==30238==by 0x8173256: activemq::util::PrimitiveMapTest::testValueNode() (PrimitiveMap.h:311) ... ==30238==by 0x818EE36: main (main.cpp:34) ==30238== 50 (36 direct, 14 indirect) bytes in 3 blocks are definitely lost in loss record 7 of 11 ==30238==at 0x4005BA5: operator new(unsigned) (vg_replace_malloc.c:163) ==30238==by 0x81CD009: activemq::util::PrimitiveMap::setByteArray(std::string const, std::vectorunsigned char, std::allocatorunsigned char const) (PrimitiveMap.h:311) ==30238==by 0x80FC6CB: activemq::connector::openwire::marshal::PrimitiveMapMarshallerTest::test() (PrimitiveMapMarshallerTest.cpp:65) ==30238==by 0x4B6706: CppUnit::TestCaseMethodFunctor::operator()() const (in /usr/lib/libcppunit-1.12.so.0.0.0) ... ==30238==by 0x818EE36: main (main.cpp:34) ==30238== 50 (36 direct, 14 indirect) bytes in 3 blocks are definitely lost in loss record 8 of 11 ==30238==at 0x4005BA5: operator new(unsigned) (vg_replace_malloc.c:163) ==30238==by 0x81CD176: activemq::util::PrimitiveMap::setByteArray(std::string const, std::vectorunsigned char, std::allocatorunsigned char const) (PrimitiveMap.h:110) ==30238==by 0x80FC6CB: activemq::connector::openwire::marshal::PrimitiveMapMarshallerTest::test() (PrimitiveMapMarshallerTest.cpp:65) ==30238==by 0x4B6706: CppUnit::TestCaseMethodFunctor::operator()() const (in /usr/lib/libcppunit-1.12.so.0.0.0) ... ==30238==by 0x818EE36: main (main.cpp:34) ==30238== 50 (36 direct, 14 indirect) bytes in 3 blocks are definitely lost in loss record 9 of 11 ==30238==at 0x4005BA5: operator new(unsigned) (vg_replace_malloc.c:163) ==30238==by 0x81CEEFF: activemq::util::Mapstd::string, activemq::util::PrimitiveMap::ValueNode::setValue(std::string const, activemq::util::PrimitiveMap::ValueNode) (PrimitiveMap.h:110) ==30238==by 0x81CD0BE: activemq::util::PrimitiveMap::setByteArray(std::string const, std::vectorunsigned char, std::allocatorunsigned char const) (PrimitiveMap.cpp:218) ==30238==by 0x80FC6CB: activemq::connector::openwire::marshal::PrimitiveMapMarshallerTest::test() (PrimitiveMapMarshallerTest.cpp:65) ==30238==by 0x4B6706: CppUnit::TestCaseMethodFunctor::operator()() const (in /usr/lib/libcppunit-1.12.so.0.0.0) ... ==30238==by 0x818EE36: main (main.cpp:34) ==30238== 50 (36 direct, 14 indirect) bytes in 3 blocks are definitely lost in loss record 10 of 11 ==30238==at 0x4005BA5: operator new(unsigned) (vg_replace_malloc.c:163) ==30238==by 0x81CE182: activemq::util::Mapstd::string, activemq::util::PrimitiveMap::ValueNode::getValue(std::string const) const (PrimitiveMap.h:110) ==30238==by 0x81CBAB2: activemq::util::PrimitiveMap::getValue(std::string const) const (PrimitiveMap.cpp:242) ==30238==by 0x81C00B4: activemq::connector::openwire::marshal::PrimitiveMapMarshaller::marshal(activemq::util::PrimitiveMap const*, std::vectorunsigned char, std::allocatorunsigned char ) (PrimitiveMapMarshaller.cpp:59) ==30238==by 0x80FC717: activemq::connector::openwire::marshal::PrimitiveMapMarshallerTest::test() (PrimitiveMapMarshallerTest.cpp:70) ==30238==by 0x4B6706: CppUnit::TestCaseMethodFunctor::operator()() const (in /usr/lib/libcppunit-1.12.so.0.0.0) ... ==30238==by 0x4C4724: CppUnit::TextTestRunner::run(std::string, bool, bool, bool) (in /usr/lib/libcppunit-1.12.so.0.0.0) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (AMQ-1136) Slow consumer causes producer to block on UsageManager.waitForSpace indefinately
Slow consumer causes producer to block on UsageManager.waitForSpace indefinately Key: AMQ-1136 URL: https://issues.apache.org/activemq/browse/AMQ-1136 Project: ActiveMQ Issue Type: Bug Affects Versions: 4.2.0 Reporter: Albert Strasheim The issue is described in this thread: http://www.nabble.com/Blocking-on-UsageManager.waitForSpace-again-tf3031460.html Basically, a slow consumer can cause a producer to block on UsageManager.waitForSpace indefinately. A basic code sample to reproduce the problem is provided here: http://www.nabble.com/Re%3A-Blocking-on-UsageManager.waitForSpace-again-p8521205.html Note that the reproducibility of the bug depends on the initial and maximum size of the VM's heap. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (AMQCPP-49) Add -W -Wall compile options
[ https://issues.apache.org/activemq/browse/AMQCPP-49?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_37975 ] Albert Strasheim commented on AMQCPP-49: The CXXFLAGS in src/test/Makefile.am issue is weird. Changing CXXFLAGS to AM_CXXFLAGS makes the autogen.sh warning go away, but the generated Makefile ends up not using these extra flags then. I'm grasping at straws here, but maybe it has something to do with setting or not setting AM_MAINTAINER_MODE in configure.ac? Add -W -Wall compile options Key: AMQCPP-49 URL: https://issues.apache.org/activemq/browse/AMQCPP-49 Project: ActiveMQ C++ Client Issue Type: Improvement Environment: gcc Reporter: Nathan Mittler Assigned To: Nathan Mittler Priority: Trivial Fix For: 2.0 Attachments: vs2005-build.diff Add -W -Wall compile options and clean up resulting warnings -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (AMQCPP-53) Declaration of extern int errno after including errno.h doesn't compile
Declaration of extern int errno after including errno.h doesn't compile
---
Key: AMQCPP-53
URL: https://issues.apache.org/activemq/browse/AMQCPP-53
Project: ActiveMQ C++ Client
Issue Type: Bug
Affects Versions: 2.0
Reporter: Albert Strasheim
Assigned To: Nathan Mittler
Fix For: 2.0
A few places in AMQCPP declare extern int errno after includes errno.h. This
fails to compile on Fedora Core 4 and Fedora Core 6 with the following error:
{noformat}
activemq/concurrent/Thread.cpp:23: error: declaration of 'int*
__errno_location()' throws different exceptions
/usr/include/bits/errno.h:38: error: than previous declaration 'int*
__errno_location() throw ()'
{noformat}
As far as I know, including errno.h should be sufficient -- the extra
declaration of errno is unnecessary. However, maybe you know of some older
platforms where it has to be declared explicitly, even after the header has
been included?
The places in the library where this issue crops up are:
* src/main/activemq/concurrent/Thread.cpp
* src/main/activemq/network/SocketError.cpp
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (AMQCPP-49) Add -W -Wall compile options
[ https://issues.apache.org/activemq/browse/AMQCPP-49?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_37949 ] Albert Strasheim commented on AMQCPP-49: I see -ansi was giving some problems with long longs. I think -ansi -pedantic -Wno-long-long is probably what we want. Add -W -Wall compile options Key: AMQCPP-49 URL: https://issues.apache.org/activemq/browse/AMQCPP-49 Project: ActiveMQ C++ Client Issue Type: Improvement Environment: gcc Reporter: Nathan Mittler Assigned To: Nathan Mittler Priority: Trivial Fix For: 2.0 Attachments: vs2005-build.diff Add -W -Wall compile options and clean up resulting warnings -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQCPP-50) Derive cms::CMSException from std::exception
Derive cms::CMSException from std::exception Key: AMQCPP-50 URL: https://issues.apache.org/activemq/browse/AMQCPP-50 Project: ActiveMQ C++ Client Issue Type: Improvement Components: CMS Impl Reporter: Albert Strasheim Assigned To: Nathan Mittler Priority: Minor Fix For: 2.0 It would be nice if cms::CMSException were derived from std::exception. std::exception's what can just call through to cms::CMSException's getMessage. Having this inheritance would be useful to people who already have logging functions or other bits and pieces in place in their programs that understand std::exceptions. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQCPP-48) Fix compilation with Visual Studio .NET 2003
Fix compilation with Visual Studio .NET 2003 Key: AMQCPP-48 URL: https://issues.apache.org/activemq/browse/AMQCPP-48 Project: ActiveMQ C++ Client Issue Type: Improvement Affects Versions: 2.0 Reporter: Albert Strasheim Assigned To: Nathan Mittler Priority: Trivial Fix For: 2.0 Attachments: amqcpp-vs2003.diff The attached patch contains a few minor changes to make the AMQCPP library compile with Visual Studio .NET 2003. This will be very useful for the [Python wrapper|http://code.google.com/p/pyactivemq/] I'm working on, since Python 2.4 and Python 2.5 still need their extension modules compiled with VS .NET 2003. If you're interested, I can also submit project files for VS .NET 2003. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQCPP-47) MapMessage getters should be const
MapMessage getters should be const -- Key: AMQCPP-47 URL: https://issues.apache.org/activemq/browse/AMQCPP-47 Project: ActiveMQ C++ Client Issue Type: Improvement Components: CMS Impl Affects Versions: 2.0 Reporter: Albert Strasheim Assigned To: Nathan Mittler Priority: Minor Fix For: 2.0 It looks to me like the cms::MapMessage getter functions can all be const? I'm guessing there isn't a MapMessage implementation yet, but I'm guessing it'll probably be implemented on top of a C++ STL map? Having the getters const will mean that people won't have to clone a MapMessage in a MessageListener if they want to read its fields. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQCPP-46) ActiveMQConnection doesn't propagate exception listener to underlying connector
ActiveMQConnection doesn't propagate exception listener to underlying connector
---
Key: AMQCPP-46
URL: https://issues.apache.org/activemq/browse/AMQCPP-46
Project: ActiveMQ C++ Client
Issue Type: Bug
Affects Versions: 1.1
Reporter: Albert Strasheim
Assigned To: Nathan Mittler
Fix For: 2.0
Attachments: amqconn-exlistener.diff
My program is doing the following:
# Create connection using ActiveMQConnectionFactory
# Set a simple exception listener that sets a boolean flag
# Block in receive on consumer
If I then kill the broker, various exceptions happen, but they are never sent
to the exception listener, because the exception listener in StompConnector is
null. It seems to me that ActiveMQConnection should set and get its exception
listener on its underlying connector and probably doesn't have to contain a
pointer to the listener itself.
If I change ActiveMQConnection as in the attached patch to also set the
exception listener on the underlying connector, my exception listener gets
called when the broker dies.
Once I detect the failure, I delete the producer, consumer, session and
connection that failed. Looks like an uncaught exception is getting thrown
during the destruction of the producer (which is the first thing I delete when
cleaning up). The problem here is probably that the connection is trying to
close down a socket that is already broken and something goes awry. I'm not
quite sure how to fix this problem.
Stack trace (with useless bits stripped out):
{noformat}
kernel32.dll!7c812a5b()
[Frames below may be incorrect and/or missing, no symbols loaded for
kernel32.dll]
kernel32.dll!7c812a5b()
myapp.exe!std::vectorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int,std::allocatorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int
::_Ucopystd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int
*(std::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int *
_First=(..\src\main\activemq\connector\stomp\StompSessionManager.cpp,254),
std::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int * _Last=(Bad Ptr,14297048),
std::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int *
_Ptr=(..\src\main\activemq\connector\stomp\StompSessionManager.cpp,254))
Line 1105 + 0x18 bytes C++
myapp.exe!std::vectorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int,std::allocatorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int ::operator=(const
std::vectorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int,std::allocatorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int_Right={...}) Line 582 + 0x1d bytes C++
0012b920()
myapp.exe!activemq::core::ActiveMQConsumer::close() Line 84 + 0x34
bytes C++
msvcr80d.dll!102418b7()
...
kernel32.dll!7c812a5b()
myapp.exe!std::vectorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int,std::allocatorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int
::_Ucopystd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int
*(std::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int * _First=(Bad Ptr,-17891602),
std::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int * _Last=(Bad Ptr,-17891602),
std::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int * _Ptr=(Bad Ptr,1886220148)) Line 1105 + 0x18 bytes C++
myapp!std::vectorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int,std::allocatorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int ::operator=(const
std::vectorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int,std::allocatorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int_Right={...}) Line 582 + 0x1d bytes C++
0012bf74()
myapp.exe!activemq::core::ActiveMQSession::onDestroySessionResource(activemq::core::ActiveMQSessionResource
* resource=0x0001) Line 558 + 0x37 bytes C++
msvcr80d.dll!10241a10()
...
kernel32.dll!7c812a5b()
myapp.exe!std::vectorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int,std::allocatorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int
::_Ucopystd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int
[jira] Commented: (AMQCPP-46) ActiveMQConnection doesn't propagate exception listener to underlying connector
[
https://issues.apache.org/activemq/browse/AMQCPP-46?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_37930
]
Albert Strasheim commented on AMQCPP-46:
There does appear to be a disconnect on the listener chain.
If I understand this correctly, you agree that there is an issue with
ActiveMQConnection?
Here's some code to reproduce the problem with exceptions I'm seeing (after
applying my patch). You can paste this code over the stuff in
vs2005-activemq-example -- it's probably the quickest way to get it building.
{noformat}
#include activemq/core/ActiveMQConnectionFactory.h
#include cms/ExceptionListener.h
#include cms/Session.h
#include iostream
struct ExceptionListener : public cms::ExceptionListener {
bool error;
ExceptionListener() : error(false) {}
virtual ~ExceptionListener(void) {}
virtual void onException( const cms::CMSException ex ) {
std::cout Got an exception in listener: ex.getMessage()
std::endl;
error = true;
}
};
int main(int argc, char* argv[]) {
ExceptionListener exListener;
activemq::core::ActiveMQConnectionFactory* connectionFactory =
new activemq::core::ActiveMQConnectionFactory(tcp://127.0.0.1:61613);
while (true) {
cms::Connection* connection = 0;
cms::Session* session = 0;
cms::Destination* destination = 0;
cms::MessageConsumer* consumer = 0;
try {
while (!exListener.error) {
connection = connectionFactory-createConnection();
connection-setExceptionListener(exListener);
session = connection-createSession(
cms::Session::AUTO_ACKNOWLEDGE );
destination = session-createTopic( TEST.FOO );
consumer = session-createConsumer( destination );
connection-start();
cms::Message* message = consumer-receive(1);
delete message;
message = 0;
}
} catch ( cms::CMSException ex ) {
std::cout Got an exception: ex.getMessage() std::endl;
}
delete consumer;
consumer = 0;
delete destination;
destination = 0;
delete session;
session = 0;
delete connection;
connection = 0;
exListener.error = false;
}
delete connectionFactory;
connectionFactory = 0;
return 0;
}
{noformat}
Use it as follows:
Compile in debug mode in Visual Studio and run the program (without a running
broker).
You should see: Got an exception: Socket::connect - No error as it retries the
createConnection part.
Start the broker. It should establish a connection and block on receive.
Kill the broker. You should see:
WARNING: activemq::io::SocketInputStream::read - An existing connection was
forcibly closed by the remote host.
FILE: ..\src\main\activemq\network\SocketInputStream.cpp, LINE: 171
FILE: ..\src\main\activemq\io\BufferedInputStream.cpp, LINE: 158
FILE: ..\src\main\activemq\io\BufferedInputStream.cpp, LINE: 81
FILE: ..\src\main\activemq\connector\stomp\StompCommandReader.cpp,
LINE: 216
FILE: ..\src\main\activemq\connector\stomp\StompCommandReader.cpp,
LINE: 120
FILE: ..\src\main\activemq\connector\stomp\StompCommandReader.cpp,
LINE: 71
FILE: ..\src\main\activemq\transport\IOTransport.cpp, LINE: 165
- tid: 7252
Got an exception in listener: activemq::io::SocketInputStream::read - An
existing connection was forcibly closed by the remote host.
Then the application crashes. I get this dialog box:
{noformat}
---
Microsoft Visual C++ Debug Library
---
Debug Error!
Program: ...
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
(Press Retry to debug the application)
---
Abort Retry Ignore
---
{noformat}
If I debug in Visual Studio, my stack looks like this:
{noformat}
msvcr80d.dll!10202b13()
[Frames below may be incorrect and/or missing, no symbols loaded for
msvcr80d.dll]
ntdll.dll!7c96d886()
...
kernel32.dll!7c812a5b()
vs2005-activemq-example.exe!std::vectorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int,std::allocatorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int
::_Ucopystd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int
*(std::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int * _First=(..\src\main\activemq\network\SocketOutputStream.cpp,85),
std::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,int * _Last=(Bad Ptr,3473888),
[jira] Created: (AMQCPP-45) Update configure.ac with release version
Update configure.ac with release version Key: AMQCPP-45 URL: https://issues.apache.org/activemq/browse/AMQCPP-45 Project: ActiveMQ C++ Client Issue Type: Task Affects Versions: 1.1 Reporter: Albert Strasheim Assigned To: Nathan Mittler Priority: Trivial Fix For: 1.1 configure.ac for the 1.1 release should be updated. The ACTIVEMQ_VERSION variable needs to be changed (the 1.x part). This should fix the headers install directory. ACTIVEMQ_LIBRARY_VERSION could also be set to some value (not sure what the best value is here, http://people.redhat.com/drepper/dsohowto.pdf might have some ideas). By the way, the ACTIVEMQ_RELEASE variable seems to be unused? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQCPP-44) Reason for socket errors not reported correctly on Windows
Reason for socket errors not reported correctly on Windows -- Key: AMQCPP-44 URL: https://issues.apache.org/activemq/browse/AMQCPP-44 Project: ActiveMQ C++ Client Issue Type: Bug Affects Versions: 1.1 Reporter: Albert Strasheim Assigned To: Nathan Mittler Fix For: 2.0 Socket errors aren't reported correctly on Windows. When the broker is down and the TcpTransport fails to connect, I get an exception saying Socket::connect - No error. strerror of errno might not be the right way to get the error description for socket errors on Windows. Maybe one needs to look at what WSAGetLastError returns, but I'm not sure. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQCPP-43) Crash when getting string property that doesn't exist
Crash when getting string property that doesn't exist
-
Key: AMQCPP-43
URL: https://issues.apache.org/activemq/browse/AMQCPP-43
Project: ActiveMQ C++ Client
Issue Type: Bug
Components: CMS Impl
Affects Versions: 1.1
Reporter: Albert Strasheim
Assigned To: Nathan Mittler
Priority: Minor
Fix For: 1.1
In the case when one calls getStringProperty for a property that doesn't exist,
a crash occurs because SimpleProperties returns NULL. I think it should return
.
Test code on Linux:
{noformat}
#include string
int main(int argc, char* argv)
{
std::string str(0);
return 0;
}
{noformat}
This dies with the following when run on FC6:
{noformat}
terminate called after throwing an instance of 'std::logic_error'
what(): basic_string::_S_construct NULL not valid
Aborted
{noformat}
Proposed patch:
{noformat}
===
--- src/main/activemq/util/SimpleProperties.h (revision 495567)
+++ src/main/activemq/util/SimpleProperties.h (working copy)
@@ -55,7 +55,7 @@
std::map std::string, std::string ::const_iterator iter =
properties.find( name );
if( iter == properties.end() ){
-return NULL;
+return ;
}
return iter-second.c_str();
{noformat}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQCPP-36) Cleanup whitespace and member function definitions in header files
[ https://issues.apache.org/activemq/browse/AMQCPP-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_37872 ] Albert Strasheim commented on AMQCPP-36: I think I have two new reasons for possibly moving code from headers to cpp files: code size and build time. The latest activemq-cpp.lib is 41,112 KB, which seems rather... large. While we were chasing down the bug we were seeing related to AMQCPP-25, we had to make changes to functions that were implemented in headers, causing large parts of the library that didn't really change to be rebuilt. Cleanup whitespace and member function definitions in header files -- Key: AMQCPP-36 URL: https://issues.apache.org/activemq/browse/AMQCPP-36 Project: ActiveMQ C++ Client Issue Type: Improvement Reporter: Albert Strasheim Assigned To: Timothy Bish Priority: Minor Fix For: 1.1 Attachments: activemq-concurrent-cleanup.diff, StompFrame-signmismatch.diff The AMQCPP code looks great in general, but many files have some stray whitespace. Also, there are quite a few headers that contain member function definitions. Some are simple, but there's also some big ones in there. I usually follow the rule that anything that can go into the .cpp should. Attached is a patch to clean up the files in activemq::concurrent. If Timothy/Nathan agrees that doing this is useful, I'll submit patches for the rest. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (AMQCPP-25) Bus error on Solaris OS from DataInput and DataOutput streams
[ https://issues.apache.org/activemq/browse/AMQCPP-25?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Albert Strasheim updated AMQCPP-25: --- Attachment: optobug.cpp Bus error on Solaris OS from DataInput and DataOutput streams - Key: AMQCPP-25 URL: https://issues.apache.org/activemq/browse/AMQCPP-25 Project: ActiveMQ C++ Client Issue Type: Bug Components: CMS Impl Affects Versions: 1.1 Environment: Solaris 10 OS Reporter: Timothy Bish Assigned To: Timothy Bish Priority: Minor Fix For: 1.1 Attachments: optobug.cpp Due to misaligned memory reads, there is a bus error that can occur in using the new DataInputStream and DataOutputStream classes. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQCPP-25) Bus error on Solaris OS from DataInput and DataOutput streams
[
https://issues.apache.org/activemq/browse/AMQCPP-25?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_37877
]
Albert Strasheim commented on AMQCPP-25:
Figured it out! Looks like a strict aliasing (whatever that is) issue with GCC
4 optimization.
Example code to be attached. Compiling with GCC 4.1.1 with different
optimization levels:
{noformat}
[EMAIL PROTECTED] ~]$ gcc --version
gcc (GCC) 4.1.1 20061011 (Red Hat 4.1.1-30)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[EMAIL PROTECTED] ~]$ g++ -O0 -Wall -ansi -o optobug optobug.cpp ./optobug
i1 == i3 OK
ll1 == ll3 OK
f1 == f3 OK
d1 == d3 OK
[EMAIL PROTECTED] ~]$ g++ -O1 -Wall -ansi -o optobug optobug.cpp ./optobug
i1 == i3 OK
ll1 == ll3 OK
f1 == f3 OK
d1 == d3 OK
[EMAIL PROTECTED] ~]$ g++ -O2 -Wall -ansi -o optobug optobug.cpp ./optobug
optobug.cpp: In static member function 'static float Endian::byteSwap(float)':
optobug.cpp:26: warning: dereferencing type-punned pointer will break
strict-aliasing rules
optobug.cpp:32: warning: dereferencing type-punned pointer will break
strict-aliasing rules
optobug.cpp: In static member function 'static double Endian::byteSwap(double)':
optobug.cpp:36: warning: dereferencing type-punned pointer will break
strict-aliasing rules
optobug.cpp:42: warning: dereferencing type-punned pointer will break
strict-aliasing rules
i1 == i3 OK
ll1 == ll3 OK
f1 != f3 ERROR
d1 != d3 ERROR
[EMAIL PROTECTED] ~]$ g++ -O2 -fno-strict-aliasing -Wall -ansi -o optobug
optobug.cpp ./optobug
i1 == i3 OK
ll1 == ll3 OK
f1 == f3 OK
d1 == d3 OK
{noformat}
The idea I get from [dereferencing type-punned pointer will break
strict-aliasing
rules|http://lists.freebsd.org/pipermail/freebsd-current/2003-July/007561.html]
is that the right way to fix this is to use a union containing a float/unsigned
int or double/unsigned long long.
Alternatively, AMQCPP's compiler flags can be changed to pass
-fno-strict-aliasing to the compiler. There's an issue to be aware of (I
think): no code that needs strict aliasing to be turned off can live in a
AMQCPP header, since this will force anyone using the library to also compile
with with -fno-strict-aliasing flag, because if they forget, things will break
mysteriously with older versions of GCC 4.
Bus error on Solaris OS from DataInput and DataOutput streams
-
Key: AMQCPP-25
URL: https://issues.apache.org/activemq/browse/AMQCPP-25
Project: ActiveMQ C++ Client
Issue Type: Bug
Components: CMS Impl
Affects Versions: 1.1
Environment: Solaris 10 OS
Reporter: Timothy Bish
Assigned To: Timothy Bish
Priority: Minor
Fix For: 1.1
Attachments: optobug.cpp
Due to misaligned memory reads, there is a bus error that can occur in using
the new DataInputStream and DataOutputStream classes.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQCPP-25) Bus error on Solaris OS from DataInput and DataOutput streams
[ https://issues.apache.org/activemq/browse/AMQCPP-25?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_37880 ] Albert Strasheim commented on AMQCPP-25: http://www.cellperformance.com/mike_acton/2006/06/understanding_strict_aliasing.html Bus error on Solaris OS from DataInput and DataOutput streams - Key: AMQCPP-25 URL: https://issues.apache.org/activemq/browse/AMQCPP-25 Project: ActiveMQ C++ Client Issue Type: Bug Components: CMS Impl Affects Versions: 1.1 Environment: Solaris 10 OS Reporter: Timothy Bish Assigned To: Timothy Bish Priority: Minor Fix For: 1.1 Attachments: optobug.cpp Due to misaligned memory reads, there is a bus error that can occur in using the new DataInputStream and DataOutputStream classes. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQCPP-25) Bus error on Solaris OS from DataInput and DataOutput streams
[ https://issues.apache.org/activemq/browse/AMQCPP-25?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_37891 ] Albert Strasheim commented on AMQCPP-25: Re: your first question. As we tried to debug this issue, we added some printfs to check values of variables and we noticed that the bugs would go away. Basically, any bit of code that changes the way the compiler optimizes the function can make the bug disappear (but it's still a bug). char c = new char, delete c is just the smallest bit of code we could come up with that would make the bug disappear. As for how to fix this, I did some further reading. Check this page: http://www.cellperformance.com/mike_acton/2006/05/demystifying_the_restrict_keyw.html In the summary they say: ... Enable strict aliasing related warnings with -Wstrict-aliasing, but do not expect to be warned in all cases. Most of the GCC versions I've tried *don't* warn on the strict aliasing violations in the current AMQCPP code. If we want to leave strict aliasing enabled, we'll have to give the code a quick review and carefully look at any future changes for strict aliasing bugs, since the compiler won't necessarily warn us. The Python folks went for the opposite approach: any C module you build with distuils is compiled with -fno-strict-aliasing, as people were probably running into this problem frequently. If AMQCPP goes the -fno-strict-aliasing route, we'll still have to check that we don't leak code that requires this option outside of the library. Fortunately this is easy -- put function implementations in cpp files so that users don't compile bits of the library when compiling their code. Linking against a library is fine, regardless of its strict aliasing flags. Of course if you have any templated stuff, you should probably make sure to not write code that depends on strict aliasing flags. Bus error on Solaris OS from DataInput and DataOutput streams - Key: AMQCPP-25 URL: https://issues.apache.org/activemq/browse/AMQCPP-25 Project: ActiveMQ C++ Client Issue Type: Bug Components: CMS Impl Affects Versions: 1.1 Environment: Solaris 10 OS Reporter: Timothy Bish Assigned To: Timothy Bish Priority: Minor Fix For: 1.1 Attachments: optobug.cpp Due to misaligned memory reads, there is a bus error that can occur in using the new DataInputStream and DataOutputStream classes. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQCPP-25) Bus error on Solaris OS from DataInput and DataOutput streams
[
https://issues.apache.org/activemq/browse/AMQCPP-25?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_37895
]
Albert Strasheim commented on AMQCPP-25:
We might consider using -Wstrict-aliasing=2. Warns in more cases, with some
chance of false positives.
I still get the following warnings with GCC 4.1.1 on FC6 with revision 495335:
{noformat}
activemq/network/ServerSocket.cpp: In member function 'virtual void
activemq::network::ServerSocket::bind(const char*, int, int)':
activemq/network/ServerSocket.cpp:162: warning: dereferencing type-punned
pointer might break strict-aliasing rules
activemq/network/ServerSocket.cpp: In member function 'virtual
activemq::network::Socket* activemq::network::ServerSocket::accept()':
activemq/network/ServerSocket.cpp:208: warning: dereferencing type-punned
pointer might break strict-aliasing rules
activemq/io/DataInputStreamTest.h:85: warning: dereferencing type-punned
pointer will break strict-aliasing rules
activemq/io/DataInputStreamTest.h:86: warning: dereferencing type-punned
pointer will break strict-aliasing rules
{noformat}
I noticed you used a memcpys to fix this issue. Did you consider trying a
union? Without knowing for certain (maybe we'll do some benchmarks tomorrow), a
union might be faster than a call to memcpy.
Anyway, tests pass on FC6. Thanks very much.
Bus error on Solaris OS from DataInput and DataOutput streams
-
Key: AMQCPP-25
URL: https://issues.apache.org/activemq/browse/AMQCPP-25
Project: ActiveMQ C++ Client
Issue Type: Bug
Components: CMS Impl
Affects Versions: 1.1
Environment: Solaris 10 OS
Reporter: Timothy Bish
Assigned To: Timothy Bish
Priority: Minor
Fix For: 1.1
Attachments: optobug.cpp
Due to misaligned memory reads, there is a bus error that can occur in using
the new DataInputStream and DataOutputStream classes.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQCPP-42) A few more strict aliasing warnings
A few more strict aliasing warnings
---
Key: AMQCPP-42
URL: https://issues.apache.org/activemq/browse/AMQCPP-42
Project: ActiveMQ C++ Client
Issue Type: Bug
Affects Versions: 1.1
Reporter: Albert Strasheim
Assigned To: Nathan Mittler
Priority: Critical
Fix For: 1.1
Brought over from AMQCPP-25.
We might consider using -Wstrict-aliasing=2. Warns in more cases, with some
chance of false positives.
I still get the following warnings with GCC 4.1.1 on FC6 with revision 495335:
{noformat}
activemq/network/ServerSocket.cpp: In member function 'virtual void
activemq::network::ServerSocket::bind(const char*, int, int)':
activemq/network/ServerSocket.cpp:162: warning: dereferencing type-punned
pointer might break strict-aliasing rules
activemq/network/ServerSocket.cpp: In member function 'virtual
activemq::network::Socket* activemq::network::ServerSocket::accept()':
activemq/network/ServerSocket.cpp:208: warning: dereferencing type-punned
pointer might break strict-aliasing rules
activemq/io/DataInputStreamTest.h:85: warning: dereferencing type-punned
pointer will break strict-aliasing rules
activemq/io/DataInputStreamTest.h:86: warning: dereferencing type-punned
pointer will break strict-aliasing rules
{noformat}
I noticed you used a memcpys to fix this issue. Did you consider trying a
union? Without knowing for certain (maybe we'll do some benchmarks tomorrow), a
union might be faster than a call to memcpy.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQCPP-39) Some AMQCPP includes not installed when doing make install on Linux
Some AMQCPP includes not installed when doing make install on Linux --- Key: AMQCPP-39 URL: https://issues.apache.org/activemq/browse/AMQCPP-39 Project: ActiveMQ C++ Client Issue Type: Bug Affects Versions: 1.1 Reporter: Albert Strasheim Assigned To: Nathan Mittler Priority: Minor Fix For: 1.1 Attachments: amqcpp-missing-includes.diff On Linux with the autotools build system, it seems that some headers aren't being installed. Patch for src/main/Makefile.am attached that fixes those that we ran into. There might be more -- maybe you want to make a script that checks that Makefile.am lists all the headers (or maybe use some kind of glob if that's possible). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQCPP-40) A few stray unix and sun defines
A few stray unix and sun defines
Key: AMQCPP-40
URL: https://issues.apache.org/activemq/browse/AMQCPP-40
Project: ActiveMQ C++ Client
Issue Type: Improvement
Affects Versions: 1.1
Reporter: Albert Strasheim
Assigned To: Nathan Mittler
Priority: Minor
Fix For: 1.1
The AMQCPP code still contains a few references to the unix and sun defines.
{noformat}
./src/main/activemq/concurrent/Mutex.h:#if (defined(__unix__) || defined(unix)
|| defined(MACOSX)) !defined(USG)
./src/main/activemq/concurrent/Thread.h:#if (defined(__unix__) || defined(unix)
|| defined(MACOSX) || defined(__APPLE__)) !defined(USG)
./src/main/activemq/util/Guid.h:#if defined( unix ) ||
defined(__APPLE__)
./src/main/activemq/util/Config.h: // used by unix like systems (including
cygwin)
./src/main/activemq/util/Config.h: #elif defined( unix )
./src/main/activemq/util/Endian.h:#if defined( unix ) || defined(__APPLE__)
./src/main/activemq/util/Endian.h:# if defined( unix ) || defined(__APPLE__)
./src/main/activemq/network/ServerSocket.h: #if !defined( unix ) ||
defined( __CYGWIN__ )
./src/main/activemq/network/SocketOutputStream.cpp:#elif defined( unix )
!defined( __CYGWIN__ ) !defined( sun )
{noformat}
These should probably be replaced by some kind of AMQ_ variant. It would nice
if one could define a single AMQ_something per platform, akin to Windows's
_WIN32 define.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQCPP-41) Byte swap on float and double truncates values
Byte swap on float and double truncates values
--
Key: AMQCPP-41
URL: https://issues.apache.org/activemq/browse/AMQCPP-41
Project: ActiveMQ C++ Client
Issue Type: Bug
Affects Versions: 1.1
Reporter: Albert Strasheim
Assigned To: Nathan Mittler
Priority: Critical
Fix For: 1.1
Attachments: doublefloat-truncate.diff
activemq::util::Endian::byteSwap truncates float and double values due to the
C-style cast it uses.
Patch for BytesMessageCommandTest is attached that shows the problem. One might
consider expanding this test to check that the minimum, maximum, -1, 0, 1 (and
-inf and inf where appropriate) and a few other values can successfully be
serialised and deserialised for each of the types.
Also in the patch is our attempt at fixing byteSwap. You'll notice that we do
something very strange: we take the argument of byteSwap and make a copy on the
heap. The reason for this is that simply doing:
{noformat}
const uintxx_t swapped_val = byteSwap( *(uintxx_t*)(value) );
{noformat}
i.e. taking the address of value instead of using the copy on the heap, fails
with GCC 4.0.2 and GCC 4.0.3. I'm guessing GCC might be trying to inline the
call to byteSwap and then something goes very wrong when taking the address of
a variable on the stack. Hopefully someone has a better idea for a workaround.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQCPP-41) Byte swap on float and double truncates values
[
https://issues.apache.org/activemq/browse/AMQCPP-41?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_37854
]
Albert Strasheim commented on AMQCPP-41:
Looking at the stack trace produced by Valgrind when it detects the error that
happens in byteSwap also seems to indicate that inlining is happening. Valgrind
reports the method at the top of the stack as readDouble from
BytesMessageCommand, but the source line as being in Endian.h.
Byte swap on float and double truncates values
--
Key: AMQCPP-41
URL: https://issues.apache.org/activemq/browse/AMQCPP-41
Project: ActiveMQ C++ Client
Issue Type: Bug
Affects Versions: 1.1
Reporter: Albert Strasheim
Assigned To: Timothy Bish
Priority: Critical
Fix For: 1.1
Attachments: doublefloat-truncate.diff
activemq::util::Endian::byteSwap truncates float and double values due to the
C-style cast it uses.
Patch for BytesMessageCommandTest is attached that shows the problem. One
might consider expanding this test to check that the minimum, maximum, -1, 0,
1 (and -inf and inf where appropriate) and a few other values can
successfully be serialised and deserialised for each of the types.
Also in the patch is our attempt at fixing byteSwap. You'll notice that we do
something very strange: we take the argument of byteSwap and make a copy on
the heap. The reason for this is that simply doing:
{noformat}
const uintxx_t swapped_val = byteSwap( *(uintxx_t*)(value) );
{noformat}
i.e. taking the address of value instead of using the copy on the heap, fails
with GCC 4.0.2 and GCC 4.0.3. I'm guessing GCC might be trying to inline the
call to byteSwap and then something goes very wrong when taking the address
of a variable on the stack. Hopefully someone has a better idea for a
workaround.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQCPP-25) Bus error on Solaris OS from DataInput and DataOutput streams
[
https://issues.apache.org/activemq/browse/AMQCPP-25?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_37862
]
Albert Strasheim commented on AMQCPP-25:
The recent changes related to this issue seems to make the unit tests not
compile with Visual Studio 2005 anymore.
{noformat}
g:\activemq-cpp\src\test\activemq\io\dataoutputstreamtest.h(44) : error C2065:
'uint16_t' : undeclared identifier
g:\activemq-cpp\src\test\activemq\io\dataoutputstreamtest.h(44) : error C2146:
syntax error : missing ';' before identifier 'shortVal'
g:\activemq-cpp\src\test\activemq\io\dataoutputstreamtest.h(44) : error C2065:
'shortVal' : undeclared identifier
g:\activemq-cpp\src\test\activemq\io\dataoutputstreamtest.h(45) : error C2065:
'uint32_t' : undeclared identifier
g:\activemq-cpp\src\test\activemq\io\dataoutputstreamtest.h(45) : error C2146:
syntax error : missing ';' before identifier 'intVal'
g:\activemq-cpp\src\test\activemq\io\dataoutputstreamtest.h(45) : error C2065:
'intVal' : undeclared identifier
g:\activemq-cpp\src\test\activemq\io\dataoutputstreamtest.h(46) : error C2065:
'uint64_t' : undeclared identifier
g:\activemq-cpp\src\test\activemq\io\dataoutputstreamtest.h(46) : error C2146:
syntax error : missing ';' before identifier 'longVal'
g:\activemq-cpp\src\test\activemq\io\dataoutputstreamtest.h(46) : error C2065:
'longVal' : undeclared identifier
{noformat}
Bus error on Solaris OS from DataInput and DataOutput streams
-
Key: AMQCPP-25
URL: https://issues.apache.org/activemq/browse/AMQCPP-25
Project: ActiveMQ C++ Client
Issue Type: Bug
Components: CMS Impl
Affects Versions: 1.1
Environment: Solaris 10 OS
Reporter: Timothy Bish
Assigned To: Timothy Bish
Priority: Minor
Fix For: 1.1
Due to misaligned memory reads, there is a bus error that can occur in using
the new DataInputStream and DataOutputStream classes.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQCPP-41) Byte swap on float and double truncates values
[
https://issues.apache.org/activemq/browse/AMQCPP-41?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_37865
]
Albert Strasheim commented on AMQCPP-41:
Thanks, I'll take a look now. We ran into this issue about 6 hours before you
checked in the first stuff to fix AMQCPP-25.
Byte swap on float and double truncates values
--
Key: AMQCPP-41
URL: https://issues.apache.org/activemq/browse/AMQCPP-41
Project: ActiveMQ C++ Client
Issue Type: Bug
Affects Versions: 1.1
Reporter: Albert Strasheim
Assigned To: Timothy Bish
Priority: Critical
Fix For: 1.1
Attachments: doublefloat-truncate.diff
activemq::util::Endian::byteSwap truncates float and double values due to the
C-style cast it uses.
Patch for BytesMessageCommandTest is attached that shows the problem. One
might consider expanding this test to check that the minimum, maximum, -1, 0,
1 (and -inf and inf where appropriate) and a few other values can
successfully be serialised and deserialised for each of the types.
Also in the patch is our attempt at fixing byteSwap. You'll notice that we do
something very strange: we take the argument of byteSwap and make a copy on
the heap. The reason for this is that simply doing:
{noformat}
const uintxx_t swapped_val = byteSwap( *(uintxx_t*)(value) );
{noformat}
i.e. taking the address of value instead of using the copy on the heap, fails
with GCC 4.0.2 and GCC 4.0.3. I'm guessing GCC might be trying to inline the
call to byteSwap and then something goes very wrong when taking the address
of a variable on the stack. Hopefully someone has a better idea for a
workaround.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQCPP-25) Bus error on Solaris OS from DataInput and DataOutput streams
[
https://issues.apache.org/activemq/browse/AMQCPP-25?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_37866
]
Albert Strasheim commented on AMQCPP-25:
Running tests against revision 494993 now.
On Fedora Core 4 with GCC 4.0.2, I get the following failures:
{noformat}
1) test:
activemq::connector::stomp::commands::BytesMessageCommandTest::testReadOnly (F)
line: 299 activemq/connector/stomp/commands/BytesMessageCommandTest.h
assertion failed
- Expression: cmd.readFloat() == 2.0f
2) test:
activemq::connector::stomp::commands::BytesMessageCommandTest::testWriteOnly
(F) line: 389 activemq/connector/stomp/commands/BytesMessageCommandTest.h
assertion failed
- Expression: cmd.readFloat() == 2.0f
3) test: activemq::io::DataInputStreamTest::test (F) line: 121
activemq/io/DataInputStreamTest.h
assertion failed
- Expression: floatVal == 10.0f
{noformat}
On Fedora Core 6 with GCC 4.1.1, I get these failures:
{noformat}
1) test:
activemq::connector::stomp::commands::BytesMessageCommandTest::testReadOnly (F)
line: 299 activemq/connector/stomp/commands/BytesMessageCommandTest.h
assertion failed
- Expression: cmd.readFloat() == 2.0f
2) test:
activemq::connector::stomp::commands::BytesMessageCommandTest::testWriteOnly
(F) line: 389 activemq/connector/stomp/commands/BytesMessageCommandTest.h
assertion failed
- Expression: cmd.readFloat() == 2.0f
3) test: activemq::io::DataInputStreamTest::test (F) line: 121
activemq/io/DataInputStreamTest.h
assertion failed
- Expression: floatVal == 10.0f
4) test: activemq::io::DataOutputStreamTest::test (F) line: 93
activemq/io/DataOutputStreamTest.h
assertion failed
- Expression: tempFloat == floatVal
{noformat}
Bus error on Solaris OS from DataInput and DataOutput streams
-
Key: AMQCPP-25
URL: https://issues.apache.org/activemq/browse/AMQCPP-25
Project: ActiveMQ C++ Client
Issue Type: Bug
Components: CMS Impl
Affects Versions: 1.1
Environment: Solaris 10 OS
Reporter: Timothy Bish
Assigned To: Timothy Bish
Priority: Minor
Fix For: 1.1
Due to misaligned memory reads, there is a bus error that can occur in using
the new DataInputStream and DataOutputStream classes.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQCPP-25) Bus error on Solaris OS from DataInput and DataOutput streams
[ https://issues.apache.org/activemq/browse/AMQCPP-25?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_37869 ] Albert Strasheim commented on AMQCPP-25: Thanks very much. Which platforms are you currently testing on? Which compiler versions? Bus error on Solaris OS from DataInput and DataOutput streams - Key: AMQCPP-25 URL: https://issues.apache.org/activemq/browse/AMQCPP-25 Project: ActiveMQ C++ Client Issue Type: Bug Components: CMS Impl Affects Versions: 1.1 Environment: Solaris 10 OS Reporter: Timothy Bish Assigned To: Timothy Bish Priority: Minor Fix For: 1.1 Due to misaligned memory reads, there is a bus error that can occur in using the new DataInputStream and DataOutputStream classes. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQCPP-25) Bus error on Solaris OS from DataInput and DataOutput streams
[ https://issues.apache.org/activemq/browse/AMQCPP-25?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_37871 ] Albert Strasheim commented on AMQCPP-25: If you're interested in shell access to a Fedora Core 4 machine with GCC 4.0.2 and Valgrind 2.4.0 installed, let me know. Bus error on Solaris OS from DataInput and DataOutput streams - Key: AMQCPP-25 URL: https://issues.apache.org/activemq/browse/AMQCPP-25 Project: ActiveMQ C++ Client Issue Type: Bug Components: CMS Impl Affects Versions: 1.1 Environment: Solaris 10 OS Reporter: Timothy Bish Assigned To: Timothy Bish Priority: Minor Fix For: 1.1 Due to misaligned memory reads, there is a bus error that can occur in using the new DataInputStream and DataOutputStream classes. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQCPP-38) Async error on broker when running integration tests
[
https://issues.apache.org/activemq/browse/AMQCPP-38?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_37829
]
Albert Strasheim commented on AMQCPP-38:
I've been running the integration tests repeatedly on Windows.
DurableTester fails most of the time. Also seeing exceptions in the broker in
new places. Also got this crash, which is quite interesting:
{noformat}
1) test: inR6025
- pure virtual function call
tegration::durable::DurableTester::test (E)
uncaught exception of unknown type
2) test: integration::simple::SimpleTester::test (E)
uncaught exception of unknown type
{noformat}
Async error on broker when running integration tests
Key: AMQCPP-38
URL: https://issues.apache.org/activemq/browse/AMQCPP-38
Project: ActiveMQ C++ Client
Issue Type: Bug
Affects Versions: 1.1
Reporter: Albert Strasheim
Assigned To: Nathan Mittler
Fix For: 1.1
Brought over from the comments in AMQCPP-28.
Sometimes when running the integration tests against the AMQ broker from
trunk, ones sees the following message from the broker:
ERROR Service - Async error occurred:
java.lang.IllegalStateException: Cannot remove a consumer that had not been
registered: ID:xxx-36153-1166305227288-5:16:-1:1
at
org.apache.activemq.broker.TransportConnection.processRemoveConsumer(TransportConnection.java:593)
at org.apache.activemq.command.RemoveInfo.visit(RemoveInfo.java:64)
at
org.apache.activemq.broker.TransportConnection.service(TransportConnection.java:287)
at
org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:178)
at
org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:65)
at
org.apache.activemq.transport.InactivityMonitor.onCommand(InactivityMonitor.java:122)
at
org.apache.activemq.transport.stomp.StompTransportFilter.sendToActiveMQ(StompTransportFilter.java:74)
at
org.apache.activemq.transport.stomp.ProtocolConverter.sendToActiveMQ(ProtocolConverter.java:119)
at
org.apache.activemq.transport.stomp.ProtocolConverter.onStompUnsubscribe(ProtocolConverter.java:379)
at
org.apache.activemq.transport.stomp.ProtocolConverter.onStompCommad(ProtocolConverter.java:151)
at
org.apache.activemq.transport.stomp.StompTransportFilter.onCommand(StompTransportFilter.java:64)
at
org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:84)
at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:137)
at java.lang.Thread.run(Thread.java:595)
Using the default activemq.xml, I can reproduce the IllegalStateException
quite reliabily:
1. Start a fresh copy of the broker (4.2 from yesterday's trunk)
2. Run the integration test under Valgrind
3. IllegalStateException happens at the end of
integration::durable::DurableTester::test or at the start of
integration::expiration::ExpirationTest::testExpired.
Subsequent test runs don't yield the error, until the broker is restarted. I
don't know if this issue could be time-dependent - if it is, it could explain
why I only see it when running under Valgrind.
On Linux, I also just got the following test failure for the first time (not
running under Valgrind):
1) test: integration::durable::DurableTester::test (E)
uncaught exception of unknown type
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQCPP-38) Async error on broker when running integration tests
[
https://issues.apache.org/activemq/browse/AMQCPP-38?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_37830
]
Albert Strasheim commented on AMQCPP-38:
Here's the stacktrace on the broker that turns up when running the integration
tests repeatedly with both the broker and the integration tests running on
Windows XP SP2 with Sun Java 1.5.0_10 on a Core 2 Duo:
{noformat}
java.lang.IllegalArgumentException: The subscription does not exist:
ID:xxx-4402-1168189818390-5:210:-1:1
at
org.apache.activemq.broker.region.AbstractRegion.acknowledge(AbstractRegion.java:311)
at
org.apache.activemq.broker.region.RegionBroker.acknowledge(RegionBroker.java:401)
at
org.apache.activemq.broker.TransactionBroker.acknowledge(TransactionBroker.java:181)
at
org.apache.activemq.broker.BrokerFilter.acknowledge(BrokerFilter.java:74)
at
org.apache.activemq.broker.BrokerFilter.acknowledge(BrokerFilter.java:74)
at
org.apache.activemq.broker.MutableBrokerFilter.acknowledge(MutableBrokerFilter.java:88)
at
org.apache.activemq.broker.TransportConnection.processMessageAck(TransportConnection.java:456)
at org.apache.activemq.command.MessageAck.visit(MessageAck.java:179)
at
org.apache.activemq.broker.TransportConnection.service(TransportConnection.java:258)
at
org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:164)
at
org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:65)
at
org.apache.activemq.transport.InactivityMonitor.onCommand(InactivityMonitor.java:122)
at
org.apache.activemq.transport.stomp.StompTransportFilter.sendToActiveMQ(StompTransportFilter.java:74)
at
org.apache.activemq.transport.stomp.StompSubscription.onMessageDispatch(StompSubscription.java:71)
at
org.apache.activemq.transport.stomp.ProtocolConverter.onActiveMQCommad(ProtocolConverter.java:479)
at
org.apache.activemq.transport.stomp.StompTransportFilter.oneway(StompTransportFilter.java:56)
at
org.apache.activemq.transport.InactivityMonitor.oneway(InactivityMonitor.java:141)
at
org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:47)
at
org.apache.activemq.broker.TransportConnection.dispatch(TransportConnection.java:972)
at
org.apache.activemq.broker.TransportConnection.processDispatch(TransportConnection.java:709)
at
org.apache.activemq.broker.TransportConnection.iterate(TransportConnection.java:725)
at
org.apache.activemq.thread.DedicatedTaskRunner.runTask(DedicatedTaskRunner.java:88)
at
org.apache.activemq.thread.DedicatedTaskRunner.access$000(DedicatedTaskRunner.java:25)
at
org.apache.activemq.thread.DedicatedTaskRunner$1.run(DedicatedTaskRunner.java:39)
{noformat}
Async error on broker when running integration tests
Key: AMQCPP-38
URL: https://issues.apache.org/activemq/browse/AMQCPP-38
Project: ActiveMQ C++ Client
Issue Type: Bug
Affects Versions: 1.1
Reporter: Albert Strasheim
Assigned To: Nathan Mittler
Fix For: 1.1
Brought over from the comments in AMQCPP-28.
Sometimes when running the integration tests against the AMQ broker from
trunk, ones sees the following message from the broker:
ERROR Service - Async error occurred:
java.lang.IllegalStateException: Cannot remove a consumer that had not been
registered: ID:xxx-36153-1166305227288-5:16:-1:1
at
org.apache.activemq.broker.TransportConnection.processRemoveConsumer(TransportConnection.java:593)
at org.apache.activemq.command.RemoveInfo.visit(RemoveInfo.java:64)
at
org.apache.activemq.broker.TransportConnection.service(TransportConnection.java:287)
at
org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:178)
at
org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:65)
at
org.apache.activemq.transport.InactivityMonitor.onCommand(InactivityMonitor.java:122)
at
org.apache.activemq.transport.stomp.StompTransportFilter.sendToActiveMQ(StompTransportFilter.java:74)
at
org.apache.activemq.transport.stomp.ProtocolConverter.sendToActiveMQ(ProtocolConverter.java:119)
at
org.apache.activemq.transport.stomp.ProtocolConverter.onStompUnsubscribe(ProtocolConverter.java:379)
at
org.apache.activemq.transport.stomp.ProtocolConverter.onStompCommad(ProtocolConverter.java:151)
at
org.apache.activemq.transport.stomp.StompTransportFilter.onCommand(StompTransportFilter.java:64)
at
org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:84)
at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:137)
at java.lang.Thread.run(Thread.java:595)
Using the default activemq.xml, I can reproduce
[jira] Commented: (AMQCPP-38) Async error on broker when running integration tests
[
https://issues.apache.org/activemq/browse/AMQCPP-38?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_37828
]
Albert Strasheim commented on AMQCPP-38:
Built a brand new AMQ 4.2, revision 493766. Also running AMQCPP from revision
493766. Using the default activemq.xml that gets included in the tarball made
by the AMQ build.
Running on Fedora Core 6 x86 Linux with Sun Java SDK 1.5.0_10. Hardware wise
I'm running a Intel P4 2.8 GHz with HT enabled with 2 GB RAM.
All the unit tests pass. The integration tests also pass, but I still get the
error on the broker the first time I run the integration tests after broker
startup. Not running under Valgrind or anything like that.
Stacktrace says:
{noformat}
java.lang.IllegalStateException: Cannot remove a consumer that had not been
registered: ID:xxx-40938-1168188574402-5:0:-1:1
at
org.apache.activemq.broker.TransportConnection.processRemoveConsumer(TransportConnection.java:552)
at org.apache.activemq.command.RemoveInfo.visit(RemoveInfo.java:64)
at
org.apache.activemq.broker.TransportConnection.service(TransportConnection.java:258)
at
org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:164)
at
org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:65)
at
org.apache.activemq.transport.InactivityMonitor.onCommand(InactivityMonitor.java:122)
at
org.apache.activemq.transport.stomp.StompTransportFilter.sendToActiveMQ(StompTransportFilter.java:74)
at
org.apache.activemq.transport.stomp.ProtocolConverter.sendToActiveMQ(ProtocolConverter.java:119)
at
org.apache.activemq.transport.stomp.ProtocolConverter.onStompUnsubscribe(ProtocolConverter.java:379)
at
org.apache.activemq.transport.stomp.ProtocolConverter.onStompCommad(ProtocolConverter.java:151)
at
org.apache.activemq.transport.stomp.StompTransportFilter.onCommand(StompTransportFilter.java:64)
at
org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:84)
at
org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:137)
at java.lang.Thread.run(Thread.java:595)
{noformat}
As you can see, the line numbers have changed slightly from the previous
stacktrace.
The second time I run the integration tests (without restarting the broker), I
get this:
{noformat}
[EMAIL PROTECTED] test-integration]$ ./activemq-test-integration
integration::durable::DurableTester::test. : errorE
integration::expiration::ExpirationTest::testExpired.b928ada1-656d-47c3-b1ee-5e6b5eb6954b
: OK
integration::expiration::ExpirationTest::testNotExpired.943b9129-9147-46f0-8016-414389f0ca5e
: OK
integration::simple::SimpleTester::test. : OK
integration::transactional::TransactionTester::test. : OK
integration::various::SimpleRollbackTest::test. : OK
!!!FAILURES!!!
Test Results:
Run: 6 Failures: 0 Errors: 1
1) test: integration::durable::DurableTester::test (E)
uncaught exception of unknown type
{noformat}
No stacktrace on the broker though. The third time I run the tests, another
failure appears:
{noformat}
[EMAIL PROTECTED] test-integration]$ ./activemq-test-integration
integration::durable::DurableTester::test. : errorE
integration::expiration::ExpirationTest::testExpired.3036ea6e-b22c-4daf-8446-53c17e6995f4
: OK
integration::expiration::ExpirationTest::testNotExpired.0577f611-aa2b-452f-9aa4-42d654375b78
: OK
integration::simple::SimpleTester::test. : OK
integration::transactional::TransactionTester::test. : errorE
integration::various::SimpleRollbackTest::test. : OK
!!!FAILURES!!!
Test Results:
Run: 6 Failures: 0 Errors: 2
1) test: integration::durable::DurableTester::test (E)
uncaught exception of unknown type
2) test: integration::transactional::TransactionTester::test (E)
uncaught exception of unknown type
{noformat}
On the next run, TransactionTester passes again.
Just restarted the broker and ran the integration tests again -- no
IllegalStateException stacktrace this time. Noticed this in the broker log on
startup the second time round:
{noformat}
INFO JournalPersistenceAdapter - Journal Recovered: 1 message(s) in
transactions recovered.
{noformat}
Ran the tests again against the second instance of the broker. Everything went
fine again. Next run after that yielded a DurableTester failure again, but no
stacktrace on the broker.
Async error on broker when running integration tests
Key: AMQCPP-38
URL: https://issues.apache.org/activemq/browse/AMQCPP-38
Project: ActiveMQ C++ Client
Issue Type: Bug
Affects Versions: 1.1
Reporter: Albert Strasheim
Assigned To: Nathan Mittler
Fix For: 1.1
Brought over from the comments in AMQCPP-28.
Sometimes when running the
[jira] Created: (AMQCPP-37) readUTF and writeUTF for BytesMessage
readUTF and writeUTF for BytesMessage - Key: AMQCPP-37 URL: https://issues.apache.org/activemq/browse/AMQCPP-37 Project: ActiveMQ C++ Client Issue Type: New Feature Components: CMS Impl Reporter: Albert Strasheim Assigned To: Nathan Mittler Fix For: 1.1 Attachments: readwriteutf.diff It seems the existing writeString function doesn't allow one to send strings to Java, as readUTF there expects a unsigned short (for length) followed by string data (not null terminated). With the attached patch applied, I am able to send strings between Java and C++. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQCPP-27) Issues reported by Valgrind when running unit tests
[ https://issues.apache.org/activemq/browse/AMQCPP-27?page=comments#action_37772 ] Albert Strasheim commented on AMQCPP-27: Still get the same leak with the latest trunk. I'm beginning to think that is is probably leak in my glibc or somewhere (running Fedora Core 6 here). Can someone on a different Linux system run this test through Valgrind? Anyway, I think this issue can probably be closed for the time being. Issues reported by Valgrind when running unit tests --- Key: AMQCPP-27 URL: https://issues.apache.org/activemq/browse/AMQCPP-27 Project: ActiveMQ C++ Client Issue Type: Bug Affects Versions: 1.1 Reporter: Albert Strasheim Assigned To: Nathan Mittler Fix For: 1.1 Attachments: activemq-cpp-deletes.diff, activemq-cpp-valgrind.log Valgrind 3.2.1 reported a few issues when running the ActiveMQ C++ unit tests. Some of them were simple cases of mismatched new[] and delete[] (patch attached). Valgrind also reports a few memory leaks, some probably the same as found by Rational Purify. Complete Valgrind log attached (after I fixed the deletes). I ran Valgrind as follows: valgrind \ --tool=memcheck \ --leak-check=yes \ --error-limit=no \ --num-callers=20 \ --freelist-vol=536870912 \ -v \ ./activemq-test -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQCPP-38) Async error on broker when running integration tests
Async error on broker when running integration tests Key: AMQCPP-38 URL: https://issues.apache.org/activemq/browse/AMQCPP-38 Project: ActiveMQ C++ Client Issue Type: Bug Affects Versions: 1.1 Reporter: Albert Strasheim Assigned To: Nathan Mittler Brought over from the comments in AMQCPP-28. Sometimes when running the integration tests against the AMQ broker from trunk, ones sees the following message from the broker: ERROR Service - Async error occurred: java.lang.IllegalStateException: Cannot remove a consumer that had not been registered: ID:xxx-36153-1166305227288-5:16:-1:1 at org.apache.activemq.broker.TransportConnection.processRemoveConsumer(TransportConnection.java:593) at org.apache.activemq.command.RemoveInfo.visit(RemoveInfo.java:64) at org.apache.activemq.broker.TransportConnection.service(TransportConnection.java:287) at org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:178) at org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:65) at org.apache.activemq.transport.InactivityMonitor.onCommand(InactivityMonitor.java:122) at org.apache.activemq.transport.stomp.StompTransportFilter.sendToActiveMQ(StompTransportFilter.java:74) at org.apache.activemq.transport.stomp.ProtocolConverter.sendToActiveMQ(ProtocolConverter.java:119) at org.apache.activemq.transport.stomp.ProtocolConverter.onStompUnsubscribe(ProtocolConverter.java:379) at org.apache.activemq.transport.stomp.ProtocolConverter.onStompCommad(ProtocolConverter.java:151) at org.apache.activemq.transport.stomp.StompTransportFilter.onCommand(StompTransportFilter.java:64) at org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:84) at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:137) at java.lang.Thread.run(Thread.java:595) Using the default activemq.xml, I can reproduce the IllegalStateException quite reliabily: 1. Start a fresh copy of the broker (4.2 from yesterday's trunk) 2. Run the integration test under Valgrind 3. IllegalStateException happens at the end of integration::durable::DurableTester::test or at the start of integration::expiration::ExpirationTest::testExpired. Subsequent test runs don't yield the error, until the broker is restarted. I don't know if this issue could be time-dependent - if it is, it could explain why I only see it when running under Valgrind. On Linux, I also just got the following test failure for the first time (not running under Valgrind): 1) test: integration::durable::DurableTester::test (E) uncaught exception of unknown type -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (AMQCPP-28) Purify and Valgrind warnings when running integration tests
[ https://issues.apache.org/activemq/browse/AMQCPP-28?page=all ] Albert Strasheim updated AMQCPP-28: --- Attachment: ExpirationTest-leak.diff I'm attaching a patch for the leak in ExpirationTest. With this patch the integration tests run clean through Valgrind. I'm still seeing the test failure associated with the async error. I made a new issue for this: AMQCPP-38. Purify and Valgrind warnings when running integration tests --- Key: AMQCPP-28 URL: https://issues.apache.org/activemq/browse/AMQCPP-28 Project: ActiveMQ C++ Client Issue Type: Bug Affects Versions: 1.1 Reporter: Albert Strasheim Assigned To: Nathan Mittler Fix For: 1.1 Attachments: activemq-cpp-test-integration-valgrind.log, ExpirationTest-leak.diff, vc2005-activemq-integration-tests-purify.txt, vc2005-activemq-integration-tests-r487924.txt Warnings from Purify when running the integration test (latest from trunk) against latest trunk of the broker. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQCPP-27) Issues reported by Valgrind when running unit tests
[ https://issues.apache.org/activemq/browse/AMQCPP-27?page=comments#action_37765 ] Albert Strasheim commented on AMQCPP-27: Haven't gotten round to this yet -- but I'll be putting our code that uses AMQCPP through a thorough Valgrind/Purify run in the next few days, so if I turn up anything I'll report it here. Issues reported by Valgrind when running unit tests --- Key: AMQCPP-27 URL: https://issues.apache.org/activemq/browse/AMQCPP-27 Project: ActiveMQ C++ Client Issue Type: Bug Affects Versions: 1.1 Reporter: Albert Strasheim Assigned To: Nathan Mittler Fix For: 1.1 Attachments: activemq-cpp-deletes.diff, activemq-cpp-valgrind.log Valgrind 3.2.1 reported a few issues when running the ActiveMQ C++ unit tests. Some of them were simple cases of mismatched new[] and delete[] (patch attached). Valgrind also reports a few memory leaks, some probably the same as found by Rational Purify. Complete Valgrind log attached (after I fixed the deletes). I ran Valgrind as follows: valgrind \ --tool=memcheck \ --leak-check=yes \ --error-limit=no \ --num-callers=20 \ --freelist-vol=536870912 \ -v \ ./activemq-test -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQCPP-35) Stomp content-length header not being set on BytesMessage
[ https://issues.apache.org/activemq/browse/AMQCPP-35?page=comments#action_37766 ] Albert Strasheim commented on AMQCPP-35: Doing this after the writeString: bytesMessage-setBodyBytes(bytesMessage-getBodyBytes(), bytesMessage-getBodyLength()); causes the message to come out as a BytesMessage on the receiving end. Stomp content-length header not being set on BytesMessage - Key: AMQCPP-35 URL: https://issues.apache.org/activemq/browse/AMQCPP-35 Project: ActiveMQ C++ Client Issue Type: Bug Components: Stomp Affects Versions: 1.1 Reporter: Albert Strasheim Assigned To: Nathan Mittler Not sure if this is a bug or if I'm just doing something wrong, but here goes. On a cms::Session I'm calling createBytesMessage and getting back a cms::BytesMessage which is an activemq::connector::stomp::commands::BytesMessageCommand underneath. On this message I set an int property and write a string using writeString. Then I send the message to my producer. At no point does it seem as if the content-length header is set in this case. I verified by checking the properties written out for this message in StompCommandWriter::writeCommand. Due to the absence of this header, when AMQCPP receives this message, it assumes it is a TextMessageCommand instead of a BytesMessageCommand. The only way the header can get set is by something calling setBytes on the BytesMessageCommand which calls through to setBytes of AbstractCommand which sets the header. I don't think this happens when one only does a writeString. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQCPP-32) Stomp messages don't preserve property types: please document this behaviour
Stomp messages don't preserve property types: please document this behaviour Key: AMQCPP-32 URL: https://issues.apache.org/activemq/browse/AMQCPP-32 Project: ActiveMQ C++ Client Issue Type: Wish Components: Stomp Affects Versions: 1.1 Reporter: Albert Strasheim Assigned To: Nathan Mittler I am producing messages from Java and C++ using ActiveMQ and AMQCPP, respectively. Messages I produce have an int property set on them which I want to select on, again in Java or C++. As far as I can tell from the [Stomp Protocol specification|http://stomp.codehaus.org/Protocol] there is no way to specify the types of message headers. As a result, all the messages end up with String properties as can be be seen in the unmarshal method of [org.apache.activemq.transport.stomp|http://svn.apache.org/viewvc/incubator/activemq/trunk/activemq-core/src/main/java/org/apache/activemq/transport/stomp/StompWireFormat.java?revision=470398view=markup]. I can work around this problem by selecting on id=123||id='123' in both Java and C++, but it seems a bit suboptimal. At least, this issue should be documented somewhere in activemq::connector::stomp::commands::StompMessage to help other people who can't figure out why their selectors don't work. We could consider adding a function that allows the user to specify that Stomp message properties should be sent in a type safe manner, and then prepend some kind of string to the property name to indicate the type. StompWireFormat on the Java side could check for this case and set the typed properties accordingly. This is probably too much of a hack -- people who want typed properties to work right can use Openwire in the (hopefully) near future. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQCPP-32) Stomp messages don't preserve property types: please document this behaviour
[ https://issues.apache.org/activemq/browse/AMQCPP-32?page=comments#action_37761 ] Albert Strasheim commented on AMQCPP-32: I think I'll make a documentation patch. Thanks. Stomp messages don't preserve property types: please document this behaviour Key: AMQCPP-32 URL: https://issues.apache.org/activemq/browse/AMQCPP-32 Project: ActiveMQ C++ Client Issue Type: Wish Components: Stomp Affects Versions: 1.1 Reporter: Albert Strasheim Assigned To: Nathan Mittler Priority: Trivial I am producing messages from Java and C++ using ActiveMQ and AMQCPP, respectively. Messages I produce have an int property set on them which I want to select on, again in Java or C++. As far as I can tell from the [Stomp Protocol specification|http://stomp.codehaus.org/Protocol] there is no way to specify the types of message headers. As a result, all the messages end up with String properties as can be be seen in the unmarshal method of [org.apache.activemq.transport.stomp|http://svn.apache.org/viewvc/incubator/activemq/trunk/activemq-core/src/main/java/org/apache/activemq/transport/stomp/StompWireFormat.java?revision=470398view=markup]. I can work around this problem by selecting on id=123||id='123' in both Java and C++, but it seems a bit suboptimal. At least, this issue should be documented somewhere in activemq::connector::stomp::commands::StompMessage to help other people who can't figure out why their selectors don't work. We could consider adding a function that allows the user to specify that Stomp message properties should be sent in a type safe manner, and then prepend some kind of string to the property name to indicate the type. StompWireFormat on the Java side could check for this case and set the typed properties accordingly. This is probably too much of a hack -- people who want typed properties to work right can use Openwire in the (hopefully) near future. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQCPP-31) Consider giving the unix #define a more unique name
[ https://issues.apache.org/activemq/browse/AMQCPP-31?page=comments#action_37759 ] Albert Strasheim commented on AMQCPP-31: Autoconf's HAVE_ defines will definately give more fine-grained control over the platform-specific code. I think this will be useful as Thread, Mutex and the socket code starts making their way onto more platforms. IIRC, you can tell autoconf to prefix the defines it puts in config.h somehow, so that you get stuff like ACTIVEMQ_CPP_HAVE_FOO. I think using multiple autoconf-built libraries with config.h's that define mostly the same stuff but differ slightly in one or two options together in a program can still lead to crazy things happening if they don't each prefix their HAVE_ defines. YMMV. Also keep in mind that if the number of options starts to escalate, it would be nice to provide a default config.h for Windows containing some sensible defaults. But this probably isn't an issue in this case, since ActiveMQ-CPP's only dependency is CppUnit (I think?). Consider giving the unix #define a more unique name --- Key: AMQCPP-31 URL: https://issues.apache.org/activemq/browse/AMQCPP-31 Project: ActiveMQ C++ Client Issue Type: Wish Affects Versions: 1.0, 1.1 Reporter: Albert Strasheim Assigned To: Timothy Bish Fix For: 1.1 src\main\activemq\concurrent\Mutex.h and src\main\activemq\concurrent\Thread.cpp check if unix is defined to enable UNIX-specific functionality. From what I've seen in other projects, it's considered a good practice to scope your defines, i.e. unix should rather be something like ACTIVEMQ_CPP_UNIX. This virtually eliminates problems when integrating multiple libraries, where defines like unix might mean different things to different libraries, meaning the user will have to do some messy preprocessor gymnastics when trying to include headers from multiple libraries in the same file. This also provides an obvious naming convention for other defines. Need, e.g., OpenBSD-specific code? Use ACTIVEMQ_CPP_OPENBSD. On Unix systems, autoconf can probably take care of this kind of thing. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQCPP-27) Issues reported by Valgrind when running unit tests
[ https://issues.apache.org/activemq/browse/AMQCPP-27?page=comments#action_37756 ] Albert Strasheim commented on AMQCPP-27: I'll check this out over the weekend and report back. Issues reported by Valgrind when running unit tests --- Key: AMQCPP-27 URL: https://issues.apache.org/activemq/browse/AMQCPP-27 Project: ActiveMQ C++ Client Issue Type: Bug Affects Versions: 1.1 Reporter: Albert Strasheim Assigned To: Nathan Mittler Fix For: 1.1 Attachments: activemq-cpp-deletes.diff, activemq-cpp-valgrind.log Valgrind 3.2.1 reported a few issues when running the ActiveMQ C++ unit tests. Some of them were simple cases of mismatched new[] and delete[] (patch attached). Valgrind also reports a few memory leaks, some probably the same as found by Rational Purify. Complete Valgrind log attached (after I fixed the deletes). I ran Valgrind as follows: valgrind \ --tool=memcheck \ --leak-check=yes \ --error-limit=no \ --num-callers=20 \ --freelist-vol=536870912 \ -v \ ./activemq-test -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQCPP-31) Consider giving the unix #define a more unique name
Consider giving the unix #define a more unique name --- Key: AMQCPP-31 URL: https://issues.apache.org/activemq/browse/AMQCPP-31 Project: ActiveMQ C++ Client Issue Type: Wish Affects Versions: 1.0, 1.1 Reporter: Albert Strasheim Assigned To: Nathan Mittler src\main\activemq\concurrent\Mutex.h and src\main\activemq\concurrent\Thread.cpp check if unix is defined to enable UNIX-specific functionality. From what I've seen in other projects, it's considered a good practice to scope your defines, i.e. unix should rather be something like ACTIVEMQ_CPP_UNIX. This virtually eliminates problems when integrating multiple libraries, where defines like unix might mean different things to different libraries, meaning the user will have to do some messy preprocessor gymnastics when trying to include headers from multiple libraries in the same file. This also provides an obvious naming convention for other defines. Need, e.g., OpenBSD-specific code? Use ACTIVEMQ_CPP_OPENBSD. On Unix systems, autoconf can probably take care of this kind of thing. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (AMQCPP-29) Projects in MSVC build building on top of one another
[ https://issues.apache.org/activemq/browse/AMQCPP-29?page=all ] Albert Strasheim reopened AMQCPP-29: Seems the include ordering and missing C:\Program Files\CppUnit\include includes fixes from my patch didn't make it. Attaching patch against latest project files. Projects in MSVC build building on top of one another - Key: AMQCPP-29 URL: https://issues.apache.org/activemq/browse/AMQCPP-29 Project: ActiveMQ C++ Client Issue Type: Bug Affects Versions: 1.1 Reporter: Albert Strasheim Assigned To: Timothy Bish Priority: Minor Fix For: 1.1 Attachments: activemq-cpp-winbuild.diff, activemq-cpp-winbuild2.diff After I've done a complete Debug build on Windows with MSVC 2005, building the solution again still yields the following each time I build: 1-- Build started: Project: vs2005-activemq-example, Configuration: Debug Win32 -- 1Linking... 1Embedding manifest... 1Build log was saved at file://c:\home\albert\work5\activemq-cpp\Debug\BuildLog.htm 1vs2005-activemq-example - 0 error(s), 0 warning(s) == Build: 1 succeeded, 0 failed, 3 up-to-date, 0 skipped == I think this relinking might have something to do with the tests and activemq-example all containing a main.cpp with is built as main.obj in the Debug directory. You might consider setting up the Windows builds as follows (idea borrowed from many other projects I've looked at): top level of project \win_build \win_build\solution.sln \win_build\project1.sln \win_build\project2.sln \win_build\Debug (output directory) \win_build\Release (output directory) \win_build\project1\Debug (intermediate directory) \win_build\project1\Release (intermediate directory) \win_build\project2\Debug (intermediate directory) \win_build\project2\Release (intermediate directory) To achieve this, each project's output directory for each build is set to (SolutionDir)$(ConfigurationName) and the intermediate directory is set to $(SolutionDir)$(ProjectName)\$(ConfigurationName) (note the extra \). This setup keeps all the Windows output out of the top level directory, and prevents projects from building on top of one another. With this setup, you need to refer to src\main as ..\src\main, etc. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (AMQCPP-29) Projects in MSVC build building on top of one another
[ https://issues.apache.org/activemq/browse/AMQCPP-29?page=all ] Albert Strasheim updated AMQCPP-29: --- Attachment: activemq-cpp-winbuild2.diff Projects in MSVC build building on top of one another - Key: AMQCPP-29 URL: https://issues.apache.org/activemq/browse/AMQCPP-29 Project: ActiveMQ C++ Client Issue Type: Bug Affects Versions: 1.1 Reporter: Albert Strasheim Assigned To: Timothy Bish Priority: Minor Fix For: 1.1 Attachments: activemq-cpp-winbuild.diff, activemq-cpp-winbuild2.diff After I've done a complete Debug build on Windows with MSVC 2005, building the solution again still yields the following each time I build: 1-- Build started: Project: vs2005-activemq-example, Configuration: Debug Win32 -- 1Linking... 1Embedding manifest... 1Build log was saved at file://c:\home\albert\work5\activemq-cpp\Debug\BuildLog.htm 1vs2005-activemq-example - 0 error(s), 0 warning(s) == Build: 1 succeeded, 0 failed, 3 up-to-date, 0 skipped == I think this relinking might have something to do with the tests and activemq-example all containing a main.cpp with is built as main.obj in the Debug directory. You might consider setting up the Windows builds as follows (idea borrowed from many other projects I've looked at): top level of project \win_build \win_build\solution.sln \win_build\project1.sln \win_build\project2.sln \win_build\Debug (output directory) \win_build\Release (output directory) \win_build\project1\Debug (intermediate directory) \win_build\project1\Release (intermediate directory) \win_build\project2\Debug (intermediate directory) \win_build\project2\Release (intermediate directory) To achieve this, each project's output directory for each build is set to (SolutionDir)$(ConfigurationName) and the intermediate directory is set to $(SolutionDir)$(ProjectName)\$(ConfigurationName) (note the extra \). This setup keeps all the Windows output out of the top level directory, and prevents projects from building on top of one another. With this setup, you need to refer to src\main as ..\src\main, etc. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQCPP-28) Purify and Valgrind warnings when running integration tests
[ https://issues.apache.org/activemq/browse/AMQCPP-28?page=comments#action_37714 ] Albert Strasheim commented on AMQCPP-28: Using the default activemq.xml, I can reproduce the IllegalStateException quite reliabily: 1. Start a fresh copy of the broker (4.2 from yesterday's trunk) 2. Run the integration test under Valgrind 3. IllegalStateException happens at the end of integration::durable::DurableTester::test or at the start of integration::expiration::ExpirationTest::testExpired. Subsequent test runs don't yield the error, until the broker is restarted. I don't know if this issue could be time-dependent -- if it is, it could explain why I only see it when running under Valgrind. On Linux, I also just got the following test failure for the first time (not running under Valgrind): 1) test: integration::durable::DurableTester::test (E) uncaught exception of unknown type Purify and Valgrind warnings when running integration tests --- Key: AMQCPP-28 URL: https://issues.apache.org/activemq/browse/AMQCPP-28 Project: ActiveMQ C++ Client Issue Type: Bug Affects Versions: 1.1 Reporter: Albert Strasheim Assigned To: Nathan Mittler Fix For: 1.1 Attachments: activemq-cpp-test-integration-valgrind.log, vc2005-activemq-integration-tests-purify.txt, vc2005-activemq-integration-tests-r487924.txt Warnings from Purify when running the integration test (latest from trunk) against latest trunk of the broker. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQCPP-28) Purify and Valgrind warnings when running integration tests
[ https://issues.apache.org/activemq/browse/AMQCPP-28?page=comments#action_37717 ] Albert Strasheim commented on AMQCPP-28: Should the new issue go under AMQ or AMQCPP? I'm guessing AMQ? Purify and Valgrind warnings when running integration tests --- Key: AMQCPP-28 URL: https://issues.apache.org/activemq/browse/AMQCPP-28 Project: ActiveMQ C++ Client Issue Type: Bug Affects Versions: 1.1 Reporter: Albert Strasheim Assigned To: Nathan Mittler Fix For: 1.1 Attachments: activemq-cpp-test-integration-valgrind.log, vc2005-activemq-integration-tests-purify.txt, vc2005-activemq-integration-tests-r487924.txt Warnings from Purify when running the integration test (latest from trunk) against latest trunk of the broker. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQCPP-29) Projects in MSVC build building on top of one another
[ https://issues.apache.org/activemq/browse/AMQCPP-29?page=comments#action_37712 ] Albert Strasheim commented on AMQCPP-29: Sure thing. I'll do this tonight or tomorrow. Projects in MSVC build building on top of one another - Key: AMQCPP-29 URL: https://issues.apache.org/activemq/browse/AMQCPP-29 Project: ActiveMQ C++ Client Issue Type: Bug Affects Versions: 1.1 Reporter: Albert Strasheim Assigned To: Nathan Mittler Priority: Minor Fix For: 1.1 After I've done a complete Debug build on Windows with MSVC 2005, building the solution again still yields the following each time I build: 1-- Build started: Project: vs2005-activemq-example, Configuration: Debug Win32 -- 1Linking... 1Embedding manifest... 1Build log was saved at file://c:\home\albert\work5\activemq-cpp\Debug\BuildLog.htm 1vs2005-activemq-example - 0 error(s), 0 warning(s) == Build: 1 succeeded, 0 failed, 3 up-to-date, 0 skipped == I think this relinking might have something to do with the tests and activemq-example all containing a main.cpp with is built as main.obj in the Debug directory. You might consider setting up the Windows builds as follows (idea borrowed from many other projects I've looked at): top level of project \win_build \win_build\solution.sln \win_build\project1.sln \win_build\project2.sln \win_build\Debug (output directory) \win_build\Release (output directory) \win_build\project1\Debug (intermediate directory) \win_build\project1\Release (intermediate directory) \win_build\project2\Debug (intermediate directory) \win_build\project2\Release (intermediate directory) To achieve this, each project's output directory for each build is set to (SolutionDir)$(ConfigurationName) and the intermediate directory is set to $(SolutionDir)$(ProjectName)\$(ConfigurationName) (note the extra \). This setup keeps all the Windows output out of the top level directory, and prevents projects from building on top of one another. With this setup, you need to refer to src\main as ..\src\main, etc. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQCPP-28) Purify and Valgrind warnings when running integration tests
[ https://issues.apache.org/activemq/browse/AMQCPP-28?page=comments#action_37713 ] Albert Strasheim commented on AMQCPP-28: I was running the latest ActiveMQ 4.2 from trunk (as of yesterday). I saw this with integration tests on Windows - broker on Windows and with integration tests on Linux - broker on Linux. Purify and Valgrind warnings when running integration tests --- Key: AMQCPP-28 URL: https://issues.apache.org/activemq/browse/AMQCPP-28 Project: ActiveMQ C++ Client Issue Type: Bug Affects Versions: 1.1 Reporter: Albert Strasheim Assigned To: Nathan Mittler Fix For: 1.1 Attachments: activemq-cpp-test-integration-valgrind.log, vc2005-activemq-integration-tests-purify.txt, vc2005-activemq-integration-tests-r487924.txt Warnings from Purify when running the integration test (latest from trunk) against latest trunk of the broker. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQCPP-27) Issues reported by Valgrind when running unit tests
[ https://issues.apache.org/activemq/browse/AMQCPP-27?page=comments#action_37703 ] Albert Strasheim commented on AMQCPP-27: Valgrind still reports this leak on Linux, but Purify says all clear on Windows. I'll take a closer sometime in the coming week. Issues reported by Valgrind when running unit tests --- Key: AMQCPP-27 URL: https://issues.apache.org/activemq/browse/AMQCPP-27 Project: ActiveMQ C++ Client Issue Type: Bug Affects Versions: 1.1 Reporter: Albert Strasheim Assigned To: Nathan Mittler Attachments: activemq-cpp-deletes.diff, activemq-cpp-valgrind.log Valgrind 3.2.1 reported a few issues when running the ActiveMQ C++ unit tests. Some of them were simple cases of mismatched new[] and delete[] (patch attached). Valgrind also reports a few memory leaks, some probably the same as found by Rational Purify. Complete Valgrind log attached (after I fixed the deletes). I ran Valgrind as follows: valgrind \ --tool=memcheck \ --leak-check=yes \ --error-limit=no \ --num-callers=20 \ --freelist-vol=536870912 \ -v \ ./activemq-test -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (AMQCPP-28) Purify and Valgrind warnings when running integration tests
[ https://issues.apache.org/activemq/browse/AMQCPP-28?page=all ] Albert Strasheim updated AMQCPP-28: --- Attachment: vc2005-activemq-integration-tests-r487924.txt Purify and Valgrind warnings when running integration tests --- Key: AMQCPP-28 URL: https://issues.apache.org/activemq/browse/AMQCPP-28 Project: ActiveMQ C++ Client Issue Type: Bug Affects Versions: 1.1 Reporter: Albert Strasheim Assigned To: Nathan Mittler Attachments: activemq-cpp-test-integration-valgrind.log, vc2005-activemq-integration-tests-purify.txt, vc2005-activemq-integration-tests-r487924.txt Warnings from Purify when running the integration test (latest from trunk) against latest trunk of the broker. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQCPP-26) Memory leaks reported by Rational Purify when running unit tests
[ https://issues.apache.org/activemq/browse/AMQCPP-26?page=comments#action_37696 ] Albert Strasheim commented on AMQCPP-26: Rational Purify is happy. I think there might still be one or two leaks that Valgrind picks up. I'll check the integration tests next. Memory leaks reported by Rational Purify when running unit tests Key: AMQCPP-26 URL: https://issues.apache.org/activemq/browse/AMQCPP-26 Project: ActiveMQ C++ Client Issue Type: Bug Affects Versions: 1.1 Reporter: Albert Strasheim Assigned To: Nathan Mittler Fix For: 1.1 Attachments: vc2005-activemq-unittests-purify.txt Rational Purify reports two potential memory leaks in the latest ActiveMQ C++ code from SVN. I've attached the complete Purfiy output. Look for the following: MPK: Potential memory leak of 116 bytes from 1 block allocated in activemq::core::ActiveMQConnectionFactory::createConnection(basic_stringchar,char_traitschar::std,allocatorchar::std::std const,basic_stringchar,char_traitschar::std,allocatorchar::std::std const,basic_stringchar,char_traitschar::std,allocatorchar::std::std const) [vc2005-activemq-unittests.exe] Potential memory leak of 116 bytes from 1 block allocated in activemq::core::ActiveMQConnectionFactory::createConnection(basic_stringchar,char_traitschar::std,allocatorchar::std::std const,basic_stringchar,char_traitschar::std,allocatorchar::std::std const,basic_stringchar,char_traitschar::std,allocatorchar::std::std const) [vc2005-activemq-unittests.exe] I think the createConnection leak has also been reported on the mailing list. Complete Purify output attached. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQCPP-26) Memory leaks reported by Rational Purify when running unit tests
[ https://issues.apache.org/activemq/browse/AMQCPP-26?page=all ] Albert Strasheim resolved AMQCPP-26. Fix Version/s: 1.1 Resolution: Fixed Memory leaks reported by Rational Purify when running unit tests Key: AMQCPP-26 URL: https://issues.apache.org/activemq/browse/AMQCPP-26 Project: ActiveMQ C++ Client Issue Type: Bug Affects Versions: 1.1 Reporter: Albert Strasheim Assigned To: Nathan Mittler Fix For: 1.1 Attachments: vc2005-activemq-unittests-purify.txt Rational Purify reports two potential memory leaks in the latest ActiveMQ C++ code from SVN. I've attached the complete Purfiy output. Look for the following: MPK: Potential memory leak of 116 bytes from 1 block allocated in activemq::core::ActiveMQConnectionFactory::createConnection(basic_stringchar,char_traitschar::std,allocatorchar::std::std const,basic_stringchar,char_traitschar::std,allocatorchar::std::std const,basic_stringchar,char_traitschar::std,allocatorchar::std::std const) [vc2005-activemq-unittests.exe] Potential memory leak of 116 bytes from 1 block allocated in activemq::core::ActiveMQConnectionFactory::createConnection(basic_stringchar,char_traitschar::std,allocatorchar::std::std const,basic_stringchar,char_traitschar::std,allocatorchar::std::std const,basic_stringchar,char_traitschar::std,allocatorchar::std::std const) [vc2005-activemq-unittests.exe] I think the createConnection leak has also been reported on the mailing list. Complete Purify output attached. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQCPP-27) Issues reported by Valgrind when running unit tests
[ https://issues.apache.org/activemq/browse/AMQCPP-27?page=comments#action_37699 ] Albert Strasheim commented on AMQCPP-27: Seems like there's still a mior issue with the threads on Linux. Valgrind says: ==10818== 8,640 bytes in 60 blocks are possibly lost in loss record 1 of 1 ==10818==at 0x400473F: calloc (vg_replace_malloc.c:279) ==10818==by 0x948AA9: _dl_allocate_tls (in /lib/ld-2.5.so) ==10818==by 0xAC8AC8: pthread_create@@GLIBC_2.1 (in /lib/libpthread-2.5.so) ==10818==by 0x819C741: activemq::concurrent::Thread::start() (Thread.cpp:82) ==10818==by 0x805130B: activemq::concurrent::MutexTest::test() (MutexTest.h:422) ==10818==by 0x26D706: CppUnit::TestCaseMethodFunctor::operator()() const (in /usr/lib/libcppunit-1.12.so.0.0.0) ==10818==by 0x25F13D: CppUnit::DefaultProtector::protect(CppUnit::Functor const, CppUnit::ProtectorContext const) (in /usr/lib/libcppunit-1.12.so.0.0.0) ==10818==by 0x269302: CppUnit::ProtectorChain::ProtectFunctor::operator()() const (in /usr/lib/libcppunit-1.12.so.0.0.0) ==10818==by 0x269054: CppUnit::ProtectorChain::protect(CppUnit::Functor const, CppUnit::ProtectorContext const) (in /usr/lib/libcppunit-1.12.so.0.0.0) ==10818==by 0x275C70: CppUnit::TestResult::protect(CppUnit::Functor const, CppUnit::Test*, std::string const) (in /usr/lib/libcppunit-1.12.so.0.0.0) ==10818==by 0x26D0AC: CppUnit::TestCase::run(CppUnit::TestResult*) (in /usr/lib/libcppunit-1.12.so.0.0.0) ==10818==by 0x26DD6E: CppUnit::TestComposite::doRunChildTests(CppUnit::TestResult*) (in /usr/lib/libcppunit-1.12.so.0.0.0) ==10818==by 0x26DCA9: CppUnit::TestComposite::run(CppUnit::TestResult*) (in /usr/lib/libcppunit-1.12.so.0.0.0) ==10818==by 0x26DD6E: CppUnit::TestComposite::doRunChildTests(CppUnit::TestResult*) (in /usr/lib/libcppunit-1.12.so.0.0.0) ==10818==by 0x26DCA9: CppUnit::TestComposite::run(CppUnit::TestResult*) (in /usr/lib/libcppunit-1.12.so.0.0.0) ==10818==by 0x27811F: CppUnit::TestRunner::WrappingSuite::run(CppUnit::TestResult*) (in /usr/lib/libcppunit-1.12.so.0.0.0) ==10818==by 0x2758D9: CppUnit::TestResult::runTest(CppUnit::Test*) (in /usr/lib/libcppunit-1.12.so.0.0.0) ==10818==by 0x277F5F: CppUnit::TestRunner::run(CppUnit::TestResult, std::string const) (in /usr/lib/libcppunit-1.12.so.0.0.0) ==10818==by 0x27B6AA: CppUnit::TextTestRunner::run(CppUnit::TestResult, std::string const) (in /usr/lib/libcppunit-1.12.so.0.0.0) ==10818==by 0x27B724: CppUnit::TextTestRunner::run(std::string, bool, bool, bool) (in /usr/lib/libcppunit-1.12.so.0.0.0) This is with r487893. Issues reported by Valgrind when running unit tests --- Key: AMQCPP-27 URL: https://issues.apache.org/activemq/browse/AMQCPP-27 Project: ActiveMQ C++ Client Issue Type: Bug Affects Versions: 1.1 Reporter: Albert Strasheim Assigned To: Nathan Mittler Attachments: activemq-cpp-deletes.diff, activemq-cpp-valgrind.log Valgrind 3.2.1 reported a few issues when running the ActiveMQ C++ unit tests. Some of them were simple cases of mismatched new[] and delete[] (patch attached). Valgrind also reports a few memory leaks, some probably the same as found by Rational Purify. Complete Valgrind log attached (after I fixed the deletes). I ran Valgrind as follows: valgrind \ --tool=memcheck \ --leak-check=yes \ --error-limit=no \ --num-callers=20 \ --freelist-vol=536870912 \ -v \ ./activemq-test -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQCPP-28) Purify and Valgrind warnings when running integration tests
Purify and Valgrind warnings when running integration tests --- Key: AMQCPP-28 URL: https://issues.apache.org/activemq/browse/AMQCPP-28 Project: ActiveMQ C++ Client Issue Type: Bug Affects Versions: 1.1 Reporter: Albert Strasheim Assigned To: Nathan Mittler Attachments: activemq-cpp-test-integration-valgrind.log, vc2005-activemq-integration-tests-purify.txt Warnings from Purify when running the integration test (latest from trunk) against latest trunk of the broker. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQCPP-29) Projects in MSVC build building on top of one another
Projects in MSVC build building on top of one another - Key: AMQCPP-29 URL: https://issues.apache.org/activemq/browse/AMQCPP-29 Project: ActiveMQ C++ Client Issue Type: Bug Affects Versions: 1.1 Reporter: Albert Strasheim Assigned To: Nathan Mittler Priority: Minor After I've done a complete Debug build on Windows with MSVC 2005, building the solution again still yields the following each time I build: 1-- Build started: Project: vs2005-activemq-example, Configuration: Debug Win32 -- 1Linking... 1Embedding manifest... 1Build log was saved at file://c:\home\albert\work5\activemq-cpp\Debug\BuildLog.htm 1vs2005-activemq-example - 0 error(s), 0 warning(s) == Build: 1 succeeded, 0 failed, 3 up-to-date, 0 skipped == I think this relinking might have something to do with the tests and activemq-example all containing a main.cpp with is built as main.obj in the Debug directory. You might consider setting up the Windows builds as follows (idea borrowed from many other projects I've looked at): top level of project \win_build \win_build\solution.sln \win_build\project1.sln \win_build\project2.sln \win_build\Debug (output directory) \win_build\Release (output directory) \win_build\project1\Debug (intermediate directory) \win_build\project1\Release (intermediate directory) \win_build\project2\Debug (intermediate directory) \win_build\project2\Release (intermediate directory) To achieve this, each project's output directory for each build is set to (SolutionDir)$(ConfigurationName) and the intermediate directory is set to $(SolutionDir)$(ProjectName)\$(ConfigurationName) (note the extra \). This setup keeps all the Windows output out of the top level directory, and prevents projects from building on top of one another. With this setup, you need to refer to src\main as ..\src\main, etc. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQCPP-26) Memory leaks reported by Rational Purify when running unit tests
Memory leaks reported by Rational Purify when running unit tests Key: AMQCPP-26 URL: https://issues.apache.org/activemq/browse/AMQCPP-26 Project: ActiveMQ C++ Client Issue Type: Bug Affects Versions: 1.1 Reporter: Albert Strasheim Assigned To: Nathan Mittler Attachments: vc2005-activemq-unittests-purify.txt Rational Purify reports two potential memory leaks in the latest ActiveMQ C++ code from SVN. I've attached the complete Purfiy output. Look for the following: MPK: Potential memory leak of 116 bytes from 1 block allocated in activemq::core::ActiveMQConnectionFactory::createConnection(basic_stringchar,char_traitschar::std,allocatorchar::std::std const,basic_stringchar,char_traitschar::std,allocatorchar::std::std const,basic_stringchar,char_traitschar::std,allocatorchar::std::std const) [vc2005-activemq-unittests.exe] Potential memory leak of 116 bytes from 1 block allocated in activemq::core::ActiveMQConnectionFactory::createConnection(basic_stringchar,char_traitschar::std,allocatorchar::std::std const,basic_stringchar,char_traitschar::std,allocatorchar::std::std const,basic_stringchar,char_traitschar::std,allocatorchar::std::std const) [vc2005-activemq-unittests.exe] I think the createConnection leak has also been reported on the mailing list. Complete Purify output attached. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQCPP-26) Memory leaks reported by Rational Purify when running unit tests
[ https://issues.apache.org/activemq/browse/AMQCPP-26?page=comments#action_37693 ] Albert Strasheim commented on AMQCPP-26: Sorry, the second leak was supposed to be: Memory leak of 16 bytes from 2 blocks allocated in activemq::transport::IOTransportTest::MyCommandReader::readCommand(void) [vc2005-activemq-unittests.exe] Memory leaks reported by Rational Purify when running unit tests Key: AMQCPP-26 URL: https://issues.apache.org/activemq/browse/AMQCPP-26 Project: ActiveMQ C++ Client Issue Type: Bug Affects Versions: 1.1 Reporter: Albert Strasheim Assigned To: Nathan Mittler Attachments: vc2005-activemq-unittests-purify.txt Rational Purify reports two potential memory leaks in the latest ActiveMQ C++ code from SVN. I've attached the complete Purfiy output. Look for the following: MPK: Potential memory leak of 116 bytes from 1 block allocated in activemq::core::ActiveMQConnectionFactory::createConnection(basic_stringchar,char_traitschar::std,allocatorchar::std::std const,basic_stringchar,char_traitschar::std,allocatorchar::std::std const,basic_stringchar,char_traitschar::std,allocatorchar::std::std const) [vc2005-activemq-unittests.exe] Potential memory leak of 116 bytes from 1 block allocated in activemq::core::ActiveMQConnectionFactory::createConnection(basic_stringchar,char_traitschar::std,allocatorchar::std::std const,basic_stringchar,char_traitschar::std,allocatorchar::std::std const,basic_stringchar,char_traitschar::std,allocatorchar::std::std const) [vc2005-activemq-unittests.exe] I think the createConnection leak has also been reported on the mailing list. Complete Purify output attached. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQCPP-27) Issues reported by Valgrind when running unit tests
Issues reported by Valgrind when running unit tests --- Key: AMQCPP-27 URL: https://issues.apache.org/activemq/browse/AMQCPP-27 Project: ActiveMQ C++ Client Issue Type: Bug Affects Versions: 1.1 Reporter: Albert Strasheim Assigned To: Nathan Mittler Attachments: activemq-cpp-deletes.diff, activemq-cpp-valgrind.log Valgrind 3.2.1 reported a few issues when running the ActiveMQ C++ unit tests. Some of them were simple cases of mismatched new[] and delete[] (patch attached). Valgrind also reports a few memory leaks, some probably the same as found by Rational Purify. Complete Valgrind log attached (after I fixed the deletes). I ran Valgrind as follows: valgrind \ --tool=memcheck \ --leak-check=yes \ --error-limit=no \ --num-callers=20 \ --freelist-vol=536870912 \ -v \ ./activemq-test -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQCPP-22) Use common name for ActiveMQ C++ library on Windows and Linux
[ https://issues.apache.org/activemq/browse/AMQCPP-22?page=comments#action_37684 ] Albert Strasheim commented on AMQCPP-22: The convention on Windows seems to be to leave off the lib- prefix. In build tools like SCons (and many others), calling a library 'foo' means 'foo.lib' on Windows and 'libfoo.a' on Linux. Use common name for ActiveMQ C++ library on Windows and Linux - Key: AMQCPP-22 URL: https://issues.apache.org/activemq/browse/AMQCPP-22 Project: ActiveMQ C++ Client Issue Type: Bug Affects Versions: 1.1 Reporter: Albert Strasheim Assigned To: Timothy Bish Fix For: 1.1 We're using SCons to build our application that links against the ActiveMQ-CPP library on Windows and Linux. The Visual Studio files included with ActiveMQ-CPP builds a library called activemq.lib whereas the Linux Autotools build builds a library called libactivemq-cpp.a. SCons takes care of the platform-specific prefix (lib or nothing) and the suffix (.a or .lib), but the base names of the library still differs, i.e. activemq vs activemq-cpp. I think it would make sense to standardise on one library name across all platforms. Personally, I'd go for activemq, but activemq-cpp is fine, as long as it's the same everywhere. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-1094) javacc arifact relocated warning from Maven
javacc arifact relocated warning from Maven --- Key: AMQ-1094 URL: https://issues.apache.org/activemq/browse/AMQ-1094 Project: ActiveMQ Issue Type: Improvement Affects Versions: 4.2.0 Reporter: Albert Strasheim Priority: Trivial [WARNING] While downloading javacc:javacc:3.2 This artifact has been relocated to net.java.dev.javacc:javacc:3.2. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-1095) Invalid messages selected from durable topic
Invalid messages selected from durable topic Key: AMQ-1095 URL: https://issues.apache.org/activemq/browse/AMQ-1095 Project: ActiveMQ Issue Type: Bug Components: Selector Affects Versions: 4.2.0 Reporter: Albert Strasheim Attachments: DurableTopicSelector.java We think we've found an issue with durable topic subscriptions and message selectors. The attached application sends messages with an int property i with values 0..19 to a topic. We also have a durable subscription to the topic, selecting messages for which i%2=0. After sending the messages, the connection is started, allowing the consumer to receive the messages we've published that match the selection criterion. The second and every subsequent time we run the application, we see the following: message.i = 19 message.i = 0 message.i = 2 message.i = 4 message.i = 6 message.i = 8 message.i = 10 message.i = 12 message.i = 14 message.i = 16 message.i = 18 message.i = 19 does not match the message selector criterion but it reaches our message handler anyway. Tested with ActiveMQ from trunk, revision 486090. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQCPP-24) activemq::util::Boolean::parseBoolean should return bool not int
activemq::util::Boolean::parseBoolean should return bool not int Key: AMQCPP-24 URL: https://issues.apache.org/activemq/browse/AMQCPP-24 Project: ActiveMQ C++ Client Issue Type: Bug Reporter: Albert Strasheim Assigned To: Nathan Mittler Attachments: boolean.diff activemq::util::Boolean::parseBoolean should return bool not int. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQCPP-22) Use common name for ActiveMQ C++ library on Windows and Linux
Use common name for ActiveMQ C++ library on Windows and Linux - Key: AMQCPP-22 URL: https://issues.apache.org/activemq/browse/AMQCPP-22 Project: ActiveMQ C++ Client Issue Type: Bug Affects Versions: 1.1 Reporter: Albert Strasheim Assigned To: Nathan Mittler We're using SCons to build our application that links against the ActiveMQ-CPP library on Windows and Linux. The Visual Studio files included with ActiveMQ-CPP builds a library called activemq.lib whereas the Linux Autotools build builds a library called libactivemq-cpp.a. SCons takes care of the platform-specific prefix (lib or nothing) and the suffix (.a or .lib), but the base names of the library still differs, i.e. activemq vs activemq-cpp. I think it would make sense to standardise on one library name across all platforms. Personally, I'd go for activemq, but activemq-cpp is fine, as long as it's the same everywhere. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQCPP-21) Minor Linux Build Issues
Minor Linux Build Issues Key: AMQCPP-21 URL: https://issues.apache.org/activemq/browse/AMQCPP-21 Project: ActiveMQ C++ Client Issue Type: Bug Environment: Linux Reporter: Albert Strasheim Assigned To: Nathan Mittler Priority: Minor We've picked up two minor issues with the build on Linux. Firstly: src\main\activemq\connector\openwire\marshal\v2\MarshallerFactory.cpp(17): #include activemq/connector/openwire/marshal/V2/MarshallerFactory.h That should be v2, not V2. Secondly, src/main/Makefile.am does not seem to install activemq/util/Config.h. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQCPP-17) Visual Studio project files shouldn't contain absolute include paths
[ https://issues.apache.org/activemq/browse/AMQCPP-17?page=comments#action_37622 ] Albert Strasheim commented on AMQCPP-17: Problem mostly solved. You might consider using a different path for CppUnit. If there's a Win32 installer for CppUnit, maybe it can provide some guidance for picking a sensible default path. Otherwise, I'd personally be inclined to go for something like C:\Program Files\CppUnit, or maybe %ProgramFiles%\CppUnit (don't know if MSVS does environment variables). Visual Studio project files shouldn't contain absolute include paths Key: AMQCPP-17 URL: https://issues.apache.org/activemq/browse/AMQCPP-17 Project: ActiveMQ C++ Client Issue Type: Improvement Reporter: Albert Strasheim Assigned To: Timothy Bish Priority: Minor Attachments: vspaths.diff The Visual Studio 2005 project files contain some absolute paths to ActiveMQ includes that should simply be paths relative to the project files. Patch for main library and example attached. Tests probably need to still be fixed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQCPP-19) Uuid class probably shouldn't use exception specifications
Uuid class probably shouldn't use exception specifications -- Key: AMQCPP-19 URL: https://issues.apache.org/activemq/browse/AMQCPP-19 Project: ActiveMQ C++ Client Issue Type: Bug Affects Versions: 1.0 Reporter: Albert Strasheim Assigned To: Nathan Mittler activemq/util/Uuid.h contains exception specifications. This causes the Microsoft compiler to warn: G:\activemq/util/Guid.h(46) : warning C4290: C++ exception specification ignored except to indicate a function is not __declspec(nothrow) In my experience, C++ code typically doesn't use exception specifications. Instead the exceptions that can be thrown are simply documented with the relevant doxygen tag. Some references: http://www.gotw.ca/publications/mill22.htm http://www.gotw.ca/gotw/082.htm http://www.boost.org/more/lib_guide.htm#Exception-specification -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQCPP-17) Visual Studio project files shouldn't contain absolute include paths
[ https://issues.apache.org/activemq/browse/AMQCPP-17?page=comments#action_37569 ] Albert Strasheim commented on AMQCPP-17: Patch has a bit of an issue. Seems Visual Studio gets confused about the paths to Queue.h because there are two Queue.h files in cms and activemq/util. The best thing to do in this case is probably to add two filters underneath Header Files, one for CMS headers and one for the ActiveMQ headers. And the same for the source files. Visual Studio project files shouldn't contain absolute include paths Key: AMQCPP-17 URL: https://issues.apache.org/activemq/browse/AMQCPP-17 Project: ActiveMQ C++ Client Issue Type: Improvement Reporter: Albert Strasheim Assigned To: Nathan Mittler Priority: Minor Attachments: vspaths.diff The Visual Studio 2005 project files contain some absolute paths to ActiveMQ includes that should simply be paths relative to the project files. Patch for main library and example attached. Tests probably need to still be fixed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQCPP-17) Visual Studio project files shouldn't contain absolute include paths
Visual Studio project files shouldn't contain absolute include paths Key: AMQCPP-17 URL: https://issues.apache.org/activemq/browse/AMQCPP-17 Project: ActiveMQ C++ Client Issue Type: Improvement Reporter: Albert Strasheim Assigned To: Nathan Mittler Priority: Minor Attachments: vspaths.diff The Visual Studio 2005 project files contain some absolute paths to ActiveMQ includes that should simply be paths relative to the project files. Patch for main library and example attached. Tests probably need to still be fixed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (AMQ-644) create Java Service Wrapper for ActiveMQ
[ https://issues.apache.org/activemq/browse/AMQ-644?page=all ] Albert Strasheim reopened AMQ-644: -- I downloaded the latest apache-activemq-4.1-incubator-SNAPSHOT ZIP today and I've noticed a few issues with the Java Service Wrapper for Windows. Firstly, my ZIP was missing wrapper.jar. According to wrapper.conf, it is supposed to live in bin\core\boot, but that directory doesn't seem to exist. The following line should probably be changed from: wrapper.java.additional.5=-Dactivemq.home=%ACTIVEMQ_HOME% to wrapper.java.additional.5=-Dactivemq.home=%ACTIVEMQ_HOME% (quotes added) so that it works if ActiveMQ is installed in a directory that contains spaces in its name, e.g. C:\Program Files\ActiveMQ. The comments immediately following # Uncomment to enable jmx should be 3 lines. They all seem to be on one line (maybe a line endings issue?). The idea I got from http://wrapper.tanukisoftware.org/doc/english/integrate-start-stop-win.html was that the second method of starting and stopping the service is preferable. If this is true, one wants the following service wrapper: wrapper.java.mainclass=org.tanukisoftware.wrapper.WrapperStartStopApp and the following application parameters (assuming run.jar hasn't changed since I tried with 4.0.2): wrapper.app.parameter.1=org.apache.activemq.console.Main wrapper.app.parameter.2=2 wrapper.app.parameter.3=start wrapper.app.parameter.4=xbean:activemq.xml wrapper.app.parameter.5=org.apache.activemq.console.Main wrapper.app.parameter.6=true wrapper.app.parameter.7=1 wrapper.app.parameter.8=stop I posted about this on the mailing list: http://mail-archives.apache.org/mod_mbox/geronimo-activemq-users/200609.mbox/[EMAIL PROTECTED] http://mail-archives.apache.org/mod_mbox/geronimo-activemq-users/200609.mbox/[EMAIL PROTECTED] create Java Service Wrapper for ActiveMQ Key: AMQ-644 URL: https://issues.apache.org/activemq/browse/AMQ-644 Project: ActiveMQ Issue Type: New Feature Components: Broker Reporter: james strachan Assigned To: Joseph Dennis Gapuz Priority: Minor Fix For: 4.1 Attachments: wrapper.conf http://wrapper.tanukisoftware.org/doc/english/introduction.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-1021) Release build of ActiveMQ-CPP from trunk with Visual Studio 2005 fails due to Windows headers include order issue
Release build of ActiveMQ-CPP from trunk with Visual Studio 2005 fails due to
Windows headers include order issue
-
Key: AMQ-1021
URL: https://issues.apache.org/activemq/browse/AMQ-1021
Project: ActiveMQ
Issue Type: Bug
Components: CMS (C++ client)
Affects Versions: 4.0.1
Environment: Windows
Reporter: Albert Strasheim
Doing a release build of ActiveMQ-CPP from trunk with Visual Studio 2005
results in the following error when compiling DataInputStreamTest.cpp:
{quote}
1-- Build started: Project: vc2005-activemq-unittests, Configuration:
Release Win32 --
1Compiling...
1DataInputStreamTest.cpp
1f:\activemq-cpp\src\main\activemq/io/ByteArrayInputStream.h(142) : warning
C4244: 'return' : conversion from '__w64 int' to 'int', possible loss of data
1C:\Program Files\Microsoft Platform SDK\Include\Winsock2.h(112) : error
C2011: 'fd_set' : 'struct' type redefinition
1C:\Program Files\Microsoft Platform SDK\Include\winsock.h(54) : see
declaration of 'fd_set'
1C:\Program Files\Microsoft Platform SDK\Include\Winsock2.h(147) : warning
C4005: 'FD_SET' : macro redefinition
1C:\Program Files\Microsoft Platform SDK\Include\winsock.h(88) : see
previous definition of 'FD_SET'
1C:\Program Files\Microsoft Platform SDK\Include\Winsock2.h(156) : error
C2011: 'timeval' : 'struct' type redefinition
1C:\Program Files\Microsoft Platform SDK\Include\winsock.h(97) : see
declaration of 'timeval'
...
{quote}
This error happens when some combination of winsock.h, winsock2.h and windows.h
is included in the wrong order. The following change fixes the problem and
might provide some clue as to what is going on.
{quote}
Index: DataInputStreamTest.h
===
--- DataInputStreamTest.h (revision 470321)
+++ DataInputStreamTest.h (working copy)
@@ -21,10 +21,10 @@
#include cppunit/TestFixture.h
#include cppunit/extensions/HelperMacros.h
+#include activemq/util/Endian.h
#include activemq/exceptions/ActiveMQException.h
#include activemq/io/BufferedInputStream.h
#include activemq/io/ByteArrayInputStream.h
-#include activemq/util/Endian.h
#include activemq/io/DataInputStream.h
#ifdef min
{quote}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
