-
Bug
-
Resolution: Fixed
-
High (View bug fix roadmap)
-
4.2
-
4.02
-
OSGi (v2) plugins that ship by default with JIRA wait 60 seconds for JIRA to start up and load the necessary plugins that these plugins depend on.
If JIRA takes longer than 60 seconds to start up, these plugins will start timing out and fail to load giving errors such as the below one.
2010-10-28 00:07:26,109 main ERROR [atlassian.plugin.manager.PluginEnabler] Unable to start the following plugins due to timeout while waiting for plugin to enable: com.atlassian.gadgets.renderer,com.atlassian.jira.gadgets,com.atlassian.gadgets.oauth.serviceprovider,com.atlassian.gadgets.embedded,com.atlassian.streams.streams-jira-plugin,com.atlassian.gadgets.dashboard 2010-10-28 00:07:36,543 Timer-0 WARN [internal.dependencies.startup.DependencyWaiterApplicationContextExecutor] Timeout occurred before finding service dependencies for [OsgiBundleXmlApplicationContext(bundle=com.atlassian.jira.gadgets, config=osgibundle:/META-INF/spring/*.xml)] 2010-10-28 00:07:36,582 Timer-0 ERROR [internal.dependencies.startup.DependencyWaiterApplicationContextExecutor] Unable to create application context for [com.atlassian.jira.gadgets], unsatisfied dependencies: Dependency on [(objectClass=com.atlassian.gadgets.dashboard.DashboardService)] (from bean [&dashboardService]), Dependency on [(objectClass=com.atlassian.gadgets.view.GadgetViewFactory)] (from bean [&gadgetViewFactory]) org.springframework.context.ApplicationContextException: Application context initialization for 'com.atlassian.jira.gadgets' has timed out at org.springframework.osgi.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor.timeout(DependencyWaiterApplicationContextExecutor.java:462) at org.springframework.osgi.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor.access$000(DependencyWaiterApplicationContextExecutor.java:51) at org.springframework.osgi.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor$WatchDogTask.run(DependencyWaiterApplicationContextExecutor.java:108) at java.util.TimerThread.mainLoop(Timer.java:512) at java.util.TimerThread.run(Timer.java:462) 2010-10-28 00:07:36,589 Timer-0 ERROR [extender.internal.activator.ContextLoaderListener] Application context refresh failed (OsgiBundleXmlApplicationContext(bundle=com.atlassian.jira.gadgets, config=osgibundle:/META-INF/spring/*.xml)) org.springframework.context.ApplicationContextException: Application context initialization for 'com.atlassian.jira.gadgets' has timed out at org.springframework.osgi.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor.timeout(DependencyWaiterApplicationContextExecutor.java:462) at org.springframework.osgi.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor.access$000(DependencyWaiterApplicationContextExecutor.java:51) at org.springframework.osgi.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor$WatchDogTask.run(DependencyWaiterApplicationContextExecutor.java:108) at java.util.TimerThread.mainLoop(Timer.java:512) at java.util.TimerThread.run(Timer.java:462)
If it happens that one of the core plugins times out e.g. REST all depended plugins such as gadgets, activity stream will fail to load. Ultimately the application will start up in an obscure way and we are leaving users without any feedback about it.
Most customer report similar problem if JIRA takes longer to start up for e.g. due to under-performing hardware or virtualistaion infrastructure.
Unfortunately, at this stage the workaround is behaviour is to restart JIRA and allows it to reinitialise the plugin framework.
If one of the core plugins isn't initiated correctly, we should lock up the application and notify the user about this problem by dropping warring into the log file:
****************************************** JIRA startup failed, JIRA has been locked. ******************************************
and UI message:
- is duplicated by
-
-
- Closed
-
- relates to
-
JRASERVER-24968 Exclude non critical plugins from being included the failed initiation check
- Closed
[JRASERVER-22633] JIRA starts up in unworkable stage if core plugin is not started
Tim Moore [Atlassian]
added a comment - There's a related issue in JIRA Studio: https://studio.atlassian.com/browse/JST-3652
This change satisfies that issue for JIRA, but needs to be applied to other applications as well.
Tim Moore [Atlassian]
added a comment - There's a related issue in JIRA Studio: https://studio.atlassian.com/browse/JST-3652
This change satisfies that issue for JIRA, but needs to be applied to other applications as well. Hi Uwe,
Thanks for posting the sql statement. My understanding is that this advertisement appears for Evaluation & Starter licenses only. Please raise an issue if this isn't the case.
Cheers,
Peter
Hi Peter,
This is maybe another issue, as not really realted to this issue (we just recognozed it, as this issue prevented us from completely disabling the fisheye plugin):
You should be able to click "Hide" on the advertisement which is saved on a per-user basis.
The "per-user" setting is exactly the thing we don't want to show to our users. We are using JIRA mainly for a non-technical (non-software-development) related project and dont want to nag our external users with Fisheye, which they a) won't understand, b) won't use. This is why we disabled FishEye and previos versions ran fine without the plugin enabled. So the message, that it is "required" by JIRA is wrong and seems to be incorrect. It's just an advertisement to sell this product.
The only thing thats related to this issue is, that Fisheye should get the "system plugin" and "required" removed from it's properties, so it can be disabled like "Bamboo" and JIRA would start like it did with it disabled before.
@Uwe "We disabled FishEye in 4.2.x, because of stupid, always-nagging advertisements to use this plugin. As we don't need it, why is there no "legal" way to completely disable it?"
You should be able to click "Hide" on the advertisement which is saved on a per-user basis.
@Kariem Yes you can use the same system property to extend the timeout in JIRA
Cheers,
Peter
Kariem Hussein
added a comment - The Confluence Knowledge Base describes a related problem and suggests raising the timeout to 5 minutes via -Datlassian.plugins.enable.wait=300. Is this also valid for JIRA? Did I miss any documentation on that?
Kariem Hussein
added a comment - The Confluence Knowledge Base describes a related problem and suggests raising the timeout to 5 minutes via -Datlassian.plugins.enable.wait=300 . Is this also valid for JIRA? Did I miss any documentation on that? Kariem Hussein
added a comment - I don't see why this is marked as fixed, regarding Uwe's latest comment.
The problem is that we are running into the same issue. The documentation just says that there should be sufficient resources allocated, but does not provide any additional hints. Is there a way to extend the timeout a little bit via application or system properties?
Kariem Hussein
added a comment - I don't see why this is marked as fixed, regarding Uwe's latest comment.
The problem is that we are running into the same issue. The documentation just says that there should be sufficient resources allocated, but does not provide any additional hints. Is there a way to extend the timeout a little bit via application or system properties? After upgrading from 4.3.0 to 4.3.1 our JIRA instance did not start up successfully anymore, because we disabled the fisheye plugin before forcefully (we really don't need it!!!). Now the new error message as above was displayed because fisheye was not started anymore.
To reenable our JIRA instance, we had to manually update the underlying database to enable fisheye again else we had no chance to start it up again. So for a locked JIRA instance it should be at least possible to access the plugins manager.
We disabled FishEye in 4.2.x, because of stupid, always-nagging advertisements to use this plugin. As we don't need it, why is there no "legal" way to completely disable it? We can disable Bamboo, but not Fisheye.
James Roper [Atlassian]
added a comment - https://jira.springsource.org/browse/OSGI-816
We found this bug in Spring DM and we think it is causing a large number of plugin system timeouts in Studio. In JIRA, the jira-sal-plugin uses osgi:listeners and so does the oauth-admin-plugin. We are currently looking at removing these.
James Roper [Atlassian]
added a comment - https://jira.springsource.org/browse/OSGI-816
We found this bug in Spring DM and we think it is causing a large number of plugin system timeouts in Studio. In JIRA, the jira-sal-plugin uses osgi:listeners and so does the oauth-admin-plugin. We are currently looking at removing these. 
Bogdan Dziedzic [Atlassian]
added a comment - It would be great, if the true cause of the experienced symptoms would be addressed (if possible).
In the same time, the application shouldn't startup, if it misses any of the core plugins.
Bogdan Dziedzic [Atlassian]
added a comment - It would be great, if the true cause of the experienced symptoms would be addressed (if possible).
In the same time, the application shouldn't startup, if it misses any of the core plugins.
Thanks,we haven't seen the messages in our 4.3 installation anymore. I thought it was because I fixed it otherwise (I disabled the Fisheye Issue Tab plugin), but maybe that's the case. Originally we were of course testing the evaluation installation. Now we have a full one. I will try that out by reenabling all plugin components!