Two questions: Stopping Camel and intercept before retry

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Two questions: Stopping Camel and intercept before retry

Hari Gangadharan
Hi All:

Thanks a lot for all the help I have received. We are nearing a production implementation of a Camel based messaging system! It was a great experience, I learned a lot and we saved a lot of time since I used Camel.

I now have two questions:

1. I use org.apache.camel.spring.Main to start my standalone Camel context. Now how do I stop it? Till now I was killing it. Can I kill it? I guess it may not be the right way since I have a feeling that the messages in the pipeline (especially the ones that are in Retry processing) is lost.

2. I really need to get access to the Message between each retry. I use recipientList to forward message to different endpoints based on a header. I have also retry rules which make the Endpoint retry a specific number of times. In many cases I may have to get control and make some header modification of the message before each retry. I could not find any good docs on that. Is there any Strategy implementation I can use that can get control of the exchange before each retry? If that is not there wouldn't it be a good idea to provide a way to intercept messages before each retry?

Thanks in advance,
Hari Gangadharan
Reply | Threaded
Open this post in threaded view
|

Re: Two questions: Stopping Camel and intercept before retry

Claus Ibsen-2
On Wed, Jan 7, 2009 at 2:23 AM, harinair <[hidden email]> wrote:

>
> Hi All:
>
> Thanks a lot for all the help I have received. We are nearing a production
> implementation of a Camel based messaging system! It was a great experience,
> I learned a lot and we saved a lot of time since I used Camel.
>
> I now have two questions:
>
> 1. I use org.apache.camel.spring.Main to start my standalone Camel context.
> Now how do I stop it? Till now I was killing it. Can I kill it? I guess it
> may not be the right way since I have a feeling that the messages in the
> pipeline (especially the ones that are in Retry processing) is lost.
How are you gonna run your application in production? Is it started
from a command line or hosted in a container such as Tomcat?
If you let Spring start Camel then Spring is handling the lifecycle of
Camel, so when Spring is shutting down it will also shutdown Camel as
well.

To avoid loosing messages you should use persistent JMS queues etc.
that guarantees not to loose messages.


>
> 2. I really need to get access to the Message between each retry. I use
> recipientList to forward message to different endpoints based on a header. I
> have also retry rules which make the Endpoint retry a specific number of
> times. In many cases I may have to get control and make some header
> modification of the message before each retry. I could not find any good
> docs on that. Is there any Strategy implementation I can use that can get
> control of the exchange before each retry? If that is not there wouldn't it
> be a good idea to provide a way to intercept messages before each retry?
Didn't we discuss this? Well 1-3 months ago there was a discussion on
this user forum about this topic.

If you use onException you should be able do some custom processing
before it's retried.
Something like this: onException(MyException.class).process(new
Processor() ... )

You can check the error handling documentation:
http://activemq.apache.org/camel/error-handling-in-camel.html

And the onException i here:
http://activemq.apache.org/camel/exception-clause.html

But I guess it could make sence to allow somekind of easy
configuration of the error handler itself to attach a processor so end
users can run some code before the retry is executed.



>
> Thanks in advance,
> Hari Gangadharan
>
> --
> View this message in context: http://www.nabble.com/Two-questions%3A-Stopping-Camel-and-intercept-before-retry-tp21323127s22882p21323127.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
>



--

/Claus Ibsen
Apache Camel Committer
Blog: http://davsclaus.blogspot.com/
Reply | Threaded
Open this post in threaded view
|

Re: Two questions: Stopping Camel and intercept before retry

Willem.Jiang
Administrator
In reply to this post by Hari Gangadharan
Hi,

Please see my comment in the mail.

harinair wrote:

> Hi All:
>
> Thanks a lot for all the help I have received. We are nearing a production
> implementation of a Camel based messaging system! It was a great experience,
> I learned a lot and we saved a lot of time since I used Camel.
>
> I now have two questions:
>
> 1. I use org.apache.camel.spring.Main to start my standalone Camel context.
> Now how do I stop it? Till now I was killing it. Can I kill it? I guess it
> may not be the right way since I have a feeling that the messages in the
> pipeline (especially the ones that are in Retry processing) is lost.
>

If you take a look at the org.apache.camel.spring.Main, you will find
this Main class has start and stop methods, so you could write your own
manager class which is based on the Spring main.


> 2. I really need to get access to the Message between each retry. I use
> recipientList to forward message to different endpoints based on a header. I
> have also retry rules which make the Endpoint retry a specific number of
> times. In many cases I may have to get control and make some header
> modification of the message before each retry. I could not find any good
> docs on that. Is there any Strategy implementation I can use that can get
> control of the exchange before each retry? If that is not there wouldn't it
> be a good idea to provide a way to intercept messages before each retry?
>
I think you need get to know some detail of the camel ErrorHandler[1][2]
first, then you could write your own DeadLetterChannel[3][4] to add you
what you need to control the exchange before retrying.

> Thanks in advance,
> Hari Gangadharan
>

[1]http://activemq.apache.org/camel/error-handling-in-camel.html
[2]http://activemq.apache.org/camel/error-handler.html
[3]http://activemq.apache.org/camel/dead-letter-channel.html
[4]http://svn.apache.org/repos/asf/activemq/camel/trunk/camel-core/src/main/java/org/apache/camel/processor/DeadLetterChannel.java

Willem

Reply | Threaded
Open this post in threaded view
|

Re: Two questions: Stopping Camel and intercept before retry

Claus Ibsen-2
Hi

I am working on some samples now for this. Will get back later.


On Wed, Jan 7, 2009 at 6:52 AM, Willem Jiang <[hidden email]> wrote:

