Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Upgrading taking a long time


Upgrading from 7.4.11 to 7.13.2 and the installer gets to the state... 

"Configuring Confluence - Please wait a few moments while we configure Confluence"

...and stays there.  This last attempt I left it running for 90 minutes but the progress bar doesn't update.   Task manager shows the process is using CPU between 0 - 10% so it seems that it's not really hung.  (Or is some thread inside the installer is?)

The service is not running and the database is hosted on a separate server. 


  • Does the installer generate a log file when ran?  If so location and name?
  • What is the installer doing at this state?
  • Is there a way to know what exactly it's doing?



- Windows 2021 R2 x64  (4 cpu / 16GB ram)

- Confluence Server 7.4.11

- DB hosted on SQL Server


Thank you

1 answer

0 votes
Brant Schroeder Community Leader Nov 19, 2021

@Jonny Polivka 

I have seen this happen in the past when the application server did not have enough memory.  I have also seen it when the DB server does not have enough CPU.  What is happing on your DB server when this is going on, is the CPU tapped?  

Our app server is 4 CPUs / 16 GB RAM.  I was watching Task Manager and memory was around 3GB the whole time the installer was running.  


Unknown on the sql server.  Will ask our DBA group...but does the installer communicate with the DB?  I didn't see or notice a lot of network activity viewing via Tack Manager.

Brant Schroeder Community Leader Nov 19, 2021

@Jonny Polivka at the end of the install all the db updates take place.  Did you check all you apps to make sure they are compatible?  Sometimes it will get hung on apps that can not upgrade.

Hi @Brant Schroeder

I did run the Confluence Update Checker before and disabled two apps that it flagged; Atlassian Rest API Browser and SSO for Atlassian Data Center.  

Did some digging on the test environment and found a few i4j_nlog_*.log files in my user AppData\Local\Temp directory that look to have relevant data.  With those clues I get to ej technologies product install4J, "multi-platform Java installer builder."  

Moving back to the test instance, I ran the 7.13.2 installer again and saw that it created and started logging to file i4j_log_Confluence_<random number>.log file.  So that answers my question if the installer creates a log file.  

Comparing that log file with the existing ones they don't quite match up so they look to be logging two different events triggered by the installer.  (This is just a guess.)

I rolled back production instance so there is no way for me to check for this file.

Brant Schroeder Community Leader Nov 20, 2021

@Jonny Polivka is your test instance the same as production?  Do you sync the data?  Did it upgrade just fine?

Hi @Brant Schroeder ,

They are not synced.    That crossed my mind over the holiday so I'll be spending time getting Test synced with Production data then upgrade.  

Test was synced with Production at one time but is overdue to have it happen again. 

Brant Schroeder Community Leader Nov 29, 2021

Did the test instance upgrade successfully?  Are the apps the same on both instances?

Test instance did upgrade successfully but it's running an older snapshot of Production data.  

This week I'll revert Test back to 7.4.11, sync the data with Production and run an upgrade to 7.13.2 .   

Like Brant Schroeder likes this

To finish off this thread...  

Finally completed upgrading both Test and Production to the latest LTS release (7.13.3 as off this writing.) 

Did take a copy of production data and use that for test.  The upgrade from 7.4.11 to 7.13.3 took about 3 hours.  The installer duration was shorter, but more than 90 minutes.  After deleting and installing files, it sat there doing something but unknown what for most of the duration.  (What is it doing during this time?) 

After installer completion, I reconfigured the settings it wiped out and started the service and the service sat there again for about 30 - 45 minutes.  Unknown what was happening but my guess is it was doing something with the db.  What's logged in the log files doesn't give any description of the activity and are not updated during this lengthy pause.  Viewing network and process activity was my only window.  

Same install experience with production but it took 80 minutes longer for both the installer and service.  Both have a long pause but are active.  Hard to say what is happening but looking at network and process activity I can see it's not unresponsive or hung.  My wish is that this activity would be logged or a heartbeat be written to the logs so it's known what is going on.  

So the short is.... test, test, test and plan for long outage for production.  

What I figured out is that a lot of mbr stuff is goning on the disk. So I think about rewriting file permissions on data folder. So it's before the change of database.

Suggest an answer

Log in or Sign up to answer
Community showcase
Published in Confluence

An update on Confluence Cloud customer feedback – June 2022

Hi everyone, We’re always looking at how to improve Confluence and customer feedback plays an important role in making sure we're investing in the areas that will bring the most value to the most c...

401 views 2 13
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you