nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Trouble? 32-bit Jira 6.0.4 upgrade to 64-bit Jira 5.1.3 instance

Justin McCamish

Our original Jira 5.1.3 instance was 64-bit. A case of mistaken identity meant we applied the 32-bit upgrade (to 6.0.4) to it using the Rapid Upgrade method.

Strangely, everything is working perfectly in testing so far. Is disaster around the corner or can we just continue on safely?

If the situation is risky, what kind of issues are we likely to have and what is the best way for us to switch to the 64-bit version?

Cheers,
Justin

Accepted answers

unknown

There are a number of problems that could crop up, for example:

- Memory heaps, with a 32bit JVM you will be limited to <4GB total heap. If you are on a VM with that much memory for the OS(or less), you wont likely have any problems. The smaller your instance/smaller the loading, the less likely you will be need this anyway.

- Native binaries, I dont know exactly what the upgade does, but as you have a 64bit OS (whatever type), generally, 32bit binaries will run fine. The 32bit upgrade would have replaced links to 64bit native JNI Tomcat components with 32bit ones.

- There is an outside chance that data serialised from a 64bit VM wont deserialise in a 32bit VM.

A brief note on 32bit JVMs on 64Bit OS. interestingly, they can run faster as a given value does not take up 64bits, reducing memory bandwidth used. In a smaller instance, the improvement would probably be barely noticeable.

I'd probably plan to upgrade to the next available release with a 64bit based distro in any case. Doing this isn't hard, usual upgrade technique (https://confluence.atlassian.com/display/JIRA/Upgrading+JIRA) will apply, in short; (a) backup JIRA_HOME/database (b) get new 64 bit version, unpack. (c) stop JIRA, repoint startup scripts to new binary location (d) update setenv.sh to refer JIRA_HOME location, ensure database drivers are copied over (e) run. If you run windows, doubtless there will be more involved, refer to Atlassian upgrade documentation for details.

All comments

unknown

There are a number of problems that could crop up, for example:

- There is an outside chance that data serialised from a 64bit VM wont deserialise in a 32bit VM.

Justin McCamish

Wow! Swift reply, Andy. Thanks for your comprehensive (and reassuring) notes.

We have a few outage opportunities over the next week or so and might just run the 64-bit 6.0.4 upgrade .exe (we're on Win Server 2008.) over it anyway, just to be safe as houses. Sounds like it will be low risk.

I just wish our Confluence upgrade had been as tolerant. Rolled back to 4.2.13 after several tries resulted in a totally non-responsive instance

unknown

Yea, when I managed a corp instance I had VM's doing dry run upgrades nearly continuously, always recommended to weed out 'fundamental' problems. A great stress saver!