Hi Claus,
this poison message mechanism is yet not configured but I will configure it and
then this poisonous message will be treated like you said. That way every other
possible poisonous situation will also work and the communication will be more
stable so I like the poison message mechanism for that sort of problem.
But I'm also looking forward to move on to Camel 3.0 😊
Best regards,
Daniel Novak
________________________________
Von: Claus Ibsen <claus.ib...@gmail.com>
Gesendet: Donnerstag, 17. Oktober 2019 17:13:26
An: users@camel.apache.org
Betreff: Re: BridgeErrorHandler on JMS Endpoint does not work as expected
Hi
Ah okay, but if you are using JMS transactions and the message cannot
be processed successfully and its rolled back. Then the JMS broker
usually have a configuration to move the message to a DQL after N
unsuccessful attempts (eg its deemed as a poison message)
Dont you have that with the message that cannot be read as a string
and you get that "german" error with something about charset decoding
error?
If the data is a bytes then you can configure Camel to treat the
message as bytes via jmsMessageType=bytes
Then maybe there is no charset decoding going on if reading the message body
On Thu, Oct 17, 2019 at 4:27 PM <daniel.no...@dz-privatbank.com> wrote:
>
> Hi Claus,
>
>
> thanks a lot for the input.
>
> I tried the convertBodyTo method but it seems that this method uses the same
> API which causes the root problem, so that didn't help. But because of your
> idea I tried a custom made processor
>
>
> public void process(Exchange exchange) throws Exception {
> try {
> exchange.getIn().getBody(String.class);
> } catch( Exception ex) {
> LOG.error("That's no good");
> exchange.getIn().setBody("");
> }
> }
>
>
> which kind of "solves" the problem with the endless loop because the
> exception is handled that way.
>
> But because you mentioned that the code in the next camel version is changed
> I don't prefer to implement workarounds in my route which I probably have to
> remove with the next version.
>
>
> So I came to the conclusion that I will configure a "poison message"
> mechanism on MQ itself.
>
> This makes sense anyways because there might be other scenarios were an
> endless loop might occur.
>
>
> Nevertheless, thx a lot,
> Best regards
> Daniel Novak
>
> ________________________________
> Von: Claus Ibsen <claus.ib...@gmail.com>
> Gesendet: Donnerstag, 17. Oktober 2019 14:27:38
> An: users@camel.apache.org
> Betreff: Re: BridgeErrorHandler on JMS Endpoint does not work as expected
>
> Hi
>
> Okay yeah it smell as if there is a little bug in the bean component.
> However as a workaround you can try to not remove those JMS headers
> before calling the bean, and/or convert the payload into a string or
> byte[] via convertBodyTo.
>
> In Camel 3 that BeanInvocation check is removed as BeanInovication is removed.
>
> I created a JIRA about the bug in the bean component
> https://issues.apache.org/jira/browse/CAMEL-14078
>
> On Thu, Oct 17, 2019 at 10:44 AM <daniel.no...@dz-privatbank.com> wrote:
> >
> > Hi Claus,
> >
> >
> > I think the problem with the JMS Consumer is a bug in Camel.
> >
> > As described in CiA2 as soon as I am in the route the configured
> > errorHandler and onException definition should be triggered as soon as an
> > exception occurs.
> >
> >
> > My route is the following:
> >
> >
> > public void configure() {
> >
> > errorHandler(deadLetterChannel(DLCRoute.ENDPOINT_DLC).onPrepareFailure(getErrorProcessor()));
> >
> > onException(Exception.class)
> >
> > .maximumRedeliveries(0).logExhaustedMessageHistory(false).logExhausted(false);
> >
> > from(ENDPOINT_QUELLE).routeId(ROUTE_ALIAS)
> > .removeHeaders("*", "JMS*") // Entfernt alle nicht notwendigen
> > JMS-Header
> > .bean(bridgeerrorhandlertestRouteEnricher, "addMetaInfo")
> > .log(INFO, log, "Ende Route: ${routeId}");
> > }
> >
> > As you can see the first step in the route is to remove unnecessary headers.
> >
> > This step is executed successfully in the RemoveHeadersProcessor#process
> > method.
> >
> > Which means that I am already in the route.
> >
> >
> > After that successfully processed step in my route I try to call a bean
> > method.
> >
> > Regardless of what the method tries to do the method
> > org.apache.camel.component.bean.AbstractBeanProcessor#process(org.apache.camel.Exchange,
> > org.apache.camel.AsyncCallback) is called.
> >
> >
> > This method has the following line which is causing the exception (line
> > 132):
> >
> > if (in.getBody() instanceof BeanInvocation) {
> >
> >
> > This is because at this point it is tried to extract the body from the
> > received JMS-TextMessage which causes the exception.
> >
> > The complete stacktrace is shown in:
> > https://stackoverflow.com/questions/58407987/apache-camel-jms-component-bridgeerrorhandler-does-not-work-as-documented
> >
> >
> > According to the book I now would expect that the onException block is
> > found because of the implemented gap detection, but neither the configured
> > errorHandler nor the onException Handler is executed.
> >
> >
> > I tried it with Camel 2.24.2. Because Camel 3.0.0 is not released yet, I am
> > not allowed to use that.
> >
> >
> > Can I create a JIRA-Issue for this or is there a way to solve the problem?
> >
> > Best regards
> > Daniel Novak
> >
> > ________________________________
> > Von: Extern - Novak, Daniel (UNIQUARE)
> > Gesendet: Donnerstag, 17. Oktober 2019 10:29:06
> > An: users@camel.apache.org
> > Betreff: AW: BridgeErrorHandler on JMS Endpoint does not work as expected
> >
> >
> > Hi Raymond,
> >
> >
> > I think I had the same problem with the FTP-Producer and I resolved it
> > using an onCompletionExceptionHandler.
> >
> > which I configured for the endpoint.
> >
> > onCompletionExceptionHandler=#myAdapterExceptionHandler
> >
> >
> > Best regards,
> >
> > Daniel Novak
> >
> > ________________________________
> > Von: Claus Ibsen <claus.ib...@gmail.com>
> > Gesendet: Mittwoch, 16. Oktober 2019 19:16:33
> > An: users@camel.apache.org
> > Betreff: Re: BridgeErrorHandler on JMS Endpoint does not work as expected
> >
> > Hi
> >
> > Okay so that is not a responsibility of the consumer / bridge error
> > handler if the error happens outside, eg in this case in the producer
> > (to).
> > So in that case you can use Camel's regular error handler which ought
> > to catch the write permission error and route it elsewhere.
> >
> > However if you say the permission error didn't result in an exception
> > then let us know and see if we can reproduce it and get it fixed.
> >
> > Also mind try with latest release as bug get fixes in both Camel and
> > 3rd party libraries over time.
> >
> > On Wed, Oct 16, 2019 at 4:55 PM ski n <raymondmees...@gmail.com> wrote:
> > >
> > > OK, I read it and understand it a little more. Still it's not exactly what
> > > I expected. An example I need to send a file with FTP component:
> > >
> > > Source (SFTP Server) --> Camel --> Destination (FTPS Server)
> > >
> > > As long as the file is at the source (and Camel is polling for whatever
> > > reason) I don't need a message on the deadletterchannel. The message isn't
> > > in the exchange yet (it's still accesible at the source), so I don't see
> > > it's already a responsibility of Camel.
> > >
> > > However I had a case where Camel didn't have the complete permission to
> > > write to the FTPS server. So it was allowed to create a file, but it
> > > wasn't
> > > allowed to write the content (an error). So the Camel exchange wasn't
> > > completed. I thought when adding bridgeerrorhandler=true that in such a
> > > case the error was sent to the deadletterchannel (Now the message was
> > > lost).
> > >
> > > Regards,
> > >
> > > Raymond
> > >
> > >
> > > Op wo 16 okt. 2019 om 16:26 schreef <daniel.no...@dz-privatbank.com>:
> > >
> > > > No. I think it's
> > > >
> > > > 11.4.8 Bridging the consumer with Camel’s error handler
> > > >
> > > >
> > > > But unfortunately it doesn't help me with my case.
> > > >
> > > >
> > > > regards
> > > >
> > > > Daniel
> > > >
> > > > ________________________________
> > > > Von: ski n <raymondmees...@gmail.com>
> > > > Gesendet: Mittwoch, 16. Oktober 2019 16:16:52
> > > > An: users@camel.apache.org
> > > > Betreff: Re: BridgeErrorHandler on JMS Endpoint does not work as
> > > > expected
> > > >
> > > > Of course, I had CiA2 already opened.
> > > >
> > > > Do you mean 11.5 (Example that bridges the consumer with Camel’s error
> > > > handler). There the bridgeerrorhandler is explained, but I'm not sure
> > > > about
> > > > the reasons.
> > > >
> > > > Op wo 16 okt. 2019 om 15:55 schreef Claus Ibsen <claus.ib...@gmail.com>:
> > > >
> > > > > Hi
> > > > >
> > > > > If you have a copy of the CiA2 book then read the error handler
> > > > > chapter which details about the bridge error handler and the reasons.
> > > > >
> > > > > On Wed, Oct 16, 2019 at 3:51 PM ski n <raymondmees...@gmail.com>
> > > > > wrote:
> > > > > >
> > > > > > Just note that SJMS component (=JMS 1.1) and SJMS2 component (=JMS
> > > > 2.0).
> > > > > >
> > > > > > I also wonder why the default for the bridgeErrorHandler option is
> > > > false?
> > > > > >
> > > > > > How can it set to true for all components globally? Or does it
> > > > > > needs to
> > > > > be
> > > > > > set for each component like in this question:
> > > > > >
> > > > > >
> > > > >
> > > > https://stackoverflow.com/questions/38194380/apache-camel-how-to-set-global-component-options
> > > > > >
> > > > > > HttpComponent http = context.getComponent("http4",
> > > > > > HttpComponent.class);
> > > > > > http.setConnectionTimeToLive(5000);
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > > Raymond
> > > > > >
> > > > > >
> > > > > > Op wo 16 okt. 2019 om 13:47 schreef
> > > > > > <daniel.no...@dz-privatbank.com>:
> > > > > >
> > > > > > > Hi guys,
> > > > > > >
> > > > > > >
> > > > > > > thanks for the answers. In the meantime I tried with Camel 2.24.2
> > > > > > > and
> > > > > the
> > > > > > > JMS-Component but the problem is still the same.
> > > > > > >
> > > > > > > Next I will with the sjms2 component.
> > > > > > >
> > > > > > >
> > > > > > > I think that in the JMS-Component the EndpointMessageListener
> > > > > > > could
> > > > do
> > > > > > > more with the exception as just setting it into the exchange and
> > > > throw
> > > > > it
> > > > > > > to the MessageListenerContainer.
> > > > > > >
> > > > > > >
> > > > > > > But now I will try with the new component and inform you with the
> > > > > results.
> > > > > > >
> > > > > > >
> > > > > > > Thx and regards
> > > > > > > Daniel Novak
> > > > > > >
> > > > > > > ________________________________
> > > > > > > Von: ski n <raymondmees...@gmail.com>
> > > > > > > Gesendet: Mittwoch, 16. Oktober 2019 13:04:46
> > > > > > > An: users@camel.apache.org
> > > > > > > Betreff: Re: BridgeErrorHandler on JMS Endpoint does not work as
> > > > > expected
> > > > > > >
> > > > > > > @Daniel instead of camel-jms you can also try camel-sjms (The
> > > > > > > Simple
> > > > > (or
> > > > > > > Springless) JMS component). In my experience this component works
> > > > > better.
> > > > > > >
> > > > > > > Op wo 16 okt. 2019 om 12:56 schreef Claus Ibsen <
> > > > claus.ib...@gmail.com
> > > > > >:
> > > > > > >
> > > > > > > > Hi
> > > > > > > >
> > > > > > > > The bridge cannot do 100% of all errors as its how the
> > > > > > > > underlying
> > > > > > > > library is designed. camel-jms uses spring jms and it has some
> > > > > > > > "limitations" on how it works and handle errors, where it does
> > > > > > > > re-connection and whatnot with the connection pool.
> > > > > > > >
> > > > > > > > On Wed, Oct 16, 2019 at 10:21 AM
> > > > > > > > <daniel.no...@dz-privatbank.com>
> > > > > wrote:
> > > > > > > > >
> > > > > > > > > Hi guys,
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > I tried to use the bridgeErrorHandler flag on my JMS Endpoint
> > > > > > > > > but
> > > > > sadly
> > > > > > > > it does not work.
> > > > > > > > >
> > > > > > > > > Because there is a lot of code which I have to share with you
> > > > > > > > > to
> > > > > make
> > > > > > > > you understand my problem I created a stackoverflow question as
> > > > > > > > it
> > > > > is way
> > > > > > > > easier to read and to respond on comments there.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > If some of you have time to take a look that would be really
> > > > really
> > > > > > > > great.
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > >
> > > > https://stackoverflow.com/questions/58407987/apache-camel-jms-component-bridgeerrorhandler-does-not-work-as-documented
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Thanks in advance
> > > > > > > > > Daniel Novak
> > > > > > > > >
> > > > > > > > >
> > > > > **********************************************************************
> > > > > > > > > This message and any attachment are confidential and may be
> > > > > privileged
> > > > > > > > or otherwise protected from disclosure. If you are not the
> > > > > > > > intended
> > > > > > > > recipient, please call or e-mail the sender and delete the
> > > > > > > > message
> > > > > and
> > > > > > > any
> > > > > > > > attachment from your system. If you are not the intended
> > > > > > > > recipient,
> > > > > you
> > > > > > > > must not copy this message or attachment or disclose the
> > > > > > > > contents
> > > > to
> > > > > any
> > > > > > > > other person. E-mail transmission cannot be guaranteed to be
> > > > > > > > secure
> > > > > or
> > > > > > > > error-free as information could be intercepted, corrupted, lost,
> > > > > > > destroyed,
> > > > > > > > arrive later or incomplete, or contain viruses. DZ PRIVATBANK
> > > > > therefore
> > > > > > > > does not accept liability for any errors or omissions in the
> > > > > contents of
> > > > > > > > this message which arises as a result of e-mail transmission. If
> > > > > > > > verification is required please request a hard-copy version.
> > > > > > > > This
> > > > > message
> > > > > > > > is provided for informational purposes only and should not be
> > > > > construed
> > > > > > > as
> > > > > > > > a solicitation or offer to buy or sell any securities or related
> > > > > > > financial
> > > > > > > > instruments. DZ PRIVATBANK does not warrant that incoming
> > > > > > > > e-mails
> > > > > will be
> > > > > > > > processed within a certain period of time. For security
> > > > > > > > reasons, DZ
> > > > > > > > PRIVATBANK does not accept any instructions that must be in
> > > > > > > > writing
> > > > > > > > (financial transactions, changes of address, etc.) sent by
> > > > > > > > e-mail.
> > > > > If a
> > > > > > > > message is urgent, please contact us by telephone.
> > > > > > > > >
> > > > > **********************************************************************
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Claus Ibsen
> > > > > > > > -----------------
> > > > > > > > http://davsclaus.com @davsclaus
> > > > > > > > Camel in Action 2: https://www.manning.com/ibsen2
> > > > > > > >
> > > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Claus Ibsen
> > > > > -----------------
> > > > > http://davsclaus.com @davsclaus
> > > > > Camel in Action 2: https://www.manning.com/ibsen2
> > > > >
> > > >
> >
> >
> >
> > --
> > Claus Ibsen
> > -----------------
> > http://davsclaus.com @davsclaus
> > Camel in Action 2: https://www.manning.com/ibsen2
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
