You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by "kraythe ." <kr...@gmail.com> on 2014/05/22 23:00:29 UTC
How to Implment Informative Transactional Error Handling?
Greetings, I have many routes that read from AMQ queues and write to other
AMQ queues. For error handling I have been using the following paradigm:
from("activemq:queue:inbox")
.onException(Exception.class).useOriginalMessage().handled(handled).maximumRedeliveries(0)
.setHeader(Exchange.FAILURE_ROUTE_ID, property(Exchange.FAILURE_ROUTE_ID))
.setHeader(Exchange.EXCEPTION_CAUGHT, simple("${exception.stacktrace}"))
.to(ExchangePattern.InOnly, "activemq:queue:dead").end();
.process(new PreProcessor())
.to("activemq:queue:outbox")
.process(new PostProcessor());
The goal being that if there was any kind of exception, that information
would be noted in the headers on the message before it was sent off to the
DLQ. The problem is this runs into roadblocks when transacted() is added to
the route.
With the code above when the route is transacted and a message fails in
post processing I want the message pulled off the outbox, record
information indicating what the exception was, and have the message sent to
the DLQ. Unfortunately I seem to be in a quandary of how to do this.
The code above simply wont work because the message being sent to the dead
letter queue gets rolled back along with the outbox if I mark the exchange
with rollback() in the exception handler. If I don't mark the message with
rollback() in the handler then the outbox doesn't get rolled back if the
post processor exceptions but the dead letter channel will contain the
correct information. On the other hand if I just let activemq handle the
transaction, it will retry and then eventually send the message to the DLQ
but the message in the DLQ will contain no information about why it failed.
So I want my cake and eat it too. I want to be able to record WHY an
exchange failed but still be able to rollback the outbox at the same time.
I have been plugging away at this a ton and I am out of ideas. What would
not be acceptable would be to require the user to troll through log files
trying to find a reason why an exchange failed. This would be an
operational nightmare. So the message and the reason for the rollback need
to be somewhere accessible and they need to be together.
I would appreciate any suggestions on how I could make this happen.
*Robert Simmons Jr. MSc. - Lead Java Architect @ EA*
*Author of: Hardcore Java (2003) and Maintainable Java (2012)*
*LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39
<http://www.linkedin.com/pub/robert-simmons/40/852/a39>*
Re: How to Implment Informative Transactional Error Handling?
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
See
http://camel.apache.org/message-history
You can get access to the message history yourself and do your own
json output and logging or whatever you want.
You should then turn off the default message history logging on the
error handler.
On Wed, May 28, 2014 at 6:17 PM, kraythe . <kr...@gmail.com> wrote:
> So I opted for a multi phasic approach. We are changing AMQ to not do any
> redeliveries but to handle DLQ for us.
>
> http://activemq.apache.org/message-redelivery-and-dlq-handling.html
>
> So we are asking activemq to not do any redelivery of the the messages and
> instead handling any redelivery on a route by route basis:
>
> from(uri).onException(IOException.class).maximumRedeliveries(2).soOn()
>
> What this means is that the message history will not be in the message on
> the DLQ but rather only in the log file. That makes it a bit more
> problematic to read but we will set up a nagios monitor on that log to look
> for those errors.
>
> The only problem I have now, then, is that the message history format is
> not entirely useful. It truncates route ids in the message history making
> things harder to trace. It would be nice if it would print out the message
> history as JSON instead. I might see if there is a way I can extract that
> message history and send it to the log directly myself with an error
> handler or exception handler. I am, however, trying to shy away from
> boilerplate exception handling in routes. What would be the ability to
> control the message history output. I would rather have an exhaustive
> history as a JSON compliant object like:
>
> "History": [
> {
> "RouteId" : "com.ea.someproject.somemodule.TestRoute",
> "ProcessorId" : "TestRoute",
> "Processor" : "activemq://queue:inbox",
> "Elapsed" : 3
> }
> {
> "RouteId" : "com.ea.someproject.somemodule.TestRoute",
> "ProcessorId" : "transacted13",
> "Processor" :
> "transacted[ref:java:app/activemq/txnManager/policy/REQUIRES_NEW",
> "Elapsed" : 2
> }
> ],
>
> And so on. We can plug in an exchange formatter but not the history
> formatter. I am wondering if there is a way I can suppress logging of
> message history without suppressing the collection of it and then log
> myself with the exchange formatter. Im sure there is some way to do it.
>
> *Robert Simmons Jr. MSc. - Lead Java Architect @ EA*
> *Author of: Hardcore Java (2003) and Maintainable Java (2012)*
> *LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39
> <http://www.linkedin.com/pub/robert-simmons/40/852/a39>*
>
>
> On Sat, May 24, 2014 at 1:16 AM, Claus Ibsen <cl...@gmail.com> wrote:
>
>> On Fri, May 23, 2014 at 6:52 PM, kraythe . <kr...@gmail.com> wrote:
>> > Its an idea but I think I would run into the same problem. The rollback
>> of
>> > the failed transation would roll back the message to the details queue as
>> > well. The problem is I need the write to the details or error queue to be
>> > outside the transaction but the inbox and outbox should be in the
>> > transaction.
>> >
>>
>> Yeah and you can do that by using a 2nd jms component that has not
>> been configured as transacted. And use the 2nd jms component to write
>> to the details queue.
>>
>> > *Robert Simmons Jr. MSc. - Lead Java Architect @ EA*
>> > *Author of: Hardcore Java (2003) and Maintainable Java (2012)*
>> > *LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39
>> > <http://www.linkedin.com/pub/robert-simmons/40/852/a39>*
>> >
>> >
>> > On Fri, May 23, 2014 at 9:14 AM, Claus Ibsen <cl...@gmail.com>
>> wrote:
>> >
>> >> Hi
>> >>
>> >> Maybe send the error details to another queue, and have a way to
>> >> correlate that message to the other message that goes into the DLQ.
>> >>
>> >> Though its a bit tricky as AMQ handles the DLQ, and Camel only would
>> >> know if its the last attempt, if you use the JMSRedeliveryCounter to
>> >> know it was the last redelivery attempt, so the message is going to
>> >> the DLQ when its rolled back this last time. And therefore I should
>> >> send a message about this exception to another queue (outside this
>> >> TX).
>> >>
>> >> You can then maybe have another Camel route that reads from the DLQ
>> >> and then enrich that message with the other message from the queue
>> >> which has the exception details, and move to a final DQL, so you have
>> >> all details in the same JMS message.
>> >>
>> >>
>> >>
>> >> On Fri, May 23, 2014 at 4:10 PM, kraythe . <kr...@gmail.com> wrote:
>> >> > Yeah, I know the rollback doesn't work that way. That wasn't what I
>> was
>> >> > driving at. I am just trying to deal with a business problem of
>> informing
>> >> > the investigator why an exchange failed though means other than
>> >> spelunking
>> >> > in a verbose log file for clues. Sometimes one investigating a problem
>> >> may
>> >> > not have access even to the logs. For example if a business issue such
>> >> as a
>> >> > studio's game site went down causing the exchanges to fail. In this
>> >> > circumstance we would rather push the exchange to a dead letter queue
>> and
>> >> > then later be able to determine why the problem happened and relish
>> those
>> >> > exchanges. Again finding the "why" in a log file isn't going to work
>> out.
>> >> >
>> >> > -- Robert
>> >> >
>> >> > On Friday, May 23, 2014, Claus Ibsen <cl...@gmail.com> wrote:
>> >> >
>> >> >> You cannot provide a reason why a rollback happens in the TX API.
>> >> >> There is no rollback(String message) api for that.
>> >> >>
>> >> >> You need to record this somewhere else if you want to use that.
>> >> >> Or do your own kind of TX rollback.
>> >> >>
>> >> >> On Thu, May 22, 2014 at 11:00 PM, kraythe . <kraythe@gmail.com
>> >> <javascript:;>>
>> >> >> wrote:
>> >> >> > Greetings, I have many routes that read from AMQ queues and write
>> to
>> >> >> other
>> >> >> > AMQ queues. For error handling I have been using the following
>> >> paradigm:
>> >> >> >
>> >> >> > from("activemq:queue:inbox")
>> >> >> >
>> >> >> >
>> >> >>
>> >>
>> .onException(Exception.class).useOriginalMessage().handled(handled).maximumRedeliveries(0)
>> >> >> > .setHeader(Exchange.FAILURE_ROUTE_ID,
>> >> >> property(Exchange.FAILURE_ROUTE_ID))
>> >> >> > .setHeader(Exchange.EXCEPTION_CAUGHT,
>> >> >> simple("${exception.stacktrace}"))
>> >> >> > .to(ExchangePattern.InOnly, "activemq:queue:dead").end();
>> >> >> > .process(new PreProcessor())
>> >> >> > .to("activemq:queue:outbox")
>> >> >> > .process(new PostProcessor());
>> >> >> >
>> >> >> > The goal being that if there was any kind of exception, that
>> >> information
>> >> >> > would be noted in the headers on the message before it was sent
>> off to
>> >> >> the
>> >> >> > DLQ. The problem is this runs into roadblocks when transacted() is
>> >> added
>> >> >> to
>> >> >> > the route.
>> >> >> >
>> >> >> > With the code above when the route is transacted and a message
>> fails
>> >> in
>> >> >> > post processing I want the message pulled off the outbox, record
>> >> >> > information indicating what the exception was, and have the message
>> >> sent
>> >> >> to
>> >> >> > the DLQ. Unfortunately I seem to be in a quandary of how to do
>> this.
>> >> >> >
>> >> >> > The code above simply wont work because the message being sent to
>> the
>> >> >> dead
>> >> >> > letter queue gets rolled back along with the outbox if I mark the
>> >> >> exchange
>> >> >> > with rollback() in the exception handler. If I don't mark the
>> message
>> >> >> with
>> >> >> > rollback() in the handler then the outbox doesn't get rolled back
>> if
>> >> the
>> >> >> > post processor exceptions but the dead letter channel will contain
>> the
>> >> >> > correct information. On the other hand if I just let activemq
>> handle
>> >> the
>> >> >> > transaction, it will retry and then eventually send the message to
>> the
>> >> >> DLQ
>> >> >> > but the message in the DLQ will contain no information about why it
>> >> >> failed.
>> >> >> >
>> >> >> > So I want my cake and eat it too. I want to be able to record WHY
>> an
>> >> >> > exchange failed but still be able to rollback the outbox at the
>> same
>> >> >> time.
>> >> >> > I have been plugging away at this a ton and I am out of ideas. What
>> >> would
>> >> >> > not be acceptable would be to require the user to troll through log
>> >> files
>> >> >> > trying to find a reason why an exchange failed. This would be an
>> >> >> > operational nightmare. So the message and the reason for the
>> rollback
>> >> >> need
>> >> >> > to be somewhere accessible and they need to be together.
>> >> >> >
>> >> >> > I would appreciate any suggestions on how I could make this happen.
>> >> >> >
>> >> >> > *Robert Simmons Jr. MSc. - Lead Java Architect @ EA*
>> >> >> > *Author of: Hardcore Java (2003) and Maintainable Java (2012)*
>> >> >> > *LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39
>> >> >> > <http://www.linkedin.com/pub/robert-simmons/40/852/a39>*
>> >> >>
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Claus Ibsen
>> >> >> -----------------
>> >> >> Red Hat, Inc.
>> >> >> Email: cibsen@redhat.com <javascript:;>
>> >> >> Twitter: davsclaus
>> >> >> Blog: http://davsclaus.com
>> >> >> Author of Camel in Action: http://www.manning.com/ibsen
>> >> >> hawtio: http://hawt.io/
>> >> >> fabric8: http://fabric8.io/
>> >> >>
>> >> >
>> >> >
>> >> > --
>> >> > *Robert Simmons Jr. MSc. - Lead Java Architect @ EA*
>> >> > *Author of: Hardcore Java (2003) and Maintainable Java (2012)*
>> >> > *LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39
>> >> > <http://www.linkedin.com/pub/robert-simmons/40/852/a39>*
>> >>
>> >>
>> >>
>> >> --
>> >> Claus Ibsen
>> >> -----------------
>> >> Red Hat, Inc.
>> >> Email: cibsen@redhat.com
>> >> Twitter: davsclaus
>> >> Blog: http://davsclaus.com
>> >> Author of Camel in Action: http://www.manning.com/ibsen
>> >> hawtio: http://hawt.io/
>> >> fabric8: http://fabric8.io/
>> >>
>>
>>
>>
>> --
>> Claus Ibsen
>> -----------------
>> Red Hat, Inc.
>> Email: cibsen@redhat.com
>> Twitter: davsclaus
>> Blog: http://davsclaus.com
>> Author of Camel in Action: http://www.manning.com/ibsen
>> hawtio: http://hawt.io/
>> fabric8: http://fabric8.io/
>>
--
Claus Ibsen
-----------------
Red Hat, Inc.
Email: cibsen@redhat.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
hawtio: http://hawt.io/
fabric8: http://fabric8.io/
Re: How to Implment Informative Transactional Error Handling?
Posted by "kraythe ." <kr...@gmail.com>.
So I opted for a multi phasic approach. We are changing AMQ to not do any
redeliveries but to handle DLQ for us.
http://activemq.apache.org/message-redelivery-and-dlq-handling.html
So we are asking activemq to not do any redelivery of the the messages and
instead handling any redelivery on a route by route basis:
from(uri).onException(IOException.class).maximumRedeliveries(2).soOn()
What this means is that the message history will not be in the message on
the DLQ but rather only in the log file. That makes it a bit more
problematic to read but we will set up a nagios monitor on that log to look
for those errors.
The only problem I have now, then, is that the message history format is
not entirely useful. It truncates route ids in the message history making
things harder to trace. It would be nice if it would print out the message
history as JSON instead. I might see if there is a way I can extract that
message history and send it to the log directly myself with an error
handler or exception handler. I am, however, trying to shy away from
boilerplate exception handling in routes. What would be the ability to
control the message history output. I would rather have an exhaustive
history as a JSON compliant object like:
"History": [
{
"RouteId" : "com.ea.someproject.somemodule.TestRoute",
"ProcessorId" : "TestRoute",
"Processor" : "activemq://queue:inbox",
"Elapsed" : 3
}
{
"RouteId" : "com.ea.someproject.somemodule.TestRoute",
"ProcessorId" : "transacted13",
"Processor" :
"transacted[ref:java:app/activemq/txnManager/policy/REQUIRES_NEW",
"Elapsed" : 2
}
],
And so on. We can plug in an exchange formatter but not the history
formatter. I am wondering if there is a way I can suppress logging of
message history without suppressing the collection of it and then log
myself with the exchange formatter. Im sure there is some way to do it.
*Robert Simmons Jr. MSc. - Lead Java Architect @ EA*
*Author of: Hardcore Java (2003) and Maintainable Java (2012)*
*LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39
<http://www.linkedin.com/pub/robert-simmons/40/852/a39>*
On Sat, May 24, 2014 at 1:16 AM, Claus Ibsen <cl...@gmail.com> wrote:
> On Fri, May 23, 2014 at 6:52 PM, kraythe . <kr...@gmail.com> wrote:
> > Its an idea but I think I would run into the same problem. The rollback
> of
> > the failed transation would roll back the message to the details queue as
> > well. The problem is I need the write to the details or error queue to be
> > outside the transaction but the inbox and outbox should be in the
> > transaction.
> >
>
> Yeah and you can do that by using a 2nd jms component that has not
> been configured as transacted. And use the 2nd jms component to write
> to the details queue.
>
> > *Robert Simmons Jr. MSc. - Lead Java Architect @ EA*
> > *Author of: Hardcore Java (2003) and Maintainable Java (2012)*
> > *LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39
> > <http://www.linkedin.com/pub/robert-simmons/40/852/a39>*
> >
> >
> > On Fri, May 23, 2014 at 9:14 AM, Claus Ibsen <cl...@gmail.com>
> wrote:
> >
> >> Hi
> >>
> >> Maybe send the error details to another queue, and have a way to
> >> correlate that message to the other message that goes into the DLQ.
> >>
> >> Though its a bit tricky as AMQ handles the DLQ, and Camel only would
> >> know if its the last attempt, if you use the JMSRedeliveryCounter to
> >> know it was the last redelivery attempt, so the message is going to
> >> the DLQ when its rolled back this last time. And therefore I should
> >> send a message about this exception to another queue (outside this
> >> TX).
> >>
> >> You can then maybe have another Camel route that reads from the DLQ
> >> and then enrich that message with the other message from the queue
> >> which has the exception details, and move to a final DQL, so you have
> >> all details in the same JMS message.
> >>
> >>
> >>
> >> On Fri, May 23, 2014 at 4:10 PM, kraythe . <kr...@gmail.com> wrote:
> >> > Yeah, I know the rollback doesn't work that way. That wasn't what I
> was
> >> > driving at. I am just trying to deal with a business problem of
> informing
> >> > the investigator why an exchange failed though means other than
> >> spelunking
> >> > in a verbose log file for clues. Sometimes one investigating a problem
> >> may
> >> > not have access even to the logs. For example if a business issue such
> >> as a
> >> > studio's game site went down causing the exchanges to fail. In this
> >> > circumstance we would rather push the exchange to a dead letter queue
> and
> >> > then later be able to determine why the problem happened and relish
> those
> >> > exchanges. Again finding the "why" in a log file isn't going to work
> out.
> >> >
> >> > -- Robert
> >> >
> >> > On Friday, May 23, 2014, Claus Ibsen <cl...@gmail.com> wrote:
> >> >
> >> >> You cannot provide a reason why a rollback happens in the TX API.
> >> >> There is no rollback(String message) api for that.
> >> >>
> >> >> You need to record this somewhere else if you want to use that.
> >> >> Or do your own kind of TX rollback.
> >> >>
> >> >> On Thu, May 22, 2014 at 11:00 PM, kraythe . <kraythe@gmail.com
> >> <javascript:;>>
> >> >> wrote:
> >> >> > Greetings, I have many routes that read from AMQ queues and write
> to
> >> >> other
> >> >> > AMQ queues. For error handling I have been using the following
> >> paradigm:
> >> >> >
> >> >> > from("activemq:queue:inbox")
> >> >> >
> >> >> >
> >> >>
> >>
> .onException(Exception.class).useOriginalMessage().handled(handled).maximumRedeliveries(0)
> >> >> > .setHeader(Exchange.FAILURE_ROUTE_ID,
> >> >> property(Exchange.FAILURE_ROUTE_ID))
> >> >> > .setHeader(Exchange.EXCEPTION_CAUGHT,
> >> >> simple("${exception.stacktrace}"))
> >> >> > .to(ExchangePattern.InOnly, "activemq:queue:dead").end();
> >> >> > .process(new PreProcessor())
> >> >> > .to("activemq:queue:outbox")
> >> >> > .process(new PostProcessor());
> >> >> >
> >> >> > The goal being that if there was any kind of exception, that
> >> information
> >> >> > would be noted in the headers on the message before it was sent
> off to
> >> >> the
> >> >> > DLQ. The problem is this runs into roadblocks when transacted() is
> >> added
> >> >> to
> >> >> > the route.
> >> >> >
> >> >> > With the code above when the route is transacted and a message
> fails
> >> in
> >> >> > post processing I want the message pulled off the outbox, record
> >> >> > information indicating what the exception was, and have the message
> >> sent
> >> >> to
> >> >> > the DLQ. Unfortunately I seem to be in a quandary of how to do
> this.
> >> >> >
> >> >> > The code above simply wont work because the message being sent to
> the
> >> >> dead
> >> >> > letter queue gets rolled back along with the outbox if I mark the
> >> >> exchange
> >> >> > with rollback() in the exception handler. If I don't mark the
> message
> >> >> with
> >> >> > rollback() in the handler then the outbox doesn't get rolled back
> if
> >> the
> >> >> > post processor exceptions but the dead letter channel will contain
> the
> >> >> > correct information. On the other hand if I just let activemq
> handle
> >> the
> >> >> > transaction, it will retry and then eventually send the message to
> the
> >> >> DLQ
> >> >> > but the message in the DLQ will contain no information about why it
> >> >> failed.
> >> >> >
> >> >> > So I want my cake and eat it too. I want to be able to record WHY
> an
> >> >> > exchange failed but still be able to rollback the outbox at the
> same
> >> >> time.
> >> >> > I have been plugging away at this a ton and I am out of ideas. What
> >> would
> >> >> > not be acceptable would be to require the user to troll through log
> >> files
> >> >> > trying to find a reason why an exchange failed. This would be an
> >> >> > operational nightmare. So the message and the reason for the
> rollback
> >> >> need
> >> >> > to be somewhere accessible and they need to be together.
> >> >> >
> >> >> > I would appreciate any suggestions on how I could make this happen.
> >> >> >
> >> >> > *Robert Simmons Jr. MSc. - Lead Java Architect @ EA*
> >> >> > *Author of: Hardcore Java (2003) and Maintainable Java (2012)*
> >> >> > *LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39
> >> >> > <http://www.linkedin.com/pub/robert-simmons/40/852/a39>*
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> Claus Ibsen
> >> >> -----------------
> >> >> Red Hat, Inc.
> >> >> Email: cibsen@redhat.com <javascript:;>
> >> >> Twitter: davsclaus
> >> >> Blog: http://davsclaus.com
> >> >> Author of Camel in Action: http://www.manning.com/ibsen
> >> >> hawtio: http://hawt.io/
> >> >> fabric8: http://fabric8.io/
> >> >>
> >> >
> >> >
> >> > --
> >> > *Robert Simmons Jr. MSc. - Lead Java Architect @ EA*
> >> > *Author of: Hardcore Java (2003) and Maintainable Java (2012)*
> >> > *LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39
> >> > <http://www.linkedin.com/pub/robert-simmons/40/852/a39>*
> >>
> >>
> >>
> >> --
> >> Claus Ibsen
> >> -----------------
> >> Red Hat, Inc.
> >> Email: cibsen@redhat.com
> >> Twitter: davsclaus
> >> Blog: http://davsclaus.com
> >> Author of Camel in Action: http://www.manning.com/ibsen
> >> hawtio: http://hawt.io/
> >> fabric8: http://fabric8.io/
> >>
>
>
>
> --
> Claus Ibsen
> -----------------
> Red Hat, Inc.
> Email: cibsen@redhat.com
> Twitter: davsclaus
> Blog: http://davsclaus.com
> Author of Camel in Action: http://www.manning.com/ibsen
> hawtio: http://hawt.io/
> fabric8: http://fabric8.io/
>
Re: How to Implment Informative Transactional Error Handling?
Posted by Claus Ibsen <cl...@gmail.com>.
On Fri, May 23, 2014 at 6:52 PM, kraythe . <kr...@gmail.com> wrote:
> Its an idea but I think I would run into the same problem. The rollback of
> the failed transation would roll back the message to the details queue as
> well. The problem is I need the write to the details or error queue to be
> outside the transaction but the inbox and outbox should be in the
> transaction.
>
Yeah and you can do that by using a 2nd jms component that has not
been configured as transacted. And use the 2nd jms component to write
to the details queue.
> *Robert Simmons Jr. MSc. - Lead Java Architect @ EA*
> *Author of: Hardcore Java (2003) and Maintainable Java (2012)*
> *LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39
> <http://www.linkedin.com/pub/robert-simmons/40/852/a39>*
>
>
> On Fri, May 23, 2014 at 9:14 AM, Claus Ibsen <cl...@gmail.com> wrote:
>
>> Hi
>>
>> Maybe send the error details to another queue, and have a way to
>> correlate that message to the other message that goes into the DLQ.
>>
>> Though its a bit tricky as AMQ handles the DLQ, and Camel only would
>> know if its the last attempt, if you use the JMSRedeliveryCounter to
>> know it was the last redelivery attempt, so the message is going to
>> the DLQ when its rolled back this last time. And therefore I should
>> send a message about this exception to another queue (outside this
>> TX).
>>
>> You can then maybe have another Camel route that reads from the DLQ
>> and then enrich that message with the other message from the queue
>> which has the exception details, and move to a final DQL, so you have
>> all details in the same JMS message.
>>
>>
>>
>> On Fri, May 23, 2014 at 4:10 PM, kraythe . <kr...@gmail.com> wrote:
>> > Yeah, I know the rollback doesn't work that way. That wasn't what I was
>> > driving at. I am just trying to deal with a business problem of informing
>> > the investigator why an exchange failed though means other than
>> spelunking
>> > in a verbose log file for clues. Sometimes one investigating a problem
>> may
>> > not have access even to the logs. For example if a business issue such
>> as a
>> > studio's game site went down causing the exchanges to fail. In this
>> > circumstance we would rather push the exchange to a dead letter queue and
>> > then later be able to determine why the problem happened and relish those
>> > exchanges. Again finding the "why" in a log file isn't going to work out.
>> >
>> > -- Robert
>> >
>> > On Friday, May 23, 2014, Claus Ibsen <cl...@gmail.com> wrote:
>> >
>> >> You cannot provide a reason why a rollback happens in the TX API.
>> >> There is no rollback(String message) api for that.
>> >>
>> >> You need to record this somewhere else if you want to use that.
>> >> Or do your own kind of TX rollback.
>> >>
>> >> On Thu, May 22, 2014 at 11:00 PM, kraythe . <kraythe@gmail.com
>> <javascript:;>>
>> >> wrote:
>> >> > Greetings, I have many routes that read from AMQ queues and write to
>> >> other
>> >> > AMQ queues. For error handling I have been using the following
>> paradigm:
>> >> >
>> >> > from("activemq:queue:inbox")
>> >> >
>> >> >
>> >>
>> .onException(Exception.class).useOriginalMessage().handled(handled).maximumRedeliveries(0)
>> >> > .setHeader(Exchange.FAILURE_ROUTE_ID,
>> >> property(Exchange.FAILURE_ROUTE_ID))
>> >> > .setHeader(Exchange.EXCEPTION_CAUGHT,
>> >> simple("${exception.stacktrace}"))
>> >> > .to(ExchangePattern.InOnly, "activemq:queue:dead").end();
>> >> > .process(new PreProcessor())
>> >> > .to("activemq:queue:outbox")
>> >> > .process(new PostProcessor());
>> >> >
>> >> > The goal being that if there was any kind of exception, that
>> information
>> >> > would be noted in the headers on the message before it was sent off to
>> >> the
>> >> > DLQ. The problem is this runs into roadblocks when transacted() is
>> added
>> >> to
>> >> > the route.
>> >> >
>> >> > With the code above when the route is transacted and a message fails
>> in
>> >> > post processing I want the message pulled off the outbox, record
>> >> > information indicating what the exception was, and have the message
>> sent
>> >> to
>> >> > the DLQ. Unfortunately I seem to be in a quandary of how to do this.
>> >> >
>> >> > The code above simply wont work because the message being sent to the
>> >> dead
>> >> > letter queue gets rolled back along with the outbox if I mark the
>> >> exchange
>> >> > with rollback() in the exception handler. If I don't mark the message
>> >> with
>> >> > rollback() in the handler then the outbox doesn't get rolled back if
>> the
>> >> > post processor exceptions but the dead letter channel will contain the
>> >> > correct information. On the other hand if I just let activemq handle
>> the
>> >> > transaction, it will retry and then eventually send the message to the
>> >> DLQ
>> >> > but the message in the DLQ will contain no information about why it
>> >> failed.
>> >> >
>> >> > So I want my cake and eat it too. I want to be able to record WHY an
>> >> > exchange failed but still be able to rollback the outbox at the same
>> >> time.
>> >> > I have been plugging away at this a ton and I am out of ideas. What
>> would
>> >> > not be acceptable would be to require the user to troll through log
>> files
>> >> > trying to find a reason why an exchange failed. This would be an
>> >> > operational nightmare. So the message and the reason for the rollback
>> >> need
>> >> > to be somewhere accessible and they need to be together.
>> >> >
>> >> > I would appreciate any suggestions on how I could make this happen.
>> >> >
>> >> > *Robert Simmons Jr. MSc. - Lead Java Architect @ EA*
>> >> > *Author of: Hardcore Java (2003) and Maintainable Java (2012)*
>> >> > *LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39
>> >> > <http://www.linkedin.com/pub/robert-simmons/40/852/a39>*
>> >>
>> >>
>> >>
>> >> --
>> >> Claus Ibsen
>> >> -----------------
>> >> Red Hat, Inc.
>> >> Email: cibsen@redhat.com <javascript:;>
>> >> Twitter: davsclaus
>> >> Blog: http://davsclaus.com
>> >> Author of Camel in Action: http://www.manning.com/ibsen
>> >> hawtio: http://hawt.io/
>> >> fabric8: http://fabric8.io/
>> >>
>> >
>> >
>> > --
>> > *Robert Simmons Jr. MSc. - Lead Java Architect @ EA*
>> > *Author of: Hardcore Java (2003) and Maintainable Java (2012)*
>> > *LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39
>> > <http://www.linkedin.com/pub/robert-simmons/40/852/a39>*
>>
>>
>>
>> --
>> Claus Ibsen
>> -----------------
>> Red Hat, Inc.
>> Email: cibsen@redhat.com
>> Twitter: davsclaus
>> Blog: http://davsclaus.com
>> Author of Camel in Action: http://www.manning.com/ibsen
>> hawtio: http://hawt.io/
>> fabric8: http://fabric8.io/
>>
--
Claus Ibsen
-----------------
Red Hat, Inc.
Email: cibsen@redhat.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
hawtio: http://hawt.io/
fabric8: http://fabric8.io/
Re: How to Implment Informative Transactional Error Handling?
Posted by "kraythe ." <kr...@gmail.com>.
Its an idea but I think I would run into the same problem. The rollback of
the failed transation would roll back the message to the details queue as
well. The problem is I need the write to the details or error queue to be
outside the transaction but the inbox and outbox should be in the
transaction.
*Robert Simmons Jr. MSc. - Lead Java Architect @ EA*
*Author of: Hardcore Java (2003) and Maintainable Java (2012)*
*LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39
<http://www.linkedin.com/pub/robert-simmons/40/852/a39>*
On Fri, May 23, 2014 at 9:14 AM, Claus Ibsen <cl...@gmail.com> wrote:
> Hi
>
> Maybe send the error details to another queue, and have a way to
> correlate that message to the other message that goes into the DLQ.
>
> Though its a bit tricky as AMQ handles the DLQ, and Camel only would
> know if its the last attempt, if you use the JMSRedeliveryCounter to
> know it was the last redelivery attempt, so the message is going to
> the DLQ when its rolled back this last time. And therefore I should
> send a message about this exception to another queue (outside this
> TX).
>
> You can then maybe have another Camel route that reads from the DLQ
> and then enrich that message with the other message from the queue
> which has the exception details, and move to a final DQL, so you have
> all details in the same JMS message.
>
>
>
> On Fri, May 23, 2014 at 4:10 PM, kraythe . <kr...@gmail.com> wrote:
> > Yeah, I know the rollback doesn't work that way. That wasn't what I was
> > driving at. I am just trying to deal with a business problem of informing
> > the investigator why an exchange failed though means other than
> spelunking
> > in a verbose log file for clues. Sometimes one investigating a problem
> may
> > not have access even to the logs. For example if a business issue such
> as a
> > studio's game site went down causing the exchanges to fail. In this
> > circumstance we would rather push the exchange to a dead letter queue and
> > then later be able to determine why the problem happened and relish those
> > exchanges. Again finding the "why" in a log file isn't going to work out.
> >
> > -- Robert
> >
> > On Friday, May 23, 2014, Claus Ibsen <cl...@gmail.com> wrote:
> >
> >> You cannot provide a reason why a rollback happens in the TX API.
> >> There is no rollback(String message) api for that.
> >>
> >> You need to record this somewhere else if you want to use that.
> >> Or do your own kind of TX rollback.
> >>
> >> On Thu, May 22, 2014 at 11:00 PM, kraythe . <kraythe@gmail.com
> <javascript:;>>
> >> wrote:
> >> > Greetings, I have many routes that read from AMQ queues and write to
> >> other
> >> > AMQ queues. For error handling I have been using the following
> paradigm:
> >> >
> >> > from("activemq:queue:inbox")
> >> >
> >> >
> >>
> .onException(Exception.class).useOriginalMessage().handled(handled).maximumRedeliveries(0)
> >> > .setHeader(Exchange.FAILURE_ROUTE_ID,
> >> property(Exchange.FAILURE_ROUTE_ID))
> >> > .setHeader(Exchange.EXCEPTION_CAUGHT,
> >> simple("${exception.stacktrace}"))
> >> > .to(ExchangePattern.InOnly, "activemq:queue:dead").end();
> >> > .process(new PreProcessor())
> >> > .to("activemq:queue:outbox")
> >> > .process(new PostProcessor());
> >> >
> >> > The goal being that if there was any kind of exception, that
> information
> >> > would be noted in the headers on the message before it was sent off to
> >> the
> >> > DLQ. The problem is this runs into roadblocks when transacted() is
> added
> >> to
> >> > the route.
> >> >
> >> > With the code above when the route is transacted and a message fails
> in
> >> > post processing I want the message pulled off the outbox, record
> >> > information indicating what the exception was, and have the message
> sent
> >> to
> >> > the DLQ. Unfortunately I seem to be in a quandary of how to do this.
> >> >
> >> > The code above simply wont work because the message being sent to the
> >> dead
> >> > letter queue gets rolled back along with the outbox if I mark the
> >> exchange
> >> > with rollback() in the exception handler. If I don't mark the message
> >> with
> >> > rollback() in the handler then the outbox doesn't get rolled back if
> the
> >> > post processor exceptions but the dead letter channel will contain the
> >> > correct information. On the other hand if I just let activemq handle
> the
> >> > transaction, it will retry and then eventually send the message to the
> >> DLQ
> >> > but the message in the DLQ will contain no information about why it
> >> failed.
> >> >
> >> > So I want my cake and eat it too. I want to be able to record WHY an
> >> > exchange failed but still be able to rollback the outbox at the same
> >> time.
> >> > I have been plugging away at this a ton and I am out of ideas. What
> would
> >> > not be acceptable would be to require the user to troll through log
> files
> >> > trying to find a reason why an exchange failed. This would be an
> >> > operational nightmare. So the message and the reason for the rollback
> >> need
> >> > to be somewhere accessible and they need to be together.
> >> >
> >> > I would appreciate any suggestions on how I could make this happen.
> >> >
> >> > *Robert Simmons Jr. MSc. - Lead Java Architect @ EA*
> >> > *Author of: Hardcore Java (2003) and Maintainable Java (2012)*
> >> > *LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39
> >> > <http://www.linkedin.com/pub/robert-simmons/40/852/a39>*
> >>
> >>
> >>
> >> --
> >> Claus Ibsen
> >> -----------------
> >> Red Hat, Inc.
> >> Email: cibsen@redhat.com <javascript:;>
> >> Twitter: davsclaus
> >> Blog: http://davsclaus.com
> >> Author of Camel in Action: http://www.manning.com/ibsen
> >> hawtio: http://hawt.io/
> >> fabric8: http://fabric8.io/
> >>
> >
> >
> > --
> > *Robert Simmons Jr. MSc. - Lead Java Architect @ EA*
> > *Author of: Hardcore Java (2003) and Maintainable Java (2012)*
> > *LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39
> > <http://www.linkedin.com/pub/robert-simmons/40/852/a39>*
>
>
>
> --
> Claus Ibsen
> -----------------
> Red Hat, Inc.
> Email: cibsen@redhat.com
> Twitter: davsclaus
> Blog: http://davsclaus.com
> Author of Camel in Action: http://www.manning.com/ibsen
> hawtio: http://hawt.io/
> fabric8: http://fabric8.io/
>
Re: How to Implment Informative Transactional Error Handling?
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
Maybe send the error details to another queue, and have a way to
correlate that message to the other message that goes into the DLQ.
Though its a bit tricky as AMQ handles the DLQ, and Camel only would
know if its the last attempt, if you use the JMSRedeliveryCounter to
know it was the last redelivery attempt, so the message is going to
the DLQ when its rolled back this last time. And therefore I should
send a message about this exception to another queue (outside this
TX).
You can then maybe have another Camel route that reads from the DLQ
and then enrich that message with the other message from the queue
which has the exception details, and move to a final DQL, so you have
all details in the same JMS message.
On Fri, May 23, 2014 at 4:10 PM, kraythe . <kr...@gmail.com> wrote:
> Yeah, I know the rollback doesn't work that way. That wasn't what I was
> driving at. I am just trying to deal with a business problem of informing
> the investigator why an exchange failed though means other than spelunking
> in a verbose log file for clues. Sometimes one investigating a problem may
> not have access even to the logs. For example if a business issue such as a
> studio's game site went down causing the exchanges to fail. In this
> circumstance we would rather push the exchange to a dead letter queue and
> then later be able to determine why the problem happened and relish those
> exchanges. Again finding the "why" in a log file isn't going to work out.
>
> -- Robert
>
> On Friday, May 23, 2014, Claus Ibsen <cl...@gmail.com> wrote:
>
>> You cannot provide a reason why a rollback happens in the TX API.
>> There is no rollback(String message) api for that.
>>
>> You need to record this somewhere else if you want to use that.
>> Or do your own kind of TX rollback.
>>
>> On Thu, May 22, 2014 at 11:00 PM, kraythe . <kraythe@gmail.com<javascript:;>>
>> wrote:
>> > Greetings, I have many routes that read from AMQ queues and write to
>> other
>> > AMQ queues. For error handling I have been using the following paradigm:
>> >
>> > from("activemq:queue:inbox")
>> >
>> >
>> .onException(Exception.class).useOriginalMessage().handled(handled).maximumRedeliveries(0)
>> > .setHeader(Exchange.FAILURE_ROUTE_ID,
>> property(Exchange.FAILURE_ROUTE_ID))
>> > .setHeader(Exchange.EXCEPTION_CAUGHT,
>> simple("${exception.stacktrace}"))
>> > .to(ExchangePattern.InOnly, "activemq:queue:dead").end();
>> > .process(new PreProcessor())
>> > .to("activemq:queue:outbox")
>> > .process(new PostProcessor());
>> >
>> > The goal being that if there was any kind of exception, that information
>> > would be noted in the headers on the message before it was sent off to
>> the
>> > DLQ. The problem is this runs into roadblocks when transacted() is added
>> to
>> > the route.
>> >
>> > With the code above when the route is transacted and a message fails in
>> > post processing I want the message pulled off the outbox, record
>> > information indicating what the exception was, and have the message sent
>> to
>> > the DLQ. Unfortunately I seem to be in a quandary of how to do this.
>> >
>> > The code above simply wont work because the message being sent to the
>> dead
>> > letter queue gets rolled back along with the outbox if I mark the
>> exchange
>> > with rollback() in the exception handler. If I don't mark the message
>> with
>> > rollback() in the handler then the outbox doesn't get rolled back if the
>> > post processor exceptions but the dead letter channel will contain the
>> > correct information. On the other hand if I just let activemq handle the
>> > transaction, it will retry and then eventually send the message to the
>> DLQ
>> > but the message in the DLQ will contain no information about why it
>> failed.
>> >
>> > So I want my cake and eat it too. I want to be able to record WHY an
>> > exchange failed but still be able to rollback the outbox at the same
>> time.
>> > I have been plugging away at this a ton and I am out of ideas. What would
>> > not be acceptable would be to require the user to troll through log files
>> > trying to find a reason why an exchange failed. This would be an
>> > operational nightmare. So the message and the reason for the rollback
>> need
>> > to be somewhere accessible and they need to be together.
>> >
>> > I would appreciate any suggestions on how I could make this happen.
>> >
>> > *Robert Simmons Jr. MSc. - Lead Java Architect @ EA*
>> > *Author of: Hardcore Java (2003) and Maintainable Java (2012)*
>> > *LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39
>> > <http://www.linkedin.com/pub/robert-simmons/40/852/a39>*
>>
>>
>>
>> --
>> Claus Ibsen
>> -----------------
>> Red Hat, Inc.
>> Email: cibsen@redhat.com <javascript:;>
>> Twitter: davsclaus
>> Blog: http://davsclaus.com
>> Author of Camel in Action: http://www.manning.com/ibsen
>> hawtio: http://hawt.io/
>> fabric8: http://fabric8.io/
>>
>
>
> --
> *Robert Simmons Jr. MSc. - Lead Java Architect @ EA*
> *Author of: Hardcore Java (2003) and Maintainable Java (2012)*
> *LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39
> <http://www.linkedin.com/pub/robert-simmons/40/852/a39>*
--
Claus Ibsen
-----------------
Red Hat, Inc.
Email: cibsen@redhat.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
hawtio: http://hawt.io/
fabric8: http://fabric8.io/
Re: How to Implment Informative Transactional Error Handling?
Posted by "kraythe ." <kr...@gmail.com>.
Yeah, I know the rollback doesn't work that way. That wasn't what I was
driving at. I am just trying to deal with a business problem of informing
the investigator why an exchange failed though means other than spelunking
in a verbose log file for clues. Sometimes one investigating a problem may
not have access even to the logs. For example if a business issue such as a
studio's game site went down causing the exchanges to fail. In this
circumstance we would rather push the exchange to a dead letter queue and
then later be able to determine why the problem happened and relish those
exchanges. Again finding the "why" in a log file isn't going to work out.
-- Robert
On Friday, May 23, 2014, Claus Ibsen <cl...@gmail.com> wrote:
> You cannot provide a reason why a rollback happens in the TX API.
> There is no rollback(String message) api for that.
>
> You need to record this somewhere else if you want to use that.
> Or do your own kind of TX rollback.
>
> On Thu, May 22, 2014 at 11:00 PM, kraythe . <kraythe@gmail.com<javascript:;>>
> wrote:
> > Greetings, I have many routes that read from AMQ queues and write to
> other
> > AMQ queues. For error handling I have been using the following paradigm:
> >
> > from("activemq:queue:inbox")
> >
> >
> .onException(Exception.class).useOriginalMessage().handled(handled).maximumRedeliveries(0)
> > .setHeader(Exchange.FAILURE_ROUTE_ID,
> property(Exchange.FAILURE_ROUTE_ID))
> > .setHeader(Exchange.EXCEPTION_CAUGHT,
> simple("${exception.stacktrace}"))
> > .to(ExchangePattern.InOnly, "activemq:queue:dead").end();
> > .process(new PreProcessor())
> > .to("activemq:queue:outbox")
> > .process(new PostProcessor());
> >
> > The goal being that if there was any kind of exception, that information
> > would be noted in the headers on the message before it was sent off to
> the
> > DLQ. The problem is this runs into roadblocks when transacted() is added
> to
> > the route.
> >
> > With the code above when the route is transacted and a message fails in
> > post processing I want the message pulled off the outbox, record
> > information indicating what the exception was, and have the message sent
> to
> > the DLQ. Unfortunately I seem to be in a quandary of how to do this.
> >
> > The code above simply wont work because the message being sent to the
> dead
> > letter queue gets rolled back along with the outbox if I mark the
> exchange
> > with rollback() in the exception handler. If I don't mark the message
> with
> > rollback() in the handler then the outbox doesn't get rolled back if the
> > post processor exceptions but the dead letter channel will contain the
> > correct information. On the other hand if I just let activemq handle the
> > transaction, it will retry and then eventually send the message to the
> DLQ
> > but the message in the DLQ will contain no information about why it
> failed.
> >
> > So I want my cake and eat it too. I want to be able to record WHY an
> > exchange failed but still be able to rollback the outbox at the same
> time.
> > I have been plugging away at this a ton and I am out of ideas. What would
> > not be acceptable would be to require the user to troll through log files
> > trying to find a reason why an exchange failed. This would be an
> > operational nightmare. So the message and the reason for the rollback
> need
> > to be somewhere accessible and they need to be together.
> >
> > I would appreciate any suggestions on how I could make this happen.
> >
> > *Robert Simmons Jr. MSc. - Lead Java Architect @ EA*
> > *Author of: Hardcore Java (2003) and Maintainable Java (2012)*
> > *LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39
> > <http://www.linkedin.com/pub/robert-simmons/40/852/a39>*
>
>
>
> --
> Claus Ibsen
> -----------------
> Red Hat, Inc.
> Email: cibsen@redhat.com <javascript:;>
> Twitter: davsclaus
> Blog: http://davsclaus.com
> Author of Camel in Action: http://www.manning.com/ibsen
> hawtio: http://hawt.io/
> fabric8: http://fabric8.io/
>
--
*Robert Simmons Jr. MSc. - Lead Java Architect @ EA*
*Author of: Hardcore Java (2003) and Maintainable Java (2012)*
*LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39
<http://www.linkedin.com/pub/robert-simmons/40/852/a39>*
Re: How to Implment Informative Transactional Error Handling?
Posted by Claus Ibsen <cl...@gmail.com>.
You cannot provide a reason why a rollback happens in the TX API.
There is no rollback(String message) api for that.
You need to record this somewhere else if you want to use that.
Or do your own kind of TX rollback.
On Thu, May 22, 2014 at 11:00 PM, kraythe . <kr...@gmail.com> wrote:
> Greetings, I have many routes that read from AMQ queues and write to other
> AMQ queues. For error handling I have been using the following paradigm:
>
> from("activemq:queue:inbox")
>
> .onException(Exception.class).useOriginalMessage().handled(handled).maximumRedeliveries(0)
> .setHeader(Exchange.FAILURE_ROUTE_ID, property(Exchange.FAILURE_ROUTE_ID))
> .setHeader(Exchange.EXCEPTION_CAUGHT, simple("${exception.stacktrace}"))
> .to(ExchangePattern.InOnly, "activemq:queue:dead").end();
> .process(new PreProcessor())
> .to("activemq:queue:outbox")
> .process(new PostProcessor());
>
> The goal being that if there was any kind of exception, that information
> would be noted in the headers on the message before it was sent off to the
> DLQ. The problem is this runs into roadblocks when transacted() is added to
> the route.
>
> With the code above when the route is transacted and a message fails in
> post processing I want the message pulled off the outbox, record
> information indicating what the exception was, and have the message sent to
> the DLQ. Unfortunately I seem to be in a quandary of how to do this.
>
> The code above simply wont work because the message being sent to the dead
> letter queue gets rolled back along with the outbox if I mark the exchange
> with rollback() in the exception handler. If I don't mark the message with
> rollback() in the handler then the outbox doesn't get rolled back if the
> post processor exceptions but the dead letter channel will contain the
> correct information. On the other hand if I just let activemq handle the
> transaction, it will retry and then eventually send the message to the DLQ
> but the message in the DLQ will contain no information about why it failed.
>
> So I want my cake and eat it too. I want to be able to record WHY an
> exchange failed but still be able to rollback the outbox at the same time.
> I have been plugging away at this a ton and I am out of ideas. What would
> not be acceptable would be to require the user to troll through log files
> trying to find a reason why an exchange failed. This would be an
> operational nightmare. So the message and the reason for the rollback need
> to be somewhere accessible and they need to be together.
>
> I would appreciate any suggestions on how I could make this happen.
>
> *Robert Simmons Jr. MSc. - Lead Java Architect @ EA*
> *Author of: Hardcore Java (2003) and Maintainable Java (2012)*
> *LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39
> <http://www.linkedin.com/pub/robert-simmons/40/852/a39>*
--
Claus Ibsen
-----------------
Red Hat, Inc.
Email: cibsen@redhat.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
hawtio: http://hawt.io/
fabric8: http://fabric8.io/