powered by Jive Software

Monitoring Service - If you do not use parameters, it brings results that have just been written to the database, but if you use it, do not!

Hello, how are you?

I currently use Openfire 4.3.2 and the version of the Monitoring Service plugin is 1.7.0.
The database we use is Oracle 11G.

When you go to the “Search Archiv” option and search without filling in any parameters, the system brings all the results of the archived conversations, including what you just archived. This behavior is totally correct!
The big problem is if you inform some parameter, such as “Keywords” or any other. In this case, it does not bring the current conversations and would only bring me if I enter the “Archiving Settings” tab and click on the “Rebuild Index” button and wait for the index to be redone.
Apparently, if you do not use any parameters, it searches directly in the database and if you use it, it searches the index that it creates. Would you always search the database? Or would this index have to be better implemented, to the point of being with the most current conversations in it?

Thank you!

I have just ran a few tests. After you send a message it can be found immediately if you search without any criteria or by names or dates. But not by a keyword. If you run “Rebuild Index” it is possible to find a message by keyword. But i have just waited a few minutes without rebuilding the index and it worked with keyword too. I’m not a developer, but i guess searching by keywords needs index for faster searching and automatic indexing takes some time (maybe it runs every few minutes). I think it is enough for regular usage and maybe running indexing too often would impact performance.

@guus @gdt ?

So, here by keyword or by period, only old conversations appear, but not new ones. By the tests I did, even waiting 1, 2 days to a week, which was that I did the test, the index did not complement itself. I had to ask to build the index.

Maybe it is related to your database, version, size. My test server has very small database and i’m using the embedded one. So maybe it updates faster. Anyway, it looks like in your case indexing is not running automatically, but i can’t say why. This might require deep investigation.

Btw, anything related in logs?

I use Oracle 11G. There is no error in the log.

By default, the index is updated every 15 minutes (the first run will be 5 minutes after the plugin starts).

You can update the interval by changing the value of conversation.search.updateInterval to a numeric value, which is the amount of minutes between each re-index. Changes to this property will not be detected until the plugin (or Openfire) is restarted.

I can’t explain why your Openfire does not do automatic refreshes. Maybe something got corrupted? You can remove the entire index by removing the <OPENFIRE_HOME>/monitoring/search directory. I strongly advice you shut down Openfire before you do this, and create a backup. The directory should be created again automatically (after five minutes). If that does not happen, then the automatic indexing doesn’t run. The most obvious reason for that is that archiving is disabled (at least one of these must be enabled: message archiving, room archiving).

Hello Guus, how are you?
I did what you suggested, in stopping the openfire, deleting the folder and waiting. He rebuilt the index himself, but look how funny.
After rebuilding, I caught up with a conversation today and viewed it without using any filter. I picked up a word used in this conversation and searched for it. Could not find the word today. Only in previous days.
I checked into “System Properties” if it had the property mentioned by you and it had not. I created it, as can be seen in the image below.
I rebooted openfire, and waited for over 40 min. and search behavior using keyword or other filter, is the same as I mentioned earlier.
As it can be verified, this new version of Openfire is not generating any errors. Unlike the previous version, it made many mistakes!

Figure 1. System Properties.

Figure 2. Filing Settings.

Another interesting thing. When I deleted the folder you mentioned and started openfire then it took the plugin monitoring the OS language, rather than the language that is configured in Openfire.
The OS is in “Portuguese - Brazil” and Openfire in English!

See Figure 2 and 3.

Figure 3. Language and Time.

Below is the Openfire log. After installing the new version, no more errors appeared.

Figure 4. Logs.

About the language, in the previous version, we had set the language “Portuguese - Brazil” in Openfire. So, I do not know if the plugin got the OS or the old configuration.

Thank you!

You are putting a lot of issues into one thread, so it can get confusing quickly. The issue with empty logs was reported a few times after 4.3 update. I think it is somehow related to permissions. It is mentioned here https://issues.igniterealtime.org/browse/OF-1684 along with other issues. Although i can’t reproduce that on Ubuntu 18.10. After i do test installation i get plenty of logs.

The issue with plugins using OS language instead of Openfire set language is known with a few plugins. This is a ticket for Monitoring https://github.com/igniterealtime/openfire-monitoring-plugin/issues/6

OK! The main problem was reported and documented. The most important is the main, that is, the search through the filters, stay right! That, if possible, is clear. I know you give the best to bring several solutions and free !!!

The problem persists!