Context Component issue

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Context Component issue

Aaron Birkland
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
Reply | Threaded
Open this post in threaded view
|

Re: Context Component issue

Aaron Birkland-2
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 <[hidden email]> 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
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Context Component issue

astefanutti
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
Reply | Threaded
Open this post in threaded view
|

Re: Context Component issue

Aaron Birkland-2
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" <[hidden email]> 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.
>
Reply | Threaded
Open this post in threaded view
|

Re: Context Component issue

Aaron Birkland-2
In reply to this post by astefanutti
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 <[hidden email]> 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.
>
Reply | Threaded
Open this post in threaded view
|

Re: Context Component issue

astefanutti
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 <[hidden email]> 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 <[hidden email]> 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.
>>

Reply | Threaded
Open this post in threaded view
|

Re: Context Component issue

Aaron Birkland-3
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 <[hidden email]>
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 <[hidden email]> 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 <[hidden email]>
> 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.
> >>
>
>