> Hi,
>
> Please see my comment in the mail.
>
> harinair wrote:
>> Hi All:
>>
>> Thanks a lot for all the help I have received. We are nearing a production
>> implementation of a Camel based messaging system! It was a great experience,
>> I learned a lot and we saved a lot of time since I used Camel.
>>
>> I now have two questions:
>>
>> 1. I use org.apache.camel.spring.Main to start my standalone Camel context.
>> Now how do I stop it? Till now I was killing it. Can I kill it? I guess it
>> may not be the right way since I have a feeling that the messages in the
>> pipeline (especially the ones that are in Retry processing) is lost.
>>
>
> If you take a look at the org.apache.camel.spring.Main, you will find
> this Main class has start and stop methods, so you could write your own
> manager class which is based on the Spring main.
>
>
>> 2. I really need to get access to the Message between each retry. I use
>> recipientList to forward message to different endpoints based on a header. I
>> have also retry rules which make the Endpoint retry a specific number of
>> times. In many cases I may have to get control and make some header
>> modification of the message before each retry. I could not find any good
>> docs on that. Is there any Strategy implementation I can use that can get
>> control of the exchange before each retry? If that is not there wouldn't it
>> be a good idea to provide a way to intercept messages before each retry?
>>
> I think you need get to know some detail of the camel ErrorHandler[1][2]
> first, then you could write your own DeadLetterChannel[3][4] to add you
> what you need to control the exchange before retrying.
>
>> Thanks in advance,
>> Hari Gangadharan
>>
>
> [1]http://activemq.apache.org/camel/error-handling-in-camel.html
> [2]http://activemq.apache.org/camel/error-handler.html
> [3]http://activemq.apache.org/camel/dead-letter-channel.html
> [4]http://svn.apache.org/repos/asf/activemq/camel/trunk/camel-core/src/main/java/org/apache/camel/processor/DeadLetterChannel.java
>
> Willem
>
>



--

/Claus Ibsen
Apache Camel Committer
Blog: http://davsclaus.blogspot.com/
Reply | Threaded
Open this post in threaded view
|

Re: Two questions: Stopping Camel and intercept before retry

Claus Ibsen-2
Hi

I have created a ticket to enhanced this in Camel
https://issues.apache.org/activemq/browse/CAMEL-1234

I have also added a wiki sample with a solution. Albeit not as good as
it will kick in even if the redelivery was a success as long the
redelivery flag is set
But it give the basic idea how to do it.
http://cwiki.apache.org/confluence/display/CAMEL/Dead+Letter+Channel



On Wed, Jan 7, 2009 at 11:52 AM, Claus Ibsen <[hidden email]> wrote:

> Hi
>
> I am working on some samples now for this. Will get back later.
>
>
> On Wed, Jan 7, 2009 at 6:52 AM, Willem Jiang <[hidden email]> wrote:
>> Hi,
>>
>> Please see my comment in the mail.
>>
>> harinair wrote:
>>> Hi All:
>>>
>>> Thanks a lot for all the help I have received. We are nearing a production
>>> implementation of a Camel based messaging system! It was a great experience,
>>> I learned a lot and we saved a lot of time since I used Camel.
>>>
>>> I now have two questions:
>>>
>>> 1. I use org.apache.camel.spring.Main to start my standalone Camel context.
>>> Now how do I stop it? Till now I was killing it. Can I kill it? I guess it
>>> may not be the right way since I have a feeling that the messages in the
>>> pipeline (especially the ones that are in Retry processing) is lost.
>>>
>>
>> If you take a look at the org.apache.camel.spring.Main, you will find
>> this Main class has start and stop methods, so you could write your own
>> manager class which is based on the Spring main.
>>
>>
>>> 2. I really need to get access to the Message between each retry. I use
>>> recipientList to forward message to different endpoints based on a header. I
>>> have also retry rules which make the Endpoint retry a specific number of
>>> times. In many cases I may have to get control and make some header
>>> modification of the message before each retry. I could not find any good
>>> docs on that. Is there any Strategy implementation I can use that can get
>>> control of the exchange before each retry? If that is not there wouldn't it
>>> be a good idea to provide a way to intercept messages before each retry?
>>>
>> I think you need get to know some detail of the camel ErrorHandler[1][2]
>> first, then you could write your own DeadLetterChannel[3][4] to add you
>> what you need to control the exchange before retrying.
>>
>>> Thanks in advance,
>>> Hari Gangadharan
>>>
>>
>> [1]http://activemq.apache.org/camel/error-handling-in-camel.html
>> [2]http://activemq.apache.org/camel/error-handler.html
>> [3]http://activemq.apache.org/camel/dead-letter-channel.html
>> [4]http://svn.apache.org/repos/asf/activemq/camel/trunk/camel-core/src/main/java/org/apache/camel/processor/DeadLetterChannel.java
>>
>> Willem
>>
>>
>
>
>
> --
>
> /Claus Ibsen
> Apache Camel Committer
> Blog: http://davsclaus.blogspot.com/
>



--

/Claus Ibsen
Apache Camel Committer
Blog: http://davsclaus.blogspot.com/
Reply | Threaded
Open this post in threaded view
|

Re: Two questions: Stopping Camel and intercept before retry

Hari Gangadharan
Thanks a lot for the quick reply.

I read your wiki writeup. Doesn't that make the interceptor run on all the subsequent pipelines if the Redelivered flag is not set to null by the Interceptor? Is it OK to set the Redelivered Flag to null? Is that used by any other Camel components?


For stopping Camel gracefully - I did something like this:
in my main():
        org.apache.camel.spring.Main main = new org.apache.camel.spring.Main();
        HangUpInterceptor interceptor = new HangUpInterceptor(main);
        Runtime.getRuntime().addShutdownHook(interceptor);
        main.start();
I also added a HangUpInterceptor:
public class HangUpInterceptor extends Thread {

    Log log = LogFactory.getLog(this.getClass());
    Main main;

    public HangUpInterceptor(Main main) {
        this.main = main;
    }

    public void run() {
        log.info("Recieved hang up - stopping Camel.");
        try {
            main.stop();
        } catch (Exception ex) {
            log.warn("Failure stopping Camel", ex);
        }
    }
}
Now the process goes down gracefully on a kill -HUP.

Regards,
Hari Gangadharan


