[
https://issues.apache.org/jira/browse/CAMEL-10972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Rivett updated CAMEL-10972:
-------------------------------
Description:
Found in 2.16.1 (I can't upgrade yet due to it being run in a legacy Spring 3.2
environment) but it looks to still be present in the current codebase from
viewing the master branch.
h3. Background
When referencing direct endpoints from a different context using the uri
{{context:endpointUri}} such as the following:
{code}
<route id="deadLetterRouteWithMulticast">
<from uri="direct:foo"/>
<multicast>
<to uri="context-a:notifyProcessingFailedRoute" />
<to uri="context-b:notifyProcessingFailedRoute" />
</multicast>
</route>
{code}
This works fine.
However swap to a {{RecipientList}} and it fails:
{code}
<route id="deadLetterRouteWithRecipientList">
<from uri="direct:foo"/>
<setHeader headerName="myRecipientListHeader">
<constant>context-a:notifyProcessingFailedRoute,context-b:notifyProcessingFailedRoute</constant>
</setHeader>
<recipientList delimiter=",">
<header>myRecipientListHeader</header>
</recipientList>
</route>
{code}
h3. Investigation
This appears to be due to {{ProducerCache}} caching by
{{Endpoint.getEndpointUri()}} which in the case of a {{DirectEndpoint}} both
the recipients in the list return the same
({{direct://notifyProcessingFailedRoute}} value in the example above).
{{ProducerCache}} is called by {{RecipientListProcessor}}
[here|https://github.com/apache/camel/blob/master/camel-core/src/main/java/org/apache/camel/processor/RecipientListProcessor.java#L202].
Note: the {{endpoint}} variable two lines above resolves to the correct
{{Endpoint}} it is the {{Producer}} which is resolved (via cache) incorrectly.
Now I don't know the Camel codebase well enough to say if
{{DirectEndpoint.getEndpointUri()}} should return ambiguous URIs in
multi-Camel-Context environments, or whether {{ProducerCache.doGetProducer()}}
(see
[here|https://github.com/apache/camel/blob/master/camel-core/src/main/java/org/apache/camel/impl/ProducerCache.java#L564])
should use a key like something as follows to use a cache key that takes into
account the {{Endpoint}}'s Camel Context:
{code}
String key = endpoint.getCamelContext().getName() + "_" +
endpoint.getEndpointUri();
{code}
This seems over-simplistic because endpoints that aren't Camel Context specific
such as JMS could be in the cache multiple times, but at least the correct
{{Endpoint}} would be returned from the cache each time, unlike now.
h3. Workarounds
1. Use different endpoint uris (e.g. prepend context name).
2. Supply the Recipient List with Endpoints rather than Strings to avoid
parsing the URIs into Endpoints and running into this issue (see [this
line|https://github.com/apache/camel/blob/master/camel-core/src/main/java/org/apache/camel/util/ExchangeHelper.java#L87]).
Seems a bit of a hack.
was:
Found in 2.16.1 (I can't upgrade yet due to it being run in a legacy Spring 3.2
environment) but it looks to still be present in the current codebase from
viewing the master branch.
h3. Background
When referencing direct endpoints from a different context using the uri
{{context:endpointUri}} such as the following:
{code}
<route id="deadLetterRouteWithMulticast">
<from uri="direct:foo"/>
<multicast>
<to uri="context-a:notifyProcessingFailedRoute" />
<to uri="context-b:notifyProcessingFailedRoute" />
</multicast>
</route>
{code}
This works fine.
However swap to a {{RecipientList}} and it fails:
{code}
<route id="deadLetterRouteWithRecipientList">
<from uri="direct:foo"/>
<setHeader headerName="myRecipientListHeader">
<constant>context-a:notifyProcessingFailedRoute,context-b:notifyProcessingFailedRoute</constant>
</setHeader>
<recipientList delimiter=",">
<header>myRecipientListHeader</header>
</recipientList>
</route>
{code}
h3. Investigation
This appears to be due to {{ProducerCache}} caching by
{{Endpoint.getEndpointUri()}} which in the case of a {{DirectEndpoint}} both
the recipients in the list return the same ({{notifyProcessingFailedRoute}} in
the example above). {{ProducerCache}} is called by {{RecipientListProcessor}}
[here|https://github.com/apache/camel/blob/master/camel-core/src/main/java/org/apache/camel/processor/RecipientListProcessor.java#L202].
Note: the {{endpoint}} variable two lines above resolves to the correct
{{Endpoint}} it is the {{Producer}} which is resolved (via cache) incorrectly.
Now I don't know the Camel codebase well enough to say if
{{DirectEndpoint.getEndpointUri()}} should return ambiguous URIs in
multi-Camel-Context environments, or whether {{ProducerCache.doGetProducer()}}
(see
[here|https://github.com/apache/camel/blob/master/camel-core/src/main/java/org/apache/camel/impl/ProducerCache.java#L564])
should use a key like something as follows to use a cache key that takes into
account the {{Endpoint}}'s Camel Context:
{code}
String key = endpoint.getCamelContext().getName() + "_" +
endpoint.getEndpointUri();
{code}
This seems over-simplistic because endpoints that aren't Camel Context specific
such as JMS could be in the cache multiple times, but at least the correct
{{Endpoint}} would be returned from the cache each time, unlike now.
h3. Workarounds
1. Use different endpoint uris (e.g. prepend context name).
2. Supply the Recipient List with Endpoints rather than Strings to avoid
parsing the URIs into Endpoints and running into this issue (see [this
line|https://github.com/apache/camel/blob/master/camel-core/src/main/java/org/apache/camel/util/ExchangeHelper.java#L87]).
Seems a bit of a hack.
> ProducerCache uses Endpoint.getEndpointUri() as key which isn't always unique!
> ------------------------------------------------------------------------------
>
> Key: CAMEL-10972
> URL: https://issues.apache.org/jira/browse/CAMEL-10972
> Project: Camel
> Issue Type: Bug
> Affects Versions: 2.16.1
> Reporter: Dan Rivett
>
> Found in 2.16.1 (I can't upgrade yet due to it being run in a legacy Spring
> 3.2 environment) but it looks to still be present in the current codebase
> from viewing the master branch.
> h3. Background
> When referencing direct endpoints from a different context using the uri
> {{context:endpointUri}} such as the following:
> {code}
> <route id="deadLetterRouteWithMulticast">
> <from uri="direct:foo"/>
> <multicast>
> <to uri="context-a:notifyProcessingFailedRoute" />
> <to uri="context-b:notifyProcessingFailedRoute" />
> </multicast>
> </route>
> {code}
> This works fine.
> However swap to a {{RecipientList}} and it fails:
> {code}
> <route id="deadLetterRouteWithRecipientList">
> <from uri="direct:foo"/>
> <setHeader headerName="myRecipientListHeader">
>
> <constant>context-a:notifyProcessingFailedRoute,context-b:notifyProcessingFailedRoute</constant>
> </setHeader>
> <recipientList delimiter=",">
> <header>myRecipientListHeader</header>
> </recipientList>
> </route>
> {code}
> h3. Investigation
> This appears to be due to {{ProducerCache}} caching by
> {{Endpoint.getEndpointUri()}} which in the case of a {{DirectEndpoint}} both
> the recipients in the list return the same
> ({{direct://notifyProcessingFailedRoute}} value in the example above).
> {{ProducerCache}} is called by {{RecipientListProcessor}}
> [here|https://github.com/apache/camel/blob/master/camel-core/src/main/java/org/apache/camel/processor/RecipientListProcessor.java#L202].
> Note: the {{endpoint}} variable two lines above resolves to the correct
> {{Endpoint}} it is the {{Producer}} which is resolved (via cache) incorrectly.
> Now I don't know the Camel codebase well enough to say if
> {{DirectEndpoint.getEndpointUri()}} should return ambiguous URIs in
> multi-Camel-Context environments, or whether
> {{ProducerCache.doGetProducer()}} (see
> [here|https://github.com/apache/camel/blob/master/camel-core/src/main/java/org/apache/camel/impl/ProducerCache.java#L564])
> should use a key like something as follows to use a cache key that takes
> into account the {{Endpoint}}'s Camel Context:
> {code}
> String key = endpoint.getCamelContext().getName() + "_" +
> endpoint.getEndpointUri();
> {code}
> This seems over-simplistic because endpoints that aren't Camel Context
> specific such as JMS could be in the cache multiple times, but at least the
> correct {{Endpoint}} would be returned from the cache each time, unlike now.
> h3. Workarounds
> 1. Use different endpoint uris (e.g. prepend context name).
> 2. Supply the Recipient List with Endpoints rather than Strings to avoid
> parsing the URIs into Endpoints and running into this issue (see [this
> line|https://github.com/apache/camel/blob/master/camel-core/src/main/java/org/apache/camel/util/ExchangeHelper.java#L87]).
> Seems a bit of a hack.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
