If a docbase is down, OpenContent will fail to start up correctly since it will throw an error during the dictionary init method. Once that error is thrown, none of the proper Spring beans are wired up, and the entire Tomcat must be restarted while the docbase is up.
Seems minor, but lots of clients have concerns with restart order in the case of an issue, and since we are 100% relying on the fact that the content server/docbase will be up at the time of restart, there are a bunch of dependencies that they have to be aware of when restarting any of their servers.
We could potentially fix this by catching (and logging) the error in the init and setting the dictionary to an empty map. Then every time we call the dictionary service, we would check if the map is null, and if it is try to run the init method again to populate it. This would remove the dependency, but isn't the most elegant solution...
If a docbase is down, OpenContent will fail to start up correctly since it will throw an error during the dictionary init method. Once that error is thrown, none of the proper Spring beans are wired up, and the entire Tomcat must be restarted while the docbase is up.
Seems minor, but lots of clients have concerns with restart order in the case of an issue, and since we are 100% relying on the fact that the content server/docbase will be up at the time of restart, there are a bunch of dependencies that they have to be aware of when restarting any of their servers.
We could potentially fix this by catching (and logging) the error in the init and setting the dictionary to an empty map. Then every time we call the dictionary service, we would check if the map is null, and if it is try to run the init method again to populate it. This would remove the dependency, but isn't the most elegant solution...