We’‘ve been using OpenFire for quite some time now - from WildFire all the way up to the latest OpenFire - on many different computers with OS’‘s ranging from Windows 2000 to Vista and have run into an issue where the server does not always seem to update the settings through the administrator page. It seems like there is no set combination of actions that forces the change to take (we’'ve tried everything we can think of), but it seems like more often than not our settings get erased next time the server restarts.
I looked through the source code and was somewhat surprised to see that a “Settings saved successfully” message is returned regardless of whether the setting was actually saved correctly through the underlying events, however any error should have shown up in the error log (based on what I saw in the code) yet there are never any errors when the settings aren’'t saved.
We are using the embedded database, so perhaps that has something to do with it, however I can’'t see any logical reason why this should be happening other than if write caching was enabled with some obscenely long value and we were restarting the server before the changes were written.
the embedded hsqldb should write all changes to the embedded-db/openfire.log file without delay. So if you change something this file should be updated with the new settings. Not sure if you can use it to verify that your changes were written to the database.
“Settings saved successfully” message is returned regardless of whether the setting was actually saved sound like a bug, may I ask which file and line numbers you are referring to?
I’'ve verified that it does not write any errors or information regarding the changed values to the log file when it claims to have saved the settings. In fact, at times I can see in the log that it deletes the property and inserts the property with the new value in the log, however when I restart the server the old value shows up.
The code I was looking at is in the server-properties.jsp file starting on line 82:
Since JiveGlobals.setProperty does not throw any exceptions, this code is always returning with a settings saved successfully message regardless of whether the settings were in fact saved, which in my case they frequently aren’‘t. There apparently is a property_set event dispatched by the JiveProperties class when a property is updated or inserted, so it’‘s odd that the server-properties.jsp page doesn’'t make use of this during updates.
The only thing that seems to make sense to me is that I noticed at some point looking through the embedded-db/openfire.log that autocommit was disabled, which would explain why none of the settings were being committed until something got around to committing the changes, however I don’'t know how to verify this and/or fix it.
Well I’'ve done some digging and found that by default the embedded database does cache changes to disk, which is defaulted to 20 seconds. So if the server shuts down before then, your changes are lost. Additionally, what is being written to disk is merely a log of your changes since the last checkpoint or shutdown command was issued and those changes are not guaranteed to make into the database after it is recreated upon the next startup if either of those two commands are not executed properly.
The other thing that I noticed was that, despite the API’'s being available to provide a clean shutdown of the server and therefore the database connection, there is no mechanism for actually performing a clean shutdown in the user interface or the daemon (which the GUI launches). The stop button merely kills the daemon thread. Frankly this is rather absurd, as regardless of whether you are using the embedded database or not, you are never going to get a clean disconnect from the database since the connection managers never get a chance to shut down properly. These are basic programming principals here people.
Considering how trivial it is to support clean shut downs of the server, I strongly urge the developers to enable this support.
So here are the issues so far:
Admin Page always shows settings as being saved successfully regardless of any errors that may have occurred or whether the database actually saved the changes.
The server never allows for a clean shut down, meaning data integrity is a big issue. <-- using the windows GUI
Changes to server settings using the embedded HSQLDB are never saved if the server shuts down before the default 20 second write-to-disk setting
Changes written to the embedded HSQLDB are never reliable due to the server never shutting down cleanly as per item #2
Message was edited by: dhm116 - clarified issue #2
I did create JM-1098 to track these issues while I can not reproduce problems during shutdown.
I use a normal kill -15 signal on linux and this shuts down Openfire with the embedded database just fine, the openfire.log and openfire.lck files are removed during shutdown.
Thanks for giving this some attention and entering this as an issue to be looked into!
An issue like not being able to save server settings properly, while not terribly detrimental to the overall functionality of the server, seemed like a basic enough issue that if that wasn’‘t being done correctly, how reliable is the rest of the implementation? This is a question others kept asking me with regards to justifying using OpenFire in our implementation, and while I believe that this sort of issue does not necessarily reflect on the rest of the implementation, it’'s hard to convince others of that when they can see something as simple as this not being handled correctly.