[
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
