StompDecoder bug fix

[zyz]

Hello!

There`s a bug in current (2.2.0 CR1)  org.hornetq.core.protocol.stomp.StompDecoder.

When a client transmits STOMP frames by successive send()`s (like http://stomp.codehaus.org/C) threre`s sometimes a case when the body has already been received but terminating NUL is still pending. This leads to ArrayIndexOutOfBoundsException on next decode() call. More commented in the code.

Also a light optimization is suggested to avoid unnecessary second call to decode() for those clients terminating frames with both NUL and \n.

The changed code comments are marked with ZaitsevY.

[clebert.suconic]

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

Do you think you could provide a test?

[zyz]

Well, why not...

1. Affected version: the one from http://anonsvn.jboss.org/repos/hornetq/trunk/.

2.1.2 Final had another STOMP parser class which was ok.

As far as I see, you've  merged my changes into http://anonsvn.jboss.org/repos/hornetq/branches/Branch_2_2_EAP/ already, thanks.

2. Attached is the server to be compiled and run with minimum HornetQ library set (see server.bat, no *nix, sorry) and 2 versions of StompDecoder class: original and fixed (with uncommented logging) - you can compile any, put into hornetq-core.jar and

3. See the difference running the client.

ps: btw, there`s another problem with HornetQ: embedded server does not respect setPersistenceEnabled(false) and setCreateJournalDir(false) doesn`t help either. More described in Server.java