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

Reply via email to