If after installation the App is not visible (it isn't on the header at the top of the page; it's also absent in the "manage apps" section of Jira) it is possible you need to increase the plugin timeout period. Jira needs to must allow at least 300 seconds for an installation (preferably 600 seconds) for an installation.
Indications:
Jira logs show a message in the following format:
Unable
...
to
...
start
...
the
...
following
...
plugins
...
due
...
to
...
timeout
...
while
...
waiting
...
for
...
plugin
...
to
...
enable:
...
eu.softwareplant.bigpicture
| Code Block |
|---|
org.eclipse.gemini.blueprint.context.support.OsgiBundleXmlApplicationContext.loadBeanDefinitions(OsgiBundleXmlApplicationContext.java:140) at org.springframework.context.support.AbstractRefreshableApplicationContext.refreshBeanFactory(AbstractRefreshableApplicationContext.java:129) at org.springframework.context.support.AbstractApplicationContext.obtainFreshBeanFactory(AbstractApplicationContext.java:537) at org.eclipse.gemini.blueprint.context.support.AbstractDelegatedExecutionApplicationContext.access$800(AbstractDelegatedExecutionApplicationContext.java:60) at org.eclipse.gemini.blueprint.context.support.AbstractDelegatedExecutionApplicationContext$3.run(AbstractDelegatedExecutionApplicationContext.java:242) at org.eclipse.gemini.blueprint.util.internal.PrivilegedUtils.executeWithCustomTCCL(PrivilegedUtils.java:85) at org.eclipse.gemini.blueprint.context.support.AbstractDelegatedExecutionApplicationContext.startRefresh(AbstractDelegatedExecutionApplicationContext.java:220) at org.eclipse.gemini.blueprint.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor.stageOne(DependencyWaiterApplicationContextExecutor.java:224) at org.eclipse.gemini.blueprint.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor.refresh(DependencyWaiterApplicationContextExecutor.java:177) at org.eclipse.gemini.blueprint.context.support.AbstractDelegatedExecutionApplicationContext.refresh(AbstractDelegatedExecutionApplicationContext.java:157) at org.eclipse.gemini.blueprint.extender.internal.activator.LifecycleManager$1.run(LifecycleManager.java:207) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) |
As you can see below, the countdown starts with 60 - it should start with at least 300. Preferably 600.
| Code Block |
|---|
Plugins that have yet to be enabled: (1): [eu.softwareplant.bigpicture], 60 seconds remaining Plugins that have yet to be enabled: (1): [eu.softwareplant.bigpicture], 59 seconds remaining (...) Plugins that have yet to be enabled: (1): [eu.softwareplant.bigpicture], 0 seconds remaining |
Cause:
As the JIRA application starts up, it goes through the following steps when starting the Plugin System:
$JIRA_INSTALL/atlassian-jira/WEB-INF/classes/atlassian-bundled-plugins.zipis extracted to$JIRA_HOME/plugins/.bundled-plugins.$JIRA_HOME/plugins/installed-pluginsis extracted to$JIRA_HOME/plugins/.osgi-plugins.
This is a fairly resource-intensive process and can place a sizeable load on the I/O of the disk and CPU of the machine that is hosting the JIRA application instance. If the required resources aren't available, the plugins may timeout and cause the application to be left in an unusable state.
This error can happen quite often on servers that only have a single-core vCPU available - JIRA applications are multi-threaded and there will be CPU contention on startup which can subsequently cause timeouts to occur.
Solution
It is possible to increase the plugin timeout period by adding the -Datlassian.plugins.enable.wait=600 argument to the JIRA application startup arguments, as in Setting Properties and Options on Startup.
This will increase the time taken to start the JIRA application up, and it does address the symptom rather than the root cause. If the machine is not powerful enough to run the application, we would suggest looking at upgrading to a more powerful host.