You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Claus Ibsen <cl...@gmail.com> on 2012/03/02 10:59:32 UTC

Re: [DISCSS] - Remove error handler mbeans from JMX

On Tue, Feb 28, 2012 at 10:03 PM, Matt Pavlovich <ma...@gmail.com> wrote:
> Hi Claus-
>
> I believe that, in general, more information available to the user via JMX
> is better.  Being able to confirm everything is wired up is very valuable to
> users-- especially ones new to the framework.  Using it to change values is
> more of an operational hot-fix vs a core use case, in my opinion.
>
> I don't know the internals to Camel enough to provide an alternative
> approach, but would like to see this information available in one form or
> another.  Perhaps moving to an array for CamelId[] and RouteId[] in the
> ErrorHandler MBean would provide a path to solve some of the issues?
>

Okay you are pushing my boundaries, and I am working on a solution.


> Thanks,
> Matt Pavlovich
>
>
> On 2/28/12 6:57 AM, Claus Ibsen wrote:
>>
>> Hi
>>
>> I am considering to remove error handlers mbeans from JMX as they are
>> painful to track properly for context and route scoped routes, in the
>> various DSLs (Java vs XML etc.). And the fact an error handler can be
>> used for multiple routes, as well being a default error handler etc.
>>
>> Currently if you add and remove routes from Java DSL you will end up
>> leaving possible not used any more mbeans for error handlers.
>>
>> It would just be easier to not enlist any error handlers in JMX. Does
>> anyone actually use them for management? Such as changing the number
>> of redelivery attempts at runtime? I do not think they provide much
>> value. And thus can be removed from JMX.
>>
>> A related ticket would be
>> https://issues.apache.org/jira/browse/CAMEL-5041
>>
>> Any thoughts?
>>
>>
>>
>



-- 
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: [DISCSS] - Remove error handler mbeans from JMX

Posted by Matt Pavlovich <ma...@gmail.com>.
Thanks, Claus.  Much appreciated!

On 3/2/12 7:28 AM, Claus Ibsen wrote:
> Okay I have committed a fix so the route scoped error handlers is now
> removed from JMX, when removing a route.
>
>
> On Fri, Mar 2, 2012 at 10:59 AM, Claus Ibsen<cl...@gmail.com>  wrote:
>> On Tue, Feb 28, 2012 at 10:03 PM, Matt Pavlovich<ma...@gmail.com>  wrote:
>>> Hi Claus-
>>>
>>> I believe that, in general, more information available to the user via JMX
>>> is better.  Being able to confirm everything is wired up is very valuable to
>>> users-- especially ones new to the framework.  Using it to change values is
>>> more of an operational hot-fix vs a core use case, in my opinion.
>>>
>>> I don't know the internals to Camel enough to provide an alternative
>>> approach, but would like to see this information available in one form or
>>> another.  Perhaps moving to an array for CamelId[] and RouteId[] in the
>>> ErrorHandler MBean would provide a path to solve some of the issues?
>>>
>> Okay you are pushing my boundaries, and I am working on a solution.
>>
>>
>>> Thanks,
>>> Matt Pavlovich
>>>
>>>
>>> On 2/28/12 6:57 AM, Claus Ibsen wrote:
>>>> Hi
>>>>
>>>> I am considering to remove error handlers mbeans from JMX as they are
>>>> painful to track properly for context and route scoped routes, in the
>>>> various DSLs (Java vs XML etc.). And the fact an error handler can be
>>>> used for multiple routes, as well being a default error handler etc.
>>>>
>>>> Currently if you add and remove routes from Java DSL you will end up
>>>> leaving possible not used any more mbeans for error handlers.
>>>>
>>>> It would just be easier to not enlist any error handlers in JMX. Does
>>>> anyone actually use them for management? Such as changing the number
>>>> of redelivery attempts at runtime? I do not think they provide much
>>>> value. And thus can be removed from JMX.
>>>>
>>>> A related ticket would be
>>>> https://issues.apache.org/jira/browse/CAMEL-5041
>>>>
>>>> Any thoughts?
>>>>
>>>>
>>>>
>>
>>
>> --
>> Claus Ibsen
>> -----------------
>> FuseSource
>> Email: cibsen@fusesource.com
>> Web: http://fusesource.com
>> Twitter: davsclaus, fusenews
>> Blog: http://davsclaus.blogspot.com/
>> Author of Camel in Action: http://www.manning.com/ibsen/
>
>

Re: [DISCSS] - Remove error handler mbeans from JMX

Posted by Claus Ibsen <cl...@gmail.com>.
Okay I have committed a fix so the route scoped error handlers is now
removed from JMX, when removing a route.


On Fri, Mar 2, 2012 at 10:59 AM, Claus Ibsen <cl...@gmail.com> wrote:
> On Tue, Feb 28, 2012 at 10:03 PM, Matt Pavlovich <ma...@gmail.com> wrote:
>> Hi Claus-
>>
>> I believe that, in general, more information available to the user via JMX
>> is better.  Being able to confirm everything is wired up is very valuable to
>> users-- especially ones new to the framework.  Using it to change values is
>> more of an operational hot-fix vs a core use case, in my opinion.
>>
>> I don't know the internals to Camel enough to provide an alternative
>> approach, but would like to see this information available in one form or
>> another.  Perhaps moving to an array for CamelId[] and RouteId[] in the
>> ErrorHandler MBean would provide a path to solve some of the issues?
>>
>
> Okay you are pushing my boundaries, and I am working on a solution.
>
>
>> Thanks,
>> Matt Pavlovich
>>
>>
>> On 2/28/12 6:57 AM, Claus Ibsen wrote:
>>>
>>> Hi
>>>
>>> I am considering to remove error handlers mbeans from JMX as they are
>>> painful to track properly for context and route scoped routes, in the
>>> various DSLs (Java vs XML etc.). And the fact an error handler can be
>>> used for multiple routes, as well being a default error handler etc.
>>>
>>> Currently if you add and remove routes from Java DSL you will end up
>>> leaving possible not used any more mbeans for error handlers.
>>>
>>> It would just be easier to not enlist any error handlers in JMX. Does
>>> anyone actually use them for management? Such as changing the number
>>> of redelivery attempts at runtime? I do not think they provide much
>>> value. And thus can be removed from JMX.
>>>
>>> A related ticket would be
>>> https://issues.apache.org/jira/browse/CAMEL-5041
>>>
>>> Any thoughts?
>>>
>>>
>>>
>>
>
>
>
> --
> Claus Ibsen
> -----------------
> FuseSource
> Email: cibsen@fusesource.com
> Web: http://fusesource.com
> Twitter: davsclaus, fusenews
> Blog: http://davsclaus.blogspot.com/
> Author of Camel in Action: http://www.manning.com/ibsen/



-- 
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/