Claus Ibsen-2 wrote
Hi

I have created a ticket to enhanced this in Camel
https://issues.apache.org/activemq/browse/CAMEL-1234

I have also added a wiki sample with a solution. Albeit not as good as
it will kick in even if the redelivery was a success as long the
redelivery flag is set
But it give the basic idea how to do it.
http://cwiki.apache.org/confluence/display/CAMEL/Dead+Letter+Channel



On Wed, Jan 7, 2009 at 11:52 AM, Claus Ibsen <claus.ibsen@gmail.com> wrote:
> Hi
>
> I am working on some samples now for this. Will get back later.
>
>
> On Wed, Jan 7, 2009 at 6:52 AM, Willem Jiang <willem.jiang@gmail.com> wrote:
>> Hi,
>>
>> Please see my comment in the mail.
>>
>> harinair wrote:
>>> Hi All:
>>>
>>> Thanks a lot for all the help I have received. We are nearing a production
>>> implementation of a Camel based messaging system! It was a great experience,
>>> I learned a lot and we saved a lot of time since I used Camel.
>>>
>>> I now have two questions:
>>>
>>> 1. I use org.apache.camel.spring.Main to start my standalone Camel context.
>>> Now how do I stop it? Till now I was killing it. Can I kill it? I guess it
>>> may not be the right way since I have a feeling that the messages in the
>>> pipeline (especially the ones that are in Retry processing) is lost.
>>>
>>
>> If you take a look at the org.apache.camel.spring.Main, you will find
>> this Main class has start and stop methods, so you could write your own
>> manager class which is based on the Spring main.
>>
>>
>>> 2. I really need to get access to the Message between each retry. I use
>>> recipientList to forward message to different endpoints based on a header. I
>>> have also retry rules which make the Endpoint retry a specific number of
>>> times. In many cases I may have to get control and make some header
>>> modification of the message before each retry. I could not find any good
>>> docs on that. Is there any Strategy implementation I can use that can get
>>> control of the exchange before each retry? If that is not there wouldn't it
>>> be a good idea to provide a way to intercept messages before each retry?
>>>
>> I think you need get to know some detail of the camel ErrorHandler[1][2]
>> first, then you could write your own DeadLetterChannel[3][4] to add you
>> what you need to control the exchange before retrying.
>>
>>> Thanks in advance,
>>> Hari Gangadharan
>>>
>>
>> [1]http://activemq.apache.org/camel/error-handling-in-camel.html
>> [2]http://activemq.apache.org/camel/error-handler.html
>> [3]http://activemq.apache.org/camel/dead-letter-channel.html
>> [4]http://svn.apache.org/repos/asf/activemq/camel/trunk/camel-core/src/main/java/org/apache/camel/processor/DeadLetterChannel.java
>>
>> Willem
>>
>>
>
>
>
> --
>
> /Claus Ibsen
> Apache Camel Committer
> Blog: http://davsclaus.blogspot.com/
>



--

/Claus Ibsen
Apache Camel Committer
Blog: http://davsclaus.blogspot.com/
Reply | Threaded
Open this post in threaded view
|

Re: Two questions: Stopping Camel and intercept before retry

Claus Ibsen-2
On Thu, Jan 8, 2009 at 1:53 AM, harinair <[hidden email]> wrote:
>
> Thanks a lot for the quick reply.
>
> I read your wiki writeup. Doesn't that make the interceptor run on all the
> subsequent pipelines if the Redelivered flag is not set to null by the
> Interceptor? Is it OK to set the Redelivered Flag to null? Is that used by
> any other Camel components?
Hi yeah I think you can clear the flag after you have done your custom
processing, so it wont intercept it again.
Camel should readd if it fails on the next attempt of redelivery. Good idea.

No the flag is for end users to inspect, to notice if the exchange is
being redeliveried. It's not used by other components.

But I will see if I can create a better solution with a nicer
configuration using DLC directly or onException,


>
>
> For stopping Camel gracefully - I did something like this:
> in my main():
>
>
>>         org.apache.camel.spring.Main main = new
>> org.apache.camel.spring.Main();
>>         HangUpInterceptor interceptor = new HangUpInterceptor(main);
>>         Runtime.getRuntime().addShutdownHook(interceptor);
>>         main.start();
>>
>
> I also added a HangUpInterceptor:
>
>
>> public class HangUpInterceptor extends Thread {
>>
>>     Log log = LogFactory.getLog(this.getClass());
>>     Main main;
>>
>>     public HangUpInterceptor(Main main) {
>>         this.main = main;
>>     }
>>
>>     public void run() {
>>         log.info("Recieved hang up - stopping Camel.");
>>         try {
>>             main.stop();
>>         } catch (Exception ex) {
>>             log.warn("Failure stopping Camel", ex);
>>         }
>>     }
>> }
>>
>
> Now the process goes down gracefully on a kill -HUP.
Yeah I thought of a shutdown hook to stop Camel. That should do the trick.


