Re: Multicast, redelivery and error handlers

2012-09-13 Thread jimbogaz 
That's great, I've got the book now, I'll go read and write te code.
Thanks again.
J
On Sep 13, 2012 1:32 PM, "Claus Ibsen-2 [via Camel]" <
ml-node+s465427n5719269...@n5.nabble.com> wrote:

> On Thu, Sep 13, 2012 at 9:04 AM, jimbogaz <[hidden 
> email]>
> wrote:
> > Thanks for the fast response Claus.  I figured that must have been the
> > case, which is why I then tried implementing the timeout method on a
> > TimeoutAwareAggregator.  I thought if I called setException there (just
> > with a plain new Exception) then that might trigger the error handler.
> >
>
> The multicast EIP is not designed to redelivery "all over again".
> If an exception occurs during processing one of the N multicasted
> message, then error handling occurs only for that particular message.
>
> When timeout is hit it does not cause any exception and therefore
> continue routing.
> So even if you set an exception in the timeout aware aggregator, then
> the EIP was not designed
> to cause error handling to redeliver from the start again.
>
> Its also a bit unusual to retry again, as when timeout is hit, the
> current in-flight message is still being processed.
> They are not instant cancelled, as that is not easily doable in Java.
>
> If you have a copy of Camel in Action then its most likely easier for
> you to do something alike show on page 349, starting section from page
> 357.
> eg use some java code and deal with timeout and retry yourself. Then
> you can also have individual timeout settings etc.
>
>
> > I should describe that what I want to happen is that either the whole
> > multicast tries again, or perhaps just the one that timed out.  Is there
> a
> > different way of achieving that?
> > Thanks again,
> > James
> > On Sep 13, 2012 8:43 AM, "Claus Ibsen-2 [via Camel]" <
> > [hidden email] >
> wrote:
> >
> >> There is no exception occurring. And therefore the error handler does
> >> not redeliver anything.
> >> If the timeout is hit on the multicast, then yes the multicast will
> >> aggregate what it currently has, and continue routing.
> >>
> >>
> >>
> >> On Wed, Sep 12, 2012 at 10:37 PM, jimbogaz <[hidden email]<
> http://user/SendEmail.jtp?type=node&node=5719232&i=0>>
> >> wrote:
> >>
> >> > Hi all.
> >> >
> >> > I think I'm missing something obvious, but I can't find anything here
> >> that
> >> > is similar to my problem, or any docs that tell me "it's obvious
> James
> >> you
> >> > twerp":
> >> >
> >> > I've put together a route that multicasts to three direct routes,
> which
> >> > simply return setBody type responses.  I have intentionally made one
> of
> >> them
> >> > take longer than the timeout on the multicast, with the intention
> that
> >> the
> >> > error handler retries the request.  It doesn't.  I have tried with
> both
> >> > having a TimeoutAwareAggregationStrategy with a setException (which I
> >> > thought would automatically invoke the error handler), and with just
> a
> >> plain
> >> > AggregationStrategy.
> >> >
> >> > I'm on Camel 2.9.3, and below are my (sanitised to protect my client)
> >> > sections from beans.xml and my main method...  can anybody tell me
> where
> >> I'm
> >> > epic failing?
> >> >
> >> >
> >> > public static void main(String... args) throws Exception {
> >> > ApplicationContext appContext = new
> >> > ClassPathXmlApplicationContext("beans.xml");
> >> > LOG.info("Initialised Application Context");
> >> > CamelContext camelContext =
> appContext.getBean("camel-context",
> >> > CamelContext.class);
> >> > ProducerTemplate producerTemplate =
> >> > camelContext.createProducerTemplate();
> >> > producerTemplate.asyncCallbackRequestBody("direct:blah",
> >> > "James[hidden email]<
> http://user/SendEmail.jtp?type=node&node=5719232&i=1>",
> >> callback);
> >> > Thread.sleep(15000);
> >> > LOG.info("FINISHED");
> >> > }
> >> >
> >> >>> > xmlns="http://camel.apache.org/schema/spring";>
> >> > com.rightmess.camel
> >> >
> >> > 
> >> >  >> > retryAttemptedLogLevel="WARN" redeliveryDelay="200"/>
> >> > 
> >> > 
> >> >   
> >> >>> >parallelProcessing="true" streaming="true"
> >> timeout="700">
> >> > 
> >> > 
> >> > 
> >> >   
> >> > 
> >> > 
> >> > 
> >> >
> 233
> >> >
> >> >
> >>
> 15/04/1868
> >> > 
> >> > 
> >> > 
> >> >
> 1500
> >> >
> >> >
> >>
> Starbucks
> >> > 
> >> > 
> >> > 
> >> > 
> >> >
> 233
> >> >
> >> >
> >>
> 0982734786238746
>
> >>
> >> > 
> >> >   
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > --
> >> > View this message in context:
> >>
> http://camel.465427.n5.nabble.com/Multicast-redelivery-and-error-handlers-tp5719208.html
> >> > Sent from the Camel - Users mailing list archive at Nabble.com.
> >>
> >>
> >>
> >> --
> >> Claus Ibsen
> >> --

