FAQ
Hello,

I'm having a strange problem with the camel context component and think it
may be a bug. I've created a unit test that currently fails:

https://gist.github.com/birkland/1b12261521dd5d5c79ef

Basically, I'm trying create a 'parent' camel context that routes a message
through two 'black box' camel contexts (named bb1 and bb2); each one
containing arbitrary routes, but containing local endpoints direct:in and
direct:out. The presence of these endpoints is a kind of "api" to a given
black box.

In the test above, the parent context is trying to pass a message through
two black boxes by wiring them together, with routes like:

from("direct:start").to(bb1:in);
from(bb1:out).to(bb2:in);
from(bb2:out).to("mock:end");

The problem is the test fails due to an exception:
org.apache.camel.FailedToStartRouteException: Failed to start route route5
because of Multiple consumers for the same endpoint is not allowed:
Endpoint[direct://out]
at
org.apache.camel.impl.DefaultCamelContext.doStartOrResumeRouteConsumers(DefaultCamelContext.java:3142)
...

This is with camel 2.15.2

Tracing the failure, I see that endpoints are analyzed in:
doCheckMultipleConsumerSupportClash(Endpoint endpoint, List<Endpoint>
routeInputs)

The problem is at line 3205 of DefaultCamelContext.java:
if (routeInputs.contains(endpoint)) { return false; }

It's not comparing endpoints by their logical name in the parent context
(bb1:out, bb2:out), but instead by their local names/URIs (direct:out,
drect:out). Each of these endpoints is an instance of DefaultEndpoint. In
the equals() method, they are considered equivalent if their URIs match.

So to me, it looks like the logic for detecting 'the same endpoint' for the
purpose of assuring that a single endpoint doesn't have multiple consumers
is incorrect in the case where endpoints defined in different camel
contexts are being compared. Identically named endpoints in separate
"black box" contexts are being considered to be equivalent, which they
clearly aren't.

Does this look like a bug to anybody else? Could a simple solution be in
DefaultEndpoint#equals: compare equivalence of endpoint URIs *and*
containing camel context IDs, rather than just URI alone?

Thanks,
    -Aaron

Search Discussions

  • Aaron Birkland at Oct 6, 2015 at 4:05 pm
    Hi All,

    I had some time to dig into this issue, and it appears more severe than I
    had initially thought. Right now, there is *no* isolation between endpoint
    names between camel contexts. In fact, using the context component in its
    current state results brings *local* endpoint names from referenced
    contexts into the address space of the containing context. This to me
    seems like a severe bug in the context component.

    For example, attempting to use the following routes (in spring DSL) will
    fail:
    <camelContext id="tester">
         <route>
           <from uri="direct:in"/> <to uri="blackBox:in"/>
         </route>
         <route>
           <from uri="blackBox:out"/> <to uri="direct:out"/>
         </route>
         <route>
           <from uri="direct:out" /> <to uri="mock:results" />
         </route>
       </camelContext>

    This will fail due to an exception:
    Caused by: org.apache.camel.FailedToStartRouteException: Failed to start
    route route5 because of Multiple consumers for the same endpoint is not
    allowed: Endpoint[direct://out]
    at
    org.apache.camel.impl.DefaultCamelContext.doStartOrResumeRouteConsumers(DefaultCamelContext.java:3473)
    ...

    I created a patch which fixes the issue, including tests. Should I create
    a Jira ticket, and submit a pull request?

        -Aaron

    On Tue, Aug 25, 2015 at 2:45 PM, Aaron Birkland wrote:

    Hello,

    I'm having a strange problem with the camel context component and think it
    may be a bug. I've created a unit test that currently fails:

    https://gist.github.com/birkland/1b12261521dd5d5c79ef

    Basically, I'm trying create a 'parent' camel context that routes a
    message through two 'black box' camel contexts (named bb1 and bb2); each
    one containing arbitrary routes, but containing local endpoints direct:in
    and direct:out. The presence of these endpoints is a kind of "api" to a
    given black box.

    In the test above, the parent context is trying to pass a message through
    two black boxes by wiring them together, with routes like:

    from("direct:start").to(bb1:in);
    from(bb1:out).to(bb2:in);
    from(bb2:out).to("mock:end");

    The problem is the test fails due to an exception:
    org.apache.camel.FailedToStartRouteException: Failed to start route route5
    because of Multiple consumers for the same endpoint is not allowed:
    Endpoint[direct://out]
    at
    org.apache.camel.impl.DefaultCamelContext.doStartOrResumeRouteConsumers(DefaultCamelContext.java:3142)
    ...

    This is with camel 2.15.2

    Tracing the failure, I see that endpoints are analyzed in:
    doCheckMultipleConsumerSupportClash(Endpoint endpoint, List<Endpoint>
    routeInputs)

    The problem is at line 3205 of DefaultCamelContext.java:
    if (routeInputs.contains(endpoint)) { return false; }

    It's not comparing endpoints by their logical name in the parent context
    (bb1:out, bb2:out), but instead by their local names/URIs (direct:out,
    drect:out). Each of these endpoints is an instance of DefaultEndpoint. In
    the equals() method, they are considered equivalent if their URIs match.

    So to me, it looks like the logic for detecting 'the same endpoint' for
    the purpose of assuring that a single endpoint doesn't have multiple
    consumers is incorrect in the case where endpoints defined in different
    camel contexts are being compared. Identically named endpoints in separate
    "black box" contexts are being considered to be equivalent, which they
    clearly aren't.

    Does this look like a bug to anybody else? Could a simple solution be in
    DefaultEndpoint#equals: compare equivalence of endpoint URIs *and*
    containing camel context IDs, rather than just URI alone?

    Thanks,
    -Aaron
  • Astefanutti at Oct 7, 2015 at 4:49 pm
    Hi Aaron,

    I've been able to reproduce your issue and your analysis is correct.

    The Endpoint returned by the context component has its reference to its
    original black-box Camel context overwritten when the 'parent' context adds
    it to its list of service. There is a clear design issue not only from the
    address space but for the lifecycle of the endpoint as well.

    You can create a JIRA ticket and I'll review / test your patch.

    Antonin



    --
    View this message in context: http://camel.465427.n5.nabble.com/Context-Component-issue-tp5770975p5772383.html
    Sent from the Camel - Users mailing list archive at Nabble.com.
  • Aaron Birkland at Oct 7, 2015 at 4:59 pm
    Hi Antonin,

    Thank you very much. Part of the patch involves having the Context
    component mint 'exported' Endpoints that have noops for several operations
    that looked dangerous to me (like setCamelContext).

    I'll create an issue this evening, and place the fixes in a cloned
    repository in github.

    Thanks again,

       -Aaron
    On Oct 7, 2015 12:49 PM, "astefanutti" wrote:

    Hi Aaron,

    I've been able to reproduce your issue and your analysis is correct.

    The Endpoint returned by the context component has its reference to its
    original black-box Camel context overwritten when the 'parent' context adds
    it to its list of service. There is a clear design issue not only from the
    address space but for the lifecycle of the endpoint as well.

    You can create a JIRA ticket and I'll review / test your patch.

    Antonin



    --
    View this message in context:
    http://camel.465427.n5.nabble.com/Context-Component-issue-tp5770975p5772383.html
    Sent from the Camel - Users mailing list archive at Nabble.com.
  • Aaron Birkland at Oct 8, 2015 at 5:13 am
    I've opened up an issue and attached a pach to it:
    https://issues.apache.org/jira/browse/CAMEL-9200

    I'm not entirely familiar with the Camel code, but this patch addresses
    everything that seemed obviously problematic to me.

    Thanks,
       Aaron
    On Wed, Oct 7, 2015 at 12:48 PM, astefanutti wrote:

    Hi Aaron,

    I've been able to reproduce your issue and your analysis is correct.

    The Endpoint returned by the context component has its reference to its
    original black-box Camel context overwritten when the 'parent' context adds
    it to its list of service. There is a clear design issue not only from the
    address space but for the lifecycle of the endpoint as well.

    You can create a JIRA ticket and I'll review / test your patch.

    Antonin



    --
    View this message in context:
    http://camel.465427.n5.nabble.com/Context-Component-issue-tp5770975p5772383.html
    Sent from the Camel - Users mailing list archive at Nabble.com.
  • Antonin Stefanutti at Oct 8, 2015 at 8:08 am
    Hi Aaron,

    Great. I’ll test your patch and comment on the JIRA ticket then.

    Antonin
    On 08 Oct 2015, at 07:13, Aaron Birkland wrote:

    I've opened up an issue and attached a pach to it:
    https://issues.apache.org/jira/browse/CAMEL-9200

    I'm not entirely familiar with the Camel code, but this patch addresses
    everything that seemed obviously problematic to me.

    Thanks,
    Aaron
    On Wed, Oct 7, 2015 at 12:48 PM, astefanutti wrote:

    Hi Aaron,

    I've been able to reproduce your issue and your analysis is correct.

    The Endpoint returned by the context component has its reference to its
    original black-box Camel context overwritten when the 'parent' context adds
    it to its list of service. There is a clear design issue not only from the
    address space but for the lifecycle of the endpoint as well.

    You can create a JIRA ticket and I'll review / test your patch.

    Antonin



    --
    View this message in context:
    http://camel.465427.n5.nabble.com/Context-Component-issue-tp5770975p5772383.html
    Sent from the Camel - Users mailing list archive at Nabble.com.
  • Aaron Birkland at Apr 28, 2016 at 3:16 pm
    Hi,

    I noticed a recent jira comment that indicates the context component is
    deprecated[1] I couldn't find anything in the code or documentation that
    indicates deprecation. Is there now a better alternative for the kinds of
    use cases the context component supported?

    [1] https://issues.apache.org/jira/browse/CAMEL-9200

    Thanks,

       -Aaron

    On Thu, Oct 8, 2015 at 4:07 AM, Antonin Stefanutti wrote:

    Hi Aaron,

    Great. I’ll test your patch and comment on the JIRA ticket then.

    Antonin
    On 08 Oct 2015, at 07:13, Aaron Birkland wrote:

    I've opened up an issue and attached a pach to it:
    https://issues.apache.org/jira/browse/CAMEL-9200

    I'm not entirely familiar with the Camel code, but this patch addresses
    everything that seemed obviously problematic to me.

    Thanks,
    Aaron
    On Wed, Oct 7, 2015 at 12:48 PM, astefanutti wrote:

    Hi Aaron,

    I've been able to reproduce your issue and your analysis is correct.

    The Endpoint returned by the context component has its reference to its
    original black-box Camel context overwritten when the 'parent' context
    adds
    it to its list of service. There is a clear design issue not only from
    the
    address space but for the lifecycle of the endpoint as well.

    You can create a JIRA ticket and I'll review / test your patch.

    Antonin



    --
    View this message in context:
    http://camel.465427.n5.nabble.com/Context-Component-issue-tp5770975p5772383.html
    Sent from the Camel - Users mailing list archive at Nabble.com.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupusers @
categoriescamel
postedAug 25, '15 at 6:45p
activeApr 28, '16 at 3:16p
posts7
users4
websitecamel.apache.org

People

Translate

site design / logo © 2021 Grokbase