SonarQube stuck on Loading after upgrade from LTS 8.9 to 9.4

We are upgrading SonarQube Enterprise edition from v7.9 to v9.4 on a Windows server. This requires us to upgrade first to LTS (v8.9) then proceed to v9.4.

After running through the first upgrade to v7.9, the final step was to upgrade the database (browsing to ‘https:\[SonarQube URL]\setup’ and following the prompts. That completed successfully and the console came up fine for v8.9. I proceeded with upgrade to v9.4 using the same steps. However, when I browsed to ‘https:\[SonarQube URL]\setup’ I just see “Loading”. Logs don’t show any errors. Log says I need to upgrade the database manually. But that’s it.

I am trying to run the database upgrade, but it’s stuck. I’ve confirmed a few things like making sure the sonar.web.context is set correctly and followed a few other suggestions, but haven’t been able to resolve yet. Any help is appreciated.


You’ve just said you checked the logs, and seen nothing. But I need to double-check: you looked at the server logs (web.log in particular) and saw no errors?


Looking at the web.log, there are no errors. There are a few warnings, notably “The database must be manually upgraded”, as well as these that don’t seem to be impacting:

*WARN  web[][o.s.a.s.w.WebService$Action] Description is not set on action api/monitoring/metrics*
*WARN  web[][o.s.a.s.w.WebService$Action] Since is not set on action api/monitoring/metrics*
*WARN  web[][o.s.a.s.w.WebService$Action] The response example is not set on action api/monitoring/metrics*
*WARN  web[][o.s.a.s.w.WebService$Action] The response example is not set on action api/system/liveness*

The sonar log also mentions the db having to be manually upgraded, but no errors or other warning. The access log shows me browsing to the \setup URL, but there is no evidence of the db upgrade happening. This wasn’t the case when I upgraded from 7.9 to 8.9. That went smoothly on the same server on the same day. I didn’t see any additional steps, but wondering if there was a change in JDBC or something that I need to investigate. If so, I would have expected an error in the logs.


Can you check your browser console for errors? And do you have 3rd-party plugins installed?


I tried running an inPrivate session in Edge (similar to Incognito, but our policy blocks incognito in Chrome. Same thing. Just keeps “Loading”. I did change the JDBC in the path to the same version that ships with v9.4 (jdbc 9.4.1) and restarted the service, in case that was causing an issue. That didn’t resolve the problem. I’m thinking of trying an earlier version (post 8.9) in case the issue is limited to v9.4.


I posted a couple questions above. Do they seem relevant?


Hi @jimoshea,

Are you observing the page is always “Loading” on Edge? Are you able to test it in Chrome or Firefox just to see if it works?


1 Like

I tested in Chrome, Firefox, Edge, and IE. Yesterday, I rolled back to 8.9 (LTS) and everything came up fine. Seems to be limited to moving past LTS… I’ll continue troubleshooting today. Sure wish I had errors in the logs to track down.

I see a similar case recently but the problem sticks to Edge. It works fine in Chrome.

Please keep me updated if you have more information. BTW, IE is not supported any longer since 9.0.

1 Like

I am having the same issue

In an attempt to get more out of the logs, I modified the file to show more details (modified “sonar.log.level=TRACE”) and restarted services. Same issue, but when I look at the web.log, I see the following:

2022.05.02 11:57:48 ERROR web[][o.a.c.c.C.[.[.[/sonar/deploy]] Servlet [jsp] in web application [/sonar/deploy] threw load() exception
java.lang.ClassNotFoundException: org.apache.jasper.servlet.JspServlet
	at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(
	at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(
	at org.apache.catalina.core.DefaultInstanceManager.loadClass(
	at org.apache.catalina.core.DefaultInstanceManager.loadClassMaybePrivileged(
	at org.apache.catalina.core.DefaultInstanceManager.newInstance(
	at org.apache.catalina.core.StandardWrapper.loadServlet(
	at org.apache.catalina.core.StandardWrapper.load(
	at org.apache.catalina.core.StandardContext.loadOnStartup(
	at org.apache.catalina.core.StandardContext.startInternal(
	at org.apache.catalina.util.LifecycleBase.start(
	at org.apache.catalina.core.ContainerBase$
	at org.apache.catalina.core.ContainerBase$
	at java.base/
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(
	at java.base/java.util.concurrent.ThreadPoolExecutor$
	at java.base/

I see that twice in the logs while in Trace mode. That said, the logs show that the EmbeddedTomcat is started and enabled on the proper port and I can browse to the page, but I just see “Loading”. Not sure if that is the issue and, if so, what is causing the exception in the servlet. So, I’m thinking “Aha!” I found something. I then rolled back to the working version 8.9, but this time I turned on TRACE logging on that version. The server comes up fine, but lo and behold I see the same exception thrown in the logs. I guess that rules that out. I simply can’t get from 8.9 to 9.4 :frowning:

I found the solution to my specific problem, and thank you to G Ann as I re-read your recommendation on the browser console. Our current site is only accessible through IE due to an F5 iRule (implemented before my time) that is being used to insert secure headers (Content-Security-Policy and a few other things) to meet previous security requirements. This causes issues when accessing the site through non-IE browsers (Chrome, Edge, etc). Not sure if v9.4 no longer supports IE 11, but it was my only option until I change the iRule remove the CSP header policy which now allows access to the site via the non-IE browsers. That allowed me to reach the /setup site and perform the DB migration.

That was a big win, but the service didn’t initially start as it now noticed an incompatible gherkin plugin. Once I removed that and restarted the service, everything came up fine in v9.4! So, two hidden problems that were resolved and now we’re done. When in doubt, increase log levels and check browser console for errors. And now my migration is over!


I’m very happy to see the issue has been resolved. But I’m still confused about why it works on non-IE browsers (Chrome, Firefox) but not Edge. It could be related to IE mode, non-IE mode on Edge … :thinking:

It does work in Edge. Just not IE. That was expected since I believe IE is no longer supported. Our issue with setting headers through F5 irules caused our problem. Now, we need to figure out how to implement the security headers at the server instead.

Is the F5 iRule applied to Chrome, Firefox? Or is it only applied to Edge? That may explain why it works with Chrome, Firefox but not Edge.

I have no F5 involvement. I am purely trying to access the localhost:9000/setup url from obviously the local machine.
This does not work with IE, FireFox but works with Chrome.
So that rules out the F5 doing anyhting to headers, whilst I can figure that IE is no longer supported, why then is FireFox giving the same issue
. I am concerned because when we go to production, are my users going to be forced to use Chrome to access SonarQube, this is against company standards for my company


IE is not supported any longer since 9.0. But Firefox should be working fine. Do you observe any errors from Developer Tools?

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.