Re: Multicast, redelivery and error handlers

2012-09-13 Thread Claus Ibsen 
On Thu, Sep 13, 2012 at 9:04 AM, jimbogaz  wrote:
> Thanks for the fast response Claus.  I figured that must have been the
> case, which is why I then tried implementing the timeout method on a
> TimeoutAwareAggregator.  I thought if I called setException there (just
> with a plain new Exception) then that might trigger the error handler.
>

The multicast EIP is not designed to redelivery "all over again".
If an exception occurs during processing one of the N multicasted
message, then error handling occurs only for that particular message.

When timeout is hit it does not cause any exception and therefore
continue routing.
So even if you set an exception in the timeout aware aggregator, then
the EIP was not designed
to cause error handling to redeliver from the start again.

Its also a bit unusual to retry again, as when timeout is hit, the
current in-flight message is still being processed.
They are not instant cancelled, as that is not easily doable in Java.

If you have a copy of Camel in Action then its most likely easier for
you to do something alike show on page 349, starting section from page
357.
eg use some java code and deal with timeout and retry yourself. Then
you can also have individual timeout settings etc.


> I should describe that what I want to happen is that either the whole
> multicast tries again, or perhaps just the one that timed out.  Is there a
> different way of achieving that?
> Thanks again,
> James
> On Sep 13, 2012 8:43 AM, "Claus Ibsen-2 [via Camel]" <
> ml-node+s465427n5719232...@n5.nabble.com> wrote:
>
>> There is no exception occurring. And therefore the error handler does
>> not redeliver anything.
>> If the timeout is hit on the multicast, then yes the multicast will
>> aggregate what it currently has, and continue routing.
>>
>>
>>
>> On Wed, Sep 12, 2012 at 10:37 PM, jimbogaz <[hidden 
>> email]>
>> wrote:
>>
>> > Hi all.
>> >
>> > I think I'm missing something obvious, but I can't find anything here
>> that
>> > is similar to my problem, or any docs that tell me "it's obvious James
>> you
>> > twerp":
>> >
>> > I've put together a route that multicasts to three direct routes, which
>> > simply return setBody type responses.  I have intentionally made one of
>> them
>> > take longer than the timeout on the multicast, with the intention that
>> the
>> > error handler retries the request.  It doesn't.  I have tried with both
>> > having a TimeoutAwareAggregationStrategy with a setException (which I
>> > thought would automatically invoke the error handler), and with just a
>> plain
>> > AggregationStrategy.
>> >
>> > I'm on Camel 2.9.3, and below are my (sanitised to protect my client)
>> > sections from beans.xml and my main method...  can anybody tell me where
>> I'm
>> > epic failing?
>> >
>> >
>> > public static void main(String... args) throws Exception {
>> > ApplicationContext appContext = new
>> > ClassPathXmlApplicationContext("beans.xml");
>> > LOG.info("Initialised Application Context");
>> > CamelContext camelContext = appContext.getBean("camel-context",
>> > CamelContext.class);
>> > ProducerTemplate producerTemplate =
>> > camelContext.createProducerTemplate();
>> > producerTemplate.asyncCallbackRequestBody("direct:blah",
>> > "James[hidden 
>> > email]",
>> callback);
>> > Thread.sleep(15000);
>> > LOG.info("FINISHED");
>> > }
>> >
>> >   > > xmlns="http://camel.apache.org/schema/spring";>
>> > com.rightmess.camel
>> >
>> > 
>> > > > retryAttemptedLogLevel="WARN" redeliveryDelay="200"/>
>> > 
>> > 
>> >   
>> >   > >parallelProcessing="true" streaming="true"
>> timeout="700">
>> > 
>> > 
>> > 
>> >   
>> > 
>> > 
>> > 
>> > 233
>> >
>> >
>> 15/04/1868
>> > 
>> > 
>> > 
>> > 1500
>> >
>> >
>> Starbucks
>> > 
>> > 
>> > 
>> > 
>> > 233
>> >
>> >
>> 0982734786238746
>>
>> > 
>> >   
>> >
>> >
>> >
>> >
>> >
>> > --
>> > View this message in context:
>> http://camel.465427.n5.nabble.com/Multicast-redelivery-and-error-handlers-tp5719208.html
>> > Sent from the Camel - Users mailing list archive at Nabble.com.
>>
>>
>>
>> --
>> Claus Ibsen
>> -
>> FuseSource
>> Email: [hidden email]
>> Web: http://fusesource.com
>> Twitter: davsclaus, fusenews
>> Blog: http://davsclaus.com
>> Author of Camel in Action: http://www.manning.com/ibsen
>>
>>
>> --
>>  If you reply to this email, your message will be added to the discussion
>> below:
>>
>> http://camel.465427.n5.nabble.com/Multicast-redelivery-and-error-handlers-tp5719208p5719232.html
>>  To unsubscribe from Multicast, redelivery and error handlers, click 
>> here