>
> Regards,
> Hari Gangadharan
>
>
>
> Claus Ibsen-2 wrote:
>>
>> Hi
>>
>> I have created a ticket to enhanced this in Camel
>> https://issues.apache.org/activemq/browse/CAMEL-1234
>>
>> I have also added a wiki sample with a solution. Albeit not as good as
>> it will kick in even if the redelivery was a success as long the
>> redelivery flag is set
>> But it give the basic idea how to do it.
>> http://cwiki.apache.org/confluence/display/CAMEL/Dead+Letter+Channel
>>
>>
>>
>> On Wed, Jan 7, 2009 at 11:52 AM, Claus Ibsen <[hidden email]>
>> wrote:
>>> Hi
>>>
>>> I am working on some samples now for this. Will get back later.
>>>
>>>
>>> On Wed, Jan 7, 2009 at 6:52 AM, Willem Jiang <[hidden email]>
>>> wrote:
>>>> Hi,
>>>>
>>>> Please see my comment in the mail.
>>>>
>>>> harinair wrote:
>>>>> Hi All:
>>>>>
>>>>> Thanks a lot for all the help I have received. We are nearing a
>>>>> production
>>>>> implementation of a Camel based messaging system! It was a great
>>>>> experience,
>>>>> I learned a lot and we saved a lot of time since I used Camel.
>>>>>
>>>>> I now have two questions:
>>>>>
>>>>> 1. I use org.apache.camel.spring.Main to start my standalone Camel
>>>>> context.
>>>>> Now how do I stop it? Till now I was killing it. Can I kill it? I guess
>>>>> it
>>>>> may not be the right way since I have a feeling that the messages in
>>>>> the
>>>>> pipeline (especially the ones that are in Retry processing) is lost.
>>>>>
>>>>
>>>> If you take a look at the org.apache.camel.spring.Main, you will find
>>>> this Main class has start and stop methods, so you could write your own
>>>> manager class which is based on the Spring main.
>>>>
>>>>
>>>>> 2. I really need to get access to the Message between each retry. I use
>>>>> recipientList to forward message to different endpoints based on a
>>>>> header. I
>>>>> have also retry rules which make the Endpoint retry a specific number
>>>>> of
>>>>> times. In many cases I may have to get control and make some header
>>>>> modification of the message before each retry. I could not find any
>>>>> good
>>>>> docs on that. Is there any Strategy implementation I can use that can
>>>>> get
>>>>> control of the exchange before each retry? If that is not there
>>>>> wouldn't it
>>>>> be a good idea to provide a way to intercept messages before each
>>>>> retry?
>>>>>
>>>> I think you need get to know some detail of the camel ErrorHandler[1][2]
>>>> first, then you could write your own DeadLetterChannel[3][4] to add you
>>>> what you need to control the exchange before retrying.
>>>>
>>>>> Thanks in advance,
>>>>> Hari Gangadharan
>>>>>
>>>>
>>>> [1]http://activemq.apache.org/camel/error-handling-in-camel.html
>>>> [2]http://activemq.apache.org/camel/error-handler.html
>>>> [3]http://activemq.apache.org/camel/dead-letter-channel.html
>>>> [4]http://svn.apache.org/repos/asf/activemq/camel/trunk/camel-core/src/main/java/org/apache/camel/processor/DeadLetterChannel.java
>>>>
>>>> Willem
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>>
>>> /Claus Ibsen
>>> Apache Camel Committer
>>> Blog: http://davsclaus.blogspot.com/
>>>
>>
>>
>>
>> --
>>
>> /Claus Ibsen
>> Apache Camel Committer
>> Blog: http://davsclaus.blogspot.com/
>>
>>
>
> --
> View this message in context: http://www.nabble.com/Two-questions%3A-Stopping-Camel-and-intercept-before-retry-tp21323127s22882p21343817.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
>



--

/Claus Ibsen
Apache Camel Committer
Blog: http://davsclaus.blogspot.com/
Reply | Threaded
Open this post in threaded view
|

Re: Two questions: Stopping Camel and intercept before retry

Hari Gangadharan
Claus:

Thanks once again - I will do that. So that my interceptor is called only once.

Do you think it is a good idea to add this shutdown hook to the Main.main()? In that I can remove my main() and the HangUpInterceptor. I can also make that modification and submit. I think I have to sign the Apache Development agreement or something? I will do that too.

PS: I just noticed that the DEAD LETTER CHANNEL Wiki page seems to be updated incorrectly. The new section you added is missing. Take a look.

Regards,
Hari Gangadharan


Claus Ibsen-2 wrote
On Thu, Jan 8, 2009 at 1:53 AM, harinair <hari_g@hotmail.com> wrote:
>
> Thanks a lot for the quick reply.
>
> I read your wiki writeup. Doesn't that make the interceptor run on all the
> subsequent pipelines if the Redelivered flag is not set to null by the
> Interceptor? Is it OK to set the Redelivered Flag to null? Is that used by
> any other Camel components?
Hi yeah I think you can clear the flag after you have done your custom
processing, so it wont intercept it again.
Camel should readd if it fails on the next attempt of redelivery. Good idea.

No the flag is for end users to inspect, to notice if the exchange is
being redeliveried. It's not used by other components.

But I will see if I can create a better solution with a nicer
configuration using DLC directly or onException,


>
>
> For stopping Camel gracefully - I did something like this:
> in my main():
>
>
>>         org.apache.camel.spring.Main main = new
>> org.apache.camel.spring.Main();
>>         HangUpInterceptor interceptor = new HangUpInterceptor(main);
>>         Runtime.getRuntime().addShutdownHook(interceptor);
>>         main.start();
>>
>
> I also added a HangUpInterceptor:
>
>
>> public class HangUpInterceptor extends Thread {
>>
>>     Log log = LogFactory.getLog(this.getClass());
>>     Main main;
>>
>>     public HangUpInterceptor(Main main) {
>>         this.main = main;
>>     }
>>
>>     public void run() {
>>         log.info("Recieved hang up - stopping Camel.");
>>         try {
>>             main.stop();
>>         } catch (Exception ex) {
>>             log.warn("Failure stopping Camel", ex);
>>         }
>>     }
>> }
>>
>
> Now the process goes down gracefully on a kill -HUP.
Yeah I thought of a shutdown hook to stop Camel. That should do the trick.


