[ 
https://issues.apache.org/jira/browse/CAMEL-5193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen updated CAMEL-5193:
-------------------------------

    Description: 
The warning gets printed but other than that, everything seems to work. (I hope)

{code}
12.04.19 10:34:26:463 [drisCamelContext JmsConsumer[dispatchHttpQueue] #4] WARN 
 org.apache.camel.processor.DeadLetterChannel - Cannot determine current route 
from Exchange with id: ID-dris-ixor-be-42350-1334569164986-0-1052464, will 
fallback and use first error handler.
12.04.19 10:34:26:463 [drisCamelContext JmsConsumer[dispatchHttpQueue] #4] WARN 
 distribution.kv78.dispatch - Failed delivery (attempt = 199) : 
org.apache.http.conn.HttpHostConnectException: Connection to 
http://81.82.232.183:9292 ref
used - 0299c1d9 - KV8passtimes - 81.82.232.183:9292 - 
queue_dispatchHttpQueue_ID_dris.ixor.be-36583-1334569163882-4_1_24_1_1007
{code}

When looking up the log statement in RedeliveryErrorHandler, I find this:

{code}
else if (!exceptionPolicy.getErrorHandlers().isEmpty()) {
                // note this should really not happen, but we have this code as 
a fail safe
                // to be backwards compatible with the old behavior
                log.warn("Cannot determine current route from Exchange with id: 
{}, will fallback and use first error handler.", exchange.getExchangeId());
                processor = 
exceptionPolicy.getErrorHandlers().iterator().next();
            }
{code}

So it shouldn't happen but it happens after all...


Here is the route causing the warning. I think it started when I made the route 
transacted. 
As shown in the log snippet above, the warning is printed when the HTTP 
endpoint throws an IOException (route ENDPOINT_DISPATCH)
{code}        
        from(ENDPOINT_DISPATCH_QUEUE +
            "?cacheLevelName=CACHE_CONSUMER&" + // necessary for message groups 
to work
            
"concurrentConsumers={{hermes.dris.distribution.kv78.concurrentOutgoingHttpDispatchers}}&"
 +
            
"maxConcurrentConsumers={{hermes.dris.distribution.kv78.maxConcurrentOutgoingHttpDispatchers}}")
            .routeId(ROUTE_ID_DISPATCH_QUEUE)
            .onException(Throwable.class)
                // transacted routes override the default error handler
                // to avoid the message going to the the ActiveMQ DLQ, forward 
to our DLQ here
                .to(ENDPOINT_DLQ)
                .handled(true)
            .end()
            .transacted()
             // determine action
             // the timingPointSequencer will check what needs to happen with 
the message
            .beanRef("timingPointSequencer", "handleDispatch")
            .choice()
                 // normal situation, the message can be sent
                
.when(header(TimingPointSequencer.HEADER_ACTION).isEqualTo(constant(TimingPointSequencer.ACTION_PROCEED)))
                    .to(ENDPOINT_DISPATCH)
                 // delay message, usually because of previous errors for this 
destination
                
.when(header(TimingPointSequencer.HEADER_ACTION).isEqualTo(constant(TimingPointSequencer.ACTION_REENQUEUE)))
                    .log(LoggingLevel.INFO, "Re-enqueuing" + MESSAGE_LOG_FORMAT)
                    .to(ENDPOINT_DISPATCH_QUEUE)
                .otherwise()
                    .log(LoggingLevel.ERROR, "No action header set ???" + 
MESSAGE_LOG_FORMAT)
                    .to(ENDPOINT_DLQ)
                .end()
            .end();

        from(ENDPOINT_DISPATCH)
            .routeId(ROUTE_ID_DISPATCH)
            .onException(IOException.class)
                // in case of IO exceptions, the message is always re-enqueued
                // reschedule parameters are set by the timingPointSequencer
                .beanRef("timingPointSequencer", "handleFailure")
                .log(LoggingLevel.WARN, "Failed delivery (attempt = 
${in.header.tpSecAttempt}) : ${in.header.CamelExceptionCaught}" + 
MESSAGE_LOG_FORMAT)
                .to(ENDPOINT_DISPATCH_QUEUE)
                .handled(true)
            .end()
             // clear http headers to avoid interference from other http 
endpoints
            .removeHeaders("CamelHttp*")
            .setHeader(Exchange.HTTP_URI, simple("http://${header."; + 
HEADER_DESTINATION_ADDRESS + "}"))
            .setHeader(Exchange.HTTP_PATH, 
simple("${properties:hermes.dris.distribution.kv78.controller.urlpath}"))
            .setHeader(Exchange.CONTENT_TYPE, constant("application/xml"))
            .setHeader(Exchange.CONTENT_ENCODING, constant("gzip")) // use gzip 
compression
            .log(verboseLoggingLevel, "Sending request to 
${in.header.CamelHttpUri}/${in.header.CamelHttpPath}" + MESSAGE_LOG_FORMAT)
             // use multicast instead of a pipeline, or the audit log will 
contain the http response!
            .multicast()
                .stopOnException()
                .to(ENDPOINT_TIMINGPOINT_HTTP + 
"?httpClientConfigurerRef=timingPointHttpClientConfigurer&headerFilterStrategy=#distributionHttpHeaderFilterStrategy",
 ENDPOINT_AUDIT_OUTGOING)
            .end()
            .beanRef("timingPointSequencer", "handleSuccess");
{code}

  was:
The warning gets printed but other than that, everything seems to work. (I hope)

12.04.19 10:34:26:463 [drisCamelContext JmsConsumer[dispatchHttpQueue] #4] WARN 
 org.apache.camel.processor.DeadLetterChannel - Cannot determine current route 
from Exchange with id: ID-dris-ixor-be-42350-1334569164986-0-1052464, will 
fallback and use first error handler.
12.04.19 10:34:26:463 [drisCamelContext JmsConsumer[dispatchHttpQueue] #4] WARN 
 distribution.kv78.dispatch - Failed delivery (attempt = 199) : 
org.apache.http.conn.HttpHostConnectException: Connection to 
http://81.82.232.183:9292 ref
used - 0299c1d9 - KV8passtimes - 81.82.232.183:9292 - 
queue_dispatchHttpQueue_ID_dris.ixor.be-36583-1334569163882-4_1_24_1_1007

When looking up the log statement in RedeliveryErrorHandler, I find this:

else if (!exceptionPolicy.getErrorHandlers().isEmpty()) {
                // note this should really not happen, but we have this code as 
a fail safe
                // to be backwards compatible with the old behavior
                log.warn("Cannot determine current route from Exchange with id: 
{}, will fallback and use first error handler.", exchange.getExchangeId());
                processor = 
exceptionPolicy.getErrorHandlers().iterator().next();
            }

So it shouldn't happen but it happens after all...


Here is the route causing the warning. I think it started when I made the route 
transacted. 
As shown in the log snippet above, the warning is printed when the HTTP 
endpoint throws an IOException (route ENDPOINT_DISPATCH)
        
        from(ENDPOINT_DISPATCH_QUEUE +
            "?cacheLevelName=CACHE_CONSUMER&" + // necessary for message groups 
to work
            
"concurrentConsumers={{hermes.dris.distribution.kv78.concurrentOutgoingHttpDispatchers}}&"
 +
            
"maxConcurrentConsumers={{hermes.dris.distribution.kv78.maxConcurrentOutgoingHttpDispatchers}}")
            .routeId(ROUTE_ID_DISPATCH_QUEUE)
            .onException(Throwable.class)
                // transacted routes override the default error handler
                // to avoid the message going to the the ActiveMQ DLQ, forward 
to our DLQ here
                .to(ENDPOINT_DLQ)
                .handled(true)
            .end()
            .transacted()
             // determine action
             // the timingPointSequencer will check what needs to happen with 
the message
            .beanRef("timingPointSequencer", "handleDispatch")
            .choice()
                 // normal situation, the message can be sent
                
.when(header(TimingPointSequencer.HEADER_ACTION).isEqualTo(constant(TimingPointSequencer.ACTION_PROCEED)))
                    .to(ENDPOINT_DISPATCH)
                 // delay message, usually because of previous errors for this 
destination
                
.when(header(TimingPointSequencer.HEADER_ACTION).isEqualTo(constant(TimingPointSequencer.ACTION_REENQUEUE)))
                    .log(LoggingLevel.INFO, "Re-enqueuing" + MESSAGE_LOG_FORMAT)
                    .to(ENDPOINT_DISPATCH_QUEUE)
                .otherwise()
                    .log(LoggingLevel.ERROR, "No action header set ???" + 
MESSAGE_LOG_FORMAT)
                    .to(ENDPOINT_DLQ)
                .end()
            .end();

        from(ENDPOINT_DISPATCH)
            .routeId(ROUTE_ID_DISPATCH)
            .onException(IOException.class)
                // in case of IO exceptions, the message is always re-enqueued
                // reschedule parameters are set by the timingPointSequencer
                .beanRef("timingPointSequencer", "handleFailure")
                .log(LoggingLevel.WARN, "Failed delivery (attempt = 
${in.header.tpSecAttempt}) : ${in.header.CamelExceptionCaught}" + 
MESSAGE_LOG_FORMAT)
                .to(ENDPOINT_DISPATCH_QUEUE)
                .handled(true)
            .end()
             // clear http headers to avoid interference from other http 
endpoints
            .removeHeaders("CamelHttp*")
            .setHeader(Exchange.HTTP_URI, simple("http://${header."; + 
HEADER_DESTINATION_ADDRESS + "}"))
            .setHeader(Exchange.HTTP_PATH, 
simple("${properties:hermes.dris.distribution.kv78.controller.urlpath}"))
            .setHeader(Exchange.CONTENT_TYPE, constant("application/xml"))
            .setHeader(Exchange.CONTENT_ENCODING, constant("gzip")) // use gzip 
compression
            .log(verboseLoggingLevel, "Sending request to 
${in.header.CamelHttpUri}/${in.header.CamelHttpPath}" + MESSAGE_LOG_FORMAT)
             // use multicast instead of a pipeline, or the audit log will 
contain the http response!
            .multicast()
                .stopOnException()
                .to(ENDPOINT_TIMINGPOINT_HTTP + 
"?httpClientConfigurerRef=timingPointHttpClientConfigurer&headerFilterStrategy=#distributionHttpHeaderFilterStrategy",
 ENDPOINT_AUDIT_OUTGOING)
            .end()
            .beanRef("timingPointSequencer", "handleSuccess");


    
> Strange warning appears: WARN  org.apache.camel.processor.DeadLetterChannel - 
> Cannot determine current route from Exchange with id 
> -----------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: CAMEL-5193
>                 URL: https://issues.apache.org/jira/browse/CAMEL-5193
>             Project: Camel
>          Issue Type: Bug
>          Components: camel-core
>    Affects Versions: 2.9.1
>            Reporter: Christian Tytgat
>
> The warning gets printed but other than that, everything seems to work. (I 
> hope)
> {code}
> 12.04.19 10:34:26:463 [drisCamelContext JmsConsumer[dispatchHttpQueue] #4] 
> WARN  org.apache.camel.processor.DeadLetterChannel - Cannot determine current 
> route from Exchange with id: ID-dris-ixor-be-42350-1334569164986-0-1052464, 
> will 
> fallback and use first error handler.
> 12.04.19 10:34:26:463 [drisCamelContext JmsConsumer[dispatchHttpQueue] #4] 
> WARN  distribution.kv78.dispatch - Failed delivery (attempt = 199) : 
> org.apache.http.conn.HttpHostConnectException: Connection to 
> http://81.82.232.183:9292 ref
> used - 0299c1d9 - KV8passtimes - 81.82.232.183:9292 - 
> queue_dispatchHttpQueue_ID_dris.ixor.be-36583-1334569163882-4_1_24_1_1007
> {code}
> When looking up the log statement in RedeliveryErrorHandler, I find this:
> {code}
> else if (!exceptionPolicy.getErrorHandlers().isEmpty()) {
>                 // note this should really not happen, but we have this code 
> as a fail safe
>                 // to be backwards compatible with the old behavior
>                 log.warn("Cannot determine current route from Exchange with 
> id: {}, will fallback and use first error handler.", 
> exchange.getExchangeId());
>                 processor = 
> exceptionPolicy.getErrorHandlers().iterator().next();
>             }
> {code}
> So it shouldn't happen but it happens after all...
> Here is the route causing the warning. I think it started when I made the 
> route transacted. 
> As shown in the log snippet above, the warning is printed when the HTTP 
> endpoint throws an IOException (route ENDPOINT_DISPATCH)
> {code}        
>         from(ENDPOINT_DISPATCH_QUEUE +
>             "?cacheLevelName=CACHE_CONSUMER&" + // necessary for message 
> groups to work
>             
> "concurrentConsumers={{hermes.dris.distribution.kv78.concurrentOutgoingHttpDispatchers}}&"
>  +
>             
> "maxConcurrentConsumers={{hermes.dris.distribution.kv78.maxConcurrentOutgoingHttpDispatchers}}")
>             .routeId(ROUTE_ID_DISPATCH_QUEUE)
>             .onException(Throwable.class)
>                 // transacted routes override the default error handler
>                 // to avoid the message going to the the ActiveMQ DLQ, 
> forward to our DLQ here
>                 .to(ENDPOINT_DLQ)
>                 .handled(true)
>             .end()
>             .transacted()
>              // determine action
>              // the timingPointSequencer will check what needs to happen with 
> the message
>             .beanRef("timingPointSequencer", "handleDispatch")
>             .choice()
>                  // normal situation, the message can be sent
>                 
> .when(header(TimingPointSequencer.HEADER_ACTION).isEqualTo(constant(TimingPointSequencer.ACTION_PROCEED)))
>                     .to(ENDPOINT_DISPATCH)
>                  // delay message, usually because of previous errors for 
> this destination
>                 
> .when(header(TimingPointSequencer.HEADER_ACTION).isEqualTo(constant(TimingPointSequencer.ACTION_REENQUEUE)))
>                     .log(LoggingLevel.INFO, "Re-enqueuing" + 
> MESSAGE_LOG_FORMAT)
>                     .to(ENDPOINT_DISPATCH_QUEUE)
>                 .otherwise()
>                     .log(LoggingLevel.ERROR, "No action header set ???" + 
> MESSAGE_LOG_FORMAT)
>                     .to(ENDPOINT_DLQ)
>                 .end()
>             .end();
>         from(ENDPOINT_DISPATCH)
>             .routeId(ROUTE_ID_DISPATCH)
>             .onException(IOException.class)
>                 // in case of IO exceptions, the message is always re-enqueued
>                 // reschedule parameters are set by the timingPointSequencer
>                 .beanRef("timingPointSequencer", "handleFailure")
>                 .log(LoggingLevel.WARN, "Failed delivery (attempt = 
> ${in.header.tpSecAttempt}) : ${in.header.CamelExceptionCaught}" + 
> MESSAGE_LOG_FORMAT)
>                 .to(ENDPOINT_DISPATCH_QUEUE)
>                 .handled(true)
>             .end()
>              // clear http headers to avoid interference from other http 
> endpoints
>             .removeHeaders("CamelHttp*")
>             .setHeader(Exchange.HTTP_URI, simple("http://${header."; + 
> HEADER_DESTINATION_ADDRESS + "}"))
>             .setHeader(Exchange.HTTP_PATH, 
> simple("${properties:hermes.dris.distribution.kv78.controller.urlpath}"))
>             .setHeader(Exchange.CONTENT_TYPE, constant("application/xml"))
>             .setHeader(Exchange.CONTENT_ENCODING, constant("gzip")) // use 
> gzip compression
>             .log(verboseLoggingLevel, "Sending request to 
> ${in.header.CamelHttpUri}/${in.header.CamelHttpPath}" + MESSAGE_LOG_FORMAT)
>              // use multicast instead of a pipeline, or the audit log will 
> contain the http response!
>             .multicast()
>                 .stopOnException()
>                 .to(ENDPOINT_TIMINGPOINT_HTTP + 
> "?httpClientConfigurerRef=timingPointHttpClientConfigurer&headerFilterStrategy=#distributionHttpHeaderFilterStrategy",
>  ENDPOINT_AUDIT_OUTGOING)
>             .end()
>             .beanRef("timingPointSequencer", "handleSuccess");
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to