You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Sri <sr...@googlemail.com> on 2010/10/12 16:28:10 UTC
Getting Thread number on concurrent consumers , threads
Hello,
I am using concurrent consumers to process the messages from active mq and I
wanted to get the thread number to debug which thread is processing which
message. is there any way that I can get the thread number from the
processor.
I am using the route in the following way.
from("jms-test:queue:" + _notificationQueue
+ "?concurrentConsumers=" + concurrentConsumers)
.onException(Exception.class).retryWhile(
bean("myRetryBean")).end()
.threads(concurrentConsumers).process(processor)
.recipientList(
header("recipientListHeader").tokenize(","))
.parallelProcessing().timeout(aggregationTimeout)
.executorService(customThreadPoolExecutor).streaming()
.aggregationStrategy(
new RecipientAggregationStrategy(
_endpointDeliveredBaseUri)).to(
"direct:chunk.completed");
suppose if the concurrent consumers size is 5 , there will be 5 threads
consuming messages with thread numbers starts from 0 to 5.
is there any way that I can get this number.
Thanks for your help in advance.
Regards
Sri
--
View this message in context: http://camel.465427.n5.nabble.com/Getting-Thread-number-on-concurrent-consumers-threads-tp3208969p3208969.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: how about robust-stop and try stop strategy support of camel while stop the application
Posted by ext2 <xu...@tongtech.com>.
I see, thanks a lot
============================================================
> Willem Jiang [mailto:willem.jiang@gmail.com]
> 2010年10月14日 14:34
> users@camel.apache.org
>Re: how about robust-stop and try stop strategy support of camel while stop
the application
I don't think current Camel can do the job 2.
But you can easily write a customer ShutdownStrategy which extends the
default one and configure it into Camel.
On 10/13/10 8:59 PM, ext2 wrote:
>
> Hi:
> I have post the question. But it seems I doesn't illustrate the
> usage clearly and cause some confuse things. So I re-write the use case,
> and repost the subject again. I am regret for it :(.
>
> While the manager decide to stop the applications. They often
> encounter such situations;
> 1: Sometimes , system shutdown is urgent, and the application must
> be stopped in time. And the user want the application support some robust
> strategy to avoid lost messages at this situation;
> The camel's graceful-shutdown strategy support the technical
> framework to fulfil such situations; But how to achieve the robust
purpose,
> it's another question. and it's not key-point here; (Actually, it's too
hard
> to guarantee not to lost any message, even it's impossible sometimes. We
> will have a risk to lost the being processed message. So we need another
> stop strategy as following).;
>
> 2: Sometimes, system shutdown is not urgent. and the manager has
> enough time to waiting applications to stop and the manager doesn't want
> take the risk of lost message; At such case, the manager require another
> stop strategy: just trying to stop in the give time. if time expired, it
> doesn't stop the system and just report stopping failed to tell the
manager:
> application cannot be shutdown now, it's working.
> And how does camel support such stop strategy ?
>
>
>
--
Willem
----------------------------------
Open Source Integration: http://www.fusesource.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: http://twitter.com/willemjiang
Re: how about robust-stop and try stop strategy support of camel
while stop the application
Posted by Willem Jiang <wi...@gmail.com>.
I don't think current Camel can do the job 2.
But you can easily write a customer ShutdownStrategy which extends the
default one and configure it into Camel.
On 10/13/10 8:59 PM, ext2 wrote:
>
> Hi:
> I have post the question. But it seems I doesn't illustrate the
> usage clearly and cause some confuse things. So I re-write the use case,
> and repost the subject again. I am regret for it :(.
>
> While the manager decide to stop the applications. They often
> encounter such situations;
> 1: Sometimes , system shutdown is urgent, and the application must
> be stopped in time. And the user want the application support some robust
> strategy to avoid lost messages at this situation;
> The camel's graceful-shutdown strategy support the technical
> framework to fulfil such situations; But how to achieve the robust purpose,
> it's another question. and it's not key-point here; (Actually, it's too hard
> to guarantee not to lost any message, even it's impossible sometimes. We
> will have a risk to lost the being processed message. So we need another
> stop strategy as following).;
>
> 2: Sometimes, system shutdown is not urgent. and the manager has
> enough time to waiting applications to stop and the manager doesn't want
> take the risk of lost message; At such case, the manager require another
> stop strategy: just trying to stop in the give time. if time expired, it
> doesn't stop the system and just report stopping failed to tell the manager:
> application cannot be shutdown now, it's working.
> And how does camel support such stop strategy ?
>
>
>
--
Willem
----------------------------------
Open Source Integration: http://www.fusesource.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: http://twitter.com/willemjiang
how about robust-stop and try stop strategy support of camel while stop the application
Posted by ext2 <xu...@tongtech.com>.
Hi:
I have post the question. But it seems I doesn't illustrate the
usage clearly and cause some confuse things. So I re-write the use case,
and repost the subject again. I am regret for it :(.
While the manager decide to stop the applications. They often
encounter such situations;
1: Sometimes , system shutdown is urgent, and the application must
be stopped in time. And the user want the application support some robust
strategy to avoid lost messages at this situation;
The camel's graceful-shutdown strategy support the technical
framework to fulfil such situations; But how to achieve the robust purpose,
it's another question. and it's not key-point here; (Actually, it's too hard
to guarantee not to lost any message, even it's impossible sometimes. We
will have a risk to lost the being processed message. So we need another
stop strategy as following).;
2: Sometimes, system shutdown is not urgent. and the manager has
enough time to waiting applications to stop and the manager doesn't want
take the risk of lost message; At such case, the manager require another
stop strategy: just trying to stop in the give time. if time expired, it
doesn't stop the system and just report stopping failed to tell the manager:
application cannot be shutdown now, it's working.
And how does camel support such stop strategy ?
Re: Does Gracefull shutdown Mbean support waiting time argument?
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
I created a ticket, so we wont forget about this
https://issues.apache.org/activemq/browse/CAMEL-3240
On Thu, Oct 14, 2010 at 9:13 PM, Claus Ibsen <cl...@gmail.com> wrote:
> On Wed, Oct 13, 2010 at 12:24 PM, ext2 <xu...@tongtech.com> wrote:
>> Hi:
>> It seems the camel's graceful shutdownis just like the requirement "robust
>> stop application": give a waiting time, force stop, and do it's best
>> ability to avoid lost message;
>>
>> But the camel cannot support "try to stop" interface; isn't it?
>
> Fell free to create a ticket about that last requirement to give up
> (eg try to stop but give up if you could not do it after X seconds).
>
>
>
>> ======================================================
>>>Hi
>>>Can you elaborate on the robust shutdown?
>>
>>>My experience is if you can't do the grace for shutdown with a certain
>>>time, the on flight exchanges maybe have no other change to be processed.
>>
>>>Do you mean Camel should store these on flight exchanges into a
>>>persistence storage, if the wait time is out.
>>
>> No, It doesn't ask for so such process.
>>
>> From the end user(system manager)'s point, it just means camel should give
>> him chance to choose:
>> 1) robust stop the application: It means the application must be stopped
>> until the waiting-time expired;
>> 2) or just try to stop application: it means the application must not be
>> stopped if system is still busy until waiting time out.
>>
>> This function could tell the system manager: if you don't want to lost the
>> message, you can do "try to stop " again and again. But if you couldn't
>> endure and choose to robust stop ((especially the case: deadlocked by extern
>> system), then you will have a risk to lost a message.
>>
>> whether using persistence storage or other means , it 's just a different
>> ways to implement the "try to stop" requirement; For example we can use
>> another simple ways to implement the requirement:
>> Suspending the consumer's IO operation to avoid continue to process
>> external message; and just waiting the Exchange to be processed over; if
>> the Exchange is still being processed while time out, just return false to
>> indicate try-stop failed;
>>
>> Thanks
>>
>>
>>
>>
>>
>>
>>
>
>
>
> --
> Claus Ibsen
> Apache Camel Committer
>
> Author of Camel in Action: http://www.manning.com/ibsen/
> Open Source Integration: http://fusesource.com
> Blog: http://davsclaus.blogspot.com/
> Twitter: http://twitter.com/davsclaus
>
--
Claus Ibsen
Apache Camel Committer
Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Re: Does Gracefull shutdown Mbean support waiting time argument?
Posted by Claus Ibsen <cl...@gmail.com>.
On Wed, Oct 13, 2010 at 12:24 PM, ext2 <xu...@tongtech.com> wrote:
> Hi:
> It seems the camel's graceful shutdownis just like the requirement "robust
> stop application": give a waiting time, force stop, and do it's best
> ability to avoid lost message;
>
> But the camel cannot support "try to stop" interface; isn't it?
Fell free to create a ticket about that last requirement to give up
(eg try to stop but give up if you could not do it after X seconds).
> ======================================================
>>Hi
>>Can you elaborate on the robust shutdown?
>
>>My experience is if you can't do the grace for shutdown with a certain
>>time, the on flight exchanges maybe have no other change to be processed.
>
>>Do you mean Camel should store these on flight exchanges into a
>>persistence storage, if the wait time is out.
>
> No, It doesn't ask for so such process.
>
> From the end user(system manager)'s point, it just means camel should give
> him chance to choose:
> 1) robust stop the application: It means the application must be stopped
> until the waiting-time expired;
> 2) or just try to stop application: it means the application must not be
> stopped if system is still busy until waiting time out.
>
> This function could tell the system manager: if you don't want to lost the
> message, you can do "try to stop " again and again. But if you couldn't
> endure and choose to robust stop ((especially the case: deadlocked by extern
> system), then you will have a risk to lost a message.
>
> whether using persistence storage or other means , it 's just a different
> ways to implement the "try to stop" requirement; For example we can use
> another simple ways to implement the requirement:
> Suspending the consumer's IO operation to avoid continue to process
> external message; and just waiting the Exchange to be processed over; if
> the Exchange is still being processed while time out, just return false to
> indicate try-stop failed;
>
> Thanks
>
>
>
>
>
>
>
--
Claus Ibsen
Apache Camel Committer
Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Re: Does Gracefull shutdown Mbean support waiting time argument?
Posted by ext2 <xu...@tongtech.com>.
Hi:
It seems the camel's graceful shutdownis just like the requirement "robust
stop application": give a waiting time, force stop, and do it's best
ability to avoid lost message;
But the camel cannot support "try to stop" interface; isn't it?
======================================================
>Hi
>Can you elaborate on the robust shutdown?
>My experience is if you can't do the grace for shutdown with a certain
>time, the on flight exchanges maybe have no other change to be processed.
>Do you mean Camel should store these on flight exchanges into a
>persistence storage, if the wait time is out.
No, It doesn't ask for so such process.
>From the end user(system manager)'s point, it just means camel should give
him chance to choose:
1) robust stop the application: It means the application must be stopped
until the waiting-time expired;
2) or just try to stop application: it means the application must not be
stopped if system is still busy until waiting time out.
This function could tell the system manager: if you don't want to lost the
message, you can do "try to stop " again and again. But if you couldn't
endure and choose to robust stop ((especially the case: deadlocked by extern
system), then you will have a risk to lost a message.
whether using persistence storage or other means , it 's just a different
ways to implement the "try to stop" requirement; For example we can use
another simple ways to implement the requirement:
Suspending the consumer's IO operation to avoid continue to process
external message; and just waiting the Exchange to be processed over; if
the Exchange is still being processed while time out, just return false to
indicate try-stop failed;
Thanks
Re: Does Gracefull shutdown Mbean support waiting time argument?
Posted by ext2 <xu...@tongtech.com>.
>Hi
>Can you elaborate on the robust shutdown?
>My experience is if you can't do the grace for shutdown with a certain
>time, the on flight exchanges maybe have no other change to be processed.
>Do you mean Camel should store these on flight exchanges into a
>persistence storage, if the wait time is out.
No, It doesn't ask for so such process.
>From the end user(system manager)'s point, it just means camel should give
him chance to choose:
1) robust stop the application: It means the application must be stopped
until the waiting-time expired;
2) or just try to stop application: it means the application must not be
stopped if system is still busy until waiting time out.
This function could tell the system manager: if you don't want to lost the
message, you can do "try to stop " again and again. But if you couldn't
endure and choose to robust stop ((especially the case: deadlocked by extern
system), then you will have a risk to lost a message.
whether using persistence storage or other means , it 's just a different
ways to implement the "try to stop" requirement; For example we can use
another simple ways to implement the requirement:
Suspending the consumer's IO operation to avoid continue to process
external message; and just waiting the Exchange to be processed over; if
the Exchange is still being processed while time out, just return false to
indicate try-stop failed;
Thanks
Re: Does Gracefull shutdown Mbean support waiting time argument?
Posted by Willem Jiang <wi...@gmail.com>.
Hi
Can you elaborate on the robust shutdown?
My experience is if you can't do the grace for shutdown with a certain
time, the on flight exchanges maybe have no other change to be processed.
Do you mean Camel should store these on flight exchanges into a
persistence storage, if the wait time is out.
On 10/13/10 11:20 AM, ext2 wrote:
> Hi:
> Camel support graceful shutdown feature. When the camelContext is
> stopped, camel will try to stop application gracefully until the time
> expired;
>
> Some-times the system manager may required to try to stop the
> application , and if the application cannot be stopped in time, the system
> manager will have another chance to decide to shutdown the application
> robustly or not;
> That's to say , does the camel graceful shutdown strategy support
> such feature as following?
>
> boolean stop(Boolean robust, int waitingTime);
> if ${robust} == false, camel will try to stop application in
> ${waitingtime) gracefully. if ${waitingTime) expired, camel will not stop
> application robustly.
> If ${robust} == true, camel will try to stop application in
> ${waitingTime), if ${waitingTime)expired, camel will shutdown application
> robustly;
>
> Thanks any suggestion
>
>
>
--
Willem
----------------------------------
Open Source Integration: http://www.fusesource.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: http://twitter.com/willemjiang
Does Gracefull shutdown Mbean support waiting time argument?
Posted by ext2 <xu...@tongtech.com>.
Hi:
Camel support graceful shutdown feature. When the camelContext is
stopped, camel will try to stop application gracefully until the time
expired;
Some-times the system manager may required to try to stop the
application , and if the application cannot be stopped in time, the system
manager will have another chance to decide to shutdown the application
robustly or not;
That's to say , does the camel graceful shutdown strategy support
such feature as following?
boolean stop(Boolean robust, int waitingTime);
if ${robust} == false, camel will try to stop application in
${waitingtime) gracefully. if ${waitingTime) expired, camel will not stop
application robustly.
If ${robust} == true, camel will try to stop application in
${waitingTime), if ${waitingTime)expired, camel will shutdown application
robustly;
Thanks any suggestion
Re: Getting Thread number on concurrent consumers , threads
Posted by Claus Ibsen <cl...@gmail.com>.
The concurrentConsumers on the JMS is for Spring JMS stuff. So you are
in the mersey how they assign thread names in that thread pool using
by spring JMS.
You may be able to hook a custom thread pool in Spring JMS using the
taskExecutor option.
And why do you have a threads in the route as well? You dont need that.
On Tue, Oct 12, 2010 at 4:28 PM, Sri <sr...@googlemail.com> wrote:
>
> Hello,
>
>
> I am using concurrent consumers to process the messages from active mq and I
> wanted to get the thread number to debug which thread is processing which
> message. is there any way that I can get the thread number from the
> processor.
>
> I am using the route in the following way.
>
> from("jms-test:queue:" + _notificationQueue
> + "?concurrentConsumers=" + concurrentConsumers)
> .onException(Exception.class).retryWhile(
> bean("myRetryBean")).end()
> .threads(concurrentConsumers).process(processor)
> .recipientList(
> header("recipientListHeader").tokenize(","))
> .parallelProcessing().timeout(aggregationTimeout)
> .executorService(customThreadPoolExecutor).streaming()
> .aggregationStrategy(
> new RecipientAggregationStrategy(
> _endpointDeliveredBaseUri)).to(
> "direct:chunk.completed");
>
> suppose if the concurrent consumers size is 5 , there will be 5 threads
> consuming messages with thread numbers starts from 0 to 5.
>
> is there any way that I can get this number.
>
>
> Thanks for your help in advance.
>
> Regards
> Sri
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/Getting-Thread-number-on-concurrent-consumers-threads-tp3208969p3208969.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
--
Claus Ibsen
Apache Camel Committer
Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus