Stomp message body is empty
diktatoren Jun 12, 2010 11:12 AMHi,
I wrote a working application, using the STOMP interface of HornetQ that worked both with a trunk version of HornetQ and the candidate release. However, after upgrading to 2.1 final, messages received from the STOMP interface no longer has any text in the body. I'm not absolutely sure that the upgrade was what caused it, but it's my best theory for now.
After reading the manual, I'm suspecting it has something to do with a content-length header, but I'm not sure where to set this, as I'm putting messages in the queue in the following way:
clientMessage.getBodyBuffer().writeString(message);
producer.send(clientMessage);
I've verified that the message variable does contain text, and I've tried the writeByteArray, writeUTF8 and writeSimpleString-methods.
the config looks like this:
<acceptor name="stomp-acceptor">
<factory-class>org.hornetq.core.remoting.impl.netty.NettyAcceptorFactory</factory-class>
<param key="protocol" value="stomp"/>
<param key="host" value="localhost"/>
<param key="port" value="61613"/>
</acceptor>
I've done a tcpdump of both the older application, and the new ones. Here's the output:
The "healthy", older one:
MESSAGE
_HQ_ORIG_ADDRESS:jms.topic.soccer.events.all
timestamp:1276304427119
redelivered:false
_HQ_ORIG_MESSAGE_ID:40802191254
expires:0
subscription:subscription/jms.topic.soccer.events.livecenter
priority:4
content-length:197
message-id:40802191255
type:18
destination:jms.topic.soccer.events.livecenter
......{"minute":"87","event-name":"Sjanse","away":"Lillestr..m","home":"Molde","player":"Fall","matchId":"378849","away-goals":"0","home-goals":"3","type":"18","mode":"insert","detailId":"6090290"}.
ACK
message-id:40802191255
...and the new one:
.MESSAGE
timestamp:1276307227879
redelivered:false
expires:0
subscription:subscription/jms.topic.soccer.events.all
priority:4
matchId:505113
message-id:17179869507
type:1034
destination:jms.topic.soccer.events.all
.
ACK
message-id:17179869507
#####
I've noticed that the new one does not contain a content-length header.
Here's the queue config:
<queue name="jms.topic.soccer.events.all">
<address>jms.topic.soccer.events.all</address>
<durable>false</durable>
</queue>
<queue name="jms.topic.soccer.events.livecenter">
<address>jms.topic.soccer.events.livecenter</address>
<durable>false</durable>
</queue>
<divert name="livecenter-divert">
<address>jms.topic.soccer.events.all</address>
<forwarding-address>jms.topic.soccer.events.livecenter</forwarding-address>
<filter string="type<>'26' AND type<>'27' AND type<>'54'"/>
<exclusive>false</exclusive>
</divert>
Both tests were done by running the following perl script:
#
# consumer with client side acknowledgment
#
use Net::STOMP::Client;
use utf8;
(@ARGV > 1 || die "Too few arguments! Usage: host queue");
my $host = $ARGV[0];
my $queue = $ARGV[1];
$stomp = Net::STOMP::Client->new(host => $host, port => 61613);
$stomp->connect(login => "guest", passcode => "guest");
printf "Connected\n";
# declare a callback to be called for each received message frame
$stomp->message_callback(sub {
my($self, $frame) = @_;
$self->ack(frame => $frame);
printf("received: %s\n", $frame->body());
return($self);
});
printf "Subscribe\n";
# subscribe to the given queue
$stomp->subscribe(destination => $queue, ack => "client");
printf "Waiting\n";
# wait for a specified message frame
$stomp->wait_for_frames(callback => sub {
my($self, $frame) = @_;
if ($frame->command() eq "MESSAGE") {
# stop waiting for new frames if body is "quit"
return(1) if $frame->body() eq "quit";
}
# continue to wait for more frames
return(0);
});
$stomp->unsubscribe(destination => $queue);
$stomp->disconnect();
####
And the session was created calling session = nettyFactory.createSession(); in both cases.
Message was edited by: PÃ¥l Evensen