managing monitor deletion and monitor injection via java plugin

1

Hi all,
I’m trying to dynamically manage monitor creation(injection) and deletion within my apama application.
While reading the documentation I went through the java API and I found out that I could use the EngineClientInterface interface and its implementing classes. In particular I tried to use the EngineClientInterface, the EngineClientBean class or the EngineManagement interface and take advantage of the deleteName() and the injectMonitorScriptFromFile() methods.
I made two version of the same code: one is a standalone java client application, the second one is an apama java plugin in order to invoke its static methods as soon as an event is intercepted by a listener.
At the moment, only the standalone java client is working properly.
It seems that I can’t use the EngineClientInterface interface (or similar classes) within an apama java plugin.
How can I solve this? Is there any other alternative?

2

Could you provide a bit more detail on why it is not working? Errors messages, logs, etc. Also please always say what product version you’re using.

I think it should work fine (assuming you’re not trying to do something weird like using this plugin to delete the only monitor that uses it, which would imply deleting itself)

3

Hello, thank you for your support.
Apama version is

correlator --version
correlator v9.9.0.7.297357
(build rel/9.9.0.x@297357 on amd64-win)

The java client appllication mainly consists of three instructions:

EngineClientInterface engineClient = EngineClientFactory.createEngineClient("localhost", 15903, "my-sample-process");

which is used to instantiate the engine client object

engineClient.deleteName("com.octotelematics.otp.apama.service.common.AggregationManager", false);

which is used to delete a monitor, similar to the engine_delete command

engineClient.injectMonitorScriptFromFile("D:/development/IDE/SoftwareAG/workspace99/core-services/monitors/AggregationManager.mon");

which is used to inject a monitor, similar to the engine_inject command.
Running the java client application is working just fine: after deleting a monitor, I check the correlator using the engine_inspect -m | grep AggregationManager command and I verify that there are no instances of that particular monitor. After injecting the monitor, I verify there is one instance of that monitor using the same engine_inspect -m | grep AggregationManager command.

Unfortunately this does not work within the apama java plugin that simply provides two static methods, one for monitor deletion and one for monitor injection.

// initialization code
static {
	logger.info("EngineExecutor plugin initialized!");
	try {		    
        engineClient = EngineClientFactory.createEngineClient("localhost", 15903, "my-sample-process");
    }
    catch (CompoundException e) {
        e.printStackTrace();
    }
}

public static void testDeleteMonitor(String monitorName) {
    try {
        if (engineClient == null) {
            logger.error("engineClient is null");
        }
        else {
            logger.info("engineClient is not null");
        }
        logger.info("apama java plugin: deleting " + monitorName);
        engineClient.deleteName(monitorName, false);
    }
    catch (EngineException e) {
        e.printStackTrace();
    }  
}

public static void testInjectMonitor(String filepath) {
    try {
        if (engineClient == null) {
            logger.error("engineClient is null");
        }
        else {
            logger.info("engineClient is not null");
        }
        logger.info("apama java plugin: injecting " + filepath);
        engineClient.injectMonitorScriptFromFile(filepath);
    }
    catch (EngineException e) {
        e.printStackTrace();
    }
}

the two static methods are invoked only after receiving a certain event containing information regarding the monitor to be deleted or the filepath to be passed in order to inject a monitor. After invoking the static methods of the apama java plugin, I only get the following logs

2017-03-02 17:16:34.183 INFO  [8288:processing] - <com.octotelematics.otp.management.utils.EngineExecutor> engineClient is not null
2017-03-02 17:16:34.199 INFO  [8288:processing] - <com.octotelematics.otp.management.utils.EngineExecutor> apama java plugin: deleting com.octotelematics.otp.apama.service.common.AggregationManager

but actually no monitor has been deleted or injected.
As always, I checked using the engine_inspect -m | grep AggregationManager command in order to count the number of monitor instances.

4

by the way, I’m working with Michele, the thread opener, on the same issue

5

If it didn’t work it’s very likely that an exception was thrown explaining why. Unfortunately this code’s try…catch is writing any stack traces to stderr - although this is the default code generated by many popular Java IDEs (like eclipse) this is a bad idea of a number of reasons, including that the stack traces don’t go into the main log along with the rest of your logging so easily missed, and also you have no time or thread information associated with them. I’d recommend using the com.apama.util.Logger (see JavaDoc) for all logging, especially exceptions, e.g.


private static final com.apama.util.Logger LOGGER = com.apama.util.Logger.getLogger(MyClass.class);
...
LOGGER.error("Failed to delete name from correlator: ", exception);

If you don’t see anything after making that change you might also add a LOGGER.info() line after successful return from the delete method just to confirm that it’s returned without error (though I think that’s unlikely).

As mentioned before, you also need to make sure that the monitor you’re trying to delete isn’t the one that loaded the plugin you’re using to delete it from (keep your EPL and plugins for deleting separate - maybe a whole separate EPL package from the rest of your application), as then you’d have a cycle and there’s no way that’s going to be able to complete.

6

I should also point out what even if the plugins is loaded by a different monitor, if it’s executing this delete call from within the same context as that monitor it’s also likely to block - but you can avoid that issue by spinning the delete call off into a background Java thread OR putting your deletion/monitor mangement logic into a separate context

7

I just tried implementing what you suggested, by using a monitor in another context. In particular a monitor in the main context spawns a new monitor to another context; the spawned monitor has an event that imports and invokes the apama java plugin.
However, still no success.
After the first invokation, I can no longer send other events in order to test the remaining static methods of the java plugin.
After a while I get some exception

meaning that the correlator didn’t acknowledge some previous message(s).
On the other hand, I also implemented an alternative solution using a new thread within the apama java plugin.
In this case, everything seems to work fine.
Thank you for your help