Camel
  1. Camel
  2. CAMEL-3906

Consumer and Producer names in JMX

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: 3.0.0, Future
    • Component/s: camel-core
    • Labels:
      None

      Description

      Currently the consumer and producer names in JMX have a name based on their java instance [1]. Due to this it is not obvious what is the endpoint of the consumers/producers.

      It can be improved to use name in the JMX tree based on endpoint URI of the consumer/producer endpoints (combined with identityHashcode) to help in the overview to faster spot the desired consumer.

      [1] Copy/paste from the DefaultManagementNamingStrategy

      ...
      String name = consumer.getClass().getSimpleName();
      if (ObjectHelper.isEmpty(name))

      { name = "Consumer"; }

      buffer.append(KEY_NAME + "=")
      .append(name)
      .append("(").append(ObjectHelper.getIdentityHashCode(consumer)).append(")");

      ...

        Activity

        Claus Ibsen made changes -
        Fix Version/s 3.0.0 [ 12315691 ]
        Fix Version/s Future [ 12315692 ]
        Fix Version/s 2.10.0 [ 12317612 ]
        Ben O'Day made changes -
        Assignee Ben O'Day [ boday ]
        Claus Ibsen made changes -
        Fix Version/s 2.10 [ 12317612 ]
        Fix Version/s 2.9.0 [ 12316374 ]
        Claus Ibsen made changes -
        Fix Version/s 2.9.0 [ 12316374 ]
        Fix Version/s 2.8.0 [ 12316226 ]
        Hide
        Claus Ibsen added a comment -

        Well you could add consumers/processors etc that are not part of a route. Just use the Camel API for that. And if you have enabled JMX to enlist always then it will do that. But I guess its uncommon and not something that the regular Camel end users does.

        And yes the endpoint being part of the MBean key would be an issue if the endpoint is dynamic updated afterwards.
        We could of course notice this in the documentation that the MBean key is the starting endpoint uri. And the actual uri is the attribute. So in case people dynamic change it they are aware of this fact. I think thats sufficient. Also I guess it would be uncommon/rare to adjust this.

        Show
        Claus Ibsen added a comment - Well you could add consumers/processors etc that are not part of a route. Just use the Camel API for that. And if you have enabled JMX to enlist always then it will do that. But I guess its uncommon and not something that the regular Camel end users does. And yes the endpoint being part of the MBean key would be an issue if the endpoint is dynamic updated afterwards. We could of course notice this in the documentation that the MBean key is the starting endpoint uri. And the actual uri is the attribute. So in case people dynamic change it they are aware of this fact. I think thats sufficient. Also I guess it would be uncommon/rare to adjust this.
        Hide
        Ben O'Day added a comment -

        For the consumer name, agreed that the endpoint name and trimmed URI would help. Also, I removed the identity hash code because I thought only a single consumer could exist for a given endpointURI...perhaps not.

        For the processors being altered after startup, I see your point. But, it seems like it would be an issue regardless of whether we name the MBean using the endpointURI or construct an MBean path based on endpointURIs. Can we easily re-register with JMX when these types of changes occur?

        Show
        Ben O'Day added a comment - For the consumer name, agreed that the endpoint name and trimmed URI would help. Also, I removed the identity hash code because I thought only a single consumer could exist for a given endpointURI...perhaps not. For the processors being altered after startup, I see your point. But, it seems like it would be an issue regardless of whether we name the MBean using the endpointURI or construct an MBean path based on endpointURIs. Can we easily re-register with JMX when these types of changes occur?
        Hide
        Claus Ibsen added a comment -

        Note that if we put part of the endpoint uri in the key of the MBean, then like mentioned above. The user could stop the consumer, change parameters on the endpoint, and start it again. For example to consume messages from another destination.

        Show
        Claus Ibsen added a comment - Note that if we put part of the endpoint uri in the key of the MBean, then like mentioned above. The user could stop the consumer, change parameters on the endpoint, and start it again. For example to consume messages from another destination.
        Hide
        Claus Ibsen added a comment - - edited

        The problem with this patch is that your hardlock the route label when the MBean gets enlisted. If the route is later stopped, and the processor is adjusted, then the MBean would potential be misleading.

        Also the labels can get long and complicated. If you use an aggregator etc.

        Also you can potentially have clashes if there are multiple routes with similar routes.
        You frankly need the identify hash code.

        I have though about adding a /routeX in the MBean key if its part of a route. Then you would have a tree like

        + consumers
        \- route1
           + consumer1
        \- route2
           + consumer2
        

        Then its maybe quicker to find the consumer you are looking for.

        On the consumer MBean we may enlist part of the endpoint in its name.
        Then you may be able to quicker identify what you are looking for. Although endpoint uris can be long and complicated.
        We maybe strip all parameters.

        So you will see something like

        JmsConsumer[queue:foo](0xab242de)
        FileConsumer[/inbox/orders](0x12d42af)
        
        Show
        Claus Ibsen added a comment - - edited The problem with this patch is that your hardlock the route label when the MBean gets enlisted. If the route is later stopped, and the processor is adjusted, then the MBean would potential be misleading. Also the labels can get long and complicated. If you use an aggregator etc. Also you can potentially have clashes if there are multiple routes with similar routes. You frankly need the identify hash code. I have though about adding a /routeX in the MBean key if its part of a route. Then you would have a tree like + consumers \- route1 + consumer1 \- route2 + consumer2 Then its maybe quicker to find the consumer you are looking for. On the consumer MBean we may enlist part of the endpoint in its name. Then you may be able to quicker identify what you are looking for. Although endpoint uris can be long and complicated. We maybe strip all parameters. So you will see something like JmsConsumer[queue:foo](0xab242de) FileConsumer[/inbox/orders](0x12d42af)
        Ben O'Day made changes -
        Attachment CAMEL-3906.patch [ 12478614 ]
        Hide
        Ben O'Day added a comment -

        simple patch to make consumer/processor JMX names more descriptive

        Show
        Ben O'Day added a comment - simple patch to make consumer/processor JMX names more descriptive
        Ben O'Day made changes -
        Field Original Value New Value
        Assignee Ben O'Day [ boday ]
        Mitko Kolev created issue -

          People

          • Assignee:
            Unassigned
            Reporter:
            Mitko Kolev
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:

              Development