Bamboo requests an application link when creating a Bitbucket Server repository but one already exists
When attempting to add a repository from your Bitbucket Server to Bamboo, Bamboo requests that you create an application link even though one already exists. When using the old application link UI you can see the application link, however switching to the new and improved application link UI, no application links are present.
Upon deleting the Bitbucket application link and attempting to re-create it, you may receive the following error: Application with id 'null' not found
Check Bamboo Administration > Overview > Manage Add-ons > System Add-ons and check the status of any Applink related plugins to see if they are Disabled. E.g.
Applinks - Plugin - Basic Authentication: com.atlassian.applinks.applinks-basicauth-plugin
- Applinks - Plugin - Core: com.atlassian.applinks.applinks-plugin
- Applinks - Plugin - CORS: com.atlassian.applinks.applinks-cors-plugin
- Applinks - Plugin - OAuth: com.atlassian.applinks.applinks-oauth-plugin
- Applinks - Plugin - Trusted Apps: com.atlassian.applinks.applinks-trustedapps-plugin
In the most recent start-up attempt of Bamboo you may see failures similar to the following which explain that certain plugins failed to start due to a timeout:
2016-11-07 10:50:13,130 ERROR [Spring DM Context Creation Timer] [OsgiPlugin] Unable to start the plugin container for plugin 'com.atlassian.applinks.applinks-cors-plugin' org.springframework.context.ApplicationContextException: Application context initialization for 'com.atlassian.applinks.applinks-cors-plugin' has timed out waiting for (|(objectClass=com.atlassian.applinks.spi.auth.AuthenticationConfigurationManager)(objectClass=com.atlassian.applinks.api.ApplicationLinkService)(objectClass=com.atlassian.applinks.core.InternalTypeAccessor)) at org.eclipse.gemini.blueprint.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor.timeout(DependencyWaiterApplicationContextExecutor.java:489) at org.eclipse.gemini.blueprint.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor.access$000(DependencyWaiterApplicationContextExecutor.java:54) at org.eclipse.gemini.blueprint.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor$WatchDogTask.run(DependencyWaiterApplicationContextExecutor.java:109) at java.util.TimerThread.mainLoop(Unknown Source) at java.util.TimerThread.run(Unknown Source)
The extraction of plugins is a rather resource-intensive process, sometimes contention and shortage of resources (Disk I/O, CPU, Memory) can cause the process of the extraction to take longer (but there are still enough resources to startup the instance instead of shutting it down completely). Your Antivirus might also interfere with the plugin load (or at least delay it).
Workaround 1: Re-enable plugins
Re-enable the plugins through the UI, see next workaround to prevent it from occurring on the next restart.
Workaround 2: Extend the plugin timeout to allow plugins more time to initialize
- Add the following start-up argument
- See configuring Bamboo on start-up documentation for the appropriate method to add start-up arguments for your operating system and start-up method:
Delete and re-create your application link again
The workarounds above should be sufficient, however the core of the problem is likely something environmental or performance related and will differ from case to case. Some suggestions:
- If you're running any AV on the server, try disabling it or adding an exclusion for the <bamboo-home> and <bamboo-install> directories.
- Treat it as a performance issue and see if you can work out where the resource contention is while starting Bamboo which is causing the delay and timeout of the plugin extraction.