It seems you have no tags attached to pages. To attach a tag simply click on the tags button at the bottom of any page.
Matthew Kemp 1222885918|%e %b %Y, %H:%M %Z|agohover
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.
epchris 1222842686|%e %b %Y, %H:%M %Z|agohover
I just tried integrating in ERMA using your example for spring integration and got a NoClassDefFoundError for the class
edu/emory/mathcs/backport/java/util/concurrent/ScheduledExecutorService
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?
mokeefe 1218554899|%e %b %Y, %H:%M %Z|agohover
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?
mokeefe, 1218554899|%e %b %Y, %H:%M %Z|agohover
ab777 1218058539|%e %b %Y, %H:%M %Z|agohover
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: http://erma.wikidot.com/configuring-erma-using-spring
. 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.
Thanks
ab777, 1218058539|%e %b %Y, %H:%M %Z|agohover
smullins 1218057128|%e %b %Y, %H:%M %Z|agohover
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.
smullins, 1218057128|%e %b %Y, %H:%M %Z|agohover
ab777 1218056155|%e %b %Y, %H:%M %Z|agohover
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
ab777, 1218056155|%e %b %Y, %H:%M %Z|agohover
smullins 1218046668|%e %b %Y, %H:%M %Z|agohover
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});
MonitoringEngine.getInstance().setProcessorFactory(factory);
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.
smullins, 1218046668|%e %b %Y, %H:%M %Z|agohover
ab777 1218040448|%e %b %Y, %H:%M %Z|agohover
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(MonitoringEngine.java:89)
at ErmaTest.main(ErmaTest.java:24)
ErmaTest.java: 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.
Thanks
ab777, 1218040448|%e %b %Y, %H:%M %Z|agohover
smullins 1218038066|%e %b %Y, %H:%M %Z|agohover
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.
dougbarth 1217947935|%e %b %Y, %H:%M %Z|agohover
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.
gopaczewski 1217618248|%e %b %Y, %H:%M %Z|agohover
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.
dougbarth 1217605785|%e %b %Y, %H:%M %Z|agohover
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.
smullins 1217600771|%e %b %Y, %H:%M %Z|agohover
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?
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.
Matthew Kemp 1217537418|%e %b %Y, %H:%M %Z|agohover
Relying on attributes like vmid and hostname is not very generic. The mandatory use of these is being removed from the MonitoringEngine.
dougbarth 1217534074|%e %b %Y, %H:%M %Z|agohover
Am I missing something? These classes seem pretty generic to me.
smullins 1217533553|%e %b %Y, %H:%M %Z|agohover
Here is the list Greg and I are proposing:
These classes rely heavily on specific attributes that Orbitz uses.