>
> Regards,
> Hari Gangadharan
>
>
>
> Claus Ibsen-2 wrote:
>>
>> Hi
>>
>> I have created a ticket to enhanced this in Camel
>> https://issues.apache.org/activemq/browse/CAMEL-1234
>>
>> I have also added a wiki sample with a solution. Albeit not as good as
>> it will kick in even if the redelivery was a success as long the
>> redelivery flag is set
>> But it give the basic idea how to do it.
>> http://cwiki.apache.org/confluence/display/CAMEL/Dead+Letter+Channel
>>
>>
>>
>> On Wed, Jan 7, 2009 at 11:52 AM, Claus Ibsen <claus.ibsen@gmail.com>
>> wrote:
>>> Hi
>>>
>>> I am working on some samples now for this. Will get back later.
>>>
>>>
>>> On Wed, Jan 7, 2009 at 6:52 AM, Willem Jiang <willem.jiang@gmail.com>
>>> wrote:
>>>> Hi,
>>>>
>>>> Please see my comment in the mail.
>>>>
>>>> harinair wrote:
>>>>> Hi All:
>>>>>
>>>>> Thanks a lot for all the help I have received. We are nearing a
>>>>> production
>>>>> implementation of a Camel based messaging system! It was a great
>>>>> experience,
>>>>> I learned a lot and we saved a lot of time since I used Camel.
>>>>>
>>>>> I now have two questions:
>>>>>
>>>>> 1. I use org.apache.camel.spring.Main to start my standalone Camel
>>>>> context.
>>>>> Now how do I stop it? Till now I was killing it. Can I kill it? I guess
>>>>> it
>>>>> may not be the right way since I have a feeling that the messages in
>>>>> the
>>>>> pipeline (especially the ones that are in Retry processing) is lost.
>>>>>
>>>>
>>>> If you take a look at the org.apache.camel.spring.Main, you will find
>>>> this Main class has start and stop methods, so you could write your own
>>>> manager class which is based on the Spring main.
>>>>
>>>>
>>>>> 2. I really need to get access to the Message between each retry. I use
>>>>> recipientList to forward message to different endpoints based on a
>>>>> header. I
>>>>> have also retry rules which make the Endpoint retry a specific number
>>>>> of
>>>>> times. In many cases I may have to get control and make some header
>>>>> modification of the message before each retry. I could not find any
>>>>> good
>>>>> docs on that. Is there any Strategy implementation I can use that can
>>>>> get
>>>>> control of the exchange before each retry? If that is not there
>>>>> wouldn't it
>>>>> be a good idea to provide a way to intercept messages before each
>>>>> retry?
>>>>>
>>>> I think you need get to know some detail of the camel ErrorHandler[1][2]
>>>> first, then you could write your own DeadLetterChannel[3][4] to add you
>>>> what you need to control the exchange before retrying.
>>>>
>>>>> Thanks in advance,
>>>>> Hari Gangadharan
>>>>>
>>>>
>>>> [1]http://activemq.apache.org/camel/error-handling-in-camel.html
>>>> [2]http://activemq.apache.org/camel/error-handler.html
>>>> [3]http://activemq.apache.org/camel/dead-letter-channel.html
>>>> [4]http://svn.apache.org/repos/asf/activemq/camel/trunk/camel-core/src/main/java/org/apache/camel/processor/DeadLetterChannel.java
>>>>
>>>> Willem
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>>
>>> /Claus Ibsen
>>> Apache Camel Committer
>>> Blog: http://davsclaus.blogspot.com/
>>>
>>
>>
>>
>> --
>>
>> /Claus Ibsen
>> Apache Camel Committer
>> Blog: http://davsclaus.blogspot.com/
>>
>>
>
> --
> View this message in context: http://www.nabble.com/Two-questions%3A-Stopping-Camel-and-intercept-before-retry-tp21323127s22882p21343817.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
>



--

/Claus Ibsen
Apache Camel Committer
Blog: http://davsclaus.blogspot.com/
Reply | Threaded
Open this post in threaded view
|

Re: Two questions: Stopping Camel and intercept before retry

Claus Ibsen-2
On Thu, Jan 8, 2009 at 8:25 PM, harinair <[hidden email]> wrote:

>
> Claus:
>
> Thanks once again - I will do that. So that my interceptor is called only
> once.
>
> Do you think it is a good idea to add this shutdown hook to the Main.main()?
> In that I can remove my main() and the HangUpInterceptor. I can also make
> that modification and submit. I think I have to sign the Apache Development
> agreement or something? I will do that too.
Yeah that is a nice place then its added at the beginning.

See contributing
http://activemq.apache.org/camel/contributing.html

For submitting patches you dont need to sign the Apache CLA. Just
remember to tick [x] in the grant ASF license when you attach a file
to the ticket in JIRA.



>
> PS: I just noticed that the DEAD LETTER CHANNEL Wiki page seems to be
> updated incorrectly. The new section you added is missing. Take a look.
The static wiki pages takes some time before they are updated with the
latest changes.

PS: I am about to commit the onRedelivery feature in Camel 1.5.1 so it
will be there out-of-the-box in the future release.