Re: Multicast, redelivery and error handlers

2012-09-13 Thread jimbogaz 
Thanks for the fast response Claus.  I figured that must have been the
case, which is why I then tried implementing the timeout method on a
TimeoutAwareAggregator.  I thought if I called setException there (just
with a plain new Exception) then that might trigger the error handler.

I should describe that what I want to happen is that either the whole
multicast tries again, or perhaps just the one that timed out.  Is there a
different way of achieving that?
Thanks again,
James
On Sep 13, 2012 8:43 AM, "Claus Ibsen-2 [via Camel]" <
ml-node+s465427n5719232...@n5.nabble.com> wrote:

> There is no exception occurring. And therefore the error handler does
> not redeliver anything.
> If the timeout is hit on the multicast, then yes the multicast will
> aggregate what it currently has, and continue routing.
>
>
>
> On Wed, Sep 12, 2012 at 10:37 PM, jimbogaz <[hidden 
> email]>
> wrote:
>
> > Hi all.
> >
> > I think I'm missing something obvious, but I can't find anything here
> that
> > is similar to my problem, or any docs that tell me "it's obvious James
> you
> > twerp":
> >
> > I've put together a route that multicasts to three direct routes, which
> > simply return setBody type responses.  I have intentionally made one of
> them
> > take longer than the timeout on the multicast, with the intention that
> the
> > error handler retries the request.  It doesn't.  I have tried with both
> > having a TimeoutAwareAggregationStrategy with a setException (which I
> > thought would automatically invoke the error handler), and with just a
> plain
> > AggregationStrategy.
> >
> > I'm on Camel 2.9.3, and below are my (sanitised to protect my client)
> > sections from beans.xml and my main method...  can anybody tell me where
> I'm
> > epic failing?
> >
> >
> > public static void main(String... args) throws Exception {
> > ApplicationContext appContext = new
> > ClassPathXmlApplicationContext("beans.xml");
> > LOG.info("Initialised Application Context");
> > CamelContext camelContext = appContext.getBean("camel-context",
> > CamelContext.class);
> > ProducerTemplate producerTemplate =
> > camelContext.createProducerTemplate();
> > producerTemplate.asyncCallbackRequestBody("direct:blah",
> > "James[hidden 
> > email]",
> callback);
> > Thread.sleep(15000);
> > LOG.info("FINISHED");
> > }
> >
> >> xmlns="http://camel.apache.org/schema/spring";>
> > com.rightmess.camel
> >
> > 
> >  > retryAttemptedLogLevel="WARN" redeliveryDelay="200"/>
> > 
> > 
> >   
> >>parallelProcessing="true" streaming="true"
> timeout="700">
> > 
> > 
> > 
> >   
> > 
> > 
> > 
> > 233
> >
> >
> 15/04/1868
> > 
> > 
> > 
> > 1500
> >
> >
> Starbucks
> > 
> > 
> > 
> > 
> > 233
> >
> >
> 0982734786238746
>
> > 
> >   
> >
> >
> >
> >
> >
> > --
> > View this message in context:
> http://camel.465427.n5.nabble.com/Multicast-redelivery-and-error-handlers-tp5719208.html
> > Sent from the Camel - Users mailing list archive at Nabble.com.
>
>
>
> --
> Claus Ibsen
> -
> FuseSource
> Email: [hidden email]
> Web: http://fusesource.com
> Twitter: davsclaus, fusenews
> Blog: http://davsclaus.com
> Author of Camel in Action: http://www.manning.com/ibsen
>
>
> --
>  If you reply to this email, your message will be added to the discussion
> below:
>
> http://camel.465427.n5.nabble.com/Multicast-redelivery-and-error-handlers-tp5719208p5719232.html
>  To unsubscribe from Multicast, redelivery and error handlers, click 
> here
> .
> NAML
>




