You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by David Hoffer <dh...@gmail.com> on 2016/05/16 21:29:36 UTC
Upgrade from 2.13.2 to 2.15.x has JMX bugs
I'm upgrading an app from Camel 2.13.2 to 2.15.6 that uses Camel's JMX
support. Specifically we query for the various routes and leverage several
of the operations. The problem is the getDescription() operation now
always returns null. I have tried several of the 2.15.x versions and they
all return null. I think there are other operations returning null as well
but this is the one that is breaking my application.
Is this a known bug in the 2.15.x release? Is there a workaround? In what
version(s) was this fixed?
-Dave
Re: Upgrade from 2.13.2 to 2.15.x has JMX bugs
Posted by David Hoffer <dh...@gmail.com>.
Yes I have been using jconsole to try to piece together what the
getDescription() used to provide but have not found all the answers.
What the route.getDescription() used to provide in the 'processor' part was
the 'to' route. E.g. where is the data going next and that is what the app
really cares about...and it handled the case where it was going to multiple
places. When I look at the 'processors' in jconsole I see a lot of
generically named processors, e.g. "aggregate1" but it does not seem to
point me to what I'm looking for. In the processor I do see a RouteId
which matches the route but I already had that, I don't see how it directs
me to where the route is going next. I do see the index but not sure how
to use that.
However I did find the dumpRouteAsXml operation and that does have the full
route so I suppose I can parse that and rebuild the list of where the route
is going. However now I have to find all cases of how that can be
specified and re-create what it used to do in getDescription(). E.g.
sometimes this is a 'to' element, sometimes a 'simple', sometimes a 'bean',
sometimes a 'process ref', etc going to be hard it seems to cover all the
cases. That being said I'm not sure my app covered all these cases with
the old Camel version as it appears it expected a 'sendTo' in the
getDescription() to delimit the destinations.
-Dave
On Wed, May 18, 2016 at 12:30 AM, Claus Ibsen <cl...@gmail.com> wrote:
> You can get the processors of the route in the processors tree. They
> have attribute which route they are part of, and a order num attribute
> that indicate in what position in the route they are from.
>
> You can also get the route overview by invoking the dump route as xml
> operations on the route or camel context mbeans.
>
> There is plenty of details maybe try using a jconsole or something and
> browse the jmx tree and see what you can find.
>
> On Tue, May 17, 2016 at 7:51 PM, David Hoffer <dh...@gmail.com> wrote:
> > I see the problem. In 2.15.x the constructor of ManagedRoute was changed
> > to: this.description = route.getDescription(), however before it was:
> > this.description = route.toString().
> >
> > Where toString was defined as "EventDrivenConsumerRoute[" +
> getEndpoint() +
> > " -> " + processor + "]" (for EventDrivenConsumerRoute class)
> >
> > This is what my app needs as we use both the getEndpoint() & processor
> > values.
> >
> > ManagedRoute has a getEndpointUri() method so I can get the first part
> from
> > that but how can I get the processor ? That is not exposed in the
> > ManagedRoute.
> >
> > -Dave
> >
> > On Tue, May 17, 2016 at 8:30 AM, David Hoffer <dh...@gmail.com>
> wrote:
> >
> >> As an example in the prior version the getDescription() method would
> >> return something like:
> >>
> >>
> EventDrivenConsumerRoute[Endpoint[file://C:/JMS/gangplank/work/guard_ACK/?delay=1000&delete=true&filter=%23partialFilter&moveFailed=.error&readLock=none]
> >> -> Pipeline[[Channel[convertBodyTo[byte[]]],
> Channel[RecipientList[Simple:
> >>
> http://0.0.0.0:80/ackStarguard/${file:onlyname}?proxyHost=0.0.0.0&proxyPort=80]
> ]]
> >> ]]
> >>
> >> In version 2.15.x it just returns null.
> >>
> >> How can I fix this?
> >>
> >> -Dave
> >>
> >>
> >>
> >> On Mon, May 16, 2016 at 3:29 PM, David Hoffer <dh...@gmail.com>
> wrote:
> >>
> >>> I'm upgrading an app from Camel 2.13.2 to 2.15.6 that uses Camel's JMX
> >>> support. Specifically we query for the various routes and leverage
> several
> >>> of the operations. The problem is the getDescription() operation now
> >>> always returns null. I have tried several of the 2.15.x versions and
> they
> >>> all return null. I think there are other operations returning null as
> well
> >>> but this is the one that is breaking my application.
> >>>
> >>> Is this a known bug in the 2.15.x release? Is there a workaround? In
> >>> what version(s) was this fixed?
> >>>
> >>> -Dave
> >>>
> >>
> >>
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
>
Re: Upgrade from 2.13.2 to 2.15.x has JMX bugs
Posted by Claus Ibsen <cl...@gmail.com>.
You can get the processors of the route in the processors tree. They
have attribute which route they are part of, and a order num attribute
that indicate in what position in the route they are from.
You can also get the route overview by invoking the dump route as xml
operations on the route or camel context mbeans.
There is plenty of details maybe try using a jconsole or something and
browse the jmx tree and see what you can find.
On Tue, May 17, 2016 at 7:51 PM, David Hoffer <dh...@gmail.com> wrote:
> I see the problem. In 2.15.x the constructor of ManagedRoute was changed
> to: this.description = route.getDescription(), however before it was:
> this.description = route.toString().
>
> Where toString was defined as "EventDrivenConsumerRoute[" + getEndpoint() +
> " -> " + processor + "]" (for EventDrivenConsumerRoute class)
>
> This is what my app needs as we use both the getEndpoint() & processor
> values.
>
> ManagedRoute has a getEndpointUri() method so I can get the first part from
> that but how can I get the processor ? That is not exposed in the
> ManagedRoute.
>
> -Dave
>
> On Tue, May 17, 2016 at 8:30 AM, David Hoffer <dh...@gmail.com> wrote:
>
>> As an example in the prior version the getDescription() method would
>> return something like:
>>
>> EventDrivenConsumerRoute[Endpoint[file://C:/JMS/gangplank/work/guard_ACK/?delay=1000&delete=true&filter=%23partialFilter&moveFailed=.error&readLock=none]
>> -> Pipeline[[Channel[convertBodyTo[byte[]]], Channel[RecipientList[Simple:
>> http://0.0.0.0:80/ackStarguard/${file:onlyname}?proxyHost=0.0.0.0&proxyPort=80]]]
>> ]]
>>
>> In version 2.15.x it just returns null.
>>
>> How can I fix this?
>>
>> -Dave
>>
>>
>>
>> On Mon, May 16, 2016 at 3:29 PM, David Hoffer <dh...@gmail.com> wrote:
>>
>>> I'm upgrading an app from Camel 2.13.2 to 2.15.6 that uses Camel's JMX
>>> support. Specifically we query for the various routes and leverage several
>>> of the operations. The problem is the getDescription() operation now
>>> always returns null. I have tried several of the 2.15.x versions and they
>>> all return null. I think there are other operations returning null as well
>>> but this is the one that is breaking my application.
>>>
>>> Is this a known bug in the 2.15.x release? Is there a workaround? In
>>> what version(s) was this fixed?
>>>
>>> -Dave
>>>
>>
>>
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Re: Upgrade from 2.13.2 to 2.15.x has JMX bugs
Posted by David Hoffer <dh...@gmail.com>.
I see the problem. In 2.15.x the constructor of ManagedRoute was changed
to: this.description = route.getDescription(), however before it was:
this.description = route.toString().
Where toString was defined as "EventDrivenConsumerRoute[" + getEndpoint() +
" -> " + processor + "]" (for EventDrivenConsumerRoute class)
This is what my app needs as we use both the getEndpoint() & processor
values.
ManagedRoute has a getEndpointUri() method so I can get the first part from
that but how can I get the processor ? That is not exposed in the
ManagedRoute.
-Dave
On Tue, May 17, 2016 at 8:30 AM, David Hoffer <dh...@gmail.com> wrote:
> As an example in the prior version the getDescription() method would
> return something like:
>
> EventDrivenConsumerRoute[Endpoint[file://C:/JMS/gangplank/work/guard_ACK/?delay=1000&delete=true&filter=%23partialFilter&moveFailed=.error&readLock=none]
> -> Pipeline[[Channel[convertBodyTo[byte[]]], Channel[RecipientList[Simple:
> http://0.0.0.0:80/ackStarguard/${file:onlyname}?proxyHost=0.0.0.0&proxyPort=80]]]
> ]]
>
> In version 2.15.x it just returns null.
>
> How can I fix this?
>
> -Dave
>
>
>
> On Mon, May 16, 2016 at 3:29 PM, David Hoffer <dh...@gmail.com> wrote:
>
>> I'm upgrading an app from Camel 2.13.2 to 2.15.6 that uses Camel's JMX
>> support. Specifically we query for the various routes and leverage several
>> of the operations. The problem is the getDescription() operation now
>> always returns null. I have tried several of the 2.15.x versions and they
>> all return null. I think there are other operations returning null as well
>> but this is the one that is breaking my application.
>>
>> Is this a known bug in the 2.15.x release? Is there a workaround? In
>> what version(s) was this fixed?
>>
>> -Dave
>>
>
>
Re: Upgrade from 2.13.2 to 2.15.x has JMX bugs
Posted by David Hoffer <dh...@gmail.com>.
As an example in the prior version the getDescription() method would return
something like:
EventDrivenConsumerRoute[Endpoint[file://C:/JMS/gangplank/work/guard_ACK/?delay=1000&delete=true&filter=%23partialFilter&moveFailed=.error&readLock=none]
-> Pipeline[[Channel[convertBodyTo[byte[]]], Channel[RecipientList[Simple:
http://0.0.0.0:80/ackStarguard/${file:onlyname}?proxyHost=0.0.0.0&proxyPort=80]]]
]]
In version 2.15.x it just returns null.
How can I fix this?
-Dave
On Mon, May 16, 2016 at 3:29 PM, David Hoffer <dh...@gmail.com> wrote:
> I'm upgrading an app from Camel 2.13.2 to 2.15.6 that uses Camel's JMX
> support. Specifically we query for the various routes and leverage several
> of the operations. The problem is the getDescription() operation now
> always returns null. I have tried several of the 2.15.x versions and they
> all return null. I think there are other operations returning null as well
> but this is the one that is breaking my application.
>
> Is this a known bug in the 2.15.x release? Is there a workaround? In
> what version(s) was this fixed?
>
> -Dave
>