- One set of Confluence, Crowd and Jira for the FudgeMsg project running in one Tomcat container on one VM
- One set of Crowd and Jira for our corporate use running in one Tomcat container on one VM
- Bamboo and FishEye for OpenGamma corporate use running behind our firewall in their own standalone implementations in their own VMs.
Reindexing Requires CrowdIf you're running your applications with Crowd, the application delegates user-related information to Crowd and uses a RESTful approach to loading the data. So far, so good. However, when Jira attempts to in-situ upgrade an installation (which again they don't recommend), it will do its database wrangling, and then reindex the system with the new functionality (in our case, going from 4.0 to 4.1.1 to allow searches based on votes and watches on issues). All this upgrading it does in the application startup logic, which happens in the Tomcat main thread. When it gets to reindexing, it then attempts about 10 different RESTful calls to your Crowd instance, as it doesn't have any caches populated on user data. However, while Tomcat has opened up port 80 (or 8080 or whatever) for Crowd, it hasn't enabled application dispatch to the Crowd servlets yet. This means that all 10 remote calls (which are actually local to the single Tomcat instance since both apps are co-hosted) hang, and the entire server startup process fails. The only workaround is to launch Crowd in its own servlet container, change your Jira's
crowd.propertiesto refer to the new one, startup, and then undo what you've done.