[jira] Commented: (AMQCPP-60) message information is lost from stomp message to jms
[
https://issues.apache.org/activemq/browse/AMQCPP-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_38443
]
Nathan Mittler commented on AMQCPP-60:
--
I think I found it ... as you had indicated, we were sending the request-id
with all messages (supposed to only send on connect message). This is fixed in
trunk. Give it a shot.
message information is lost from stomp message to jms
-
Key: AMQCPP-60
URL: https://issues.apache.org/activemq/browse/AMQCPP-60
Project: ActiveMQ C++ Client
Issue Type: Bug
Components: Stomp
Affects Versions: 1.1
Environment: Using Windows XP SP2, JDK 1.6.0, Bea Weblogic Server 8.1
SP6, ActiveMQ-CPP 1.0, ActiveMQ 4.1 patched with Fix for AMQ-1110
Reporter: Kay Stanke
Assigned To: Nathan Mittler
Priority: Critical
Fix For: 2.0
As my producer is a cpp server program i downloaded and compiled activemq-cpp
1.0. I managed to make activemq-cpp compile and link as shared lib / dll
under vc 7.1 (Visual Studio .NET 2003). My consumer is located on a bea wls
8.1 I use the jms to jms bridge to forward the messages. For other reasons
(see AMQ-1141) the forward fails. I can see in the dumped message:
message: ActiveMQTextMessage {commandId = 3, responseRequired = false,
messageId = ID:KStanke-2844-1170064566619-5:0:-1:1:1,
originalDestination = null,
originalTransactionId = null,
producerId = ID:KStanke-2844-1170064566619-5:0:-1:1,
destination = queue://TEST.FOO,
transactionId = null, expiration = 0,
timestamp = 1170064774288,
arrival = 0,
correlationId = null,
replyTo = null,
persistent = false,
type = null,
priority = 4,
groupID = null,
groupSequence = 0, targetConsumerId = null, compressed = false,
userID = null, content = [EMAIL PROTECTED],
marshalledProperties = [EMAIL PROTECTED], dataStructure = null,
redeliveryCounter = 0, size = 0, properties = {request-id=2},
readOnlyProperties = true,
readOnlyBody = true, droppable = false, text = null}
i'm missing the persistence as i used pProducer-setDeliveryMode(
DeliveryMode::PERSISTANT ); As my message is a text message i'm missing the
message text as well. I created the message with: pMessage =
pSession-createTextMessage(messageText); with an nonempty string.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (AMQCPP-62) Broken CLIENT_ACKNOWLEDGE
[ https://issues.apache.org/activemq/browse/AMQCPP-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_38444 ] Nathan Mittler commented on AMQCPP-62: -- I've made a fix to the validation of received ack messages. Give the latest trunk a whirl. Broken CLIENT_ACKNOWLEDGE - Key: AMQCPP-62 URL: https://issues.apache.org/activemq/browse/AMQCPP-62 Project: ActiveMQ C++ Client Issue Type: Bug Affects Versions: 1.0, 1.1 Environment: Windows XP SP2 Visual C++ 8 Reporter: Manuel Vivo Assigned To: Nathan Mittler Fix For: 2.0 Attachments: test-1-0.zip, test-1-1.zip We've been trying to use the CLIENT_ACKNOWLEDGE mode without success. As a test, we've modified the example code in the distribution so it uses CLIENT_ACKNOWLEDGE, and it gives an error. I'm attaching the modified C++ code, and the output. We're using the release versions of ActiveMQ (4.1.0) and ActiveMQ CPP (1.0) We've tried also with the latest snapshot of ActiveMQ (apache-activemq-4.2-incubator-20070120.082020-21.zip) and the version 1.1 of ActiveMQ CPP, downloaded with svn co https://svn.apache.org/repos/asf/incubator/activemq/activemq-cpp/tags/activemq-cpp-1.1 It doesn't work either, but the error message is different. I'm attaching the modified code and the related output also. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (AMQCPP-64) Inconsistency in topic names when creating topics
[ https://issues.apache.org/activemq/browse/AMQCPP-64?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Mittler updated AMQCPP-64: - Description: Hi I am using the activemq-cpp cms api 1.0 release. The problem I am facing is like this- My producer sends a message to the consumer and a message should be sent from the receiving end as a reply after this - consider a situation where a loginRequest message has been sent and now a loginReply message should be sent from the receiving end. Attached is a sample main that can reproduce the problem I am facing - I have modified the sample helloproducer helloconsumer code available at http://activemq.org/site/activemq-cpp-client.html to reproduce my problem so that its easier for you to see. Please see attached cpp file = DestProbs.cpp. If you execute this piece of code you will see the output as in the attached image file (see attachments = DestinationProblem.JPG) This is what the code does producer lets call it xxx sends a Hello world! from thread to the consumer consumer lets call it yyy receives the message and displays it this is the normal behavior as given in the example on http://activemq.org/site/activemq-cpp-client.html Following extra needs to be done now from yyy a reply should go back to xxx ... for this i registered a producer at yyy by creating a topic using the message-getCMSReplyTo() and then replying back to that destination. The mismatch can be easily see by doing a bstat when I created the consumer yyy initially it created a topic by name say ABCDEFGH (which is a random id) and later on when I used the message-getCMSReplyTo() to create a topic the topic was registered with the name /topic/ABCDEFGH . the additional /topic/ that has got added is doing a mess up here and the replies from yyy to xxx are not reaching xxx (getting enqueued and not dequeued) ... the /topic/ gets added due to the following statement in HelloWorldProducer - run method message-setCMSReplyTo(replyTopic-toProviderString()); here the toProviderString method adds it actually ... if you replace this method with just the toString() method ... you will get a stomp exception saying that destinations should start with either /topic/ or /queue/ Can somebody make this code work please. For every message sent by the producer to consumer Hello world! from thread there should be a reply coming back as Thank you for Hello World !!! Please help me urgently here. Thank you in advance Lalit Nagpal CSA, SunGard was: Hi I am using the activemq-cpp cms api 1.0 release. The problem I am facing is like this- My producer sends a message to the consumer and a message should be sent from the receiving end as a reply after this - consider a situation where a loginRequest message has been sent and now a loginReply message should be sent from the receiving end. Attached is a sample main that can reproduce the problem I am facing - I have modified the sample helloproducer helloconsumer code available at http://activemq.org/site/activemq-cpp-client.html to reproduce my problem so that its easier for you to see. Please see attached cpp file = DestProbs.cpp. If you execute this piece of code you will see the output as in the attached image file (see attachments = DestinationProblem.JPG) This is what the code does producer lets call it xxx sends a Hello world! from thread to the consumer consumer lets call it yyy receives the message and displays it this is the normal behavior as given in the example on http://activemq.org/site/activemq-cpp-client.html Following extra needs to be done now from yyy a reply should go back to xxx ... for this i registered a producer at yyy by creating a topic using the message-getCMSReplyTo() and then replying back to that destination. The mismatch can be easily see by doing a bstat when I created the consumer yyy initially it created a topic by name say ABCDEFGH (which is a random id) and later on when I used the message-getCMSReplyTo() to create a topic the topic was registered with the name /topic/ABCDEFGH . the additional /topic/ that has got added is doing a mess up here and the replies from yyy to xxx are not reaching xxx (getting enqueued and not dequeued) ... the /topic/ gets added due to the following statement in HelloWorldProducer - run method message-setCMSReplyTo(replyTopic-toProviderString()); here the toProviderString method adds it actually ... if you replace this method with just the toString() method ... you will get a stomp exception saying that destinations should start with either /topic/ or /queue/ Can somebody make this code work please. For every message sent by the producer to consumer Hello world! from thread there should be a reply coming back as Thank you for Hello World !!! Please help me urgently here. Thank you in advance Lalit
[jira] Resolved: (AMQCPP-64) Inconsistency in topic names when creating topics
[ https://issues.apache.org/activemq/browse/AMQCPP-64?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Mittler resolved AMQCPP-64. -- Resolution: Won't Fix Looking closer at you sample code, it looks like the problem is how you're setting the CMSReplyTo. The following line is incorrect: message-setCMSReplyTo(replyTopic-toProviderString()); it should be: message-setCMSReplyTo(replyTopic-toString()); I'm going to resolve this issue for now - if you still find problems with replyTo, we can always open this back up. Inconsistency in topic names when creating topics - Key: AMQCPP-64 URL: https://issues.apache.org/activemq/browse/AMQCPP-64 Project: ActiveMQ C++ Client Issue Type: Bug Components: CMS Impl, Stomp Affects Versions: 1.0 Environment: win / lin Reporter: Lalit Nagpal Assigned To: Nathan Mittler Fix For: 2.0 Attachments: DestinationProblem.JPG, DestProbs.cpp Hi I am using the activemq-cpp cms api 1.0 release. The problem I am facing is like this- My producer sends a message to the consumer and a message should be sent from the receiving end as a reply after this - consider a situation where a loginRequest message has been sent and now a loginReply message should be sent from the receiving end. Attached is a sample main that can reproduce the problem I am facing - I have modified the sample helloproducer helloconsumer code available at http://activemq.org/site/activemq-cpp-client.html to reproduce my problem so that its easier for you to see. Please see attached cpp file = DestProbs.cpp. If you execute this piece of code you will see the output as in the attached image file (see attachments = DestinationProblem.JPG) This is what the code does producer lets call it xxx sends a Hello world! from thread to the consumer consumer lets call it yyy receives the message and displays it this is the normal behavior as given in the example on http://activemq.org/site/activemq-cpp-client.html Following extra needs to be done now from yyy a reply should go back to xxx ... for this i registered a producer at yyy by creating a topic using the message-getCMSReplyTo() and then replying back to that destination. The mismatch can be easily see by doing a bstat when I created the consumer yyy initially it created a topic by name say ABCDEFGH (which is a random id) and later on when I used the message-getCMSReplyTo() to create a topic the topic was registered with the name /topic/ABCDEFGH . the additional /topic/ that has got added is doing a mess up here and the replies from yyy to xxx are not reaching xxx (getting enqueued and not dequeued) ... the /topic/ gets added due to the following statement in HelloWorldProducer - run method message-setCMSReplyTo(replyTopic-toProviderString()); here the toProviderString method adds it actually ... if you replace this method with just the toString() method ... you will get a stomp exception saying that destinations should start with either /topic/ or /queue/ Can somebody make this code work please. For every message sent by the producer to consumer Hello world! from thread there should be a reply coming back as Thank you for Hello World !!! Please help me urgently here. Thank you in advance Lalit Nagpal CSA, SunGard -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (AMQCPP-61) CMSException::what returns c_str of temporary std::string
[ https://issues.apache.org/activemq/browse/AMQCPP-61?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Mittler closed AMQCPP-61. Resolution: Fixed fixed in trunk 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-60) message information is lost from stomp message to jms
[
https://issues.apache.org/activemq/browse/AMQCPP-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_38039
]
Nathan Mittler commented on AMQCPP-60:
--
Many bugs have been fixed since 1.0 - I would recommend trying the latest trunk
(or even the 1.1 tag).
message information is lost from stomp message to jms
-
Key: AMQCPP-60
URL: https://issues.apache.org/activemq/browse/AMQCPP-60
Project: ActiveMQ C++ Client
Issue Type: Bug
Components: Stomp
Affects Versions: 1.1
Environment: Using Windows XP SP2, JDK 1.6.0, Bea Weblogic Server 8.1
SP6, ActiveMQ-CPP 1.0, ActiveMQ 4.1 patched with Fix for AMQ-1110
Reporter: Kay Stanke
Assigned To: Nathan Mittler
Priority: Critical
Fix For: 2.0
As my producer is a cpp server program i downloaded and compiled activemq-cpp
1.0. I managed to make activemq-cpp compile and link as shared lib / dll
under vc 7.1 (Visual Studio .NET 2003). My consumer is located on a bea wls
8.1 I use the jms to jms bridge to forward the messages. For other reasons
(see AMQ-1141) the forward fails. I can see in the dumped message:
message: ActiveMQTextMessage {commandId = 3, responseRequired = false,
messageId = ID:KStanke-2844-1170064566619-5:0:-1:1:1,
originalDestination = null,
originalTransactionId = null,
producerId = ID:KStanke-2844-1170064566619-5:0:-1:1,
destination = queue://TEST.FOO,
transactionId = null, expiration = 0,
timestamp = 1170064774288,
arrival = 0,
correlationId = null,
replyTo = null,
persistent = false,
type = null,
priority = 4,
groupID = null,
groupSequence = 0, targetConsumerId = null, compressed = false,
userID = null, content = [EMAIL PROTECTED],
marshalledProperties = [EMAIL PROTECTED], dataStructure = null,
redeliveryCounter = 0, size = 0, properties = {request-id=2},
readOnlyProperties = true,
readOnlyBody = true, droppable = false, text = null}
i'm missing the persistence as i used pProducer-setDeliveryMode(
DeliveryMode::PERSISTANT ); As my message is a text message i'm missing the
message text as well. I created the message with: pMessage =
pSession-createTextMessage(messageText); with an nonempty string.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (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:all-tabpanel
]
Nathan Mittler closed AMQCPP-59.
Resolution: Fixed
Since it sounds like it's working now, I'm closing this issue.
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_38022
]
Nathan Mittler commented on AMQCPP-58:
--
I've done a bit of clean up to catch various error conditions and clean up
properly. Try the latest trunk and see if that leak goes away.
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-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_38024
]
Nathan Mittler commented on AMQCPP-59:
--
Albert,
I think the issue was your main module. It wasn't destroying the resources it
allocated each time through the loop. I've fixed this in the code below. Give
it a try and see if you're still having problems.
{code:title=main.cpp|borderStyle=solid}
#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;
}
};
ExceptionListener exListener;
activemq::core::ActiveMQConnectionFactory* connectionFactory = NULL;
cms::Connection* connection = NULL;
cms::Session* session = NULL;
cms::Destination* destination = NULL;
cms::MessageConsumer* consumer = NULL;
void cleanup(){
if( consumer != NULL ){
delete consumer;
consumer = NULL;
}
if( destination != NULL ){
delete destination;
destination = NULL;
}
if( session != NULL ){
delete session;
session = NULL;
}
if( connection != NULL ){
delete connection;
connection = NULL;
}
if( connectionFactory != NULL ){
delete connectionFactory;
connectionFactory = 0;
}
exListener.error = false;
}
int main(int argc, char* argv[]) {
while( true ) {
try {
activemq::core::ActiveMQConnectionFactory* connectionFactory =
new
activemq::core::ActiveMQConnectionFactory(tcp://127.0.0.1:61613);
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;
cleanup();
} catch ( cms::CMSException ex ) {
std::cout Got an exception: ex.getMessage() std::endl;
}
cleanup();
}
return 0;
}
{code}
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
Re: wiki access
Great - thanks! On 1/27/07, Hiram Chirino [EMAIL PROTECTED] wrote: Hi Nathan, We recently moved the confluence instance.. Something must have gotten borked. I'll look into it. BUT... I think we are looking into moving the space on to ASF managed machines.. not sure how long that will take so, I'll try to get this fix for you ASAP in the mean time. On 1/27/07, Nathan Mittler [EMAIL PROTECTED] wrote: Hey guys, I've apparently lost my privileges to change our wiki. Was just trying to update the AMQCPP 1.1 release page ( http://www.activemq.org/site/activemq-cpp-11-release.html) and was denied. Thanks, Nate -- Regards, Hiram Blog: http://hiramchirino.com
[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_38021
]
Nathan Mittler commented on AMQCPP-56:
--
Albert, I think you were trying out trunk while I was in the middle of changing
things. Specifically, the bit about the AMQCPP_UNUSED macro - I got rid of
that in my last submittal. Grab the latest trunk and try rebuilding - if
you're still seeing warnings, we'll reopen.
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.
Re: Doxample: Can we ship it with our code?
Hey Hiram, Is the resolution on this that we can just add a new header to his file in our distro? On 1/19/07, Hiram Chirino [EMAIL PROTECTED] wrote: Thanks Oren! On Jan 18, 2007, at 6:49 PM, Oren Ben-Kiki wrote: On Thu, 2007-01-18 at 18:09 -0500, Hiram Chirino wrote: ... Yeah the differences between the two get a bit complex and IANAL too :) But I think the biggest difference between the Licenses are that Apache licensed software is a bit more liberal with how it can be used. For example it allows commercial companies to make modifications and redistribute without giving back the changes. Which is contrary to the GPL philosophy. In essence the Apache, BSD, and MIT licenses are more Business friendly. So I light of that, you might not actually want to Apache License it.. And that would be OK... I don't feel that strongly about it. It isn't exactly the crown jewels :-) But if you don't mind other folks using your file (even for commercial reasons), you would just need to also add this to the header for us to be able to consume it: Copyright [] [name of copyright owner] Licensed under the Apache License, Version 2.0 (the License); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. Fine, put that in there with my name (Oren Ben-Kiki) and the current year (2007). And hopefully within a short period of time this will be in the Autoconf archive and the problem will go away. Share Enjoy, Oren Ben-Kiki
wiki access
Hey guys, I've apparently lost my privileges to change our wiki. Was just trying to update the AMQCPP 1.1 release page ( http://www.activemq.org/site/activemq-cpp-11-release.html) and was denied. Thanks, Nate
[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_38006
]
Nathan Mittler commented on AMQCPP-46:
--
The destructor of the consumer should not throw an exception, if it is this is
an error. At this point, I think we've exhausted this issue.
If you wouldn't mind, let's create two new issues:
1) consumer detor throwing exception
2) valgrind/purify output
Thanks again for all your help!
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] Closed: (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
]
Nathan Mittler closed AMQCPP-46.
Resolution: Fixed
This has been fixed in trunk
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++
msvcr80d.dll!10241a10()
...
kernel32.dll!7c812a5b
[jira] Commented: (AMQCPP-57) Typo in names of delivery modes
[ https://issues.apache.org/activemq/browse/AMQCPP-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_38009 ] Nathan Mittler commented on AMQCPP-57: -- Oops - good find :) While changing it to -TENT would cause compatibility issues, I think it's an easy fix and I'd rather just make it right once and for all than have two versions that have same value. 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] Closed: (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:all-tabpanel
]
Nathan Mittler closed AMQCPP-56.
Resolution: Fixed
fixed in trunk. Tested in msvc with warning level at 3
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] Closed: (AMQCPP-57) Typo in names of delivery modes
[ https://issues.apache.org/activemq/browse/AMQCPP-57?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Mittler closed AMQCPP-57. Resolution: Fixed fixed in trunk 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] Reopened: (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:all-tabpanel
]
Nathan Mittler reopened AMQCPP-56:
--
still a few issues on os x
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] Closed: (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:all-tabpanel
]
Nathan Mittler closed AMQCPP-56.
Resolution: Fixed
gcc problems fixed in trunk.
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] 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_37998
]
Nathan Mittler commented on AMQCPP-46:
--
hm ... I'm not getting that same stack trace in msvc, but I did find one bug in
the new code (for the propagation of close to child resources). I recommend
giving it a try again with the latest trunk. Do a make clean all of amq-cpp
just to make sure any bugs we find are really from the latest code.
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),
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] Closed: (AMQCPP-55) Need close() to propagate to child resources
[ https://issues.apache.org/activemq/browse/AMQCPP-55?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Mittler closed AMQCPP-55. Resolution: Duplicate This is being fixed along with issue AMQCPP-46 Need close() to propagate to child resources Key: AMQCPP-55 URL: https://issues.apache.org/activemq/browse/AMQCPP-55 Project: ActiveMQ C++ Client Issue Type: Bug Components: CMS Impl Affects Versions: 1.1 Environment: All Reporter: Nathan Mittler Assigned To: Nathan Mittler Priority: Minor Fix For: 2.0 Currently, the user is required to close CMS resources in the following order: consumer/producer session connection We should make this more like the JMS API which allows you to only close parent resources. For example, closing session should automatically close all child producers and consumers. Likewise, closing a connection should close child sessions, and their consumers and producers. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (AMQCPP-53) Declaration of extern int errno after including errno.h doesn't compile
[
https://issues.apache.org/activemq/browse/AMQCPP-53?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nathan Mittler closed AMQCPP-53.
Resolution: Fixed
fixed in trunk
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_37977 ] Nathan Mittler commented on AMQCPP-49: -- patches are always welcome :) 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] 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_37982
]
Nathan Mittler commented on AMQCPP-46:
--
at first glance it looks like the problem is in your main ... the consumers
should be closed (either explicitly or implicitly through the destructor)
before closing the session.
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
[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_37983
]
Nathan Mittler commented on AMQCPP-46:
--
I've cleaned up a couple of items that you might want to grab from trunk.
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
[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_37986
]
Nathan Mittler commented on AMQCPP-46:
--
Albert - you are correct. Looking at the JMS 1.1 spec, it specifically says in
the documentation on Session.close:
There is no need to close the producers and consumers of a closed session.
This, however, sounds like a new issue to me. Could you create one?
Also, could you indicate whether or not the current code works properly when
explicitly closing consumers before closing the session?
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),
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
[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_37989
]
Nathan Mittler commented on AMQCPP-46:
--
Albert,
I've made some updates to trunk to do the automatic closing of comsumers and
producers when you close the session. Could you give that a try?
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
[jira] Updated: (AMQCPP-54) Build broken due to autoconf problem?
[ https://issues.apache.org/activemq/browse/AMQCPP-54?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Mittler updated AMQCPP-54: - Priority: Trivial (was: Major) Fix Version/s: 2.0 Build broken due to autoconf problem? - Key: AMQCPP-54 URL: https://issues.apache.org/activemq/browse/AMQCPP-54 Project: ActiveMQ C++ Client Issue Type: Bug Affects Versions: 2.0 Environment: Ubuntu Linux 2.6.17-10-386 #2 Tue Dec 5 22:26:18 UTC 2006 Reporter: Wilfred Springer Assigned To: Nathan Mittler Priority: Trivial Fix For: 2.0 Running autogen.sh gives: src/test-integration/Makefile.am:34: `CXXFLAGS' is a user variable, you should not override it; src/test-integration/Makefile.am:34: use `AM_CXXFLAGS' instead. src/test/Makefile.am:88: `CXXFLAGS' is a user variable, you should not override it; src/test/Makefile.am:88: use `AM_CXXFLAGS' instead. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (AMQCPP-54) Build broken due to autoconf problem?
[ https://issues.apache.org/activemq/browse/AMQCPP-54?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_37993 ] Nathan Mittler commented on AMQCPP-54: -- The build is not broken ... it's just a warning from autogen.sh. You can still run ./configure and build just fine. We had to override CXXFLAGS in the test/test-integration Makefile.am files because we couldn't figure out a better way to get test-specific CXXFLAGS to work. If you know of a better way to do this, we would very much appreciate a patch! Build broken due to autoconf problem? - Key: AMQCPP-54 URL: https://issues.apache.org/activemq/browse/AMQCPP-54 Project: ActiveMQ C++ Client Issue Type: Bug Affects Versions: 2.0 Environment: Ubuntu Linux 2.6.17-10-386 #2 Tue Dec 5 22:26:18 UTC 2006 Reporter: Wilfred Springer Assigned To: Nathan Mittler Priority: Trivial Fix For: 2.0 Running autogen.sh gives: src/test-integration/Makefile.am:34: `CXXFLAGS' is a user variable, you should not override it; src/test-integration/Makefile.am:34: use `AM_CXXFLAGS' instead. src/test/Makefile.am:88: `CXXFLAGS' is a user variable, you should not override it; src/test/Makefile.am:88: use `AM_CXXFLAGS' instead. -- 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_37994
]
Nathan Mittler commented on AMQCPP-46:
--
sure thing - grab trunk!
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] Closed: (AMQCPP-54) Build broken due to autoconf problem?
[ https://issues.apache.org/activemq/browse/AMQCPP-54?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Mittler closed AMQCPP-54. Resolution: Fixed Since the build works, I'm considering it fixed. Build broken due to autoconf problem? - Key: AMQCPP-54 URL: https://issues.apache.org/activemq/browse/AMQCPP-54 Project: ActiveMQ C++ Client Issue Type: Bug Affects Versions: 2.0 Environment: Ubuntu Linux 2.6.17-10-386 #2 Tue Dec 5 22:26:18 UTC 2006 Reporter: Wilfred Springer Assigned To: Nathan Mittler Priority: Trivial Fix For: 2.0 Running autogen.sh gives: src/test-integration/Makefile.am:34: `CXXFLAGS' is a user variable, you should not override it; src/test-integration/Makefile.am:34: use `AM_CXXFLAGS' instead. src/test/Makefile.am:88: `CXXFLAGS' is a user variable, you should not override it; src/test/Makefile.am:88: use `AM_CXXFLAGS' instead. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (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
]
Nathan Mittler closed AMQCPP-46.
Resolution: Fixed
The example seems to be working fine now on OS X.
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-55) Need close() to propagate to child resources
Need close() to propagate to child resources Key: AMQCPP-55 URL: https://issues.apache.org/activemq/browse/AMQCPP-55 Project: ActiveMQ C++ Client Issue Type: Bug Components: CMS Impl Affects Versions: 1.1 Environment: All Reporter: Nathan Mittler Assigned To: Nathan Mittler Priority: Minor Fix For: 2.0 Currently, the user is required to close CMS resources in the following order: consumer/producer session connection We should make this more like the JMS API which allows you to only close parent resources. For example, closing session should automatically close all child producers and consumers. Likewise, closing a connection should close child sessions, and their consumers and producers. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Work started: (AMQCPP-55) Need close() to propagate to child resources
[ https://issues.apache.org/activemq/browse/AMQCPP-55?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on AMQCPP-55 started by Nathan Mittler. Need close() to propagate to child resources Key: AMQCPP-55 URL: https://issues.apache.org/activemq/browse/AMQCPP-55 Project: ActiveMQ C++ Client Issue Type: Bug Components: CMS Impl Affects Versions: 1.1 Environment: All Reporter: Nathan Mittler Assigned To: Nathan Mittler Priority: Minor Fix For: 2.0 Currently, the user is required to close CMS resources in the following order: consumer/producer session connection We should make this more like the JMS API which allows you to only close parent resources. For example, closing session should automatically close all child producers and consumers. Likewise, closing a connection should close child sessions, and their consumers and producers. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (AMQCPP-51) Autoconf is not properly setting CXXFLAGS on Linux
[
https://issues.apache.org/activemq/browse/AMQCPP-51?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nathan Mittler updated AMQCPP-51:
-
Fix Version/s: 2.0
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
Fix For: 2.0
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] Closed: (AMQCPP-51) Autoconf is not properly setting CXXFLAGS on Linux
[
https://issues.apache.org/activemq/browse/AMQCPP-51?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nathan Mittler closed AMQCPP-51.
Resolution: Duplicate
This is a duplicate of AMQCPP-49. I have re-opened that issue to address this.
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
Fix For: 2.0
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] Assigned: (AMQCPP-30) Add support to activemq-cpp to support the openwire protocol
[ https://issues.apache.org/activemq/browse/AMQCPP-30?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Mittler reassigned AMQCPP-30: Assignee: Timothy Bish (was: Nathan Mittler) Add support to activemq-cpp to support the openwire protocol Key: AMQCPP-30 URL: https://issues.apache.org/activemq/browse/AMQCPP-30 Project: ActiveMQ C++ Client Issue Type: New Feature Components: Openwire Environment: All Reporter: Nathan Mittler Assigned To: Timothy Bish Priority: Critical Fix For: 2.0 Original Estimate: 8 weeks Remaining Estimate: 8 weeks Need to complete the first cut at the implementation of the openwire transport -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (AMQCPP-49) Add -W -Wall compile options
[ https://issues.apache.org/activemq/browse/AMQCPP-49?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Mittler closed AMQCPP-49. Resolution: Fixed The compiler options are working correctly now. Due to some problems with the cppunit header files, I had to use different CXXFLAGS when building test and test-integration. As a result, running ./autogen.sh now gives a couple of warnings about overriding CXXFLAGS. 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] Closed: (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:all-tabpanel ] Nathan Mittler closed AMQCPP-38. Resolution: Fixed I believe this to be a broker side issue captured in AMQ-1077 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: 2.0 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. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (AMQCPP-49) Add -W -Wall compile options
[ https://issues.apache.org/activemq/browse/AMQCPP-49?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Mittler reopened AMQCPP-49: -- Accidentally disabled -W -Wall 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] Closed: (AMQCPP-40) A few stray unix and sun defines
[
https://issues.apache.org/activemq/browse/AMQCPP-40?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nathan Mittler closed AMQCPP-40.
Resolution: Fixed
fixed in trunk
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: 2.0
Reporter: Albert Strasheim
Assigned To: Nathan Mittler
Priority: Minor
Fix For: 2.0
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.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (AMQCPP-50) Derive cms::CMSException from std::exception
[ https://issues.apache.org/activemq/browse/AMQCPP-50?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Mittler closed AMQCPP-50. Resolution: Fixed Applied to trunk 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. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (AMQCPP-44) Reason for socket errors not reported correctly on Windows
[ https://issues.apache.org/activemq/browse/AMQCPP-44?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_37963 ] Nathan Mittler commented on AMQCPP-44: -- I've updated trunk to log all socket errors as is appropriate for the platform. Please take a look and see if this solves your problem. 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. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (AMQCPP-49) Add -W -Wall compile options
[ https://issues.apache.org/activemq/browse/AMQCPP-49?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Mittler closed AMQCPP-49. Resolution: Fixed Finally got cygwin happy. Removed use of -ansi -pedantic on cygwin, as well as a couple of other -Wno-XXX options. 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] Closed: (AMQCPP-48) Fix compilation with Visual Studio .NET 2003
[ https://issues.apache.org/activemq/browse/AMQCPP-48?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Mittler closed AMQCPP-48. Resolution: Fixed Patch applied to trunk 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] Closed: (AMQCPP-47) MapMessage getters should be const
[ https://issues.apache.org/activemq/browse/AMQCPP-47?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Mittler closed AMQCPP-47. Resolution: Fixed Patch applied to trunk 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] 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_37940 ] Nathan Mittler commented on AMQCPP-49: -- Unfortunately, without it - many warnings that are important don't show up in gcc ... such as problems with const-ness. And since users would be including our headers, making sure they are clean is important. 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 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] 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_37942 ] Nathan Mittler commented on AMQCPP-49: -- I'd rather not have to get that specific. Looking at the output from -Wall, it doesn't seem to be that fussy. I've already got most of the changes locally. 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 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] 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_37943 ] Nathan Mittler commented on AMQCPP-49: -- Also, I'd prefer to go with the approach of exposing all the warnings and then selectively disabling the ones we choose to ignore. That way, we're fully aware of what we're ignoring. The opposite is risky. 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 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] Closed: (AMQCPP-49) Add -W -Wall compile options
[ https://issues.apache.org/activemq/browse/AMQCPP-49?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Mittler closed AMQCPP-49. Resolution: Fixed Made changes throughout the source to support -W -Wall 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 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] 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_37946 ] Nathan Mittler commented on AMQCPP-49: -- You need to grab the latest makefile.am for main. Please provide a sample of the warnings that you're getting with msvc 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 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-49) Add -W -Wall compile options
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 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
Re: activemq-cpp compilation warnings
At this point, the vote for 1.1 has already gone to the incubator PMC, so unfortunately it's to late to get it into 1.1. Why don't you capture that in an issue targeted for 2.0 http://issues.apache.org/activemq/browse/AMQCPP ... if there are enough issues, we may cut an patched 1.1.1 release before going to 2.0. Regards, Nate On 1/18/07, Motl [EMAIL PROTECTED] wrote: Hi, Why isn't actviemq-cpp compiled with '-W -Wall' options? It's very useful, because default warning level for gcc is quite low. The problem is that while compiling code that uses cms/* headers with -W -Wall, number of warnings appears like that: ./activemq/exceptions/ActiveMQException.h: In copy constructor `activemq::exceptions::ActiveMQException::ActiveMQException(const activemq::exceptions::ActiveMQException)': ./activemq/exceptions/ActiveMQException.h:55: warning: base class `class cms::CMSException' should be explicitly initialized in the copy constructor and it's quite annoying. Could it be fixed in 1.1 release - there is no big work here. Thanks. -- View this message in context: http://www.nabble.com/activemq-cpp-compilation-warnings-tf3033440.html#a8428456 Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
Re: [VOTE] Release ActiveMQ-CPP 1.1
I've removed the doxygen files from the project and have cut a new source bundle: http://people.apache.org/~nmittler/incubator-activemq-cpp-1.1-src.zip On 1/16/07, Hiram Chirino [EMAIL PROTECTED] wrote: This is the case then we need to delete the m4 macro from the svn repo and the distro. And ask folks to install it manually as part of the build procedure... or we could just remove all the doxygen bits out of the autoconf stuff so that it's not a dependency. On 1/16/07, Nathan Mittler [EMAIL PROTECTED] wrote: It appears that the Autoconf macros are under the GPL (as expected) http://sourceforge.net/projects/ac-archive/. What is the typical way we deal with this at the ASF? On 1/16/07, Nathan Mittler [EMAIL PROTECTED] wrote: Great - thanks! On 1/15/07, Hiram Chirino [EMAIL PROTECTED] wrote: Hi Nathan, No I'm not really sure what it is but I assume it had to be something BSDish.. I'll do a little digging and see what I can find. On 1/15/07, Nathan Mittler [EMAIL PROTECTED] wrote: Hiram, Do you know anything about the license in this file? Is it compatible with the ASF? Also, does anyone have an example of a LICENSE.txt that includes multiple licenses ... not sure what this should look like? Thanks, Nate On 1/15/07, Kevan Miller [EMAIL PROTECTED] wrote: On Jan 14, 2007, at 11:07 AM, Nathan Mittler wrote: Hi everyone, Several bug fixes as well as a few new features have been incorporated into ActiveMQ-CPP - worthy of a 1.1 release, before we go for full openwire support in 2.0. The source bundle for the release candidate can be found here: http://people.apache.org/~nmittler/incubator-activemq-cpp-1.1-src.zip http://people.apache.org/%7Enmittler/incubator-activemq-cpp-1.1-src.zip http://people.apache.org/%7Etabish/activemq-cpp-1.0.zip And here's the wiki page for the release: http://www.activemq.org/site/activemq-cpp-11-release.html http://www.activemq.org/site/activemq-cpp-10-release.html Please cast your votes: [ ] +1 Release the source as Apache ActiveMQ CPP 1.1 [ ] -1 Veto the release (provide specific comments) The following file in your distribution seems to be licensed under the same license as Autoconf. I don't know what that license is. I assume it's compatible with the ASF. The license needs to be included in your LICENSE.txt file. === ==./m4/ac_doxygen.m4 === # This file is part of Autoconf. -*- Autoconf -*- # Copyright (C) 2004 Oren Ben-Kiki # This file is distributed under the same terms as the Autoconf macro files. ... --kevan -- Regards, Hiram Blog: http://hiramchirino.com -- Regards, Hiram Blog: http://hiramchirino.com
Re: [VOTE] Release ActiveMQ-CPP 1.1
And here's my +1 ... bringing the totals to: +1: 6 +0: 0 -1 : 0 Since the vote has been out for 3 days, I think it's safe to say that the release passes. Given that AMQ is on the verge of becoming a TLP, is the next step still to bring a vote on the general incubator list? On 1/17/07, Kevan Miller [EMAIL PROTECTED] wrote: On Jan 17, 2007, at 9:36 AM, Mittler, Nathan wrote: Hi Kevan, With the current changes, can I call you a +1? Thanks, Nate -Original Message- From: Nathan Mittler [mailto: [EMAIL PROTECTED] Sent: Wednesday, January 17, 2007 6:42 AM To: activemq-dev@geronimo.apache.org Subject: Re: [VOTE] Release ActiveMQ-CPP 1.1 I've removed the doxygen files from the project and have cut a new source bundle: http://people.apache.org/~nmittler/incubator-activemq-cpp-1.1-src.ziphttp://people.apache.org/%7Enmittler/incubator-activemq-cpp-1.1-src.zip Thanks for the reminder Nathan. +1 Release the source as Apache ActiveMQ CPP 1.1 --kevan
[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_37932
]
Nathan Mittler commented on AMQCPP-46:
--
Committed a fix for the exception listener to trunk and added unit tests to
verify. Will look into the producer destruction next.
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
Re: [VOTE] Release ActiveMQ-CPP 1.1
It appears that the Autoconf macros are under the GPL (as expected) http://sourceforge.net/projects/ac-archive/. What is the typical way we deal with this at the ASF? On 1/16/07, Nathan Mittler [EMAIL PROTECTED] wrote: Great - thanks! On 1/15/07, Hiram Chirino [EMAIL PROTECTED] wrote: Hi Nathan, No I'm not really sure what it is but I assume it had to be something BSDish.. I'll do a little digging and see what I can find. On 1/15/07, Nathan Mittler [EMAIL PROTECTED] wrote: Hiram, Do you know anything about the license in this file? Is it compatible with the ASF? Also, does anyone have an example of a LICENSE.txt that includes multiple licenses ... not sure what this should look like? Thanks, Nate On 1/15/07, Kevan Miller [EMAIL PROTECTED] wrote: On Jan 14, 2007, at 11:07 AM, Nathan Mittler wrote: Hi everyone, Several bug fixes as well as a few new features have been incorporated into ActiveMQ-CPP - worthy of a 1.1 release, before we go for full openwire support in 2.0. The source bundle for the release candidate can be found here: http://people.apache.org/~nmittler/incubator-activemq-cpp-1.1-src.ziphttp://people.apache.org/%7Enmittler/incubator-activemq-cpp-1.1-src.zip http://people.apache.org/%7Etabish/activemq-cpp-1.0.zip And here's the wiki page for the release: http://www.activemq.org/site/activemq-cpp-11-release.html http://www.activemq.org/site/activemq-cpp-10-release.html Please cast your votes: [ ] +1 Release the source as Apache ActiveMQ CPP 1.1 [ ] -1 Veto the release (provide specific comments) The following file in your distribution seems to be licensed under the same license as Autoconf. I don't know what that license is. I assume it's compatible with the ASF. The license needs to be included in your LICENSE.txt file. === ==./m4/ac_doxygen.m4 === # This file is part of Autoconf. -*- Autoconf -*- # Copyright (C) 2004 Oren Ben-Kiki # This file is distributed under the same terms as the Autoconf macro files. ... --kevan -- Regards, Hiram Blog: http://hiramchirino.com
Re: [VOTE] Release ActiveMQ-CPP 1.1
Hiram, Do you know anything about the license in this file? Is it compatible with the ASF? Also, does anyone have an example of a LICENSE.txt that includes multiple licenses ... not sure what this should look like? Thanks, Nate On 1/15/07, Kevan Miller [EMAIL PROTECTED] wrote: On Jan 14, 2007, at 11:07 AM, Nathan Mittler wrote: Hi everyone, Several bug fixes as well as a few new features have been incorporated into ActiveMQ-CPP - worthy of a 1.1 release, before we go for full openwire support in 2.0. The source bundle for the release candidate can be found here: http://people.apache.org/~nmittler/incubator-activemq-cpp-1.1-src.zip http://people.apache.org/%7Etabish/activemq-cpp-1.0.zip And here's the wiki page for the release: http://www.activemq.org/site/activemq-cpp-11-release.html http://www.activemq.org/site/activemq-cpp-10-release.html Please cast your votes: [ ] +1 Release the source as Apache ActiveMQ CPP 1.1 [ ] -1 Veto the release (provide specific comments) The following file in your distribution seems to be licensed under the same license as Autoconf. I don't know what that license is. I assume it's compatible with the ASF. The license needs to be included in your LICENSE.txt file. === ==./m4/ac_doxygen.m4 === # This file is part of Autoconf. -*- Autoconf -*- # Copyright (C) 2004 Oren Ben-Kiki # This file is distributed under the same terms as the Autoconf macro files. ... --kevan
[VOTE] Release ActiveMQ-CPP 1.1
Hi everyone, Several bug fixes as well as a few new features have been incorporated into ActiveMQ-CPP - worthy of a 1.1 release, before we go for full openwire support in 2.0. The source bundle for the release candidate can be found here: http://people.apache.org/~nmittler/incubator-activemq-cpp-1.1-src.zip http://people.apache.org/%7Etabish/activemq-cpp-1.0.zip And here's the wiki page for the release: http://www.activemq.org/site/activemq-cpp-11-release.html http://www.activemq.org/site/activemq-cpp-10-release.html Please cast your votes: [ ] +1 Release the source as Apache ActiveMQ CPP 1.1 [ ] -1 Veto the release (provide specific comments) Regards, Nate
[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_37883 ] Nathan Mittler commented on AMQCPP-25: -- Hi Albert, Great work! Looks like you might be onto something here. Just out of curiosity, where did you get the idea for your patch (char c = new char, delete c) - I didn't see that solution called out in the links you posted. Perhaps I just missed it. Thanks! 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_37884 ] Nathan Mittler commented on AMQCPP-25: -- As indicated in the links Albert provided, we should add the following compiler flags: -fstrict-aliasing -Wstrict-aliasing 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] Updated: (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:all-tabpanel ] Nathan Mittler updated AMQCPP-38: - Fix Version/s: (was: 1.1) 2.0 Moving to release 2.0 - the current thought is that this may be an issue with 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: 2.0 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-42) A few more strict aliasing warnings
[
https://issues.apache.org/activemq/browse/AMQCPP-42?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nathan Mittler updated AMQCPP-42:
-
Fix Version/s: (was: 2.0)
1.1
A few more strict aliasing warnings
---
Key: AMQCPP-42
URL: https://issues.apache.org/activemq/browse/AMQCPP-42
Project: ActiveMQ C++ Client
Issue Type: Improvement
Affects Versions: 1.1
Reporter: Albert Strasheim
Assigned To: Timothy Bish
Priority: Minor
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] Closed: (AMQCPP-42) A few more strict aliasing warnings
[
https://issues.apache.org/activemq/browse/AMQCPP-42?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nathan Mittler closed AMQCPP-42.
Resolution: Fixed
Assignee: Nathan Mittler (was: Timothy Bish)
Patches have been applied. Running on FC4 with gcc 4.0.1, I do not see any
warnings. Unit tests run fine as well.
A few more strict aliasing warnings
---
Key: AMQCPP-42
URL: https://issues.apache.org/activemq/browse/AMQCPP-42
Project: ActiveMQ C++ Client
Issue Type: Improvement
Affects Versions: 1.1
Reporter: Albert Strasheim
Assigned To: Nathan Mittler
Priority: Minor
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] Closed: (AMQCPP-32) Stomp messages don't preserve property types: please document this behaviour
[ https://issues.apache.org/activemq/browse/AMQCPP-32?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Mittler closed AMQCPP-32. Resolution: Fixed I have documented the behavior here http://www.activemq.org/site/activemq-cpp-stomp.html 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 Fix For: 1.1 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=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_37832 ] Nathan Mittler commented on AMQCPP-32: -- I agree with Tim - this really should be commented on the wiki page. The user isn't going to be looking into the code comments - rather, they should only be looking at the CMS API. The CMS API isn't going to tell them the specific quirks of a particular implementation. I'll take this issue and will update the wiki page accordingly. 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 Fix For: 1.1 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] Updated: (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:all-tabpanel ] Nathan Mittler updated AMQCPP-38: - Fix Version/s: 1.1 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] Updated: (AMQCPP-32) Stomp messages don't preserve property types: please document this behaviour
[ https://issues.apache.org/activemq/browse/AMQCPP-32?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Mittler updated AMQCPP-32: - Fix Version/s: 1.1 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 Fix For: 1.1 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] Closed: (AMQCPP-27) Issues reported by Valgrind when running unit tests
[ https://issues.apache.org/activemq/browse/AMQCPP-27?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Mittler closed AMQCPP-27. Resolution: Fixed If the leaks shown by valgrind end up being real leaks or if more leaks pop up - we'll just open a new issue. 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-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_37827 ] Nathan Mittler commented on AMQCPP-38: -- Running the integration tests several times in a row against the latest trunk of the broker (everything co-located on the same OS X machine), I do not get this error. Could you please provide your environment? Also, try running against the broker's latest trunk and see if you still have problems. 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-27) Issues reported by Valgrind when running unit tests
[ https://issues.apache.org/activemq/browse/AMQCPP-27?page=comments#action_37753 ] Nathan Mittler commented on AMQCPP-27: -- I haven't heard back - was this resolved by my latest changes? 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] Updated: (AMQCPP-31) Consider giving the unix #define a more unique name
[ https://issues.apache.org/activemq/browse/AMQCPP-31?page=all ] Nathan Mittler updated AMQCPP-31: - Fix Version/s: 1.1 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
Re: Undocumented stomp header?
Ok, that clears it up. Thnx! On 12/19/06, Brian McCallister [EMAIL PROTECTED] wrote: On Dec 17, 2006, at 9:58 AM, Nathan Mittler wrote: Hey guys, I was just looking at the stomp transport and noticed what appears to be an undocumented extension to stomp adding a header for subscription ID (literally the string id on the wire) to the subscribe and unsubscribe frames. I have just a few questions: Yep, this is the subscription id in activemq. It is added, as well, it might be useful :-) 1) Is this equivalent to a consumer id? ... meaning that the client application can use this value to subscribe multiple times to the same destination through the same connection? I cannot think of any way to accomplish this in the stomp connector, but in theory, yes. 2) Is there any reason that not providing this header might cause the 4.1broker to throw an exception on an unsubscribe, but not 4.0.2? It shouldn't even be used, actually. 3) Is this header documented anywhere? I did not see it here http://www.activemq.org/site/stomp.html or here http://stomp.codehaus.org/Protocol Nope, is there for informational purposes if you are looking at JMX, basically. -Brian
[jira] Commented: (AMQCPP-27) Issues reported by Valgrind when running unit tests
[ https://issues.apache.org/activemq/browse/AMQCPP-27?page=comments#action_37706 ] Nathan Mittler commented on AMQCPP-27: -- Ok, I think I got it. Grab the latest activemq/concurrent/Thread.cpp and give that a try. 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-28) Purify and Valgrind warnings when running integration tests
[ https://issues.apache.org/activemq/browse/AMQCPP-28?page=comments#action_37708 ] Nathan Mittler commented on AMQCPP-28: -- ... also, what version of the broker are you running against? 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] Resolved: (AMQ-517) Create a C++ client for ActiveMQ that can work with STOMP and OpenWire
[ https://issues.apache.org/activemq/browse/AMQ-517?page=all ] Nathan Mittler resolved AMQ-517. Resolution: Fixed Since activemq-cpp can support both stomp and openwire, I think it's safe to say this issue has been resolved. I will open another issue under AMQCPP to address adding support for openwire (which is already underway). Create a C++ client for ActiveMQ that can work with STOMP and OpenWire -- Key: AMQ-517 URL: https://issues.apache.org/activemq/browse/AMQ-517 Project: ActiveMQ Issue Type: Improvement Components: JMS client Reporter: Nathan Mittler Assigned To: Nathan Mittler Priority: Minor Attachments: cms.tar.gz, cms_v2.tar.gz, cms_v3.tar.gz I've created this issue to post my code. Attached is my first cut at CMS (C++ Message Service) with a Stomp client. The idea is that CMS is the API (like JMS) and any messaging protocol can be used behind it (Stomp, OpenWire, etc). The docs folder contains the doxygen html for the source as well as a pdf document that gives a high-level overview. -- 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-30) Add support to activemq-cpp to support the openwire protocol
Add support to activemq-cpp to support the openwire protocol Key: AMQCPP-30 URL: https://issues.apache.org/activemq/browse/AMQCPP-30 Project: ActiveMQ C++ Client Issue Type: New Feature Components: Openwire Environment: All Reporter: Nathan Mittler Assigned To: Nathan Mittler Priority: Critical Fix For: 2.0 Need to complete the first cut at the implementation of the openwire transport -- 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_37715 ] Nathan Mittler commented on AMQCPP-28: -- We've just recently discovered this same problem. It seems that the integration tests work fine against 4.0.2, but not the latest trunk. Since this isn't related to the memory leaks, would you mind opening a new JIRA issue for this? 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] Assigned: (AMQCPP-29) Projects in MSVC build building on top of one another
[ https://issues.apache.org/activemq/browse/AMQCPP-29?page=all ] Nathan Mittler reassigned AMQCPP-29: Assignee: Timothy Bish (was: Nathan Mittler) 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 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] Closed: (AMQCPP-16) CMS API needs updates to more closely follow JMS API
[ https://issues.apache.org/activemq/browse/AMQCPP-16?page=all ] Nathan Mittler closed AMQCPP-16. Resolution: Fixed Assignee: Nathan Mittler (was: Timothy Bish) At this point, we have implemented 3 of the 4 changes. We're going to push out the implementation of the recover method for now. If someone really wants that functionality, we can create another issue in the future. CMS API needs updates to more closely follow JMS API Key: AMQCPP-16 URL: https://issues.apache.org/activemq/browse/AMQCPP-16 Project: ActiveMQ C++ Client Issue Type: Improvement Components: CMS Impl Affects Versions: 1.1, 2.0 Reporter: Timothy Bish Assigned To: Nathan Mittler Priority: Minor Fix For: 1.1 The CMS API interfaces need updates so that they more closely follow the JMS API: 1. Change longs to long long types. 2. The ReplyTo accessors should handle cms::Destination pointers, not strings -- 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_37710 ] Nathan Mittler commented on AMQCPP-29: -- It sounds like you know what needs to be done - would you fancy providing us with a patch? 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] Updated: (AMQCPP-27) Issues reported by Valgrind when running unit tests
[ https://issues.apache.org/activemq/browse/AMQCPP-27?page=all ] Nathan Mittler updated AMQCPP-27: - Fix Version/s: 1.1 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] Updated: (AMQCPP-28) Purify and Valgrind warnings when running integration tests
[ https://issues.apache.org/activemq/browse/AMQCPP-28?page=all ] Nathan Mittler updated AMQCPP-28: - Fix Version/s: 1.1 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] Updated: (AMQCPP-29) Projects in MSVC build building on top of one another
[ https://issues.apache.org/activemq/browse/AMQCPP-29?page=all ] Nathan Mittler updated AMQCPP-29: - Fix Version/s: 1.1 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
Undocumented stomp header?
Hey guys, I was just looking at the stomp transport and noticed what appears to be an undocumented extension to stomp adding a header for subscription ID (literally the string id on the wire) to the subscribe and unsubscribe frames. I have just a few questions: 1) Is this equivalent to a consumer id? ... meaning that the client application can use this value to subscribe multiple times to the same destination through the same connection? 2) Is there any reason that not providing this header might cause the 4.1broker to throw an exception on an unsubscribe, but not 4.0.2? 3) Is this header documented anywhere? I did not see it here http://www.activemq.org/site/stomp.html or here http://stomp.codehaus.org/Protocol Thanks, Nate
[jira] Commented: (AMQCPP-28) Purify and Valgrind warnings when running integration tests
[ https://issues.apache.org/activemq/browse/AMQCPP-28?page=comments#action_37718 ] Nathan Mittler commented on AMQCPP-28: -- For now, let's stick this under AMQCPP until we are sure that it's not a bug on the client side. If we determine it really is a broker issue later, we can move it over. 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_37702 ] Nathan Mittler commented on AMQCPP-27: -- I've added a couple of tweaks to trunk. If this doesn't work I think Valgrind is giving us a phantom memory leak. There really isn't anything in that particular chunk of code that can leak memory. 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-27) Issues reported by Valgrind when running unit tests
[ https://issues.apache.org/activemq/browse/AMQCPP-27?page=comments#action_37694 ] Nathan Mittler commented on AMQCPP-27: -- Patch applied to trunk - Thanks! I will look at the Valgrind output a bit later. 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-26) Memory leaks reported by Rational Purify when running unit tests
[ https://issues.apache.org/activemq/browse/AMQCPP-26?page=comments#action_37695 ] Nathan Mittler commented on AMQCPP-26: -- I've made some changes in trunk that I'd like you to try when you get a chance. Thanks for the help! 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-27) Issues reported by Valgrind when running unit tests
[ https://issues.apache.org/activemq/browse/AMQCPP-27?page=comments#action_37697 ] Nathan Mittler commented on AMQCPP-27: -- I think I may have located the last leak listed in the file ... but it will only occur on win32 - I'm assuming this is your platform? I don't have access to a windows box - could you give the latest trunk a try? I haven't built it on win32 but it was just a 1-line change ... so cross your fingers :) Thanks again for your help - it is much appreciated! 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-27) Issues reported by Valgrind when running unit tests
[ https://issues.apache.org/activemq/browse/AMQCPP-27?page=comments#action_37698 ] Nathan Mittler commented on AMQCPP-27: -- I've fixed a couple other leaks that I've found related to the leak in activemq::connector::stomp::StompConnectorTest::testCommand(). 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-28) Purify and Valgrind warnings when running integration tests
[ https://issues.apache.org/activemq/browse/AMQCPP-28?page=comments#action_37700 ] Nathan Mittler commented on AMQCPP-28: -- please reuse the issues when they're all related to the same problem (e.g. memory leaks). At this point, let's keep it at two: this one for leaks related to integ tests, and AMQCPP-27 for leaks related to unit 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] Commented: (AMQCPP-28) Purify and Valgrind warnings when running integration tests
[ https://issues.apache.org/activemq/browse/AMQCPP-28?page=comments#action_37701 ] Nathan Mittler commented on AMQCPP-28: -- Updates have been applied to trunk. 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] Commented: (AMQCPP-16) CMS API needs updates to more closely follow JMS API
[ https://issues.apache.org/activemq/browse/AMQCPP-16?page=comments#action_37685 ] Nathan Mittler commented on AMQCPP-16: -- 1) has been implemented in trunk. This required changes to DataInput/OutputStreams and ByteArrayInput/OuptutStreams to facilitate the new BytesMessage API. I also update the InputStream and OutputStream APIs to remove const where not necessary. Tim, give this a try in windows (regarding the const changes) ... gcc is very giving on this particular issue :) Also, could you comment on any of the others that you have implemented in trunk? Thanks. CMS API needs updates to more closely follow JMS API Key: AMQCPP-16 URL: https://issues.apache.org/activemq/browse/AMQCPP-16 Project: ActiveMQ C++ Client Issue Type: Improvement Components: CMS Impl Affects Versions: 1.1, 2.0 Reporter: Timothy Bish Assigned To: Timothy Bish Priority: Minor Fix For: 1.1 The CMS API interfaces need updates so that they more closely follow the JMS API: 1. Change longs to long long types. 2. The ReplyTo accessors should handle cms::Destination pointers, not strings -- 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-20) Deadlock when in stomp connector close
Deadlock when in stomp connector close -- Key: AMQCPP-20 URL: https://issues.apache.org/activemq/browse/AMQCPP-20 Project: ActiveMQ C++ Client Issue Type: Bug Affects Versions: 1.0 Reporter: Nathan Mittler Assigned To: Nathan Mittler Fix For: 1.1 When a broken socket occurs, the stomp connector attempts to asynchronously close itself. This can cause a deadlock if the main thread is in the close method and is performing a join on the transport thread. -- 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] Closed: (AMQCPP-20) Deadlock when in stomp connector close
[ https://issues.apache.org/activemq/browse/AMQCPP-20?page=all ] Nathan Mittler closed AMQCPP-20. Resolution: Fixed Fixed in trunk Removed the call to close from the asynchronous thread. The user will eventually close it anyway ... that's the more natural point to do a close. Deadlock when in stomp connector close -- Key: AMQCPP-20 URL: https://issues.apache.org/activemq/browse/AMQCPP-20 Project: ActiveMQ C++ Client Issue Type: Bug Affects Versions: 1.0 Reporter: Nathan Mittler Assigned To: Nathan Mittler Fix For: 1.1 When a broken socket occurs, the stomp connector attempts to asynchronously close itself. This can cause a deadlock if the main thread is in the close method and is performing a join on the transport thread. -- 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-20) Deadlock when in stomp connector close
[ https://issues.apache.org/activemq/browse/AMQCPP-20?page=all ] Nathan Mittler reopened AMQCPP-20: -- Need to add better handling of close, so that we don't log an error or notify the client if the broken socket was due to the sending of the stomp disconnect message (server-initiated socket disconnect). Deadlock when in stomp connector close -- Key: AMQCPP-20 URL: https://issues.apache.org/activemq/browse/AMQCPP-20 Project: ActiveMQ C++ Client Issue Type: Bug Affects Versions: 1.0 Reporter: Nathan Mittler Assigned To: Nathan Mittler Fix For: 1.1 When a broken socket occurs, the stomp connector attempts to asynchronously close itself. This can cause a deadlock if the main thread is in the close method and is performing a join on the transport thread. -- 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] Closed: (AMQCPP-20) Deadlock when in stomp connector close
[ https://issues.apache.org/activemq/browse/AMQCPP-20?page=all ] Nathan Mittler closed AMQCPP-20. Resolution: Fixed fixed in trunk Deadlock when in stomp connector close -- Key: AMQCPP-20 URL: https://issues.apache.org/activemq/browse/AMQCPP-20 Project: ActiveMQ C++ Client Issue Type: Bug Affects Versions: 1.0 Reporter: Nathan Mittler Assigned To: Nathan Mittler Fix For: 1.1 When a broken socket occurs, the stomp connector attempts to asynchronously close itself. This can cause a deadlock if the main thread is in the close method and is performing a join on the transport thread. -- 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-18) ActiveMQConnection.close() causes app to crash
ActiveMQConnection.close() causes app to crash -- Key: AMQCPP-18 URL: https://issues.apache.org/activemq/browse/AMQCPP-18 Project: ActiveMQ C++ Client Issue Type: Bug Affects Versions: 1.0 Environment: All platforms Reporter: Nathan Mittler Assigned To: Nathan Mittler Fix For: 1.1 We currently have a flawed exception handling model in StompCommandReader. It propagates different exceptions than the ones that are advertised, which causes the exception to slip through and crash the application. -- 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
