You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@servicemix.apache.org by Ujval Mysore <Uj...@infosys.com> on 2006/08/28 08:46:08 UTC
Issues found when load tested servicemix
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***
Re: Issues found when load tested servicemix
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <Uj...@infosys.com> 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