--
View this message in context: 
http://camel.465427.n5.nabble.com/Multicast-redelivery-and-error-handlers-tp5719208p5719236.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: Multicast, redelivery and error handlers

2012-09-12 Thread Claus Ibsen 
There is no exception occurring. And therefore the error handler does
not redeliver anything.
If the timeout is hit on the multicast, then yes the multicast will
aggregate what it currently has, and continue routing.



On Wed, Sep 12, 2012 at 10:37 PM, jimbogaz  wrote:
> Hi all.
>
> I think I'm missing something obvious, but I can't find anything here that
> is similar to my problem, or any docs that tell me "it's obvious James you
> twerp":
>
> I've put together a route that multicasts to three direct routes, which
> simply return setBody type responses.  I have intentionally made one of them
> take longer than the timeout on the multicast, with the intention that the
> error handler retries the request.  It doesn't.  I have tried with both
> having a TimeoutAwareAggregationStrategy with a setException (which I
> thought would automatically invoke the error handler), and with just a plain
> AggregationStrategy.
>
> I'm on Camel 2.9.3, and below are my (sanitised to protect my client)
> sections from beans.xml and my main method...  can anybody tell me where I'm
> epic failing?
>
>
> public static void main(String... args) throws Exception {
> ApplicationContext appContext = new
> ClassPathXmlApplicationContext("beans.xml");
> LOG.info("Initialised Application Context");
> CamelContext camelContext = appContext.getBean("camel-context",
> CamelContext.class);
> ProducerTemplate producerTemplate =
> camelContext.createProducerTemplate();
> producerTemplate.asyncCallbackRequestBody("direct:blah",
> "Jamesd...@thingy.com", callback);
> Thread.sleep(15000);
> LOG.info("FINISHED");
> }
>
>xmlns="http://camel.apache.org/schema/spring";>
> com.rightmess.camel
>
> 
>  retryAttemptedLogLevel="WARN" redeliveryDelay="200"/>
> 
> 
>   
>   parallelProcessing="true" streaming="true" timeout="700">
> 
> 
> 
>   
> 
> 
> 
> 233
>
> 15/04/1868
> 
> 
> 
> 1500
>
> Starbucks
> 
> 
> 
> 
> 233
>
> 0982734786238746
> 
>   
>
>
>
>
>
> --
> View this message in context: 
> http://camel.465427.n5.nabble.com/Multicast-redelivery-and-error-handlers-tp5719208.html
> Sent from the Camel - Users mailing list archive at Nabble.com.



-- 
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen

Re: Multicast, redelivery and error handlers

2012-09-12 Thread jimbogaz 
Oh, and the asyncCallbackRequestBody call is intentional (I am under the
impression that this is a way to have an InOut route that doesn't block the
initiating thread... my multicast routes will eventually be CXF over JMS
calls).



--
View this message in context: 
http://camel.465427.n5.nabble.com/Multicast-redelivery-and-error-handlers-tp5719208p5719209.html
Sent from the Camel - Users mailing list archive at Nabble.com.