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

Reply via email to