30 is the default size of ServiceMix thread pool. So it means a component does not correctly implement the MEP used.
From your explanations, it should be the jms out binding.
What's the configuration you used for #4 ? Also, you should try to upgrade to 3.0-M2, it will certainly fix the problem.
On 8/28/06, Ujval Mysore <[EMAIL PROTECTED]> wrote:
Hi, Right now I am evaluating servicemix 2.0.2. As part of other requirements I have deployed servicemix2.0.2 on Weblogic 8.1. I have load tested servicemix in various scenarios and I was confused to see the results. I have load tested all the following scenarios using load runner. I ran the load tests for 5 minutes with 15 simultaneous virtual users, each vuser resending the request once it gets back the response for its previous request and with a very small payload of 10KB per request. Various scenarios include orchestrating the binding components JMS, router and WSIF in the following ways: 1) JMSInBinding --> JMSOutBinding: The client sends the request to servicemix. The JMSInBinding which is listening to a queue reads the message and sends the normalized message to the JMSOutBinding which simply creates a jms message and puts it in another queue. This worked fine without any problem. 2) JMSInBinding --> WSIF: The JMSInBinding sends the message to the WSIF binding component. This scenario also worked fine. 3) JMSInBinding --> WSIF --> WSIF Adding to the previous scenario, the destination service of the WSIF will be one more WSIF. This scenario also worked fine. 4) JMSInBinding --> WSIF --> JMSOutBinding This scenario failed miserably. It hardly processes 30 requests and then hangs. I have debugged the servicemix code and found that for the 30 successful requests, all the three components executed successfully. For the failed transactions, the flow stops at the JMSInBinding. It seems a deadlock is occurring somewhere. On further debugging I found that the method doSend(MessageExchangeImpl) in the SedaFlow.java is also getting executed. When the request flows from JMSInBinding to the WSIF, the values me.getSyncState() and me.getMirror().getSyncState() are '0'. Hence enqueue(packet) is being called. After the execution of WSIF before going to JMSOutBinding, I found the values to be me.getSyncState() =0 and me.getMirror().getSyncState() = 1. Hence doRouting is getting called. This is getting executed perfectly for around first 30 requests. Later, all the requests are getting stuck in the first flow i.e. JMSInBinding --> WSIF. The WSIF is also not getting executed. I also found out that queue.poll method in run() of SedaQueue.java is working properly, as it is getting the message exchange without any problem. I think there is a deadlock occurring somewhere here. 5) JMSInBinding --> Router --> JMSOutBinding I was surprised to note that this scenario works without any problem. 6) JMSInBinding --> Router --> WSIF This scenario too worked fine. 7) JMSInBinding --> Router --> WSIF --> JMSOutBinding This scenario also failed. The results were similar to the point 4. Is it a problem with servicemix? Kindly look into this and please let me know at the earliest. Is there any mechanism to trace the flow of the message in servicemix? Thanks in advance, Ujval Mysore **************** CAUTION - Disclaimer ***************** This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system. ***INFOSYS******** End of Disclaimer ********INFOSYS***
-- Cheers, Guillaume Nodet