>
> Regards,
> Hari Gangadharan
>
>
>
> Claus Ibsen-2 wrote:
>>
>> On Thu, Jan 8, 2009 at 1:53 AM, harinair <[hidden email]> wrote:
>>>
>>> Thanks a lot for the quick reply.
>>>
>>> I read your wiki writeup. Doesn't that make the interceptor run on all
>>> the
>>> subsequent pipelines if the Redelivered flag is not set to null by the
>>> Interceptor? Is it OK to set the Redelivered Flag to null? Is that used
>>> by
>>> any other Camel components?
>> Hi yeah I think you can clear the flag after you have done your custom
>> processing, so it wont intercept it again.
>> Camel should readd if it fails on the next attempt of redelivery. Good
>> idea.
>>
>> No the flag is for end users to inspect, to notice if the exchange is
>> being redeliveried. It's not used by other components.
>>
>> But I will see if I can create a better solution with a nicer
>> configuration using DLC directly or onException,
>>
>>
>>>
>>>
>>> For stopping Camel gracefully - I did something like this:
>>> in my main():
>>>
>>>
>>>>         org.apache.camel.spring.Main main = new
>>>> org.apache.camel.spring.Main();
>>>>         HangUpInterceptor interceptor = new HangUpInterceptor(main);
>>>>         Runtime.getRuntime().addShutdownHook(interceptor);
>>>>         main.start();
>>>>
>>>
>>> I also added a HangUpInterceptor:
>>>
>>>
>>>> public class HangUpInterceptor extends Thread {
>>>>
>>>>     Log log = LogFactory.getLog(this.getClass());
>>>>     Main main;
>>>>
>>>>     public HangUpInterceptor(Main main) {
>>>>         this.main = main;
>>>>     }
>>>>
>>>>     public void run() {
>>>>         log.info("Recieved hang up - stopping Camel.");
>>>>         try {
>>>>             main.stop();
>>>>         } catch (Exception ex) {
>>>>             log.warn("Failure stopping Camel", ex);
>>>>         }
>>>>     }
>>>> }
>>>>
>>>
>>> Now the process goes down gracefully on a kill -HUP.
>> Yeah I thought of a shutdown hook to stop Camel. That should do the trick.
>>
>>
>>>
>>> Regards,
>>> Hari Gangadharan
>>>
>>>
>>>
>>> Claus Ibsen-2 wrote:
>>>>
>>>> Hi
>>>>
>>>> I have created a ticket to enhanced this in Camel
>>>> https://issues.apache.org/activemq/browse/CAMEL-1234
>>>>
>>>> I have also added a wiki sample with a solution. Albeit not as good as
>>>> it will kick in even if the redelivery was a success as long the
>>>> redelivery flag is set
>>>> But it give the basic idea how to do it.
>>>> http://cwiki.apache.org/confluence/display/CAMEL/Dead+Letter+Channel
>>>>
>>>>
>>>>
>>>> On Wed, Jan 7, 2009 at 11:52 AM, Claus Ibsen <[hidden email]>
>>>> wrote:
>>>>> Hi
>>>>>
>>>>> I am working on some samples now for this. Will get back later.
>>>>>
>>>>>
>>>>> On Wed, Jan 7, 2009 at 6:52 AM, Willem Jiang <[hidden email]>
>>>>> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Please see my comment in the mail.
>>>>>>
>>>>>> harinair wrote:
>>>>>>> Hi All:
>>>>>>>
>>>>>>> Thanks a lot for all the help I have received. We are nearing a
>>>>>>> production
>>>>>>> implementation of a Camel based messaging system! It was a great
>>>>>>> experience,
>>>>>>> I learned a lot and we saved a lot of time since I used Camel.
>>>>>>>
>>>>>>> I now have two questions:
>>>>>>>
>>>>>>> 1. I use org.apache.camel.spring.Main to start my standalone Camel
>>>>>>> context.
>>>>>>> Now how do I stop it? Till now I was killing it. Can I kill it? I
>>>>>>> guess
>>>>>>> it
>>>>>>> may not be the right way since I have a feeling that the messages in
>>>>>>> the
>>>>>>> pipeline (especially the ones that are in Retry processing) is lost.
>>>>>>>
>>>>>>
>>>>>> If you take a look at the org.apache.camel.spring.Main, you will find
>>>>>> this Main class has start and stop methods, so you could write your
>>>>>> own
>>>>>> manager class which is based on the Spring main.
>>>>>>
>>>>>>
>>>>>>> 2. I really need to get access to the Message between each retry. I
>>>>>>> use
>>>>>>> recipientList to forward message to different endpoints based on a
>>>>>>> header. I
>>>>>>> have also retry rules which make the Endpoint retry a specific number
>>>>>>> of
>>>>>>> times. In many cases I may have to get control and make some header
>>>>>>> modification of the message before each retry. I could not find any
>>>>>>> good
>>>>>>> docs on that. Is there any Strategy implementation I can use that can
>>>>>>> get
>>>>>>> control of the exchange before each retry? If that is not there
>>>>>>> wouldn't it
>>>>>>> be a good idea to provide a way to intercept messages before each
>>>>>>> retry?
>>>>>>>
>>>>>> I think you need get to know some detail of the camel
>>>>>> ErrorHandler[1][2]
>>>>>> first, then you could write your own DeadLetterChannel[3][4] to add
>>>>>> you
>>>>>> what you need to control the exchange before retrying.
>>>>>>
>>>>>>> Thanks in advance,
>>>>>>> Hari Gangadharan
>>>>>>>
>>>>>>
>>>>>> [1]http://activemq.apache.org/camel/error-handling-in-camel.html
>>>>>> [2]http://activemq.apache.org/camel/error-handler.html
>>>>>> [3]http://activemq.apache.org/camel/dead-letter-channel.html
>>>>>> [4]http://svn.apache.org/repos/asf/activemq/camel/trunk/camel-core/src/main/java/org/apache/camel/processor/DeadLetterChannel.java
>>>>>>
>>>>>> Willem
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> /Claus Ibsen
>>>>> Apache Camel Committer
>>>>> Blog: http://davsclaus.blogspot.com/
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> /Claus Ibsen
>>>> Apache Camel Committer
>>>> Blog: http://davsclaus.blogspot.com/
>>>>
>>>>
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Two-questions%3A-Stopping-Camel-and-intercept-before-retry-tp21323127s22882p21343817.html
>>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>>
>>>
>>
>>
>>
>> --
>>
>> /Claus Ibsen
>> Apache Camel Committer
>> Blog: http://davsclaus.blogspot.com/
>>
>>
>
> --
> View this message in context: http://www.nabble.com/Two-questions%3A-Stopping-Camel-and-intercept-before-retry-tp21323127s22882p21359117.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
>



--

/Claus Ibsen
Apache Camel Committer
Blog: http://davsclaus.blogspot.com/
Reply | Threaded
Open this post in threaded view
|

Re: Two questions: Stopping Camel and intercept before retry

Hari Gangadharan
Claus:

I have added a JIRA issue for Hangup support. Also attached a patch file and two new java files.
https://issues.apache.org/activemq/browse/CAMEL-1244

I am fairly new in this so I hope I did not screw-up anything.
Regards,
Hari Gangadharan


