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 <har...@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.ib...@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.ji...@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.
