9 Replies Latest reply on Apr 16, 2009 6:36 PM by Ian Springer

    JBoss messaging queue autodiscovery

    Fredrik Newbie

      Hi,
      I am running JON (server,agent) version 2.1.2.SP1. When I add a queue to my monitored JBoss As instance, it does not show up in JON automatically. I have to run an agent "discovery -f". I have tried to configure different parameter in agent config file, to no luck. Does anybody know how i can get the queues to show up automatically.

      Thanks!
      Fredrik

        • 1. Re: JBoss messaging queue autodiscovery
          Heiko Rupp Master

          Hello,

          do you add the Queue via JON or by hand.
          If the latter: the agent should pick it up after at most 24h. You can also run a "manual discovery" (with full scan enabled) from the platform's operations tab).
          If you have added it via JON itself, can you please open a JIRA at https://jira.jboss.org/jira/browse/JOPR with more details on how to reproduce the issue?

          • 2. Re: JBoss messaging queue autodiscovery
            Fredrik Newbie

            I just deployed a queue in JBoss by adding a service xml to the deploy directory. Is it possible to shorten the time? 24 hours is a bit long. What config parameter should i change? I tried most of them but with no luck.

            /Fredrik

            • 3. Re: JBoss messaging queue autodiscovery
              mazz Master

              You can configure this. But before I tell you how, I remind you that performing service scans may be time consuming, which is why we do it every 24 hours (time consuming because, for example, the agent has to probe the JBossAS's JMX Server and look at all the MBeans to see if anything is new). But if you don't mind having the agent probe your JBossAS server more frequently, then look in your agent's configuration file (located at {agent-install-dir}/conf) and you will see this setting:

              <!--
               _______________________________________________________________
               rhq.agent.plugins.service-discovery.period-secs
              
               Defines how often a service discovery scan is run. This type
               of scan is used to find new services that have been added or
               removed from existing platforms and servers. Technically,
               this kind of discovery is used to find any child resource
               to an existing parent resource (like a platform or server).
               The value is specified in seconds.
               -->
               <!--
               <entry key="rhq.agent.plugins.service-discovery.period-secs" value="86400"/>
               -->
              


              It is commented out, but you see its default value. Read the comment to learn about this setting.

              To change this setting, you can do so directly from the UI (assuming you have imported your "RHQ Agent" resource into inventory). Traverse to the Config tab of your agent resource and you'll see this setting.

              Otherwise, you'll have to modify the agent configuration by hand via the "setconfig" prompt command. You cannot just simply edit this agent-configuration.xml file and expect the change to take effect, PLEASE read the comments at the top of agent-configuration.xml for more on changing the config.

              • 4. Re: JBoss messaging queue autodiscovery
                Fredrik Newbie

                Thanks! Now it works. Missed the part about "this configuration file is no longer read or used".

                /Fredrik

                • 5. Re: JBoss messaging queue autodiscovery
                  Heiko Rupp Master

                  Mazz,
                  would 1h be a good compromise between load on the resources and convenience for the user ?

                  Heiko

                  • 6. Re: JBoss messaging queue autodiscovery
                    Ian Springer Master

                    +1 on lowering the default interval - I'd vote for somewhere between 1 and 3 hours. I know the service scan puts some load on the managed servers and so it's undesirable to run it too often, but 24 hours always seemed too extreme to me.

                    • 8. Re: JBoss messaging queue autodiscovery
                      mazz Master

                      I added a comment to the JIRA.

                      Is 1h really that much faster from a new user's perspective than 24h?

                      And is it worth the additional overhead (24x overhead) to provide this?

                      The 24h automatic scan was to detect things changing that an admin wasn't aware changed.

                      Normally, if we deploy things through the UI, we'll force a scan and we'll detect it immediately (this happens today). If you deploy things outside the UI, all you need to do is execute a Manual Discovery (several ways to do this via the UI in addition to the agent "discovery" prompt command).

                      The 24h scan is only to detect things that happened when they weren't expected by the admin.

                      I would rather not decrease performance to support something that can be accomplished in other ways (the user just has to tell the UI to run the discovery).

                      What does 1h give you that 24h doesn't? Its still "a long time" from a users perspective. So, now, I can manually deploy a war and just have to wait 1 hour for it to show up, as opposd to 24h? :-/ Still isn't very "responsive" to a user. But the point is, the 24h isn't supposed to be responsive to the user - its supposed to periodically catch things changing in the environment that an admin wasn't aware of.

                      And of course, a user is still allowed to configure this however they want - but if they change it, it is on them when performance on the agent suffers.

                      • 9. Re: JBoss messaging queue autodiscovery
                        Ian Springer Master

                        Well, 1 hour may not be instant gratification, but it's a lot more responsive than 24 hours. Perhaps we can compromise and set it to 3h or 6h.