Support Migration Notice: To update migrated JIRA cases click here to open a new case use www.vmware.com/go/sr | vFabric Hyperic 5.7.0 is Now Available

Hyperic HQ

Make the query property-based in the plugin to monitor multiple Spring applications on one machine

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Deferred
  • Affects Version/s: 4.2.0.7
  • Fix Version/s: None
  • Component/s: None
  • Case Links:
    none
  • Regression:
    No

Description

Whenever I start up more than 1 of my instrumented Spring Applications they ALL become 'unavailable' at the Server Resrouce level in Hyperic. And if only one is running - they are all flagged as available.

This is a pretty basic test case so maybe a problem with my installation of HQ agent and server or something I'm doing wrong on the application side. Could someone give me some help on this?

I'm running Open Source HQ server and agent 4.2.0.7 (with and without the patches supplied by Dave and Holly) on Platform :
Description: SuSE 10
Vendor : SuSE
Vendor Version : 10
OS Version : 2.6.16.60-0.37_f594963d-vmi
Architecture : i686

The simplest test case I can come up with is to run this class on a server with the HQ agent installed:

public class KeepOnRunning {

public static void main(String[] args) throws NumberFormatException,
InterruptedException { Thread.sleep(Integer.parseInt(args[0])); System.out.println("Woke up, bye"); }
}

I run it with command line options as specified here: http://support.hyperic.com/display/DOC/Instrumenting+Java+Applications+for+Management

For example:
$ java -cp -Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=6980
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false
-Dspring.managed.application.name=FirstServer KeepOnRunning 600000 &

Once running instigate an Autodiscovery in hyperic and you should see a new 'Server' on the platform called '<server> FirstServer Spring Application'

This should have a nice green Availability metric when the app is up, and it'll go red when it goes it down...

Now run another instance of the app with different JMX port and app name:
$ java -cp . -Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=6980
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false
-Dspring.managed.application.name=SecondServer KeepOnRunning 600000 &

Even without instigating Autodiscovery, the Availability of FirstServer will become red whenever SecondServer is running. However if SecondServer is running but FirstServer is down, then FirstServer shows as Available again.

I know that there is no actual spring conext involved in my test
class, but I get the same problem if my JVM's create a Spring Context instantiated againstinstrumented Spring (v3) jars. In that case the exposed Services inside the Spring Application Servers remain available and visible but, as above, 'Avaliablity' for all Spring Application Server Resources goes red once more than one is running.

Activity

Hide
Helena Edelson added a comment -

I think the PTQL for the Spring Application process is not unique enough to allow 2 instances of a Spring application on the same machine.

This resolved his issue locally but we might treat this as a bug.

Go to Inventory->Configuration for each of the servers and change the ptql property value to "State.Name.sw=java,Args..eq=-Dspring.managed.application.name=FirstServer" and "State.Name.sw=java,Args..eq=-Dspring.managed.application.name=SecondServer" respectively.

Show
Helena Edelson added a comment - I think the PTQL for the Spring Application process is not unique enough to allow 2 instances of a Spring application on the same machine. This resolved his issue locally but we might treat this as a bug. Go to Inventory->Configuration for each of the servers and change the ptql property value to "State.Name.sw=java,Args..eq=-Dspring.managed.application.name=FirstServer" and "State.Name.sw=java,Args..eq=-Dspring.managed.application.name=SecondServer" respectively.
Hide
Idan Hod added a comment -

As part of our continuous effort to improve product quality, The Hyperic product team has decided to implement a "zero bug policy" methodology.

Following this methodology, only defects that are planned to be handled in the near future will remain open. Any other defect will be deferred, with the option to be reevaluated if the need arises, or if changes to the Hyperic road-map make such defect a candidate for a fix.

We believe this new process will help create clarity and focus in the Hyperic road-map and ultimately benefit our customer base.

This bug has been deferred as part of the new policy.

We appreciate your cooperation and continues contribution to the improvement of Hyperic.

Show
Idan Hod added a comment - As part of our continuous effort to improve product quality, The Hyperic product team has decided to implement a "zero bug policy" methodology. Following this methodology, only defects that are planned to be handled in the near future will remain open. Any other defect will be deferred, with the option to be reevaluated if the need arises, or if changes to the Hyperic road-map make such defect a candidate for a fix. We believe this new process will help create clarity and focus in the Hyperic road-map and ultimately benefit our customer base. This bug has been deferred as part of the new policy. We appreciate your cooperation and continues contribution to the improvement of Hyperic.

People

Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved:
    Last comment:
    42 weeks ago