| Subject: | MESSAGEs do not decode if server heart-beats have been received |
Hi,
I've come across an odd bug in Net::STOMP::Client.
It occurs on version 1.1, once client and server heart-beats have been enabled, and
more than one has already been received from the server.
At this point, any subsequent MESSAGE frame will fail to be decoded.
Looking at Net/STOMP/Client/Frame.pm, at approximately line 250, we have code like
this:
$temp = substr($$bufref, $state->{command_idx}, $state->{command_len});
unless ($temp =~ /^\s*($CommandRE)$/o) {
Net::STOMP::Client::Error::report("%s: invalid command", $me);
}
Now this regex is failing because $temp contains leading nulls. I'm dumping out the
value of $temp just prior, and I get the following results:
$VAR1 = [
'',
'',
'',
'',
'M',
'E',
'S',
'S',
'A',
'G',
'E'
];
again, with hexadecimal:
$VAR1 = [
'00',
'00',
'00',
'00',
'4d',
'45',
'53',
'53',
'41',
'47',
'45'
];
I note that the number of leading nulls is equivalent to the number of server pings
that have passed prior to the MESSAGE frame arriving.
I have a bit of a workaround for this issue, which is to change the relevant code
like so:
unless ($temp =~ /^\x00*($CommandRE)$/o) {
Net::STOMP::Client::Error::report("%s: invalid command", $me);
}
$frame->command($1);
However my guess at the root cause here is that the index into the bufref is not
coping with the code around line 241 that does $$bufref =~ s/\n+//;
Cheers,
Toby