Flooding the Stomp interface - any ideas?

Question

Does anyone have any experience of overloading the new Stomp interface using the OpenMQ 4.4 beta running under Windows? I've found that if messages are sent in too fast, exceptions occur. This happens with a Producer tool (for example Michael Justin's free download) and a different demo program based on the Delphi TStompClient component from the Codehaus site. I suspect it will happen with any program that writes, say, several hundred messages to a topic or queue in rapid succession.
A workaround which I have just tried this morning is to put in a Sleep(0) after each send in order to cede a bit of processor time to the JMS - early signs are that this seems to work. However I would like to know if anyone else has experience of this issue and what the best way forward is. Is it a JMS bug?
The exception generated is below - you can see that the JMS is having trouble interpreting a Stomp message with missing characters at the start of the message. (Different fragments will displayed in different occurrences of the exception).
04-Jun-2009 18:56:23
SEVERE: Parse incomming data failed: Unknown STOMP command: tination:/topic/Torus2ClientTopic
com.sun.messaging.bridge.service.stomp.FrameParseException: Unknown STOMP command: tination:/topic/Torus2ClientTopic
at com.sun.messaging.bridge.service.stomp.StompFrameMessage.parseCommand(StompFrameMessage.java:549)
at com.sun.messaging.bridge.service.stomp.StompProtocolParser.hasNextMessage(StompProtocolParser.java:179)
at com.sun.grizzly.filter.ParserProtocolFilter.execute(ParserProtocolFilter.java:139)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:136)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:103)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:89)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:53)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57)
at com.sun.grizzly.ContextTask.run(ContextTask.java:69)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Thanks for any ideas...

Answer 1

I've tried a few different platforms and mostly JRE 1.6u13. Yesterday I started using the JDK (1.6u13 - for compatibility with Open build 8/9). I have used Windows 2003 & Windows Vista. To be sure that everything is the latest, I've re-installed this afternoon as follows:
- Processor: Intel 2 Core Duo 2GHz.
- OS: Windows 32-bit Vista SP1
- Install JDK 1.6u14
- Install OpenMQ 4.4 build 9 and set up for Stomp
- Start imqbrokerd from a command window
- Create a topic with default parameters with the imqadmin tool
- Download "Habari OpenMQ Client - Delphi demo download" from: http://www55.pair.com/betasoft/habari.html#item_1197
- Unzip and run: ...\HabariOpenMQ-demo\demo\delphigui\GUIDemo.exe
- Ignoring the row of big buttons on top (no reason, that's just what I did) look at the left hand half of the screen and the different sections separated by parallel lines:
     - In the Connection section click the Connect button
     - In the Session section click the Create button;
     - Click OK in the dialog that appears, accepting Automatic Acknowledgement
     - In the Destinations section type the name of your test topic in the empty text box just above the New button and click New
     - Subscribe to this topic by highlighting it in the Destinations list box and clicking the Subscribe button
     - Click the Send button to send the default message and check that it is received in the Log Window (Received test message:....)
     - Change the repeat count to 10000 and click Send again.
This configuration (with JDK 1.6u14 instead of u13) seems to be more robust than previous configurations I have tried. I could not get the problem to occur when sending only 1000 messages, so I increased the count to 10000. Then dozens of errors occurred.
I suspect the problem is not at the client side because it is also seen with a different client - using code based on the Delphi TStompClient class downloaded from the Codehaus site. (The TStompClient even uses a different TCP socket from the Habari component so it has different code at all levels of the program).
Banner at the top of a startup log is:
Open Message Queue 4.4
Sun Microsystems, Inc.
Version: 4.4 (Build 9-d)
Compile: Fri 06/05/2009
Copyright (c) 2009 Sun Microsystems, Inc. All rights reserved. Use is
subject to license terms.
================================================================================
Java Runtime: 1.6.0_14 Sun Microsystems Inc. C:\Program Files\Java\jdk1.6.0_14\jre
[12/Jun/2009:13:11:39 BST] IMQ_HOME=C:\Program Files\Sun\MessageQueue\mq
[12/Jun/2009:13:11:39 BST] IMQ_VARHOME=C:\Program Files\Sun\MessageQueue\var\mq
[12/Jun/2009:13:11:39 BST] Windows Vista 6.0 x86 JonStewart.apdcomms.co.uk (2 cpu) jon.stewart
[12/Jun/2009:13:11:40 BST] Java Heap Size: max=189376k, current=18176k
[12/Jun/2009:13:11:40 BST] Arguments:
[12/Jun/2009:13:11:40 BST] [B1004]: Starting the portmapper service using tcp [ 7676, 50, * ] with min threads 1 and max threads of 1
[12/Jun/2009:13:11:40 BST] [B1060]: Loading persistent data...
[12/Jun/2009:13:11:40 BST] Using built-in file-based persistent store: C:\Program Files\Sun\MessageQueue\var\mq\instances\imqbroker\
[12/Jun/2009:13:11:40 BST] [B1318]: Initialize bridge service manager
[12/Jun/2009:13:11:40 BST] BridgeManager: Loading bridge stomp
[12/Jun/2009:13:11:40 BST] BridgeManager: Loaded bridge stomp
[P.S. the different name for this post is 'cos I was having trouble accessing my original Sun account]