[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] 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-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-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] 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] 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] 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
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
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] 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] 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] 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] 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] 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] Commented: (AMQCPP-14) CMSExpiration not handled properly in ActiveMQProducer
[ https://issues.apache.org/activemq/browse/AMQCPP-14?page=comments#action_37573 ] Nathan Mittler commented on AMQCPP-14: -- Another issue was found in that the MessageConsumer's receive() method does not seem to take message expiration into account before returning it. After a quick inspection, it appears the .NET client may have the same issue. An example of what should be done is shown in ActiveMQMessageConsumer's dequeue method: https://svn.apache.org/repos/asf/incubator/activemq/trunk/activemq-core/src/main/java/org/apache/activemq/ActiveMQMessageConsumer.java CMSExpiration not handled properly in ActiveMQProducer -- Key: AMQCPP-14 URL: https://issues.apache.org/activemq/browse/AMQCPP-14 Project: ActiveMQ C++ Client Issue Type: Bug Components: CMS Impl Affects Versions: 1.0 Environment: All Reporter: Nathan Mittler Assigned To: Nathan Mittler Priority: Minor Fix For: 1.1 Original Estimate: 1 day Remaining Estimate: 1 day ActiveMQProducer.send method is overwriting the CMSExpiration in the message with its default timeToLive value. This is incorrect - it should set the expiry to (expiry + timeToLive). An example of this is in ActiveMQ's ActiveMQSession: https://svn.apache.org/repos/asf/incubator/activemq/trunk/activemq-core/src/main/java/org/apache/activemq/ActiveMQSession.java A work-around is to specify the timeToLive value in the producer. -- 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
ActiveMQ-CPP 1.0 released
Hey everyone, We have an official release of ActiveMQ-CPP 1.0! You can go to the release page here: http://www.activemq.org/site/activemq-cpp-10-release.html . And the main ActiveMQ-CPP page has been updated as well: http://www.activemq.org/site/activemq-c-clients.html Thanks to everyone that helped get this out the door! We have already begun work on our next major release which will have support for openwire, so stay tuned! :) Regards, Nate
[jira] Closed: (AMQCPP-15) Add other versions of send method to CMS MessageProducer
[ https://issues.apache.org/activemq/browse/AMQCPP-15?page=all ] Nathan Mittler closed AMQCPP-15. Resolution: Duplicate This issue is being handled by AMQ-CPP-16 Add other versions of send method to CMS MessageProducer Key: AMQCPP-15 URL: https://issues.apache.org/activemq/browse/AMQCPP-15 Project: ActiveMQ C++ Client Issue Type: New Feature Components: CMS Impl Affects Versions: 1.0 Environment: All Reporter: Nathan Mittler Assigned To: Nathan Mittler Priority: Minor Fix For: 1.1 Original Estimate: 1 day Remaining Estimate: 1 day There are two versions of the send method in JMS that are not currently part of the CMS API. send(Destination destination, Message message, int deliveryMode, int priority, long timeToLive) send(Message message, int deliveryMode, int priority, long timeToLive) -- 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
activemq-cpp integration tests fixed
Tim fixed the bug in the integration tests - they seem to be working on both linux and windows now. Also, I've refactored the socket code quite a bit. We're now using blocking sockets - something we should have been doing from the beginning :). This makes all the frame reading code a lot simpler! When one of you OSX guys gets some free time, we'd appreciate it if you could give the latest trunk a go and see if you run into any problems building or running the tests. Thanks! Nate
Re: Lets vote: activemq-cpp-1.0 release
Hey Hiram, So how does the PMC vote on releases? Do we need to have a RC available for download - or will they just sort of take the ppmc's word for it and vote it in? Also, is there anything else we need to do in advance? Updates to the website, etc? I'm such a n00b! :) Thanks, Nate On 11/13/06, Hiram Chirino [EMAIL PROTECTED] wrote: Hi Nathan, Actually.. you can't yet. Once the ppmc has approved a release, the release must be approved by at least 3 incubator PMC members. You should tally the vote and then start a new vote thread on the general @ incubator mailing list. On 11/13/06, Mittler, Nathan [EMAIL PROTECTED] wrote: Great! That'll do it - thanks, guys! We'll update the website with the release. Nate -Original Message- From: Jonas Lim [mailto:[EMAIL PROTECTED] Sent: Sunday, November 12, 2006 8:36 PM To: activemq-dev@geronimo.apache.org Subject: Re: Lets vote: activemq-cpp-1.0 release +1 Regards, Jonas Timothy Bish wrote: I think it's about time we start this ball rolling, so let's take a vote on whether to call the source archive located here: http://people.apache.org/~tabish the official 1.0 release of activemq-cpp What do you think, is it time to put this one to bed? - Timothy A. Bish -- Regards, Hiram Blog: http://hiramchirino.com
[jira] Commented: (AMQ-1022) when client is not authorized to write to A_QUEUE, producer.send to A_QUEUE does not raise exception
[ https://issues.apache.org/activemq/browse/AMQ-1022?page=comments#action_37423 ] Nathan Mittler commented on AMQ-1022: - Please give this test build a try and let me know how it goes ... http://people.apache.org/~nmittler/apache-activemq-4.2-incubator-SNAPSHOT.tar.gz when client is not authorized to write to A_QUEUE, producer.send to A_QUEUE does not raise exception Key: AMQ-1022 URL: https://issues.apache.org/activemq/browse/AMQ-1022 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 4.0.1 Environment: Windows, amq 4.0.1, using security features described on http://incubator.apache.org/activemq/security.html Reporter: Massive Boisson Using amq 4.0.1, transacted session, jms.useAsyncSend=false, security features described on http://incubator.apache.org/activemq/security.html and client NOT authorized to write to A_QUEUE, producer.send to that A_QUEUE does NOT raise an exception. Instead an asynchronous exception is raised to ExceptionListener. This way the data from the message is essentially lost, because it is not possible to connect exception to the message that should have cause the exception. -- 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: code review for transport patch
One more thing ... looks like all the unit tests in the broker still pass with these changes On 11/11/06, Nathan Mittler [EMAIL PROTECTED] wrote: Hey guys, I took a crack at a fix which sends a stomp error frame back to the client in the event of a failure during authentication or authorization. I haven't been through much of this code before, so I'd like to get some feedback on my changes. Part of my concern is that some of the tweaks will affect all protocols (not only stomp) so I want to make sure I get it right. In particular, a connection error is returned back to the client if an exception is caught by the TransportConnection.onCommand. In the case of stomp, this ends up as a stomp error frame. Here's the patch against the latest trunk: http://people.apache.org/~nmittler/patch.txthttp://people.apache.org/%7Enmittler/patch.txt I also have a tarball if anyone wants to check it out: http://people.apache.org/~nmittler/http://people.apache.org/%7Enmittler/apache-activemq-4.2-incubator-SNAPSHOT.tar.gz http://people.apache.org/%7Enmittler/apache-activemq-4.2-incubator-SNAPSHOT.tar.gz Thanks, Nate
Re: Lets vote: activemq-cpp-1.0 release
So far, we've got two +1's ... if we want to stick with the standard 3-vote model, we need at least one more person to chime in ... unless we let Tim vote for himself :) On 11/9/06, Hiram Chirino [EMAIL PROTECTED] wrote: +1 On 11/9/06, Nathan Mittler [EMAIL PROTECTED] wrote: Agreed - this is long overdue! I've just tried it out on linux and all is well. +1 On 11/9/06, Timothy Bish [EMAIL PROTECTED] wrote: I think it's about time we start this ball rolling, so let's take a vote on whether to call the source archive located here: http://people.apache.org/~tabish the official 1.0 release of activemq-cpp What do you think, is it time to put this one to bed? - Timothy A. Bish -- Regards, Hiram Blog: http://hiramchirino.com
[jira] Commented: (AMQ-1012) Receiving a BytesMessage sent from Java using CMS listener causes exception thrown in class BufferedInputStream
[
https://issues.apache.org/activemq/browse/AMQ-1012?page=comments#action_37349 ]
Nathan Mittler commented on AMQ-1012:
-
I just tried again against the Oct 24th build of 4.0.2 and everything seems to
be working. Could you re-download 4.0.2 and try again?
BTW, the current activemq-cpp client will dump the following on a connection
close:
BufferedInputStream::read() - failed reading bytes from stream - tid: 3075726256
FILE: activemq/io/BufferedInputStream.cpp, LINE: 139 - tid: 3075726256
terminate called after throwing an instance of 'activemq::io::IOException'
This is not really a bug - it's an exception that is caught in the context of
the consumer thread as a result of us closing the connection while it's
listening on the socket. We have plans for cleaning this up, but for now you
can ignore this.
Receiving a BytesMessage sent from Java using CMS listener causes exception
thrown in class BufferedInputStream
Key: AMQ-1012
URL: https://issues.apache.org/activemq/browse/AMQ-1012
Project: ActiveMQ
Issue Type: Bug
Components: CMS (C++ client)
Affects Versions: 4.0.2
Environment: Ubuntu Linux 6.06 LTS, ActiveMQ 4.0.2, CMS version 0.0.2
with STOMP
Reporter: Mark Silberbauer
Fix For: 4.0.3
Original Estimate: 1 day
Remaining Estimate: 1 day
1) Setup a MessageListener to listen for messages on Topic X using CMS.
2) Send a BytesMessage from ActiveMQ java JMS interface to Topic X
3) An exception is thrown from BufferedInputStream::bufferData() with
description failed reading bytes from stream
int bytesRead = stream-read( buffer+tail, bufferSize-tail );
if( bytesRead == 0 ){
throw IOException( __FILE__, __LINE__,
BufferedInputStream::read() - failed reading bytes from stream);
}
4) The operation of the CMS interface is broken thereafter.
Note:
This only occurs when sending a BytesMessage from Java to C++
Sending a BytesMessage from C++ to Java or C++ to C++ works perfectly.
Sending messages of Type TextMessage also works perfectly.
--
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: Assembly module in 4.0.2
Ok, thanks. Just wanted to make sure that it wasn't something unexpected that snuck into the build. On 11/4/06, Hiram Chirino [EMAIL PROTECTED] wrote: Hi Nathan.. The primary build system for the 4.0.x branch is still maven 1. We include m2 poms so we can build the jars and deploy them to m2 repo, but the main distribution is built with maven 1. On 11/4/06, Nathan Mittler [EMAIL PROTECTED] wrote: The assembly module is commented out in the pom.xml under the 4.0.2 tag, so no distribution is created. I ucommented it and everything seems to work fine in m2. Was this intended, or did it get into svn by mistake? Thanks, Nate -- Regards, Hiram Blog: http://hiramchirino.com
who's going to ApacheCon Austin?
Hey everyone, Just wondering who was going from the ActiveMQ crowd. Tim Bish and I received the approval to take a company-sponsored boondoggle for our first ApacheCon :) ... should be a good opportunity to put names with faces. Nate
Re: auto-generating documentation for C++ client?
On 8/3/06, Hiram Chirino [EMAIL PROTECTED] wrote: On 8/3/06, Nathan Mittler [EMAIL PROTECTED] wrote: Hiram, I've updated the docs so that there's two separate directories: https://svn.apache.org/repos/asf/incubator/activemq/site/cms - This has just the cms API and https://svn.apache.org/repos/asf/incubator/activemq/site/activemq-cpp - This has the all the implementation code It's a little funky right now because I wasn't sure how to get the docs for the implementation to link to the docs for cms ... but maybe we play with it a bit and see if we can figure out how to make doxygen do that. that's great! Perhaps we just generate the cms docs again when generating the actimemq ones??? What I meant to say is that since the two packages are generated separately, the html docs for the implementation will reference interfaces in cms (for example cms::TextMessage), but they will essentially be dead links. Maybe there is a way when generating the implementation docs to have it reference the cms docs, but I'm not sure.
Re: auto-generating documentation for C++ client?
Yea - the interesting thing is that I never even get prompted for my password ... the error pops up before I get a chance ... strange On 8/2/06, James Strachan [EMAIL PROTECTED] wrote: Strange - there shouldn't be - anything within the activemq folder should have the same karma. On 8/2/06, Nathan Mittler [EMAIL PROTECTED] wrote: Hey James, Just tried to commit and got the following error: svn: MKACTIVITY of '/repos/asf/!svn/act/010cd0f707b0': 403 Forbidden ( http://svn.apache.org) Is there some special permission that I need for submitting to that folder? On 8/2/06, James Strachan [EMAIL PROTECTED] wrote: On 8/1/06, Nathan Mittler [EMAIL PROTECTED] wrote: Hey guys, I've submitted the patch. James - as it stands, Tim has some docs that are ready to go - should we just post them on a server (people.apache.org?) and link to them from the web page? Awesome! Lets do it. The website is here... http://svn.apache.org/repos/asf/incubator/activemq/site/ so I checked in the NMS docs here... http://svn.apache.org/repos/asf/incubator/activemq/site/nms/ so how about we put the CMS docs here? http://svn.apache.org/repos/asf/incubator/activemq/site/cms/ If you just check in the docs, I've a cron job that refreshes the people.apache.org box from SVN and they should show up there. BTW there seems to be some delay (of up to an hour or so) before updates to SVN actually show up at apache on the web page as there's some kinda proxy/caching stuff going on. -- James --- http://radio.weblogs.com/0112098/ -- James --- http://radio.weblogs.com/0112098/
Re: auto-generating documentation for C++ client?
I've uploaded the docs to http://people.apache.org/~nmittler/ On 8/2/06, James Strachan [EMAIL PROTECTED] wrote: If you want to email me a tarball I could try insert it for you - then see if you could update it? On 8/3/06, Nathan Mittler [EMAIL PROTECTED] wrote: Yea - the interesting thing is that I never even get prompted for my password ... the error pops up before I get a chance ... strange On 8/2/06, James Strachan [EMAIL PROTECTED] wrote: Strange - there shouldn't be - anything within the activemq folder should have the same karma. On 8/2/06, Nathan Mittler [EMAIL PROTECTED] wrote: Hey James, Just tried to commit and got the following error: svn: MKACTIVITY of '/repos/asf/!svn/act/010cd0f707b0': 403 Forbidden ( http://svn.apache.org) Is there some special permission that I need for submitting to that folder? On 8/2/06, James Strachan [EMAIL PROTECTED] wrote: On 8/1/06, Nathan Mittler [EMAIL PROTECTED] wrote: Hey guys, I've submitted the patch. James - as it stands, Tim has some docs that are ready to go - should we just post them on a server (people.apache.org?) and link to them from the web page? Awesome! Lets do it. The website is here... http://svn.apache.org/repos/asf/incubator/activemq/site/ so I checked in the NMS docs here... http://svn.apache.org/repos/asf/incubator/activemq/site/nms/ so how about we put the CMS docs here? http://svn.apache.org/repos/asf/incubator/activemq/site/cms/ If you just check in the docs, I've a cron job that refreshes the people.apache.org box from SVN and they should show up there. BTW there seems to be some delay (of up to an hour or so) before updates to SVN actually show up at apache on the web page as there's some kinda proxy/caching stuff going on. -- James --- http://radio.weblogs.com/0112098/ -- James --- http://radio.weblogs.com/0112098/ -- James --- http://radio.weblogs.com/0112098/
Re: auto-generating documentation for C++ client?
Hey guys, I've submitted the patch. James - as it stands, Tim has some docs that are ready to go - should we just post them on a server (people.apache.org?) and link to them from the web page? On 8/1/06, Bish, Tim [EMAIL PROTECTED] wrote: Great! :) How about submitting a patch to get the auto-generation working then we can look at automatically generating the documentation on a CI box or something? Alright, I submitted a new issue with the activemq-cpp updates, and a drop of the generated docs in it. Once that's committed we can take a look at auto generation. -- Timothy Bish Sensis Corporation --
auto-generation of openwire commands
Hey James, Tim and I are starting to look at porting the openwire-cpp client into activemq-cpp and I'm trying to get a handle on how the autogeneration works. So far, I've downloaded and built the activemq-openwire-generator project as this looks to be the guy that performs the autogeneration, and I've got a few questions ... 1) Is there documentation available that explains how the autogeneration works? Didn't see much after a bit of googling. 2) It looks like the groovy scripts and the code in the activemq-openwire-generator library don't know the specifics of the commands such as properties, etc. If this is the case, it would seem that there must be a set of generic input files that provides the tool with the commands and their properties. Is this the case? And if so, where are these files defined? 3) How is the auto generation tool run? My guess is that it's through Maven. I found this e-mail exchange ( http://mail-archives.apache.org/mod_mbox/geronimo-activemq-dev/200602.mbox/[EMAIL PROTECTED]) where you suggest using maven openwire:generate. Just took a shot and tried mvn openwire:generate, but there doesn't seem to be a plugin available. Do I need to drop back to Maven 1.x to make this work? That's all for now ... I'm sure I'll have more questions later :) Thanks, Nate
[jira] Resolved: (AMQ-823) Incorect handling of message size in ByteArrayOutputStream::write
[ https://issues.apache.org/activemq/browse/AMQ-823?page=all ] Nathan Mittler resolved AMQ-823. Resolution: Fixed Patch has been applied ... Thanks! Incorect handling of message size in ByteArrayOutputStream::write - Key: AMQ-823 URL: https://issues.apache.org/activemq/browse/AMQ-823 Project: ActiveMQ Issue Type: Bug Components: CMS (C++ client) Affects Versions: incubation Environment: RHEL 4/32bit Reporter: Radek Sedmak Assigned To: Nathan Mittler Attachments: patch.txt Original Estimate: 10 minutes Remaining Estimate: 10 minutes when you are sending message via openwire protocol, ByteArrayOutputStream::write is called in certain moment ... when message size is greater then defaul CHUNK space is reallocated and there is check for EOF offset. if( offset bodySize ) expandBody() ; but should be there if ( offset = bodySize ) expandBody(); -- 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: (AMQ-707) makefile plus some changes for the CMS C++ client
[ https://issues.apache.org/activemq/browse/AMQ-707?page=comments#action_36641 ] Nathan Mittler commented on AMQ-707: This issue was for the original CMS client, which has since been replaced by activemq-cpp. I don't think this applies to the new client. makefile plus some changes for the CMS C++ client - Key: AMQ-707 URL: https://issues.apache.org/activemq/browse/AMQ-707 Project: ActiveMQ Issue Type: Improvement Components: JMS client Affects Versions: 4.0 RC2 Reporter: Manuel Teira Assigned To: Nathan Mittler Priority: Minor Fix For: 4.1 Attachments: patch.bz2 I've written a trivial makefile to be able to compile the CMS over Stomp C++ client on Solaris , using Sun Workshop 6. I've also made some changes: -Added a strerror_r macro for solaris. -Define MSG_NOSIGNAL as zero for solaris -Added 'using namespace activemq' to some files to make Sun Workshop find some objects. -Corrected a pair of memory leaks found under purify sessions. -Corrected a bug in StompTransportFactory::createTransport, not using the argument brokerUrl -Deleted a trailing comma in a enum in Session.h, making Sun CC to warn. -Added a dummy test to just send a message. -- 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: (AMQ-779) add createDurableSubscriber() methods to Session.h
[ https://issues.apache.org/activemq/browse/AMQ-779?page=all ] Nathan Mittler reassigned AMQ-779: -- Assign To: Nathan Mittler add createDurableSubscriber() methods to Session.h -- Key: AMQ-779 URL: https://issues.apache.org/activemq/browse/AMQ-779 Project: ActiveMQ Type: Improvement Components: CMS Reporter: james strachan Assignee: Nathan Mittler e.g. http://java.sun.com/j2ee/1.4/docs/api/javax/jms/Session.html#createDurableSubscriber(javax.jms.Topic,%20java.lang.String) -- 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: (AMQ-779) add createDurableSubscriber() methods to Session.h
[ https://issues.apache.org/activemq/browse/AMQ-779?page=comments#action_36528 ] Nathan Mittler commented on AMQ-779: It looks like this has been implemented in activemq-cpp, not sure that it has been tested yet. We should add an integration test for this. add createDurableSubscriber() methods to Session.h -- Key: AMQ-779 URL: https://issues.apache.org/activemq/browse/AMQ-779 Project: ActiveMQ Type: Improvement Components: CMS Reporter: james strachan Assignee: Nathan Mittler e.g. http://java.sun.com/j2ee/1.4/docs/api/javax/jms/Session.html#createDurableSubscriber(javax.jms.Topic,%20java.lang.String) -- 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:
+1
Thanks for the patch!
Nate
On 7/4/06, Hiram Chirino [EMAIL PROTECTED] wrote:
It should be on it's way to your gmail account.
On 7/4/06, Nathan Mittler [EMAIL PROTECTED] wrote:
Hey Hiram,
Looks ok at first glance - could you send me the patch file as an
attachment? I seem to be having problems applying the patch through
copy
paste into subclipse.
Thanks,
Nate
On 7/3/06, Hiram Chirino [EMAIL PROTECTED] wrote:
Hi Nathan,
Please review the following patch. It allows the stomp client to
accept
a
variable amount of while space between frames. I ran the integration
tests
a slightly modified amq broker where it used 3 \n between frames and
also
one where no \n were used between frames. Everything seemed to work,
but
since c++ is not my forte, I'm looking for a +1 from a before I commit
the
change.
Index: src/main/activemq/connector/stomp/StompCommandReader.cpp
===
---
src/main/activemq/connector/stomp/StompCommandReader.cpp(revision
418889)
+++
src/main/activemq/connector/stomp/StompCommandReader.cpp(working
copy)
@@ -70,20 +70,46 @@
void StompCommandReader::readStompCommand( StompFrame frame )
throw ( StompConnectorException )
{
-// Read the command;
-int numChars = readStompHeaderLine();
+ while( true )
+ {
+ // Clean up the mess.
+ buffer.clear();
-if( numChars = 0 )
-{
-throw StompConnectorException(
-__FILE__, __LINE__,
-StompCommandReader::readStompCommand:
-Error on Read of Command Header );
-}
+ // Read the command;
+ readStompHeaderLine();
-// Set the command in the frame - copy the memory.
-frame.setCommand( reinterpret_castchar*(buffer[0]) );
-
+// Ignore all white space before the command.
+int offset=-1;
+for( size_t ix = 0; ix buffer.size()-1; ++ix )
+{
+ // Find the first non space character
+ char b = buffer[ix];
+switch ( b )
+{
+ case '\n':
+ case '\t':
+ case '\r':
+ break;
+
+ default:
+ offset = ix;
+ break;
+}
+
+ if( offset != -1 )
+ {
+ break;
+ }
+}
+
+ if( offset = 0 )
+ {
+ // Set the command in the frame - copy the memory.
+ frame.setCommand(
reinterpret_castchar*(buffer[offset]) );
+ break;
+ }
+
+ }
// Clean up the mess.
buffer.clear();
}
@@ -224,8 +250,7 @@
read( buffer[0], content_length );
// Content Length read, now pop the end terminator off
(\0\n).
-if(inputStream-read() != '\0' ||
- inputStream-read() != '\n')
+if(inputStream-read() != '\0' )
{
throw StompConnectorException(
__FILE__, __LINE__,
@@ -251,16 +276,6 @@
continue;
}
-// We read up to the first NULL, now lets pop off the
required
-// newline to complete the packet.
-if(inputStream-read() != '\n')
-{
-throw StompConnectorException(
-__FILE__, __LINE__,
-StompCommandReader::readStompBody:
-Read Body, and no trailing newline);
-}
-
break; // Read null and newline we are done.
}
}
On 7/3/06, Nathan Mittler [EMAIL PROTECTED] wrote:
No problem - sorry for the confusion :)
On 7/3/06, Hiram Chirino [EMAIL PROTECTED] wrote:
Oh. That makes sense! Sorry for the noise!
On 7/3/06, Mittler, Nathan [EMAIL PROTECTED] wrote:
Hey Hiram,
I was actually thinking of the messages coming from the broker
to
the
client - the newer version of the broker always sends a \0\n to
denote
the end of the frame. I'm not sure if the CMS client is sly
enough
to
handle both cases - I think it's expecting one or the other
(either
\0
or \0\n). I was just throwing that out there as a possible
reason
that
the client may freeze on a read - waiting for the trailing \n
that
never
comes.
-Original Message-
From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] On Behalf
Of Hiram Chirino
Sent: Monday, July 03, 2006 12:58 PM
To: activemq-dev@geronimo.apache.org
Subject: Re:
Hi Nathan,
I'm not so sure about that. I think that AMQ should support
receiving a STOMP frame terminated
Re: New refactored STOMP implementation.
Hiram, BTW, did you run the activemq-cpp cpp-unit tests against the broker with the new stomp transport? I took a look at your code and it looks like you still have the request-id/response-id headers in there, so it should work fine. Looks a lot simpler - easier to find your way around. Nate On 7/4/06, James Strachan [EMAIL PROTECTED] wrote: It all looks good to me. Given we've already hit AMQ-793 recently... http://issues.apache.org/activemq/browse/AMQ-793 due to the flow control issues in the stomp implementation under load, I'd say lets get rid of the old version and go with the new. On 7/2/06, Hiram Chirino [EMAIL PROTECTED] wrote: Howdy STOMP developers, Just wantted to let you know that I spent the day doing some major refactoring to the STOMP server side protocol implementation in ActiveMQ. The previous implementation did all the work inside a WireFormat layer. The poll model that it imposed made some things difficult to do and made the code just ugly. I refactored it so that StompWireFormat takes the STOMP frames and produces StompCommand objects which are like a 1:1 mapping (Perhaps I should rename that to StompFrame). Then the stomp transport factory sets up the TcpTransport to be filtered by a StompTransportFilter which converts the StompCommand/Protocol into the ActiveMQ commands and Protocol. Since the Transport is more event based and is also aware of the transport lifecycle, it should let us continue to extend and add more features to the STOMP protocol easier. I implemented this in a new package so that we can easily switch back to the old implementation if needed. Out of the box we are now using the new implementation. But I'd like to get some feed back to see if it introduced any new bugs or if it fixed any old bugs. If all goes well, I'll get rid of the old version soon. -- Regards, Hiram Blog: http://hiramchirino.com -- James --- http://radio.weblogs.com/0112098/
[jira] Commented: (AMQ-517) Create a C++ client for ActiveMQ that can work with STOMP and OpenWire
[ https://issues.apache.org/activemq/browse/AMQ-517?page=comments#action_36505 ] Nathan Mittler commented on AMQ-517: We're getting there - I've submitted the activemq-cpp to trunk. Currently it still only supports stomp, so it is a complete replacement for CMS. But, it's architecture is very close to the .NET openwire client and supports pluggable connectors in preparation for merging the openwire-cpp code in. This will be our next major task. 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 Type: Improvement Components: JMS client Reporter: Nathan Mittler Assignee: 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] Commented: (AMQ-739) STOMP transport handles JMS type improperly
[ https://issues.apache.org/activemq/browse/AMQ-739?page=comments#action_36437 ] Nathan Mittler commented on AMQ-739: clients can use bytes and text messages so long as they follow AMQ's scheme for making the distinction: if content-length is specified, it's a bytes message, otherwise it's text. So I don't think any action needs to be taken on this issue other than updating AMQ's stomp page to make it clear how to make the distinction between bytes and text using the stomp protocol. STOMP transport handles JMS type improperly --- Key: AMQ-739 URL: https://issues.apache.org/activemq/browse/AMQ-739 Project: ActiveMQ Type: Bug Components: Transport Versions: 4.0.1, 4.0 Environment: sending from STOMP to JMS Reporter: Nathan Mittler Assignee: Nathan Mittler Priority: Minor Fix For: 4.1 Original Estimate: 1 week Remaining: 1 week Sending a text message from a stomp client with a content-length results in a bytes message on JMS. Suggest doing the following ... 1) The stomp transport should always add the content-length header to out-going messages, regardless of content-type or whether or not a content-length was provided on the incoming message. 2) The stomp transport should handle in-coming messages with a content-type header, and should pass that through. 3) If a message comes in without a content-length or a content-type, it should just be assumed a TextMessage. This way we can use the terminating null character as the delimiter. -- 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: STOMP and JMSType
I think that clears things up for me a bit - what you're proposing makes sense. I'll poke around today and see what I can come up with. Thanks, Nate On 6/12/06, Brian McCallister [EMAIL PROTECTED] wrote: On Jun 12, 2006, at 4:14 PM, Nathan Mittler wrote: Agreed ... using the type header is not an option. --- From the bug report --- It isn't possible to reuse the type header (JMSType) for the purpose of sending through the information as to what type of message it is (text or bytes). So this means that we need to add another activemq extension header. I propose amq-msg-type. --- / From the bug report -- I like this a lot better, and think it would be a reasonable default rule for mapping in 4.X. I am not convinced we need this, but I much prefer it to a hardcoded transform, as this would allow for much more useful transforms (ie, aplication-aware). Although I agree conceptually, I'm thinking this might be a bit of an overkill for the task at hand. Agreed. I just hate to layer on another backwards compatibility issue beyond what we already have. By designing it to be forward compatible with an arbitrary mapping we can grow into a future solution more easily. Once we add this header we will need to support it ~forever. Right now the STOMP transport only works with bytes and text messages, and creating this transform model won't change that. I think if we one day decide to refactor the transport to accept other message types - that would be the time to make this sort of change. What if I want to switch on Content-type to decide between text or bytes? It is a common header to use, but is not part of the spec (as stomp doesn;t care, but is happy to pass it along). This makes more sense to me in terms of mapping between Stomp and JMS, but it is not compatible with switching on a specific content header. The mapping between Stomp and JMS is actually rather important to get right as it is the low level interop mapping between various platforms and Java. As such, I want to make sure we are building towards a correct solution. Aside from all this, controlling the protocol -- (semi-)protocol mapping should be a configuration thing, not a flag the client must put on every message it sends. The end goal for me is to have all messages coming in from the Stomp adaptor be bytes messages, unless someone has an overriding need for something else (quote possible). The current behavior is pretty bad as a default, but we just released 4.0 with it, so we are stuck until we make another backwards incompatible release (5.0). In 4.1 we can add the amq-msg-type header to allow people to force things to bytes (or text) but for the 5.0 end game we will need to make the mapping pluggable in order to make the upgrade path as easy as possible. if we are going to need pluggable eventually, why not do it now in order to allow people to fix the bytes/text mistake (I can say it is a mistake, I wrote it =) at the server level instead of having to add a header to every message. We have, then, three configurations which people are likely to want: 1) Current (3.2 and 4.0 compatible) one which is made more palatable by letting the client specify via the amq-msg-type. 2) Map everything to bytes, which I would like to make the default in 5.0. 3) Map everything to Text (which is what I would actually use if we had it as I convert all the bytes ones I send now into strings anyway). If we are going to have it be sufficiently pluggable to support these three, we should consider letting users provide their own. -Brian
Re: STOMP and JMSType
So it sounds like we're all in agreement on the content-type header. For text, it would be something like text and for bytes it would be application/octet-stream. So this would not be an application-level header, but would be used by my stomp client code to determine which message type to create. If we're all in agreement with that, then it seems to make sense that the default functionality of the broker be modified to handle content-type in this way. And if that's true, then it seems like this particular issue is resolved. This way, we get it into the 4.1 release with no problems. We can create another issue to do the refactoring as you've suggested ... which will probably take a little more time and several conversations to get right. How does this sound? Nate On 6/13/06, Brian McCallister [EMAIL PROTECTED] wrote: On Jun 13, 2006, at 1:50 PM, Nathan Mittler wrote: Could you guys point me to a place in AMQ where this sort of thing is being done? That would save me a lot of searching =) I'm viewing this problem from the client side - the Stomp C++ client that Tim Bish and I are writing currently supports text and bytes messages. Within a general Stomp client, I would suggest that switching on JMS message types is not a productive goal. Using Content-type here makes a lot more sense, I think. . It would make a lot of sense to set it for text messages going out to Stomp if there is not one already supplied. Stomp is a protocol, like HTTP or SMTP -- hardwiring a client to a specific server implementation is probably not a general solution (though is fine if it is specifically an activemq client which happens to use stomp for transport). So when I get a stomp frame in, I need to map it back to a text or bytes message. We chose to do this for a couple of reasons: 1) to give JMS users a familiar interface and 2) to provide a simple interface for reading and writing text messages (e.g. xml). Content-type: text/xml -- Content-type: application/octet-stream With that said, I'm not seeing how I can do that mapping if the transformer is provided only in the SUBSCRIBE. A client could potentially get a variety of message types from a single subscription. I think it would have to be part of the MESSAGE frame, rather than the SUBSCRIBE. SUBSCRIBE activemq-transformer: com.example.ContentTypeMapper Here are the use cases I see: s/transformer/activemq-transformer/g I like the namespace. Client-Server 1) SEND\n...\ntransformer:text (client tells server it's a text message) +1 2) SEND\n...\ntransformer:bytes (client tells server it's a bytes message) +1 3) SEND\n...\ntransformer:default (client tells server to use content-length to make determination) -1 Give it a descriptive name so that we can change the default without breaking these. 4) SEND\n...\n (no transformer specified - same as #3) +1 5) SEND\n..\ntransformer:bob (client gives server unknown transformer - use default) Return an error -- do not quietly swallow this. Server-Client 1) MESSAGE\n...\ntransformer:text (server tells client it's a text message) +1 2) MESSAGE\n...\ntransformer:bytes (server tells client it's a bytes message) +1 3) MESSAGE\n...\ntransformer:default (server tells client to use content-length to make determination) -1 same as #3 above 4) MESSAGE\n...\n (no transformer specified - same as #3) +1 5) MESSAGE\n...\ntransformer:bob (server tells client to use unknown transformer - use default) -1 same as #5 above This does highlight that we have two real transform cases, send and receive if we support CONNECT or SUBSCRIBE level transformers. We can infer the correct direct on MESSAGE and SEND, but not the others. As this would make the interface have all of two methods, I am quite happy combining it. Alternately we can have different headers on SUBSCRIBE and CONNECT -Brian
[jira] Created: (AMQ-748) Add request-id and response-id headers to STOMP connect/connected handshake
Add request-id and response-id headers to STOMP connect/connected handshake --- Key: AMQ-748 URL: https://issues.apache.org/activemq/browse/AMQ-748 Project: ActiveMQ Type: New Feature Components: Transport Reporter: Nathan Mittler Assigned to: Nathan Mittler Priority: Minor For the new activemq-cpp library, we need to extend the STOMP connect/connected handshake so that we get back a response-id for our response correlator. To do this, we need to send something in the connect request that contains a client-defined request-id. My first thought was to just reuse the message-id header, but that is typically reserved for cases when a client is expecting to acknowledge a message. So rather than risk breaking that paradigm, I propose a new header request-id that is just used on the connect message. When the broker receives a connect request with a request-id header, it creates a connected response with a response-id set to the request-id of the original request. This way the client can treat the handshake as a true request/response. -- 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: (AMQ-739) STOMP transport handles JMS type improperly
[ https://issues.apache.org/activemq/browse/AMQ-739?page=comments#action_36315 ] Nathan Mittler commented on AMQ-739: It isn't possible to reuse the type header (JMSType) for the purpose of sending through the information as to what type of message it is (text or bytes). So this means that we need to add another activemq extension header. I propose amq-msg-type. STOMP transport handles JMS type improperly --- Key: AMQ-739 URL: https://issues.apache.org/activemq/browse/AMQ-739 Project: ActiveMQ Type: Bug Components: Transport Environment: sending from STOMP to JMS Reporter: Nathan Mittler Assignee: Nathan Mittler Priority: Minor Fix For: 4.1 Original Estimate: 1 week Remaining: 1 week Sending a text message from a stomp client with a content-length results in a bytes message on JMS. Suggest doing the following ... 1) The stomp transport should always add the content-length header to out-going messages, regardless of content-type or whether or not a content-length was provided on the incoming message. 2) The stomp transport should handle in-coming messages with a content-type header, and should pass that through. 3) If a message comes in without a content-length or a content-type, it should just be assumed a TextMessage. This way we can use the terminating null character as the delimiter. -- 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: STOMP bytes messages
I just re-read your e-mail and I'm not sure if the issue is the lack of or the inclusion of an eclipse workspace (oh, the joys of e-mail!). I extracted the tar and made sure there were eclipse project settings in there (keep in mind, these files are purely for local builds and will not be included in any commit to svn). So, I'm not sure if I have any actions :) Nate On 4/14/06, Mittler, Nathan [EMAIL PROTECTED] wrote: Oops ... sorry about that :). I'm at work right now and don't have access to the code - I'll get it to you this evening. Do you have an eclipse environment with the CDT for building C++ projects? ... otherwise I can throw some makefiles together if that's easier for you. Unfortunately, the current version of the code only works with a pthread environment - hopefully you're not on windoze :). Nate -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hiram Chirino Sent: Friday, April 14, 2006 11:53 AM To: activemq-dev@geronimo.apache.org Subject: Re: STOMP bytes messages Howdy.. now eclipse project files were included in the tar :( On 4/14/06, Hiram Chirino [EMAIL PROTECTED] wrote: yep got.. just got a little swamped. Will look into it asap. On 4/14/06, Nathan Mittler [EMAIL PROTECTED] wrote: Hey Hiram, Just wanted to see if you received the code I sent you (the first try was rejected by the server because of the file size). Let me know if you have any trouble compiling/etc. Nate -- Regards, Hiram -- Regards, Hiram
[jira] Closed: (AMQ-620) Get openwire-cpp buiding on linux/gcc
[ https://issues.apache.org/activemq/browse/AMQ-620?page=all ] Nathan Mittler closed AMQ-620: -- Resolution: Duplicate This issue is being addressed by AMQ 656 Get openwire-cpp buiding on linux/gcc - Key: AMQ-620 URL: https://issues.apache.org/activemq/browse/AMQ-620 Project: ActiveMQ Type: Task Components: JMS client Environment: Linux with gcc 4.x Reporter: Nathan Mittler Priority: Minor Attachments: openwire-cpp-mods.tar.gz Need to get the c++ port of the openwire-c# client building on linux. I'm posting code that should help get there. There are a few outstanding issues ... 1) the use of smart pointers seems to be a problem for the compiler. 2) autogenerated code for command/marshall files is using undefined types -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-685) CMS C++ Client - bug handling bytes messages
CMS C++ Client - bug handling bytes messages Key: AMQ-685 URL: https://issues.apache.org/activemq/browse/AMQ-685 Project: ActiveMQ Type: Bug Components: JMS client Versions: 4.0 RC 2 Environment: any Reporter: Nathan Mittler Priority: Minor The content-length property isn't used properly when reading bytes messages -- 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: Regarding feedback on OpenWire C++ client
On 3/28/06, David Fahlander [EMAIL PROTECTED] wrote:
Hi Nathan,
1) Use of smart pointers.
Though the user interface would be cleaner without smart pointers
they
serves a purpose even when the passed in object is not owned by the
client.
As soon as an object is shared between two classes you have the
problem when the object should be deleted - this problem is
eliminated
when using SP's, the object is deleted when both object releases its
reference to it.
I'm not sure I agree. For user-generated objects, it should be up to
the user to
add and remove references to them across the openwire library (such as
references
to IMessageListeners). When the user passes in a reference to one of
his objects,
he's not expecting to give any amount of lifetime control to the
openwire code.
In fact, the user object may not even have been created on the heap,
it may be a
local variable that was added just for the scope of a function. In
this case,
when the openwire library decides to delete it, the application blows
up! We
have to make a separation of what is and what is not under our
library's control.
We can't assume a structure of the client code, this forces the client
into a
particular way of programming and causes our client to become a burden
to the
developer and will turn them off to using ActiveMQ.
Regarding objects that the user provides, we still get benefits by using
smart pointers for them. It is not always the creator that is
responsible of deletion. Especially in a threaded application it can be
important to not end-up with ghost pointers. A thread in our client
library that holds a pointer to a listener, must be able to rely on that
the instance is still alive as long as it holds the SP to it. If the
user would provide an ordinary pointer, the user must never delete it as
long as there might be threads in our library using it. What about
static objects that should last forever in the client's lifetime then?
Still, we want to be able to take down the client in a controlled way.
Doing that without smart pointers, may create a lot of problems in our
experience.
The burden for the user would only lie in the classes that implement
our interfaces. If our API requires a pIMessageListener, the user must
hold his message listener using a pMyMessageListener allocated with
new MyMessageLister (...);. The user does not have to let this affect
his design. If the user wants, this instance can lie as a member within
another class that is neither derived from our interface nor maintained
as a smart pointer.
You get no benefits at all by adding smart pointers to the interface. The
user will delete their objects whenever they wish, regardless of what the
openwire library does ... and if it does so, the openwire library will
explode as soon as it tries to reference it. That's the thing - this is C++
and there is no mechanism to prevent someone from coding badly, and adding
smart pointers to the API isn't going to change that. The user is
responsible for both adding and removing referenes to its objects. And it's
not the job of the openwire lib to worry about memory management in the
user-domain - it should only be concerned with its own memory management.
In addition, smart pointers are assuming that the object is allocated on the
heap, as it will do a delete when the last reference is removed. This is
wrong, because the user should be able allocate its objects in whatever way
makes sense for the application.
Also, adding smart pointer arguments to all the methods on the api makes it
complicated and ugly. If the openwire library wants to use smart pointers
internally, that's fine, but it shouldn't impose the use of smart pointers
on the user. It's our job to make the user's experience a good one so they
continue to use ActiveMQ in their applications.
SP's and Strings: Semi-agreed :) The setters should all have const
char*
but we could change the getters to std:string (without SP), then it
is
up to the user to either use it as a std:string or a const char*.
I think symmetry is a good thing. We should pick one way or the other
...
either both the getter and setter take const char* or they both take
strings.
Also, when passing strings around, they should be passed as const
std::string ...
this way you don't have to copy the entire string, you just pass a
constant reference
to it. This will save a lot of processing when dealing with large
text messages, for
example.
The options we have regarding passing and holding strings are the
following:
Class Xxx {
pstring name;
public:
void setName (pstring name) {
this-name = name;
}
pstring getName () {
return this-name;
}
pstring createName() {
return new string (name: + *name);
}
};
In the above example, strings are never copied, just the ptr value. The
downside is that the caller needs to pass their strings as
Re: [jira] Updated: (AMQ-656) Update of AMQ C++ client
no problem! Nate On 3/27/06, David Fahlander [EMAIL PROTECTED] wrote: Oops... I've been building it using GCC on a linux but where the path is smbmount:ed and hosted by a windows machine. Sorry about the error. Thanks, /David -Original Message- From: Nathan Mittler [mailto:[EMAIL PROTECTED] Sent: den 26 mars 2006 19:51 To: activemq-dev@geronimo.apache.org Subject: Re: [jira] Updated: (AMQ-656) Update of AMQ C++ client Hi David, One minor tweak (for linux) ... in Guid.cpp, the include should be Guid.hpp, not guid.hpp. Paths in linux are case-sensitive, so it won't build. Regards, Nate On 3/24/06, David Fahlander (JIRA) [EMAIL PROTECTED] wrote: [ http://jira.activemq.org/jira//browse/AMQ-656?page=all ] David Fahlander updated AMQ-656: Attachment: source_060324.zip This is a complete update that replaces the previous attached file. Now compiles without warnings with full warning turned on on the following compilers: gcc 3.4.3 gcc 4.0.2 visual c++ 2005 Fixes also done with marshalling of messageId as int instead of short. Update of AMQ C++ client Key: AMQ-656 URL: http://jira.activemq.org/jira//browse/AMQ-656 Project: ActiveMQ Type: Improvement Components: JMS client Reporter: MF Attachments: source_060323.zip, source_060324.zip Attached is a new update of the C++ client, the zip-file contains the full source since the update is a major overhaul. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.activemq.org/jira//secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Regarding feedback on OpenWire C++ client
Hi Mats, On 3/27/06, Mats Forslöf [EMAIL PROTECTED] wrote: Hi All, Thanks everyone for looking at and testing the latest C++ client update. Sorry if we have not been so clear regarding the stability of the code, the code is highly untested and as said in the upload mail we will commence testing/debugging shortly - so expect bugs!! No problem, bugs are expected ... just reporting that I think I found one :-) As we've just finished the port we will shift focus and look into all the issues you have raised, see comments below. 1) Use of smart pointers. Though the user interface would be cleaner without smart pointers they serves a purpose even when the passed in object is not owned by the client. As soon as an object is shared between two classes you have the problem when the object should be deleted - this problem is eliminated when using SP's, the object is deleted when both object releases its reference to it. I'm not sure I agree. For user-generated objects, it should be up to the user to add and remove references to them across the openwire library (such as references to IMessageListeners). When the user passes in a reference to one of his objects, he's not expecting to give any amount of lifetime control to the openwire code. In fact, the user object may not even have been created on the heap, it may be a local variable that was added just for the scope of a function. In this case, when the openwire library decides to delete it, the application blows up! We have to make a separation of what is and what is not under our library's control. We can't assume a structure of the client code, this forces the client into a particular way of programming and causes our client to become a burden to the developer and will turn them off to using ActiveMQ. SP's and Strings: Semi-agreed :) The setters should all have const char* but we could change the getters to std:string (without SP), then it is up to the user to either use it as a std:string or a const char*. I think symmetry is a good thing. We should pick one way or the other ... either both the getter and setter take const char* or they both take strings. Also, when passing strings around, they should be passed as const std::string ... this way you don't have to copy the entire string, you just pass a constant reference to it. This will save a lot of processing when dealing with large text messages, for example. 2) ITextMessage should extend IMessage This was a last minute change to make it compile. Nate, your solution seems to be a viable way of handling it - thanks! No problem. 3) SP dynamic_cast rather than reinterpret_cast It is correct that reinterpret_cast does not adjust the pointer value as needed when casting between different classes in a class hierarchy. However, the reinterpret_cast is used for casting between void* and objects and is needed for the p template to work. Where such pointer-value-adjustment is needed (up/down-casting), static_cast is used which works the same as dynamic_cast except that it does no runtime type check. Hmmm ... so why are we using void* instead of T*? 4) ExceptionListener An ExceptionListener is missing. We could either add a method on IMessageListener or add a new interface IExceptionListener, prefer the latter. Ok? Agreed. 5) .NET namespace Hiram, what rules does Apache imply on this? Is it ok to use the namespaces your giving examples on? Looking on the Java code all Apache code starts with org.apache. Regards, Mats David Regards, Nate
Re: [jira] Updated: (AMQ-656) Update of AMQ C++ client
Hi David, One minor tweak (for linux) ... in Guid.cpp, the include should be Guid.hpp, not guid.hpp. Paths in linux are case-sensitive, so it won't build. Regards, Nate On 3/24/06, David Fahlander (JIRA) [EMAIL PROTECTED] wrote: [ http://jira.activemq.org/jira//browse/AMQ-656?page=all ] David Fahlander updated AMQ-656: Attachment: source_060324.zip This is a complete update that replaces the previous attached file. Now compiles without warnings with full warning turned on on the following compilers: gcc 3.4.3 gcc 4.0.2 visual c++ 2005 Fixes also done with marshalling of messageId as int instead of short. Update of AMQ C++ client Key: AMQ-656 URL: http://jira.activemq.org/jira//browse/AMQ-656 Project: ActiveMQ Type: Improvement Components: JMS client Reporter: MF Attachments: source_060323.zip, source_060324.zip Attached is a new update of the C++ client, the zip-file contains the full source since the update is a major overhaul. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.activemq.org/jira//secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
openwire C++ client
I've taken a closer look at the openwire C++ client this weekend and noticed
a few things ...
1) I think there are a few cases where we could reduce the usage of smart
pointers.
One instance where I think smart pointer usage is questionable is when
openwire is referencing an object that it doesn't control. For example,
when my code declares a class that is an IMessageListener, it seems strange
that this should be passed in as a smart pointer to openwire functions.
Openwire doesn't control the lifetime of this object, so I don't believe it
should be referencing it in a managed way.
Another case where smart pointers could be avoided is strings. If all
string member variables are std::strings, then the setXXX method could just
take a const char* and the const getXXX method could simply return a
const char* (which would be the value returned from the mystr.c_str()
method). This makes for a much simpler and symmetric API.
2) ITextMessage should extend IMessage
It seems that the ITextMessage class was at one time derived from IMessage,
but it is commented out (probably to get through compilation :-) ). If you
try to call send() on the MessagePublisher class with an ITextMessage, the
code won't compile.
I've gotten around this by making ITextMessage extend IMessage - the trick
is that when you do this, ActiveMQTextMessage gets IMessage from two
branches. In one branch, it gets the methods from IMessage implemented for
it ( by ActiveMQMessage) and in the other branch (ITextMessage), it
doesn't. So you have to have ActiveMQTextMessage implement all the methods
from the IMessage interface and delegate them to the ActiveMQMessage base
class. This seems to do the trick.
3) It seems that the smart pointer code should be using dynamic_cast rather
than reinterpret cast. I seem to remember times where a dynamic_cast
returned a slightly different address (in some cases). If this is the
case, it could be very dangerous to use reinterpret_cast everywhere since it
just takes the same pointer and treats its address as the other type
(corrupting the references to the object). This could lead to strange bugs
that are difficult to track down.
The other problem is in the fact that the internal pointer is a void* rather
than a T*. This complicates debugging, because the debugger sees an
internal pointer, but doesn't look inside since it doesn't know what type it
really is.
4) I'm not seeing an ExceptionListener equivalent. Am I missing something?
5) I got a small sample app compiling, but I'm getting a segfault when
creating a session (could certainly be user error - a code snippet is
below). Here's the stack dump:
Thread [1] (Suspended: Signal 'SIGSEGV' received. Description:
Segmentation fault.)
12 apache::activemq::client::command::ConnectionInfo::marshal() at
src/command/ConnectionInfo.cpp:111 0x0804fd02
11 apache::activemq::client::protocol::OpenWireFormat::marshal() at
src/protocol/OpenWireFormat.cpp:89 0x0808c0a3
10 apache::activemq::client::transport::SocketTransport::send() at
src/transport/SocketTransport.cpp:144 0x08051650
9 apache::activemq::client::transport::SocketTransport::asyncRequest()
at src/transport/SocketTransport.cpp:109 0x08052e11
8 apache::activemq::client::transport::SocketTransport::request() at
src/transport/SocketTransport.cpp:123 0x08051362
7 apache::activemq::client::Connection::syncRequest() at
src/Connection.cpp:188 0x0805e31e
6 apache::activemq::client::Connection::checkConnected() at
src/Connection.cpp:298 0x0805e196
5 apache::activemq::client::Connection::syncRequest() at
src/Connection.cpp:186 0x0805e2d1
4 apache::activemq::client::Connection::createSession() at
src/Connection.cpp:173 0x0805fb56
3 apache::activemq::client::Connection::createSession() at
src/Connection.cpp:162 0x0805db3b
2 Tester::test() at ../main.cpp:47 0x0804bd8a
1 main() at ../main.cpp:102 0x0804ab34
My code is a modified version of the cms sample ... the guts of the code is
shown below
int numMessages = 1000;
int sleepTime = 10;
printf(Starting activemqcms test (sending %d messages and
sleeping %d seconds) ...\n, numMessages, sleepTime );
// START SNIPPET: demo
ConnectionFactory connectionFactory( pUri(new
Uri(tcp://127.0.0.1:61616) ) );
pIConnection connection = connectionFactory.createConnection
();
pISession session = connection-createSession();
pITopic topic = session-getTopic(mytopic);
pMessageConsumer consumer =
p_castMessageConsumer(session-createConsumer( topic ));
consumer-setMessageListener( pIMessageListener(this) );
pIMessageProducer producer = session-createProducer( topic );
const char* text = this is a test!;
pITextMessage msg = session-createTextMessage( text );
for( int ix=0; ixnumMessages; ++ix ){
producer-send( msg );
