Atlassian Confluence 5

Alex Mags

2014-06-19 (Last Modified: 2014-06-19)

Page content

I migrated the awesome intranet WIKI system Confluence from v4 on Linux to v5 on Windows. This was not straight forward (it was hell) but it’s now working great. As a JAVA based app it runs fine on Windows and it’s easier to support on this platform (IMHO). Some findings/gotchas:

Confluence config settings

All references to setenv.bat in Atlassian docs should be ignored. Making JVM config changes to this file has no impact. Big red herring. Instead use tomcat config GUI or registry settings. This article is correct where lots of other confluence guides are wrong https://confluence.atlassian.com/display/CONF43/Configuring+System+Properties

Confluence

JVM memory settings don’t work out of the box** It’s left as an exercise to the admin to guestimate how much RAM the application will require and allocate not to little, not too much, but just right:

This error can be thrown from the Serial, Parallel or Concurrent collectors. It often means that the Xmx value is too high, however it can also be because it is too low" https://confluence.atlassian.com/display/CONFKB/Confluence+Crashes+Due+to+java.lang.OutOfMemoryError+GC+overhead+limit+exceeded

This is some sort of Goldilocks IT… You have to monitor and figure out the right max & min memory settings for your enviroment.

Confluence can’t get to the plugin market place

Out of the box, Confluence can’t get to the plugin market place. It runs an old version of JRE 1.6u20 and JAVA cannot connect if it cannot verify public certs for SSL connections. You need to add SSL certs for the Market Place website to the JRE cert store. Edit the JRE trusted certificate authorities files using Portecle GUI java.exe -jar portecle.jar

`echo JRE` `default` `password is changeit`

cd /d "c:\Program Files\Atlassian\Confluence\jre\bin"

`set certspath=*Path to your` `SSLCerts here*`

set keystore=C:\Program Files\Atlassian\Confluence\jre\lib\security\cacerts

`keytool.exe -``import` `-alias CompanyRootCA -file %certspath%\CompanyRootCA.cer -keystore` `"%keystore%"`

keytool.exe -``import -alias ServerName -file %certspath%\ServerName.cer -keystore "%keystore%"

`keytool.exe -``import` `-alias Proxy -file %certspath%\proxy.crt -keystore` `"%keystore%"`

keytool.exe -``import -alias atlassian -file %certspath%\StarAtlassianPositiveSSL.cer -keystore "%keystore%"

`keytool.exe -``import` `-alias cloudfront -file %certspath%\StarCloudfrontVerisign.cer -keystore` `"%keystore%"`

keytool.exe -list -keystore "%keystore%"


## Confluence 4.3.3 upgrade to Confluence 5 fails

We've been using confluence since v2 in 2007 and upgraded through v3 and v4. At some point Atlassian decided to change database collation to case sensitive and change string datatypes to unicode.  The upgrade process doesn't allow for the schema change.  Confluence 5 upgrade process adds a new table (user\_mapping) with nvarchar datatype and then crashes when trying to link this to other table columns with varchar.
`2014``-``06``-``16` `11``:``29``:``40``,``732` `ERROR [localhost-startStop-``1``] [hibernate.tool.hbm2ddl.SchemaUpdate] execute Unsuccessful: alter table FOLLOW_CONNECTIONS add constraint FK_FOLLOW_CONNECTIONS_FOLLOWER foreign key (FOLLOWER) references user_mapping`

`2014``-``06``-``16` `11``:``29``:``40``,``732` `ERROR [localhost-startStop-``1``] [hibernate.tool.hbm2ddl.SchemaUpdate] execute Column` `'user_mapping.user_key'` `is not the same data type as referencing column` `'FOLLOW_CONNECTIONS.FOLLOWER'` `in foreign key` `'FK_FOLLOW_CONNECTIONS_FOLLOWER'``.`

`2014``-``06``-``16` `11``:``29``:``40``,``733` `ERROR [localhost-startStop-``1``] [hibernate.tool.hbm2ddl.SchemaUpdate] execute could not complete schema update`
Atlassian had no solution for this.  An option might have been export to XML, make a new database with new schema, import from XML.  Assuming the export-import process captures everything.  But our database was too large and the export process timed out.

Fortunately we had an amazing DBA who was able to refactor the database to the new schema, after which the upgrade completed ok.

Atlassian do not have a High Availability solution for Confluence. If the server fails you're out of luck.  But virtualisation can help here since it gives you option to cluster at virtualisation layer rather than applicaiton layer. Running Confluence on a Virtual Machine in a cluster protects you against hardware failure (VM host).  Replicating the VM to another datacentre protects you against a site-wide outage (e.g. storage failure).