Claus Ibsen-2 wrote
On Thu, Jan 8, 2009 at 8:25 PM, harinair <hari_g@hotmail.com> wrote:
>
> Claus:
>
> Thanks once again - I will do that. So that my interceptor is called only
> once.
>
> Do you think it is a good idea to add this shutdown hook to the Main.main()?
> In that I can remove my main() and the HangUpInterceptor. I can also make
> that modification and submit. I think I have to sign the Apache Development
> agreement or something? I will do that too.
Yeah that is a nice place then its added at the beginning.

See contributing
http://activemq.apache.org/camel/contributing.html

For submitting patches you dont need to sign the Apache CLA. Just
remember to tick [x] in the grant ASF license when you attach a file
to the ticket in JIRA.



>
> PS: I just noticed that the DEAD LETTER CHANNEL Wiki page seems to be
> updated incorrectly. The new section you added is missing. Take a look.
The static wiki pages takes some time before they are updated with the
latest changes.

PS: I am about to commit the onRedelivery feature in Camel 1.5.1 so it
will be there out-of-the-box in the future release.


>
> Regards,
> Hari Gangadharan
>
>
>
> Claus Ibsen-2 wrote:
>>
>> On Thu, Jan 8, 2009 at 1:53 AM, harinair <hari_g@hotmail.com> wrote:
>>>
>>> Thanks a lot for the quick reply.
>>>
>>> I read your wiki writeup. Doesn't that make the interceptor run on all
>>> the
>>> subsequent pipelines if the Redelivered flag is not set to null by the
>>> Interceptor? Is it OK to set the Redelivered Flag to null? Is that used
>>> by
>>> any other Camel components?
>> Hi yeah I think you can clear the flag after you have done your custom
>> processing, so it wont intercept it again.
>> Camel should readd if it fails on the next attempt of redelivery. Good
>> idea.
>>
>> No the flag is for end users to inspect, to notice if the exchange is
>> being redeliveried. It's not used by other components.
>>
>> But I will see if I can create a better solution with a nicer
>> configuration using DLC directly or onException,
>>
>>
>>>
>>>
>>> For stopping Camel gracefully - I did something like this:
>>> in my main():
>>>
>>>
>>>>         org.apache.camel.spring.Main main = new
>>>> org.apache.camel.spring.Main();
>>>>         HangUpInterceptor interceptor = new HangUpInterceptor(main);
>>>>         Runtime.getRuntime().addShutdownHook(interceptor);
>>>>         main.start();
>>>>
>>>
>>> I also added a HangUpInterceptor:
>>>
>>>
>>>> public class HangUpInterceptor extends Thread {
>>>>
>>>>     Log log = LogFactory.getLog(this.getClass());
>>>>     Main main;
>>>>
>>>>     public HangUpInterceptor(Main main) {
>>>>         this.main = main;
>>>>     }
>>>>
>>>>     public void run() {
>>>>         log.info("Recieved hang up - stopping Camel.");
>>>>         try {
>>>>             main.stop();
>>>>         } catch (Exception ex) {
>>>>             log.warn("Failure stopping Camel", ex);
>>>>         }
>>>>     }
>>>> }
>>>>
>>>
>>> Now the process goes down gracefully on a kill -HUP.
>> Yeah I thought of a shutdown hook to stop Camel. That should do the trick.
>>
>>
>>>
>>> Regards,
>>> Hari Gangadharan
>>>
>>>
>>>
>>> Claus Ibsen-2 wrote:
>>>>
>>>> Hi
>>>>
>>>> I have created a ticket to enhanced this in Camel
>>>> https://issues.apache.org/activemq/browse/CAMEL-1234
>>>>
>>>> I have also added a wiki sample with a solution. Albeit not as good as
>>>> it will kick in even if the redelivery was a success as long the
>>>> redelivery flag is set
>>>> But it give the basic idea how to do it.
>>>> http://cwiki.apache.org/confluence/display/CAMEL/Dead+Letter+Channel
>>>>
>>>>
>>>>
>>>> On Wed, Jan 7, 2009 at 11:52 AM, Claus Ibsen <claus.ibsen@gmail.com>
>>>> wrote:
>>>>> Hi
>>>>>
>>>>> I am working on some samples now for this. Will get back later.
>>>>>
>>>>>
>>>>> On Wed, Jan 7, 2009 at 6:52 AM, Willem Jiang <willem.jiang@gmail.com>
>>>>> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Please see my comment in the mail.
>>>>>>
>>>>>> harinair wrote:
>>>>>>> Hi All:
>>>>>>>
>>>>>>> Thanks a lot for all the help I have received. We are nearing a
>>>>>>> production
>>>>>>> implementation of a Camel based messaging system! It was a great
>>>>>>> experience,
>>>>>>> I learned a lot and we saved a lot of time since I used Camel.
>>>>>>>
>>>>>>> I now have two questions:
>>>>>>>
>>>>>>> 1. I use org.apache.camel.spring.Main to start my standalone Camel
>>>>>>> context.
>>>>>>> Now how do I stop it? Till now I was killing it. Can I kill it? I
>>>>>>> guess
>>>>>>> it
>>>>>>> may not be the right way since I have a feeling that the messages in
>>>>>>> the
>>>>>>> pipeline (especially the ones that are in Retry processing) is lost.
>>>>>>>
>>>>>>
>>>>>> If you take a look at the org.apache.camel.spring.Main, you will find
>>>>>> this Main class has start and stop methods, so you could write your
>>>>>> own
>>>>>> manager class which is based on the Spring main.
>>>>>>
>>>>>>
>>>>>>> 2. I really need to get access to the Message between each retry. I
>>>>>>> use
>>>>>>> recipientList to forward message to different endpoints based on a
>>>>>>> header. I
>>>>>>> have also retry rules which make the Endpoint retry a specific number
>>>>>>> of
>>>>>>> times. In many cases I may have to get control and make some header
>>>>>>> modification of the message before each retry. I could not find any
>>>>>>> good
>>>>>>> docs on that. Is there any Strategy implementation I can use that can
>>>>>>> get
>>>>>>> control of the exchange before each retry? If that is not there
>>>>>>> wouldn't it
>>>>>>> be a good idea to provide a way to intercept messages before each
>>>>>>> retry?
>>>>>>>
>>>>>> I think you need get to know some detail of the camel
>>>>>> ErrorHandler[1][2]
>>>>>> first, then you could write your own DeadLetterChannel[3][4] to add
>>>>>> you
>>>>>> what you need to control the exchange before retrying.
>>>>>>
>>>>>>> Thanks in advance,
>>>>>>> Hari Gangadharan
>>>>>>>
>>>>>>
>>>>>> [1]http://activemq.apache.org/camel/error-handling-in-camel.html
>>>>>> [2]http://activemq.apache.org/camel/error-handler.html
>>>>>> [3]http://activemq.apache.org/camel/dead-letter-channel.html
>>>>>> [4]http://svn.apache.org/repos/asf/activemq/camel/trunk/camel-core/src/main/java/org/apache/camel/processor/DeadLetterChannel.java
>>>>>>
>>>>>> Willem
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> /Claus Ibsen
>>>>> Apache Camel Committer
>>>>> Blog: http://davsclaus.blogspot.com/
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> /Claus Ibsen
>>>> Apache Camel Committer
>>>> Blog: http://davsclaus.blogspot.com/
>>>>
>>>>
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Two-questions%3A-Stopping-Camel-and-intercept-before-retry-tp21323127s22882p21343817.html
>>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>>
>>>
>>
>>
>>
>> --
>>
>> /Claus Ibsen
>> Apache Camel Committer
>> Blog: http://davsclaus.blogspot.com/
>>
>>
>
> --
> View this message in context: http://www.nabble.com/Two-questions%3A-Stopping-Camel-and-intercept-before-retry-tp21323127s22882p21359117.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
>



