I’m working on several modules at the moment that depend on each other, and I would like to setup continuous communication between them while they’re running (My first thought is something like a publish/subscribe model). Does anybody know how this can be achieved in Ignition?
Right now during testing, I’m having the modules create/constantly check and update a text file in the tmp directory, but that doesnt feel like a good long term proposition. the information being passed may change rarely, so constantly reading a text file may be inefficient.
I can’t really think of anything better at the moment.
What scope are these modules running in? Do they depend on each other (in the Ignition module dependency sense, as in module A depends on module B in its module.xml file)?
Interesting problem. I would mimic Ignition’s Push notification system. Have a central class with static methods that look up either a global hub, or a project-specific hub. The hub class (possibly just an instance of the central class) would then have methods to register a listener, and add notifications. You could even have those hub methods use the native push listener classes to eliminate the bulk of your coding effort.
Put all of this in a separate module and make your other modules depend on it.
Object lifetimes will be tricky. The push notification system gets away without a de-register function because its all in the clients, and they can’t unload their modules. The entire client restarts in such cases.
In the gateway, modules can be loaded, unloaded, reloaded, and restarted at will. A registered listener will cause old module versions to remain referenced, with corresponding memory leak and unwanted behavior. You would have to solve that part. I haven’t looked to see if there’s a module manager event that could be hooked to deal with that.
The modules are all gateway scoped, nothing else. They don’t strictly speaking “depend” on each other in an Ignition module dependency sense, they simply need to share some information…
The Push notification idea sounds promising, Thanks for the suggestion! I’d certainly prefer to go that route. The only other idea I’m considering is to incorporate an external Java pub/sub api into all the modules which means I have to manage socket connections, and those can be unreliable.
A “central” module that all your other modules depend on, that does nothing but expose a Guava EventBus, might work just fine.
Thanks for the help.
I’ve been reading up on Guava EventBus, looks like it’ll do the trick. I also thought of creating a tag driver, maintaining information through its driver tags, and just having other modules subscribe to those tags… (wont be doing either till Monday, since its the end of the workday in France )
turns out there’s a Guava EventBus in ‘context.getEventBus()’, buried in one of the interfaces extended by GatewayContext.
[quote=“nifemi”]turns out there’s a Guava EventBus in ‘context.getEventBus()’, buried in one of the interfaces extended by GatewayContext.
Careful. I suspect you’re going to run into weird class loading issues with your event objects if you use this one.