You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by jfaath <jf...@apache.org> on 2010/03/23 19:57:34 UTC

error-handling advice with queues

I'm looking for some advice on how to deal with errors during a large
processing task.  It seems like it should be simple but I'm having trouble
figuring out what to do.

I have an HTTP endpoint that receives XML messages then sticks them in a
processing queue.  From the queue, they get unmarshalled into JAXB objects
and then processed by a Java class.  Now, the messages consist or a large
number of readings.  Some may be good, some may be bad.  The good ones get
processed, but the bad ones are stuffed into a JAXB object.  

When the processing is done, I'd like to throw this object on an error queue
(or, marshal then throw on the queue).  But I can't figure out how to do
this the best way.  The processing class should exit gracefully so I don't
want to throw a final exception.

What might be the best way to do this?  Can I add the error object to a
queue programmatically within the processor?  Can the processor return the
error object so I can throw it on the queue via the route?  Is there a nice
and easy way to do this?

Thanks,

JF
-- 
View this message in context: http://old.nabble.com/error-handling-advice-with-queues-tp28005566p28005566.html
Sent from the Camel - Users mailing list archive at Nabble.com.


Re: How camel define content of message sent to catch clause ?

Posted by Claus Ibsen <cl...@gmail.com>.
On Fri, Mar 26, 2010 at 6:07 AM, ext2 <xu...@tongtech.com> wrote:
>
>
> In camel , try-catch means , if exception occurs , catch-clause will be
> execute.
> And how does camel define : What is message(catch-clause received) 's
> content?
>
> Is the content exactly equals to the processed content where exception just
> occurs?
>
> For pipe line , catch-clause will received a message whose  content which
> will be exactly where exception occurs;
> But for multi-case , catch-clause can only received a message whose content
> is the multi-case's received original message.
>
> So the pipe-line and multi-cast doesn't consistence. Is it the multi-case 's
> bug ? for example:
>
> <doTry>
>   <process1>
>   <process2>
> <doCatch>...</doCatch>
> </doTry>
>
> If process2 failed , catch clause will received message which content is the
> process1's result.
>
> But another multi-case example
>
> <dotry>
>        <multi-cast stopOnException="true">
>                <pipeline> <process1><process2> </pipeline>
>                <pipeline> <process3> <process4> </pipeline>
>    </multi-cast>
> <doCatch> </doCatch>
> </dotry>
>
> If process2 failed , doCatch will received message whose content is original
> message send  to mult-cast, but not be the process1's result;
>
> So is it a bug of multi-cast pattern?
>

That is how the multicast EIP pattern works. It sends the SAME message
to X destinations.
So if you continue routing AFTER the multicast you would use the
original message.

But Camel offers you to aggregate with the multicast. So in you case
you can add a aggregationStrategy to multicast and let it just use the
new exchange

>
>



-- 
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: error-handling advice with queues

Posted by jfaath <jf...@apache.org>.
Thanks, based on some of your suggestions and some more research, I was able
to come up with a suitable solution.



