Is there any new feature in JIRA 7.8 which disables all addons not certified to work with 7.8? Pre-7.8, all such addons had a warning.
As of 7.8, Tempo Timesheets keep disabling themselves on reboot.
@Jiri Pik My timeout value is around 500 for timeout value and I've allocation almost 8gb for 200000 issues right now.
There is not a feature to disable plugins based on any kind of certification. However Jira will disable a plugin if that plugin fails to load repeatedly in Jira.
From looking at the version history of this plugin, it appears that the vendor just released a new version of this plugin, 8.9.0, which appears to be the first version of this plugin that is noted as compatible with Jira 7.8.x. Considering this version appears to have been released 1 day after you created this post, it feels like a safe bet you were running an older version of this plugin that wasn't really built for this version of Jira.
Did you check that Tempo needs an update before taking it to 7.8 ? I had faced it - maybe that's why it was disabled.
Did you check Tempo had an update ?
Hi: yes, I have done and no help.
Hi:
The problem is that as of the latest JIRA Server Version this addin, unlike any other addin, has startup problems - see the logs below - and the Log analyzer points to
https://confluence.atlassian.com/jirakb/jira-startup-fails-from-application-context-error-278073550.html?utm_medium=logScan&utm_source=STP
and
https://confluence.atlassian.com/jirakb/jira-applications-system-plugin-timeout-while-waiting-for-add-ons-to-enable-212173447.html?utm_medium=logScan&utm_source=STP
There is certainly NO CPU bottleneck.
Could it be some Postgres connection string setting?
What to do?
Interestingly , Jiri and Andrew - I noticed this on my 7.8 jira server version as well.
When we usually see this kind of timeout, there are a pair of things I recommend:
It is possible to increase the plugin timeout period by adding the -Datlassian.plugins.enable.wait=300 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.
It is possible to increase the plugin timeout period by adding the -Datlassian.plugins.enable.wait=300 argument to the JIRA application startup arguments, as in Setting Properties and Options on Startup.
-Datlassian.plugins.enable.wait=300
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.
Also sometimes when you upgrade Jira, I have seen the setenv.sh file, (or the windows service starting Jira) can become reset or overwritten. In cases like this Jira tends to default back to the default memory settings. Which works fine for a new install, but tends to be insufficient in environments with lots of issues, custom fields, plugins, etc.
How foolish of me that I had forgotten to check my JVM arguments after upgrade.
Restored my argument back and it works fine now - plugin is up.
My jvm had plugin timeout params before - it was removed after upgrade. restored them back
@Jiri Pik I'd suggest you add the addin timeout param in your jvm argument. give plugins sufficient time to start . That should work.
Yeah, but what timeout do you have in mind?
JVM_SUPPORT_RECOMMENDED_ARGS="-Datlassian.plugins.enable.wait=300"
does not help
Andrew:
I have added
but there is apparently another timeout
@Andy Heinzer: I still do not understand why the sentenv.sh and server.xml are always removed on upgrade of JIRA / Confluence, unlike the config file with database connection strings. Yes, they are in different directories but the use cases are identical.
If the server.xml has a https URL in previous version, then it would most likely remain the same after upgrade!
500 is the magic number. 300 is too low and 500 is just right.
THANK YOU.
It looks like you're new here. Sign in or register to get started.
