Recent Forum Posts
From categories:

The reason we rely on the edu.emory.mathcs.backport is because of Java 1.4 support. I know that 1.4 is near end-of-life, but at the time we release erma we still required 1.4 support.

I just tried integrating in ERMA using your example for spring integration and got a NoClassDefFoundError for the class
Is there a reason why ERMA relies on edu.emory.mathcs.backport? Why not just the ScheduleExecutorService in java 1.5? is it just too late and my brain isn't working?

If you have configured ERMA using Spring wiring, including the MonitoringEngineManager bean, then you shouldn't need to call MonitoringEngine.getInstance().startup() within your application.

Could you post your xml here and we'll review it?

I am getting your idea now. Can you please help me out.

I am trying the following:

. I have configured the ERMA in a xml file using the steps given on the link:
. I have a simple Java application in the same project that uses the ERMA monitor APIs. But when I called MonitoringEngine.getInstance().startup() in my application, it was giving the error: processorFactory is null. Is there anything else that I need to do in my application?

Do I need to run the MonitorProcessor in a separate project.

Do let me know if you need any other information related to my code. I will appreciate that.


Typically, we configure ERMA via Spring wiring. That's where we create our ProcessGroups and MonitorProcessors. How have you configured ERMA for your project?

The above code was an example of how to configure the processor factory programatically, if you don't use Spring for dependency injection.

MonitorProcessors are passed into the ProcessGroups and are designed to consume Monitors and process them in some way. An example would be the LoggingMonitorProcessor which as it receives Monitors from the MonitoringEngine it will log them out.

Thanks for the suggestion.

Am I missing something on the documentation page, as I didn't find the above code. One more thing: how to initialize "someMonitorProcessor" above? Its an error when I create an instance of MonitorProcessor.

What else do I need to do to observe the captured events? I have the following:
1) Test application alongwith monitors
2) In the same project, I have configured ERMA
3) I assume I need to run the MonitorProcessor in a different project right?

Thank you very much

Hi ab777,
You're getting that error because you haven't specified the processor factory for your MonitoringEngine. You need to do something like this:

ProcessGroup pg = new ProcessGroup(someMonitorProcessor);
SimpleMonitorProcessorFactory factory = new SimpleMonitorProcessorFactory(new ProcessGroup[] {pg});

If it helps, you may want to look at the unit tests for these classes to get a clearer picture for how they work together. Think of a ProcessGroup as a way to route Monitors to a set of MonitorProcessors.

I want to use the functionality provided by ERMA monitors. I created a sample Java application and hooked the erma monitor APIs into it. Also, I configured ERMA using the steps provided by you.

But, I am not completely clear from the documentation. So, when I ran the application, I got this exception:

Exception in thread "main" java.lang.IllegalStateException: processorFactory is null
at com.orbitz.monitoring.api.MonitoringEngine.startup(
at ErmaTest.main( 24 has MonitoringEngine.getInstance().startup();

Can you please help me in using the monitor functionality and viewing the captured events at the processor side. Do I need to hook some additional code in the application besides calling the monitoringEngine startup/shutdown and monitor APIs.


Ok, I'm going to remove the EventPatternMonitorProcessor only. I'll refactor the xmlMonitorRenderer to not have hardcoded attribute names so its more flexible. Once that's done, I think we're good to release the first binary.

Re: Removal of Classes by smullinssmullins, 06 Aug 2008 15:54

I can buy that argument. Obviously, this MP would be a lot more useful if we had an open source EPM system. Since we don't, we might as well remove it.

Re: Removal of Classes by dougbarthdougbarth, 05 Aug 2008 14:52

OK, can we compromise here by removing just the EventPatternMonitorProcessor? Even if we were to refactor this I don't see anyone else getting much value out of a processor that renders a monitor to xml and sticks it in a separate attribute of the same monitor. Orbitz can then extend the XmlMonitorRenderer internally with EPM app specific stuff.

I think the general issue here isn't just whether code is "generic" enough, but whether we expect others to perceive value in something vs. it just having the appearance of cruft.

Re: Removal of Classes by gopaczewskigopaczewski, 01 Aug 2008 19:17

Assuming those two attributes are always there is fine IMO. However, what they are initialized to, should change.

hostname can be initialized correctly in the MonitoringEngine so we might as well keep it. vmid should be defaulted to something sensical like "not set" and we should drop the initialization from Orbitz specific environment properties. That code initialization code can live in your codebase.

I don't see any harm in keeping those attributes. The only case were they wouldn't be applicable would be in a non-distributed environment. But then, there's a lot of stuff in ERMA that could go away if we assumed we aren't distributed.

Re: Removal of Classes by dougbarthdougbarth, 01 Aug 2008 15:49

but should those be mandatory? I removed setting those attributes from the MonitoringEngine, so can we guarantee that everyone who uses erma would always use those attributes?

Re: Removal of Classes by smullinssmullins, 01 Aug 2008 14:26

The "vmid" attribute is simply a name for the application, and "hostname" is the name of the machine that it is running on. How are those not generic? In the case where you are monitoring a distributed system, it is certainly always the case where you'd want to record those attributes in your events.

Re: Removal of Classes by mokeefemokeefe, 01 Aug 2008 01:08

Relying on attributes like vmid and hostname is not very generic. The mandatory use of these is being removed from the MonitoringEngine.

Re: Removal of Classes by Matthew KempMatthew Kemp, 31 Jul 2008 20:50

Am I missing something? These classes seem pretty generic to me.

Re: Removal of Classes by dougbarthdougbarth, 31 Jul 2008 19:54

Here is the list Greg and I are proposing:

  1. EventPatternMonitorProcessor
  2. EventPatternMonitorRenderer
  3. EventPatternLoggingMonitorProcessor
  4. XmlMonitorRenderer

These classes rely heavily on specific attributes that Orbitz uses.

Removal of Classes by smullinssmullins, 31 Jul 2008 19:45
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License