Allen Lau-2 wrote:
> 
> I would think something like
> 
> .beanRef("processor", "process")
> .split().method("mySplitterBean", "splitMessage")
> .choice
> .when(simple("${in.header.error} != null").to("mock:invalid")
> .otherwise().to("mock:valid");
> 
> Your mySplitterBean would just create a 2 different messages, one with the
> error header
> and one without.   Checkout the example on the splitter page for an
> example.
> 
> In the case there is no error, then your splitter should just return 1
> message and you should be fine.
> 
> Hope that helps.
> Allen
> 
> On Thu, Mar 25, 2010 at 8:39 AM, jfaath <jf...@apache.org> wrote:
> 
>>
>> The splitter stuff doesn't seem to be useful for my issue, but I can see
>> now
>> in the CBR page how to do logic in the route based on the header.  In
>> fact,
>> I was using the CBR on my route already.  I'm still not clear on how to
>> actually set the header to the "error object in java code.
>>
>> Here is the gist of my actual route.  Based on the XML content of the
>> message coming in, I route to a different java processor.  However, this
>> error method I want to use is common to all processors.  Can you offer a
>> quick suggestion as to how I would do it using the route below?
>>
>> from("jetty:http://0.0.0.0:8282/process").convertBodyTo(String.class)
>> .inOnly("jms:queue:data.inbound")
>> .choice
>> .when().xpath("/readingsType1")
>>  .unmarshal(jaxbDf)
>>  .beanRef("dataProcessor1", "process")
>> .when().xpath("/readingsType2")
>>  .unmarshal(jaxbDf)
>>  .beanRef("dataProcessor2", "process")
>> .otherwise().to("mock:invalid")
>>
>>
>> Allen Lau-2 wrote:
>> >
>> > Look at these pages for samples.
>> >
>> > http://camel.apache.org/splitter.html
>> > http://camel.apache.org/content-based-router.html
>> >
>> > I would most likely create a POJO to split the message up and then use
>> the
>> > content base router to
>> > route the message.
>> >
>> > On Wed, Mar 24, 2010 at 9:04 AM, jfaath <jf...@apache.org> wrote:
>> >
>> >>
>> >> I'll give this a shot.  Can you give me a quick example or point me to
>> a
>> >> sample that does something similar (ex. setting a header in code,
>> >> performing
>> >> conditional logic in a route based on a header).
>> >>
>> >> -JF
>> >>
>> >>
>> >> Allen Lau-2 wrote:
>> >> >
>> >> > I could be wrong here, but you could easily stick the "error" object
>> as
>> >> > part
>> >> > of the message header.   As long as your components
>> >> > understand that header, you can easily retrieve it and only send
>> that
>> >> > portion to an error queue.
>> >> >
>> >> > The default message headers in Camel is defined as
>> >> >
>> >> > Map<String, Object> headers;
>> >> >
>> >> > so basically you can stuff whatever you want into it.
>> >> >
>> >> >
>> >> > On Tue, Mar 23, 2010 at 4:02 PM, jfaath <jf...@apache.org> wrote:
>> >> >
>> >> >>
>> >> >> I'm not sure that would work.  As I stated in my original post, I
>> >> don't
>> >> >> want
>> >> >> to send the entire message to the error queue, just the portion
>> that
>> >> was
>> >> >> invalid.  So, if my original message has, say, 11 readings, and 3
>> of
>> >> them
>> >> >> are bad, I only want to send the 3 bad ones to the error queue.
>> >> During
>> >> >> processing, I stick the bad readings into an "error object".  It's
>> the
>> >> >> contents of this object (that I can easily marshal to XML) that I
>> want
>> >> to
>> >> >> send to the queue.
>> >> >>
>> >> >> FYI, here is a simplified version of my route:
>> >> >>
>> >> >>
>> >> >> from("jetty:http://0.0.0.0:8282/process
>> ").convertBodyTo(String.class)
>> >> >>        .inOnly("jms:queue:data.inbound")
>> >> >>        .unmarshal(jaxbDf)
>> >> >>        .beanRef("dataProcessor", "process")
>> >> >>
>> >> >>
>> >> >> Allen Lau-2 wrote:
>> >> >> >
>> >> >> > How about just setting a header when you are done processing and
>> >> there
>> >> >> is
>> >> >> > an
>> >> >> > error?
>> >> >> >
>> >> >> > Then in your route, just send any message to the error queue when
>> >> the
>> >> >> > header
>> >> >> > is detected.
>> >> >> >
>> >> >> > On Tue, Mar 23, 2010 at 11:57 AM, jfaath <jf...@apache.org>
>> wrote:
>> >> >> >
>> >> >> >>
>> >> >> >> I'm looking for some advice on how to deal with errors during a
>> >> large
>> >> >> >> processing task.  It seems like it should be simple but I'm
>> having
>> >> >> >> trouble
>> >> >> >> figuring out what to do.
>> >> >> >>
>> >> >> >> I have an HTTP endpoint that receives XML messages then sticks
>> them
>> >> in
>> >> >> a
>> >> >> >> processing queue.  From the queue, they get unmarshalled into
>> JAXB
>> >> >> >> objects
>> >> >> >> and then processed by a Java class.  Now, the messages consist
>> or
>> a
>> >> >> large
>> >> >> >> number of readings.  Some may be good, some may be bad.  The
>> good
>> >> ones
>> >> >> >> get
>> >> >> >> processed, but the bad ones are stuffed into a JAXB object.
>> >> >> >>
>> >> >> >> When the processing is done, I'd like to throw this object on an
>> >> error
>> >> >> >> queue
>> >> >> >> (or, marshal then throw on the queue).  But I can't figure out
>> how
>> >> to
>> >> >> do
>> >> >> >> this the best way.  The processing class should exit gracefully
>> so
>> >> I
>> >> >> >> don't
>> >> >> >> want to throw a final exception.
>> >> >> >>
>> >> >> >> What might be the best way to do this?  Can I add the error
>> object
>> >> to
>> >> >> a
>> >> >> >> queue programmatically within the processor?  Can the processor
>> >> return
>> >> >> >> the
>> >> >> >> error object so I can throw it on the queue via the route?  Is
>> >> there
>> >> a
>> >> >> >> nice
>> >> >> >> and easy way to do this?
>> >> >> >>
>> >> >> >> Thanks,
>> >> >> >>
>> >> >> >> JF
>> >> >> >> --
>> >> >> >> View this message in context:
>> >> >> >>
>> >> >>
>> >>
>> http://old.nabble.com/error-handling-advice-with-queues-tp28005566p28005566.html
>> >> >> >> Sent from the Camel - Users mailing list archive at Nabble.com.
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >> >
>> >> >>
>> >> >> --
>> >> >> View this message in context:
>> >> >>
>> >>
>> http://old.nabble.com/error-handling-advice-with-queues-tp28005566p28008395.html
>> >> >> Sent from the Camel - Users mailing list archive at Nabble.com.
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >> --
>> >> View this message in context:
>> >>
>> http://old.nabble.com/error-handling-advice-with-queues-tp28005566p28016879.html
>> >> Sent from the Camel - Users mailing list archive at Nabble.com.
>> >>
>> >>
>> >
>> >
>>
>> --
>> View this message in context:
>> http://old.nabble.com/error-handling-advice-with-queues-tp28005566p28030652.html
>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>
>>
> 
> 

-- 
View this message in context: http://old.nabble.com/error-handling-advice-with-queues-tp28005566p28046605.html
Sent from the Camel - Users mailing list archive at Nabble.com.


Re: error-handling advice with queues

Posted by Allen Lau <al...@gmail.com>.
I would think something like

.beanRef("processor", "process")
.split().method("mySplitterBean", "splitMessage")
.choice
.when(simple("${in.header.error} != null").to("mock:invalid")
.otherwise().to("mock:valid");

Your mySplitterBean would just create a 2 different messages, one with the
error header
and one without.   Checkout the example on the splitter page for an example.

In the case there is no error, then your splitter should just return 1
message and you should be fine.

Hope that helps.
Allen

On Thu, Mar 25, 2010 at 8:39 AM, jfaath <jf...@apache.org> wrote:

>
> The splitter stuff doesn't seem to be useful for my issue, but I can see
> now
> in the CBR page how to do logic in the route based on the header.  In fact,
> I was using the CBR on my route already.  I'm still not clear on how to
> actually set the header to the "error object in java code.
>
> Here is the gist of my actual route.  Based on the XML content of the
> message coming in, I route to a different java processor.  However, this
> error method I want to use is common to all processors.  Can you offer a
> quick suggestion as to how I would do it using the route below?
>
> from("jetty:http://0.0.0.0:8282/process").convertBodyTo(String.class)
> .inOnly("jms:queue:data.inbound")
> .choice
> .when().xpath("/readingsType1")
>  .unmarshal(jaxbDf)
>  .beanRef("dataProcessor1", "process")
> .when().xpath("/readingsType2")
>  .unmarshal(jaxbDf)
>  .beanRef("dataProcessor2", "process")
> .otherwise().to("mock:invalid")
>
>
> Allen Lau-2 wrote:
> >
> > Look at these pages for samples.
> >
> > http://camel.apache.org/splitter.html
> > http://camel.apache.org/content-based-router.html
> >
> > I would most likely create a POJO to split the message up and then use
> the
> > content base router to
> > route the message.
> >
> > On Wed, Mar 24, 2010 at 9:04 AM, jfaath <jf...@apache.org> wrote:
> >
> >>
> >> I'll give this a shot.  Can you give me a quick example or point me to a
> >> sample that does something similar (ex. setting a header in code,
> >> performing
> >> conditional logic in a route based on a header).
> >>
> >> -JF
> >>
> >>
> >> Allen Lau-2 wrote:
> >> >
> >> > I could be wrong here, but you could easily stick the "error" object
> as
> >> > part
> >> > of the message header.   As long as your components
> >> > understand that header, you can easily retrieve it and only send that
> >> > portion to an error queue.
> >> >
> >> > The default message headers in Camel is defined as
> >> >
> >> > Map<String, Object> headers;
> >> >
> >> > so basically you can stuff whatever you want into it.
> >> >
> >> >
> >> > On Tue, Mar 23, 2010 at 4:02 PM, jfaath <jf...@apache.org> wrote:
> >> >
> >> >>
> >> >> I'm not sure that would work.  As I stated in my original post, I
> >> don't
> >> >> want
> >> >> to send the entire message to the error queue, just the portion that
> >> was
> >> >> invalid.  So, if my original message has, say, 11 readings, and 3 of
> >> them
> >> >> are bad, I only want to send the 3 bad ones to the error queue.
> >> During
> >> >> processing, I stick the bad readings into an "error object".  It's
> the
> >> >> contents of this object (that I can easily marshal to XML) that I
> want
> >> to
> >> >> send to the queue.
> >> >>
> >> >> FYI, here is a simplified version of my route:
> >> >>
> >> >>
> >> >> from("jetty:http://0.0.0.0:8282/process
> ").convertBodyTo(String.class)
> >> >>        .inOnly("jms:queue:data.inbound")
> >> >>        .unmarshal(jaxbDf)
> >> >>        .beanRef("dataProcessor", "process")
> >> >>
> >> >>
> >> >> Allen Lau-2 wrote:
> >> >> >
> >> >> > How about just setting a header when you are done processing and
> >> there
> >> >> is
> >> >> > an
> >> >> > error?
> >> >> >
> >> >> > Then in your route, just send any message to the error queue when
> >> the
> >> >> > header
> >> >> > is detected.
> >> >> >
> >> >> > On Tue, Mar 23, 2010 at 11:57 AM, jfaath <jf...@apache.org>
> wrote:
> >> >> >
> >> >> >>
> >> >> >> I'm looking for some advice on how to deal with errors during a
> >> large
> >> >> >> processing task.  It seems like it should be simple but I'm having
> >> >> >> trouble
> >> >> >> figuring out what to do.
> >> >> >>
> >> >> >> I have an HTTP endpoint that receives XML messages then sticks
> them
> >> in
> >> >> a
> >> >> >> processing queue.  From the queue, they get unmarshalled into JAXB
> >> >> >> objects
> >> >> >> and then processed by a Java class.  Now, the messages consist or
> a
> >> >> large
> >> >> >> number of readings.  Some may be good, some may be bad.  The good
> >> ones
> >> >> >> get
> >> >> >> processed, but the bad ones are stuffed into a JAXB object.
> >> >> >>
> >> >> >> When the processing is done, I'd like to throw this object on an
> >> error
> >> >> >> queue
> >> >> >> (or, marshal then throw on the queue).  But I can't figure out how
> >> to
> >> >> do
> >> >> >> this the best way.  The processing class should exit gracefully so
> >> I
> >> >> >> don't
> >> >> >> want to throw a final exception.
> >> >> >>
> >> >> >> What might be the best way to do this?  Can I add the error object
> >> to
> >> >> a
> >> >> >> queue programmatically within the processor?  Can the processor
> >> return
> >> >> >> the
> >> >> >> error object so I can throw it on the queue via the route?  Is
> >> there
> >> a
> >> >> >> nice
> >> >> >> and easy way to do this?
> >> >> >>
> >> >> >> Thanks,
> >> >> >>
> >> >> >> JF
> >> >> >> --
> >> >> >> View this message in context:
> >> >> >>
> >> >>
> >>
> http://old.nabble.com/error-handling-advice-with-queues-tp28005566p28005566.html
> >> >> >> Sent from the Camel - Users mailing list archive at Nabble.com.
> >> >> >>
> >> >> >>
> >> >> >
> >> >> >
> >> >>
> >> >> --
> >> >> View this message in context:
> >> >>
> >>
> http://old.nabble.com/error-handling-advice-with-queues-tp28005566p28008395.html
> >> >> Sent from the Camel - Users mailing list archive at Nabble.com.
> >> >>
> >> >>
> >> >
> >> >
> >>
> >> --
> >> View this message in context:
> >>
> http://old.nabble.com/error-handling-advice-with-queues-tp28005566p28016879.html
> >> Sent from the Camel - Users mailing list archive at Nabble.com.
> >>
> >>
> >
> >
>
> --
> View this message in context:
> http://old.nabble.com/error-handling-advice-with-queues-tp28005566p28030652.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
>

Re: try-catch conflict with default-error-handler

Posted by Claus Ibsen <cl...@gmail.com>.
On Fri, Mar 26, 2010 at 7:30 AM, ext2 <xu...@tongtech.com> wrote:
> Sorry, I forget to say, this is running on camel 2.2;
>
> I have checked the camel's document and source-code; the camel-document say
> " try-catch will disable the error-handler"; but while I checking the
> source-code of camel , it only disable  error-handlers of node (which is
> conjunction with doTry pattern).
>
>  In the following example, only <filter> processor is conjunction with
> <doTry>. So only filter processor's  error-handler is disabled. But
> error-handlers of  other processor which defined inside filter is not
> disabled.
>
> So the catch-clause is not invoked. Is it a bug?
>

I have created a ticket to look into it
https://issues.apache.org/activemq/browse/CAMEL-2577


> ---------------------------------------------------------------------------
> Follow route use a default-error-handler for the route, and also defined  a
> custom exception handle logic using try-catch-pattern.
>
> But if the "myProcessRaiseError" raised exception the catch-clause cannot be
> invoked; Why? Is it camel's bug?
>
>
> <route>
>      <from uri="ws:... "/>
>         <bean ...>
>        <doTry>
>         <filter>
>                <simple>${body} == 'firstChoice'</simple>
>                      <bean ref="myProcess" />
>                      <bean ref="myProcessRaiseError"/>
>              </filter>
>                <doCatch>
>                        ..some error handler...
>                </doCatch>
>        </doTry>
>     <process ...>
> </route>
>
>
>
>
>
>
>



-- 
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: try-catch conflict with default-error-handler

Posted by ext2 <xu...@tongtech.com>.
Sorry, I forget to say, this is running on camel 2.2;

I have checked the camel's document and source-code; the camel-document say
" try-catch will disable the error-handler"; but while I checking the
source-code of camel , it only disable  error-handlers of node (which is
conjunction with doTry pattern).

 In the following example, only <filter> processor is conjunction with
<doTry>. So only filter processor's  error-handler is disabled. But
error-handlers of  other processor which defined inside filter is not
disabled.

So the catch-clause is not invoked. Is it a bug?

---------------------------------------------------------------------------
Follow route use a default-error-handler for the route, and also defined  a
custom exception handle logic using try-catch-pattern. 

But if the "myProcessRaiseError" raised exception the catch-clause cannot be
invoked; Why? Is it camel's bug?


<route>
      <from uri="ws:... "/>
	 <bean ...>
	<doTry>
     	 <filter>
      		<simple>${body} == 'firstChoice'</simple>
		      <bean ref="myProcess" />
		      <bean ref="myProcessRaiseError"/>
	      </filter>
		<doCatch>
			..some error handler...
		</doCatch>
	</doTry>
     <process ...>
</route>







try-catch conflict with default-error-handler

Posted by ext2 <xu...@tongtech.com>.
Follow route use a default-error-handler for the route, and also defined  a
custom exception handle logic using try-catch-pattern. 

But if the "myProcessRaiseError" raised exception the catch-clause cannot be
invoked; Why? Is it camel's bug?


<route>
      <from uri="ws:... "/>
	 <bean ...>
	<doTry>
     	 <filter>
      		<simple>${body} == 'firstChoice'</simple>
		      <bean ref="myProcess" />
		      <bean ref="myProcessRaiseError"/>
	      </filter>
		<doCatch>
			..some error handler...
		</doCatch>
	</doTry>
     <process ...>
</route>





How camel define content of message sent to catch clause ?

Posted by ext2 <xu...@tongtech.com>.

In camel , try-catch means , if exception occurs , catch-clause will be
execute. 
And how does camel define : What is message(catch-clause received) 's
content? 

Is the content exactly equals to the processed content where exception just
occurs?

For pipe line , catch-clause will received a message whose  content which
will be exactly where exception occurs;
But for multi-case , catch-clause can only received a message whose content
is the multi-case's received original message.

So the pipe-line and multi-cast doesn't consistence. Is it the multi-case 's
bug ? for example:

<doTry>
   <process1>
   <process2>
<doCatch>...</doCatch>
</doTry>

If process2 failed , catch clause will received message which content is the
process1's result.

But another multi-case example

<dotry>
	<multi-cast stopOnException="true">
		<pipeline> <process1><process2> </pipeline>
		<pipeline> <process3> <process4> </pipeline>
    </multi-cast>
<doCatch> </doCatch>
</dotry>

If process2 failed , doCatch will received message whose content is original
message send  to mult-cast, but not be the process1's result;

So is it a bug of multi-cast pattern?  



Re: error-handling advice with queues

Posted by jfaath <jf...@apache.org>.
The splitter stuff doesn't seem to be useful for my issue, but I can see now
in the CBR page how to do logic in the route based on the header.  In fact,
I was using the CBR on my route already.  I'm still not clear on how to
actually set the header to the "error object in java code.

Here is the gist of my actual route.  Based on the XML content of the
message coming in, I route to a different java processor.  However, this
error method I want to use is common to all processors.  Can you offer a
quick suggestion as to how I would do it using the route below?

from("jetty:http://0.0.0.0:8282/process").convertBodyTo(String.class)
.inOnly("jms:queue:data.inbound")
.choice
.when().xpath("/readingsType1")
  .unmarshal(jaxbDf)
  .beanRef("dataProcessor1", "process")
.when().xpath("/readingsType2")
  .unmarshal(jaxbDf)
  .beanRef("dataProcessor2", "process")
.otherwise().to("mock:invalid")


Allen Lau-2 wrote:
> 
> Look at these pages for samples.
> 
> http://camel.apache.org/splitter.html
> http://camel.apache.org/content-based-router.html
> 
> I would most likely create a POJO to split the message up and then use the
> content base router to
> route the message.
> 
> On Wed, Mar 24, 2010 at 9:04 AM, jfaath <jf...@apache.org> wrote:
> 
>>
>> I'll give this a shot.  Can you give me a quick example or point me to a
>> sample that does something similar (ex. setting a header in code,
>> performing
>> conditional logic in a route based on a header).
>>
>> -JF
>>
>>
>> Allen Lau-2 wrote:
>> >
>> > I could be wrong here, but you could easily stick the "error" object as
>> > part
>> > of the message header.   As long as your components
>> > understand that header, you can easily retrieve it and only send that
>> > portion to an error queue.
>> >
>> > The default message headers in Camel is defined as
>> >
>> > Map<String, Object> headers;
>> >
>> > so basically you can stuff whatever you want into it.
>> >
>> >
>> > On Tue, Mar 23, 2010 at 4:02 PM, jfaath <jf...@apache.org> wrote:
>> >
>> >>
>> >> I'm not sure that would work.  As I stated in my original post, I
>> don't
>> >> want
>> >> to send the entire message to the error queue, just the portion that
>> was
>> >> invalid.  So, if my original message has, say, 11 readings, and 3 of
>> them
>> >> are bad, I only want to send the 3 bad ones to the error queue. 
>> During
>> >> processing, I stick the bad readings into an "error object".  It's the
>> >> contents of this object (that I can easily marshal to XML) that I want
>> to
>> >> send to the queue.
>> >>
>> >> FYI, here is a simplified version of my route:
>> >>
>> >>
>> >> from("jetty:http://0.0.0.0:8282/process").convertBodyTo(String.class)
>> >>        .inOnly("jms:queue:data.inbound")
>> >>        .unmarshal(jaxbDf)
>> >>        .beanRef("dataProcessor", "process")
>> >>
>> >>
>> >> Allen Lau-2 wrote:
>> >> >
>> >> > How about just setting a header when you are done processing and
>> there
>> >> is
>> >> > an
>> >> > error?
>> >> >
>> >> > Then in your route, just send any message to the error queue when
>> the
>> >> > header
>> >> > is detected.
>> >> >
>> >> > On Tue, Mar 23, 2010 at 11:57 AM, jfaath <jf...@apache.org> wrote:
>> >> >
>> >> >>
>> >> >> I'm looking for some advice on how to deal with errors during a
>> large
>> >> >> processing task.  It seems like it should be simple but I'm having
>> >> >> trouble
>> >> >> figuring out what to do.
>> >> >>
>> >> >> I have an HTTP endpoint that receives XML messages then sticks them
>> in
>> >> a
>> >> >> processing queue.  From the queue, they get unmarshalled into JAXB
>> >> >> objects
>> >> >> and then processed by a Java class.  Now, the messages consist or a
>> >> large
>> >> >> number of readings.  Some may be good, some may be bad.  The good
>> ones
>> >> >> get
>> >> >> processed, but the bad ones are stuffed into a JAXB object.
>> >> >>
>> >> >> When the processing is done, I'd like to throw this object on an
>> error
>> >> >> queue
>> >> >> (or, marshal then throw on the queue).  But I can't figure out how
>> to
>> >> do
>> >> >> this the best way.  The processing class should exit gracefully so
>> I
>> >> >> don't
>> >> >> want to throw a final exception.
>> >> >>
>> >> >> What might be the best way to do this?  Can I add the error object
>> to
>> >> a
>> >> >> queue programmatically within the processor?  Can the processor
>> return
>> >> >> the
>> >> >> error object so I can throw it on the queue via the route?  Is
>> there
>> a
>> >> >> nice
>> >> >> and easy way to do this?
>> >> >>
>> >> >> Thanks,
>> >> >>
>> >> >> JF
>> >> >> --
>> >> >> View this message in context:
>> >> >>
>> >>
>> http://old.nabble.com/error-handling-advice-with-queues-tp28005566p28005566.html
>> >> >> Sent from the Camel - Users mailing list archive at Nabble.com.
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >> --
>> >> View this message in context:
>> >>
>> http://old.nabble.com/error-handling-advice-with-queues-tp28005566p28008395.html
>> >> Sent from the Camel - Users mailing list archive at Nabble.com.
>> >>
>> >>
>> >
>> >
>>
>> --
>> View this message in context:
>> http://old.nabble.com/error-handling-advice-with-queues-tp28005566p28016879.html
>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>
>>
> 
> 

-- 
View this message in context: http://old.nabble.com/error-handling-advice-with-queues-tp28005566p28030652.html
Sent from the Camel - Users mailing list archive at Nabble.com.


Re: error-handling advice with queues

Posted by Allen Lau <al...@gmail.com>.
Look at these pages for samples.

http://camel.apache.org/splitter.html
http://camel.apache.org/content-based-router.html

I would most likely create a POJO to split the message up and then use the
content base router to
route the message.

On Wed, Mar 24, 2010 at 9:04 AM, jfaath <jf...@apache.org> wrote:

>
> I'll give this a shot.  Can you give me a quick example or point me to a
> sample that does something similar (ex. setting a header in code,
> performing
> conditional logic in a route based on a header).
>
> -JF
>
>
> Allen Lau-2 wrote:
> >
> > I could be wrong here, but you could easily stick the "error" object as
> > part
> > of the message header.   As long as your components
> > understand that header, you can easily retrieve it and only send that
> > portion to an error queue.
> >
> > The default message headers in Camel is defined as
> >
> > Map<String, Object> headers;
> >
> > so basically you can stuff whatever you want into it.
> >
> >
> > On Tue, Mar 23, 2010 at 4:02 PM, jfaath <jf...@apache.org> wrote:
> >
> >>
> >> I'm not sure that would work.  As I stated in my original post, I don't
> >> want
> >> to send the entire message to the error queue, just the portion that was
> >> invalid.  So, if my original message has, say, 11 readings, and 3 of
> them
> >> are bad, I only want to send the 3 bad ones to the error queue.  During
> >> processing, I stick the bad readings into an "error object".  It's the
> >> contents of this object (that I can easily marshal to XML) that I want
> to
> >> send to the queue.
> >>
> >> FYI, here is a simplified version of my route:
> >>
> >>
> >> from("jetty:http://0.0.0.0:8282/process").convertBodyTo(String.class)
> >>        .inOnly("jms:queue:data.inbound")
> >>        .unmarshal(jaxbDf)
> >>        .beanRef("dataProcessor", "process")
> >>
> >>
> >> Allen Lau-2 wrote:
> >> >
> >> > How about just setting a header when you are done processing and there
> >> is
> >> > an
> >> > error?
> >> >
> >> > Then in your route, just send any message to the error queue when the
> >> > header
> >> > is detected.
> >> >
> >> > On Tue, Mar 23, 2010 at 11:57 AM, jfaath <jf...@apache.org> wrote:
> >> >
> >> >>
> >> >> I'm looking for some advice on how to deal with errors during a large
> >> >> processing task.  It seems like it should be simple but I'm having
> >> >> trouble
> >> >> figuring out what to do.
> >> >>
> >> >> I have an HTTP endpoint that receives XML messages then sticks them
> in
> >> a
> >> >> processing queue.  From the queue, they get unmarshalled into JAXB
> >> >> objects
> >> >> and then processed by a Java class.  Now, the messages consist or a
> >> large
> >> >> number of readings.  Some may be good, some may be bad.  The good
> ones
> >> >> get
> >> >> processed, but the bad ones are stuffed into a JAXB object.
> >> >>
> >> >> When the processing is done, I'd like to throw this object on an
> error
> >> >> queue
> >> >> (or, marshal then throw on the queue).  But I can't figure out how to
> >> do
> >> >> this the best way.  The processing class should exit gracefully so I
> >> >> don't
> >> >> want to throw a final exception.
> >> >>
> >> >> What might be the best way to do this?  Can I add the error object to
> >> a
> >> >> queue programmatically within the processor?  Can the processor
> return
> >> >> the
> >> >> error object so I can throw it on the queue via the route?  Is there
> a
> >> >> nice
> >> >> and easy way to do this?
> >> >>
> >> >> Thanks,
> >> >>
> >> >> JF
> >> >> --
> >> >> View this message in context:
> >> >>
> >>
> http://old.nabble.com/error-handling-advice-with-queues-tp28005566p28005566.html
> >> >> Sent from the Camel - Users mailing list archive at Nabble.com.
> >> >>
> >> >>
> >> >
> >> >
> >>
> >> --
> >> View this message in context:
> >>
> http://old.nabble.com/error-handling-advice-with-queues-tp28005566p28008395.html
> >> Sent from the Camel - Users mailing list archive at Nabble.com.
> >>
> >>
> >
> >
>
> --
> View this message in context:
> http://old.nabble.com/error-handling-advice-with-queues-tp28005566p28016879.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
>

Re: error-handling advice with queues

Posted by jfaath <jf...@apache.org>.
I'll give this a shot.  Can you give me a quick example or point me to a
sample that does something similar (ex. setting a header in code, performing
conditional logic in a route based on a header).

-JF


Allen Lau-2 wrote:
> 
> I could be wrong here, but you could easily stick the "error" object as
> part
> of the message header.   As long as your components
> understand that header, you can easily retrieve it and only send that
> portion to an error queue.
> 
> The default message headers in Camel is defined as
> 
> Map<String, Object> headers;
> 
> so basically you can stuff whatever you want into it.
> 
> 
> On Tue, Mar 23, 2010 at 4:02 PM, jfaath <jf...@apache.org> wrote:
> 
>>
>> I'm not sure that would work.  As I stated in my original post, I don't
>> want
>> to send the entire message to the error queue, just the portion that was
>> invalid.  So, if my original message has, say, 11 readings, and 3 of them
>> are bad, I only want to send the 3 bad ones to the error queue.  During
>> processing, I stick the bad readings into an "error object".  It's the
>> contents of this object (that I can easily marshal to XML) that I want to
>> send to the queue.
>>
>> FYI, here is a simplified version of my route:
>>
>>
>> from("jetty:http://0.0.0.0:8282/process").convertBodyTo(String.class)
>>        .inOnly("jms:queue:data.inbound")
>>        .unmarshal(jaxbDf)
>>        .beanRef("dataProcessor", "process")
>>
>>
>> Allen Lau-2 wrote:
>> >
>> > How about just setting a header when you are done processing and there
>> is
>> > an
>> > error?
>> >
>> > Then in your route, just send any message to the error queue when the
>> > header
>> > is detected.
>> >
>> > On Tue, Mar 23, 2010 at 11:57 AM, jfaath <jf...@apache.org> wrote:
>> >
>> >>
>> >> I'm looking for some advice on how to deal with errors during a large
>> >> processing task.  It seems like it should be simple but I'm having
>> >> trouble
>> >> figuring out what to do.
>> >>
>> >> I have an HTTP endpoint that receives XML messages then sticks them in
>> a
>> >> processing queue.  From the queue, they get unmarshalled into JAXB
>> >> objects
>> >> and then processed by a Java class.  Now, the messages consist or a
>> large
>> >> number of readings.  Some may be good, some may be bad.  The good ones
>> >> get
>> >> processed, but the bad ones are stuffed into a JAXB object.
>> >>
>> >> When the processing is done, I'd like to throw this object on an error
>> >> queue
>> >> (or, marshal then throw on the queue).  But I can't figure out how to
>> do
>> >> this the best way.  The processing class should exit gracefully so I
>> >> don't
>> >> want to throw a final exception.
>> >>
>> >> What might be the best way to do this?  Can I add the error object to
>> a
>> >> queue programmatically within the processor?  Can the processor return
>> >> the
>> >> error object so I can throw it on the queue via the route?  Is there a
>> >> nice
>> >> and easy way to do this?
>> >>
>> >> Thanks,
>> >>
>> >> JF
>> >> --
>> >> View this message in context:
>> >>
>> http://old.nabble.com/error-handling-advice-with-queues-tp28005566p28005566.html
>> >> Sent from the Camel - Users mailing list archive at Nabble.com.
>> >>
>> >>
>> >
>> >
>>
>> --
>> View this message in context:
>> http://old.nabble.com/error-handling-advice-with-queues-tp28005566p28008395.html
>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>
>>
> 
> 

-- 
View this message in context: http://old.nabble.com/error-handling-advice-with-queues-tp28005566p28016879.html
Sent from the Camel - Users mailing list archive at Nabble.com.


Re: error-handling advice with queues

Posted by Allen Lau <al...@gmail.com>.
I could be wrong here, but you could easily stick the "error" object as part
of the message header.   As long as your components
understand that header, you can easily retrieve it and only send that
portion to an error queue.

The default message headers in Camel is defined as

Map<String, Object> headers;

so basically you can stuff whatever you want into it.


On Tue, Mar 23, 2010 at 4:02 PM, jfaath <jf...@apache.org> wrote:

>
> I'm not sure that would work.  As I stated in my original post, I don't
> want
> to send the entire message to the error queue, just the portion that was
> invalid.  So, if my original message has, say, 11 readings, and 3 of them
> are bad, I only want to send the 3 bad ones to the error queue.  During
> processing, I stick the bad readings into an "error object".  It's the
> contents of this object (that I can easily marshal to XML) that I want to
> send to the queue.
>
> FYI, here is a simplified version of my route:
>
>
> from("jetty:http://0.0.0.0:8282/process").convertBodyTo(String.class)
>        .inOnly("jms:queue:data.inbound")
>        .unmarshal(jaxbDf)
>        .beanRef("dataProcessor", "process")
>
>
> Allen Lau-2 wrote:
> >
> > How about just setting a header when you are done processing and there is
> > an
> > error?
> >
> > Then in your route, just send any message to the error queue when the
> > header
> > is detected.
> >
> > On Tue, Mar 23, 2010 at 11:57 AM, jfaath <jf...@apache.org> wrote:
> >
> >>
> >> I'm looking for some advice on how to deal with errors during a large
> >> processing task.  It seems like it should be simple but I'm having
> >> trouble
> >> figuring out what to do.
> >>
> >> I have an HTTP endpoint that receives XML messages then sticks them in a
> >> processing queue.  From the queue, they get unmarshalled into JAXB
> >> objects
> >> and then processed by a Java class.  Now, the messages consist or a
> large
> >> number of readings.  Some may be good, some may be bad.  The good ones
> >> get
> >> processed, but the bad ones are stuffed into a JAXB object.
> >>
> >> When the processing is done, I'd like to throw this object on an error
> >> queue
> >> (or, marshal then throw on the queue).  But I can't figure out how to do
> >> this the best way.  The processing class should exit gracefully so I
> >> don't
> >> want to throw a final exception.
> >>
> >> What might be the best way to do this?  Can I add the error object to a
> >> queue programmatically within the processor?  Can the processor return
> >> the
> >> error object so I can throw it on the queue via the route?  Is there a
> >> nice
> >> and easy way to do this?
> >>
> >> Thanks,
> >>
> >> JF
> >> --
> >> View this message in context:
> >>
> http://old.nabble.com/error-handling-advice-with-queues-tp28005566p28005566.html
> >> Sent from the Camel - Users mailing list archive at Nabble.com.
> >>
> >>
> >
> >
>
> --
> View this message in context:
> http://old.nabble.com/error-handling-advice-with-queues-tp28005566p28008395.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
>

Re: error-handling advice with queues

Posted by jfaath <jf...@apache.org>.
I'm not sure that would work.  As I stated in my original post, I don't want
to send the entire message to the error queue, just the portion that was
invalid.  So, if my original message has, say, 11 readings, and 3 of them
are bad, I only want to send the 3 bad ones to the error queue.  During
processing, I stick the bad readings into an "error object".  It's the
contents of this object (that I can easily marshal to XML) that I want to
send to the queue.

FYI, here is a simplified version of my route:

       
from("jetty:http://0.0.0.0:8282/process").convertBodyTo(String.class)
        .inOnly("jms:queue:data.inbound")
        .unmarshal(jaxbDf)
        .beanRef("dataProcessor", "process")


Allen Lau-2 wrote:
> 
> How about just setting a header when you are done processing and there is
> an
> error?
> 
> Then in your route, just send any message to the error queue when the
> header
> is detected.
> 
> On Tue, Mar 23, 2010 at 11:57 AM, jfaath <jf...@apache.org> wrote:
> 
>>
>> I'm looking for some advice on how to deal with errors during a large
>> processing task.  It seems like it should be simple but I'm having
>> trouble
>> figuring out what to do.
>>
>> I have an HTTP endpoint that receives XML messages then sticks them in a
>> processing queue.  From the queue, they get unmarshalled into JAXB
>> objects
>> and then processed by a Java class.  Now, the messages consist or a large
>> number of readings.  Some may be good, some may be bad.  The good ones
>> get
>> processed, but the bad ones are stuffed into a JAXB object.
>>
>> When the processing is done, I'd like to throw this object on an error
>> queue
>> (or, marshal then throw on the queue).  But I can't figure out how to do
>> this the best way.  The processing class should exit gracefully so I
>> don't
>> want to throw a final exception.
>>
>> What might be the best way to do this?  Can I add the error object to a
>> queue programmatically within the processor?  Can the processor return
>> the
>> error object so I can throw it on the queue via the route?  Is there a
>> nice
>> and easy way to do this?
>>
>> Thanks,
>>
>> JF
>> --
>> View this message in context:
>> http://old.nabble.com/error-handling-advice-with-queues-tp28005566p28005566.html
>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>
>>
> 
> 

-- 
View this message in context: http://old.nabble.com/error-handling-advice-with-queues-tp28005566p28008395.html
Sent from the Camel - Users mailing list archive at Nabble.com.


Re: error-handling advice with queues

Posted by Allen Lau <al...@gmail.com>.
How about just setting a header when you are done processing and there is an
error?

Then in your route, just send any message to the error queue when the header
is detected.

On Tue, Mar 23, 2010 at 11:57 AM, jfaath <jf...@apache.org> wrote:

>
> I'm looking for some advice on how to deal with errors during a large
> processing task.  It seems like it should be simple but I'm having trouble
> figuring out what to do.
>
> I have an HTTP endpoint that receives XML messages then sticks them in a
> processing queue.  From the queue, they get unmarshalled into JAXB objects
> and then processed by a Java class.  Now, the messages consist or a large
> number of readings.  Some may be good, some may be bad.  The good ones get
> processed, but the bad ones are stuffed into a JAXB object.
>
> When the processing is done, I'd like to throw this object on an error
> queue
> (or, marshal then throw on the queue).  But I can't figure out how to do
> this the best way.  The processing class should exit gracefully so I don't
> want to throw a final exception.
>
> What might be the best way to do this?  Can I add the error object to a
> queue programmatically within the processor?  Can the processor return the
> error object so I can throw it on the queue via the route?  Is there a nice
> and easy way to do this?
>
> Thanks,
>
> JF
> --
> View this message in context:
> http://old.nabble.com/error-handling-advice-with-queues-tp28005566p28005566.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
>