--

/Claus Ibsen
Apache Camel Committer
Blog: http://davsclaus.blogspot.com/
Reply | Threaded
Open this post in threaded view
|

Re: Two questions: Stopping Camel and intercept before retry

Semir Elezovikj
In the doStop() method of org.apache.camel.spring.Main class the application context is closed.
What will this actually do ?
Let us say in my camel-server.xml file, I have definitions for an activemq broker running on port 61616.
When I close the application context the broker does not shutdown.
What does closing the application context result with ?
Reply | Threaded
Open this post in threaded view
|

Re: Two questions: Stopping Camel and intercept before retry

Hari Gangadharan
So that the Camel router is shutdown for the maintenance or upgrade. There is no need to shutdown your broker with Camel. Right? For my case my broker services many other applications including the Camel based message router. I can independently stop each other but if I stop Message Broker then Camel logs shows Exceptions... hence in that case I may stop the Camel first and then the Broker.

Probably you have this question since you run Camel within the Apache ActiveMQ broker?

Hari Gangadharan

selezovikj wrote
In the doStop() method of org.apache.camel.spring.Main class the application context is closed.
What will this actually do ?
Let us say in my camel-server.xml file, I have definitions for an activemq broker running on port 61616.
When I close the application context the broker does not shutdown.
What does closing the application context result with ?
Reply | Threaded
Open this post in threaded view
|

Re: Two questions: Stopping Camel and intercept before retry

Claus Ibsen-2
Hi

You can use JMX to start/stop CamelContext. We have it on the roadmap
for Camel 2.x to let Camel be much more dynamic manageable at runtime
to add/remove/pause producers/consumers etc. But stopping and starting
a CamelContext should be doable.

The Main in camel-spring is usually for running Camel during
development or testing using camel:run or running Camel standalone.

At production Camel is usually embedded in some sort of container:
- AMQ
- SMX
- Tomcat
- OSGi
- J2EE
- etc.

On Fri, Jan 16, 2009 at 9:13 AM, harinair <[hidden email]> wrote:

>
> So that the Camel router is shutdown for the maintenance or upgrade. There is
> no need to shutdown your broker with Camel. Right? For my case my broker
> services many other applications including the Camel based message router. I
> can independently stop each other but if I stop Message Broker then Camel
> logs shows Exceptions... hence in that case I may stop the Camel first and
> then the Broker.
>
> Probably you have this question since you run Camel within the Apache
> ActiveMQ broker?
>
> Hari Gangadharan
>
>
> selezovikj wrote:
>>
>> In the doStop() method of org.apache.camel.spring.Main class the
>> application context is closed.
>> What will this actually do ?
>> Let us say in my camel-server.xml file, I have definitions for an activemq
>> broker running on port 61616.
>> When I close the application context the broker does not shutdown.
>> What does closing the application context result with ?
>>
>>
>
> --
> View this message in context: http://www.nabble.com/Two-questions%3A-Stopping-Camel-and-intercept-before-retry-tp21323127s22882p21494364.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
>



--
-------
Claus Ibsen
Apache Camel Committer

Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Reply | Threaded
Open this post in threaded view
|

Re: Two questions: Stopping Camel and intercept before retry

Semir Elezovikj
In reply to this post by Hari Gangadharan
My question is how to gracefully stop this instance:

org.apache.camel.spring.Main -ac file.xml

In this file.xml I have definitions for starting an activemq broker on port 61616.

I expect that if in my Java code I call Main.getInstance.getApplicationContext.close() this will close camel and since this instance started the activemq broker, the shutting down of the broker will be taken care of automatically.

Is this the way to gracefully stop this instance ?

harinair wrote
So that the Camel router is shutdown for the maintenance or upgrade. There is no need to shutdown your broker with Camel. Right? For my case my broker services many other applications including the Camel based message router. I can independently stop each other but if I stop Message Broker then Camel logs shows Exceptions... hence in that case I may stop the Camel first and then the Broker.

Probably you have this question since you run Camel within the Apache ActiveMQ broker?

Hari Gangadharan

selezovikj wrote
In the doStop() method of org.apache.camel.spring.Main class the application context is closed.
What will this actually do ?
Let us say in my camel-server.xml file, I have definitions for an activemq broker running on port 61616.
When I close the application context the broker does not shutdown.
What does closing the application context result with ?