reliable message sends using STOMP

[sam.bishop]

I have a question about how to use STOMP with HornetQ.  We have been using HornetQ for a long time, but only as a JMS broker.  Now we have an external system that we would like to receive messages from, and that system is written in Perl.  The obvious thing to do was to enable a STOMP acceptor in our broker configuration.  I did that and found that successfully sending messages from Perl was a snap, and I thought all was well.

However, I then checked to make sure that a send fails when I would expect it to, so I tried sending to an non-existent address.  What I found was that the Perl client seems unaware that something went wrong, there is no complaint in the HornetQ logs, and I see no sign of the message on the server.  This is a big problem for us, since we want to be absolutely sure that we do not lose these messages.

We are using the Net::Stomp Perl library, version 0.45, and HornetQ version 2.2.5.  We are also using the send_transactional Net::Stomp method, which uses BEGIN, RECEIPT, and COMMIT frames to make sure that the server has successfully received the message.

I'm still trying different things to figure out how to make this work, but I thought I would ask to see if someone else has dealt with this before.

Thanks,

Sam

[gaohoward]

2.2.5 is a pretty old version. Can you please try the latest release?

[sam.bishop]

Sure.  I've reproduced this using the 2.3.0.BETA3 release.  At this point I believe this is a bug.  Let me know if I ought to enter a JIRA case.

Besides bumping up the HornetQ version, I have also switched to a Perl library that has good debugging support.  Here's my Perl code:

#!/usr/bin/perl

use Net::STOMP::Client;

use No::Worries::Log qw(*);

log_filter("debug");

$Net::STOMP::Client::Debug = "all";

my $stomp = Net::STOMP::Client->new(host => 'localhost', port => '61613');

$stomp->connect();

my $ret = $stomp->send(

        destination => 'jms.queue.NonExistent',

        body => 'message body',

        receipt => $stomp->uuid()

    );

$stomp->wait_for_receipts(timeout => 10);

$stomp->disconnect;

And here's the output:

# 2012/12/21-09:16:04 titan-stomp2[6832]: connect to tcp://localhost:61613 ok: 127.0.0.1

# 2012/12/21-09:16:04 titan-stomp2[6832]: Net::STOMP::Client=HASH(0x803c7ee8)->connect()

# 2012/12/21-09:16:04 titan-stomp2[6832]: encoding CONNECT frame

# 2012/12/21-09:16:04 titan-stomp2[6832]:  H accept-version:1.0,1.1,1.2

# 2012/12/21-09:16:04 titan-stomp2[6832]:  H host:localhost

# 2012/12/21-09:16:04 titan-stomp2[6832]: sent 52 bytes

# 2012/12/21-09:16:04 titan-stomp2[6832]: received 89 bytes

# 2012/12/21-09:16:04 titan-stomp2[6832]: decoding CONNECTED frame

# 2012/12/21-09:16:04 titan-stomp2[6832]:  H version:1.1

# 2012/12/21-09:16:04 titan-stomp2[6832]:  H session:945282069

# 2012/12/21-09:16:04 titan-stomp2[6832]:  H server:HornetQ/2.2.5 HornetQ Messaging Engine

# 2012/12/21-09:16:04 titan-stomp2[6832]: Net::STOMP::Client=HASH(0x803c7ee8)->send()

# 2012/12/21-09:16:04 titan-stomp2[6832]: encoding SEND frame

# 2012/12/21-09:16:04 titan-stomp2[6832]:  H destination:jms.queue.NonExistent

# 2012/12/21-09:16:04 titan-stomp2[6832]:  H receipt:803c7ee8-50d48b44-1ab0-c96f-1

# 2012/12/21-09:16:04 titan-stomp2[6832]:  H content-length:12

# 2012/12/21-09:16:04 titan-stomp2[6832]:  B 0000 6d657373 61676520 626f6479           mess age  body

# 2012/12/21-09:16:04 titan-stomp2[6832]: sent 109 bytes

# 2012/12/21-09:16:04 titan-stomp2[6832]: received 52 bytes

# 2012/12/21-09:16:04 titan-stomp2[6832]: decoding RECEIPT frame

# 2012/12/21-09:16:04 titan-stomp2[6832]:  H receipt-id:803c7ee8-50d48b44-1ab0-c96f-1

# 2012/12/21-09:16:04 titan-stomp2[6832]: Net::STOMP::Client=HASH(0x803c7ee8)->disconnect()

# 2012/12/21-09:16:04 titan-stomp2[6832]: encoding DISCONNECT frame

# 2012/12/21-09:16:04 titan-stomp2[6832]: sent 13 bytes

