You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@servicemix.apache.org by angeloNZ <an...@nz.fujitsu.com> on 2009/09/14 08:06:33 UTC
Camel Throttler problem
Hi,
I'm using SM 3.3 running on Tomcat with Camel 1.6.
In my xbean.xml I have 2 consumer definitions that calls the same provider
definition. One of the routes implements an additional saxon transformation
processing that is required before calling the provider.
REST consumer - Camel --- Saxon
|
SOAP provider
|
SOAP consumer - Camel -----
Now we're trying to add a common throttler component that would apply
different throttle values depending on some value we're expecting from the
request body.
REST consumer - Camel - Saxon ---
| | |
Throttler - SOAP provider
| | |
SOAP consumer - Camel - ------
So at the moment I'm doing this in my Throttler:
from("jbi:service:http://namespace/ThrottlerService")
.choice()
.when().xpath("//role =
''RoleA").to("jbi:service:http://namespace/RoleAService")
.when().xpath("//role =
''RoleB").to("jbi:service:http://namespace/RoleBService")
.end();
from("jbi:service:http://namespace/RoleAService")
.throttler(5).timePeriodMillis(60000).to("jbi:service:http://namespace/TargetService")
from("jbi:service:http://namespace/RoleBService")
.throttler(10).timePeriodMillis(60000).to("jbi:service:http://namespace/TargetService")
from("jbi:service:http://namespace/TargetService")
.choice()
.when().xpath("//request =
'REST").to("jbi:service:http://namespace/SaxonService")
.when().xpath("//request =
''SOAP").to("jbi:service:http://namespace/SOAPService")
.end();
Here's what I observed when I tested this approach:
- If I fire 6 consecutive REST requests for Role A within a 1 minute period,
the 5 requests gets processed fine and the 6th one waited for the next
minute before getting a response. (Expected)
- Similarly if I fire 11 consecutive SOAP requests for Role A within a 1
minute period, the 10 requests gets processed fine and the 11th one waited
for the next minute before getting a response. (Expected)
- If I alternate sending REST and SOAP requests I seem to be able to fire
more than 5 requests for REST and more than 10 requests for SOAP before the
next requests had to wait for the next time slice. (Bad)
- If I fire 6 consecutive REST requests, while the 6th request is waiting
for the next time slice and I fire 1 SOAP request, both the 6th request and
the SOAP request eventually times out. After which any further REST or SOAP
requests are blocked and times out 100% of the time and does not get through
even on the next time slices forcing me to restart my ServiceMix instance.
(Bad)
My questions are:
- How does the throttler behave when set differently for services that
eventually end up calling the same provider endpoint? What's the
recommended approach for this situation? I'd also appreciate any
explainations for those bad behaviors that I've observed above.
Thanks for the help.
--
View this message in context: http://www.nabble.com/Camel-Throttler-problem-tp25430730p25430730.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: Camel Throttler problem
Posted by angeloNZ <an...@nz.fujitsu.com>.
Hi Gert,
The problem was the thread size of servicemix. I did a compare of
servicemix.xml of ServiceMix standalone and that of the web-console version
and one setting I noticed missing in the console version is this:
<sm:executorFactory>
<bean
class="org.apache.servicemix.executors.impl.ExecutorFactoryImpl">
<property name="defaultConfig">
<bean
class="org.apache.servicemix.executors.impl.ExecutorConfig">
<property name="corePoolSize"
value="${servicemix.corePoolSize}"/>
<property name="maximumPoolSize"
value="${servicemix.maximumPoolSize}"/>
<property name="queueSize"
value="${servicemix.queueSize}"/>
</bean>
</property>
</bean>
</sm:executorFactory>
I added that into my servicemix.xml then added the property values into
servicemix-web-console.properties file then things started working. I'm
just wondering, why was this setting left out of the console version?
Gert Vanthienen wrote:
>
> L.S.,
>
> This obviously should not happen. The camel routes will translate
> into an object model at runtime and there should be no connection
> between the two throttler objects in both routes. There's still one
> component thread pool though and there's a single shared endpoint
> instance off course, which could somehow explain why you end up with
> the deadlock. Do you think you can create a simple unit test to
> demonstrate the problem, because that would help us a lot when fixing
> this?
>
> Did you build your own servicemix-camel component to upgrade to Camel
> 1.6, because the default version for ServiceMix 3.3 is Camel 1.4? I
> ask because we had a bug which resembles the throughput rate issues
> you're having here
> (https://issues.apache.org/activemq/browse/CAMEL-1199), but that got
> fixed in Camel 1.6. However, just using Camel 1.6 in your SU would
> not pick up this fix, you'd have to upgrade the component itself.
>
> Regards,
>
> Gert Vanthienen
> ------------------------
> Open Source SOA: http://fusesource.com
> Blog: http://gertvanthienen.blogspot.com/
>
>
>
> 2009/9/14 angeloNZ <an...@nz.fujitsu.com>:
>>
>> Hi,
>>
>> I'm using SM 3.3 running on Tomcat with Camel 1.6.
>>
>> In my xbean.xml I have 2 consumer definitions that calls the same
>> provider
>> definition. One of the routes implements an additional saxon
>> transformation
>> processing that is required before calling the provider.
>>
>> REST consumer - Camel --- Saxon
>> |
>> SOAP provider
>> |
>> SOAP consumer - Camel -----
>>
>> Now we're trying to add a common throttler component that would apply
>> different throttle values depending on some value we're expecting from
>> the
>> request body.
>>
>> REST consumer - Camel - Saxon ---
>> | | |
>> Throttler - SOAP provider
>> | | |
>> SOAP consumer - Camel - ------
>>
>> So at the moment I'm doing this in my Throttler:
>>
>> from("jbi:service:http://namespace/ThrottlerService")
>> .choice()
>> .when().xpath("//role =
>> ''RoleA").to("jbi:service:http://namespace/RoleAService")
>> .when().xpath("//role =
>> ''RoleB").to("jbi:service:http://namespace/RoleBService")
>> .end();
>>
>> from("jbi:service:http://namespace/RoleAService")
>>
>> .throttler(5).timePeriodMillis(60000).to("jbi:service:http://namespace/TargetService")
>>
>> from("jbi:service:http://namespace/RoleBService")
>>
>> .throttler(10).timePeriodMillis(60000).to("jbi:service:http://namespace/TargetService")
>>
>>
>> from("jbi:service:http://namespace/TargetService")
>> .choice()
>> .when().xpath("//request =
>> 'REST").to("jbi:service:http://namespace/SaxonService")
>> .when().xpath("//request =
>> ''SOAP").to("jbi:service:http://namespace/SOAPService")
>> .end();
>>
>> Here's what I observed when I tested this approach:
>>
>> - If I fire 6 consecutive REST requests for Role A within a 1 minute
>> period,
>> the 5 requests gets processed fine and the 6th one waited for the next
>> minute before getting a response. (Expected)
>>
>> - Similarly if I fire 11 consecutive SOAP requests for Role A within a 1
>> minute period, the 10 requests gets processed fine and the 11th one
>> waited
>> for the next minute before getting a response. (Expected)
>>
>> - If I alternate sending REST and SOAP requests I seem to be able to fire
>> more than 5 requests for REST and more than 10 requests for SOAP before
>> the
>> next requests had to wait for the next time slice. (Bad)
>>
>> - If I fire 6 consecutive REST requests, while the 6th request is waiting
>> for the next time slice and I fire 1 SOAP request, both the 6th request
>> and
>> the SOAP request eventually times out. After which any further REST or
>> SOAP
>> requests are blocked and times out 100% of the time and does not get
>> through
>> even on the next time slices forcing me to restart my ServiceMix
>> instance.
>> (Bad)
>>
>>
>> My questions are:
>> - How does the throttler behave when set differently for services that
>> eventually end up calling the same provider endpoint? What's the
>> recommended approach for this situation? I'd also appreciate any
>> explainations for those bad behaviors that I've observed above.
>>
>>
>> Thanks for the help.
>>
>>
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Camel-Throttler-problem-tp25430730p25430730.html
>> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>>
>>
>
>
> -----
> ---
> Gert Vanthienen
> http://gertvanthienen.blogspot.com
>
--
View this message in context: http://www.nabble.com/Camel-Throttler-problem-tp25430730p25447948.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: Camel Throttler problem
Posted by Gert Vanthienen <ge...@gmail.com>.
L.S.,
This obviously should not happen. The camel routes will translate
into an object model at runtime and there should be no connection
between the two throttler objects in both routes. There's still one
component thread pool though and there's a single shared endpoint
instance off course, which could somehow explain why you end up with
the deadlock. Do you think you can create a simple unit test to
demonstrate the problem, because that would help us a lot when fixing
this?
Did you build your own servicemix-camel component to upgrade to Camel
1.6, because the default version for ServiceMix 3.3 is Camel 1.4? I
ask because we had a bug which resembles the throughput rate issues
you're having here
(https://issues.apache.org/activemq/browse/CAMEL-1199), but that got
fixed in Camel 1.6. However, just using Camel 1.6 in your SU would
not pick up this fix, you'd have to upgrade the component itself.
Regards,
Gert Vanthienen
------------------------
Open Source SOA: http://fusesource.com
Blog: http://gertvanthienen.blogspot.com/
2009/9/14 angeloNZ <an...@nz.fujitsu.com>:
>
> Hi,
>
> I'm using SM 3.3 running on Tomcat with Camel 1.6.
>
> In my xbean.xml I have 2 consumer definitions that calls the same provider
> definition. One of the routes implements an additional saxon transformation
> processing that is required before calling the provider.
>
> REST consumer - Camel --- Saxon
> |
> SOAP provider
> |
> SOAP consumer - Camel -----
>
> Now we're trying to add a common throttler component that would apply
> different throttle values depending on some value we're expecting from the
> request body.
>
> REST consumer - Camel - Saxon ---
> | | |
> Throttler - SOAP provider
> | | |
> SOAP consumer - Camel - ------
>
> So at the moment I'm doing this in my Throttler:
>
> from("jbi:service:http://namespace/ThrottlerService")
> .choice()
> .when().xpath("//role =
> ''RoleA").to("jbi:service:http://namespace/RoleAService")
> .when().xpath("//role =
> ''RoleB").to("jbi:service:http://namespace/RoleBService")
> .end();
>
> from("jbi:service:http://namespace/RoleAService")
>
> .throttler(5).timePeriodMillis(60000).to("jbi:service:http://namespace/TargetService")
>
> from("jbi:service:http://namespace/RoleBService")
>
> .throttler(10).timePeriodMillis(60000).to("jbi:service:http://namespace/TargetService")
>
>
> from("jbi:service:http://namespace/TargetService")
> .choice()
> .when().xpath("//request =
> 'REST").to("jbi:service:http://namespace/SaxonService")
> .when().xpath("//request =
> ''SOAP").to("jbi:service:http://namespace/SOAPService")
> .end();
>
> Here's what I observed when I tested this approach:
>
> - If I fire 6 consecutive REST requests for Role A within a 1 minute period,
> the 5 requests gets processed fine and the 6th one waited for the next
> minute before getting a response. (Expected)
>
> - Similarly if I fire 11 consecutive SOAP requests for Role A within a 1
> minute period, the 10 requests gets processed fine and the 11th one waited
> for the next minute before getting a response. (Expected)
>
> - If I alternate sending REST and SOAP requests I seem to be able to fire
> more than 5 requests for REST and more than 10 requests for SOAP before the
> next requests had to wait for the next time slice. (Bad)
>
> - If I fire 6 consecutive REST requests, while the 6th request is waiting
> for the next time slice and I fire 1 SOAP request, both the 6th request and
> the SOAP request eventually times out. After which any further REST or SOAP
> requests are blocked and times out 100% of the time and does not get through
> even on the next time slices forcing me to restart my ServiceMix instance.
> (Bad)
>
>
> My questions are:
> - How does the throttler behave when set differently for services that
> eventually end up calling the same provider endpoint? What's the
> recommended approach for this situation? I'd also appreciate any
> explainations for those bad behaviors that I've observed above.
>
>
> Thanks for the help.
>
>
>
>
>
>
> --
> View this message in context: http://www.nabble.com/Camel-Throttler-problem-tp25430730p25430730.html
> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>
>