I am wondering why we need all the full functionality of the Monitoring plugin while we are mainly leveraging only the message archiving parts of it (The admin console search is not that critical for us). Any input on branching out the monitoring plugin to use only the archive part or are there any configuration knobs to make this lighter? Currently, this plugin is definitely adding delays/complexity for upgrades, restarts of the service, given the large size of our message archive. Thanks for your input!
The Monitoring Service plugin has a complex history. It effectively is two plugins wrapped in one: a part that performs message archiving, and a part that collects statistics.
Although it makes sense to separate the two (or even more sense to inline the message archiving functionality into Openfire itself), the burden of doing that, combined with all of the backwards compatibility issues that this might cause, has prevented us from doing that so far.
Although there is more functionality in the plugin that just ‘message archiving’, I am surprised to read that you believe that the functionalities measurably affect each-others performance - or am I misinterpreting the message that you are trying to get across?
Exactly what parts of the plugin is adding the overhead that you are referring to?
Thanks for the prompt response Guus. Our message archive has over 150M records at the moment. The challenges have been the index rebuilds with server version upgrades. We are currently at 4.6.4 and trying to move to any higher version, takes hours to rebuild the indexes and that also shoots up the CPU utilization on those hosts.
Ah, you’re talking about the Lucene indices, that are used for text search. There currently is no configuration option to disable that feature (and the corresponding index generation). I can see the value in that, so I’ll at the very least raise a feature request: Allow text search to be disabled · Issue #354 · igniterealtime/openfire-monitoring-plugin · GitHub
Generically speaking, indexing is additive. A complete re-index should be a rare occurrence, and only happen when an index’ structure is broken/outdated.
You might be able to trick the plugin in thinking that the indices are OK / need no updates, but that’s a hacky solution at best. Each index is stored on disk, in directories under OPENFIRE_HOME/monitoring. If you add two small (empty?) indices in those directories, and modify the metadata in indexprops.xml to suggest that the last time the index was updated is some date far in the future, you might be able to prevent indexing from taking place.
The suggested approach to trick Openfire to skip indexing works. Thanks!
1 Like