Note the "server" header from the CONNECTED frame, by the way.  The actual 2.2.5 version of HornetQ doesn't provide that header.

Here's what I get from an Apache Apollo instance, using the same Perl code:

# 2012/12/21-09:19:44 titan-stomp2[6076]: connect to tcp://localhost:61613 ok: 127.0.0.1

# 2012/12/21-09:19:44 titan-stomp2[6076]: Net::STOMP::Client=HASH(0x803c7ee8)->connect()

# 2012/12/21-09:19:44 titan-stomp2[6076]: encoding CONNECT frame

# 2012/12/21-09:19:44 titan-stomp2[6076]:  H passcode:password

# 2012/12/21-09:19:44 titan-stomp2[6076]:  H accept-version:1.0,1.1,1.2

# 2012/12/21-09:19:44 titan-stomp2[6076]:  H host:localhost

# 2012/12/21-09:19:44 titan-stomp2[6076]:  H login:admin

# 2012/12/21-09:19:44 titan-stomp2[6076]: sent 82 bytes

# 2012/12/21-09:19:44 titan-stomp2[6076]: received 129 bytes

# 2012/12/21-09:19:44 titan-stomp2[6076]: decoding CONNECTED frame

# 2012/12/21-09:19:44 titan-stomp2[6076]:  H version:1.2

# 2012/12/21-09:19:44 titan-stomp2[6076]:  H server:apache-apollo/1.5

# 2012/12/21-09:19:44 titan-stomp2[6076]:  H host-id:stomp-test2

# 2012/12/21-09:19:44 titan-stomp2[6076]:  H session:stomp-test2-3ea

# 2012/12/21-09:19:44 titan-stomp2[6076]:  H heart-beat:100,10000

# 2012/12/21-09:19:44 titan-stomp2[6076]:  H user-id:admin

# 2012/12/21-09:19:44 titan-stomp2[6076]: Net::STOMP::Client=HASH(0x803c7ee8)->send()

# 2012/12/21-09:19:44 titan-stomp2[6076]: encoding SEND frame

# 2012/12/21-09:19:44 titan-stomp2[6076]:  H destination:jms.queue.NonExistent

# 2012/12/21-09:19:44 titan-stomp2[6076]:  H receipt:803c7ee8-50d48c20-17bc-fa65-1

# 2012/12/21-09:19:44 titan-stomp2[6076]:  H content-length:12

# 2012/12/21-09:19:44 titan-stomp2[6076]:  B 0000 6d657373 61676520 626f6479           mess age  body

# 2012/12/21-09:19:44 titan-stomp2[6076]: sent 109 bytes

# 2012/12/21-09:19:44 titan-stomp2[6076]: received 170 bytes

# 2012/12/21-09:19:44 titan-stomp2[6076]: decoding ERROR frame

# 2012/12/21-09:19:44 titan-stomp2[6076]:  H message:Internal Server Error\c org.apache.activemq.apollo.stomp.StompProtocolHandler$ProtocolException\c Invalid stomp destination name\c jms.queue.NonExistent

unexpected ERROR frame received: Internal Server Error: org.apache.activemq.apollo.stomp.StompProtocolHandler$ProtocolException: Invalid stomp destination name: jms.queue.NonExistent

# 2012/12/21-09:19:44 titan-stomp2[6076]: Net::STOMP::Client=HASH(0x803c7ee8)->disconnect()

# 2012/12/21-09:19:44 titan-stomp2[6076]: encoding DISCONNECT frame

# 2012/12/21-09:19:44 titan-stomp2[6076]: sent 13 bytes

Thanks,

Sam

[gaohoward]

Hi Sam,

I think this is the current behavior of hornetq. However I think we can give user an option to change that behavior (maybe in the form of an extra header in CONNECT frame).

Howard

[gaohoward]

https://issues.jboss.org/browse/HORNETQ-1105

created a jira to track it.

[sam.bishop]

Hi, Howard.

Thank you.  I really appreciate your help.

I don't know if another header is necessary.  It seems like whether a client cares about whether the send was successful or not is already encoded in whether the client asks for a receipt.

However this plays out, I think I've found a workable solution in the meantime.  (In case anyone else has this same question.)  We're already monitoring our dead-letter queue, and I found a send-to-dla-on-no-route flag in the hornetq-configuration.xml file that causes these messages to be sent to the dead-letter queue.

Thanks again,

Sam

[gaohoward]

OK I agree there is no need to add another header. It will just return an error frame whenever the client sends a message to a non-existent destination.

Thanks

Howard