Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Won't Fix
-
incubation
-
None
-
None
-
WinXP with Java 1.5 (latest) and MacOSX with Java 1.5 (latest)
Description
Configuring JCAFlow according to the default config files in the servicemix distribution appears to work without error, however, if messages are sent to a jms-binding component in rapid succession (as in a tight 'for' loop), the flow fails.
The issue can be reproduced using a simple example based on the jms-binding example and the default config files in the 'conf/' directory of the 6/27 snapshot. The zip file attached contains the complete example, which was originally run from the 'examples' directory of the servicemix distribution. Running it elsewhere may require changes to the config file and ant script.
The attached example uses a full config from the servicemix conf dir, but it should be noted that the issue was originally encountered using a default config (i.e. the flow was specified simply using: flowName=jca?jmsUrl=tcp://etc) - using this config and no references to tx.xml, jndi.xml, or others, the issue still occurred, but it took 20-50 messages in the loop to trigger it.
Running the example appears to load servicemix and establish a JCAFlow without error. The JMSClient from the jms-binding example can be run repeatedly with no problems.
The example also includes a JMS sender and listener, the listener just hangs on receive, while the sender fires 10 messages in a tight loop. On average, only six messages into the loop I begin to receive the error (note: the 'blockingTimeout' parameter and other pooling configuration were tweaked, but the issue seems to happen regardless of what is put into tx.xml):
"ERROR - ActiveMQSession - error dispatching message:
org.apache.servicemix.jbi.RuntimeJBIException: javax.jbi.messaging.MessagingException: javax.jms.JMSException: No ManagedConnections available within configured blocking timeout ( 6000 [ms] )"
I tweaked the 'blockingTimeout' in this run to 6000 so that I could be sure it was really loading my config. The logs for one such test run are also included in the zip file attached under the directory 'test-run-logs'