Loading...

Type: Bug
Resolution: Fixed
Priority: Highest
Fix Version/s: 6.15.8, 7.0.1
Affects Version/s: 6.14.0, 6.14.1, 6.14.3, 6.15.1, 6.15.2, 6.15.4
Component/s: Site - Backup / Import
Labels:
- scale-team

Support reference count:
33
Symptom Severity:
Severity 1 - Critical
UIS:
62
Bug Fix Policy:
View Atlassian Server bug fix policy

Environment

XML Site Exports created out of Confluence 6.14.0+ may fail to be imported into new Confluence instance.

Affected versions

Only these versions are affected by this bug:

All Confluence 6.14.x
Confluence 6.15.0 -> 6.15.7

Steps to reproduce

Perform a Site XML Backup from any Confluence 6.14.0+
Setup a new Confluence instance and import the above XML backup and the import fails

Expected behaviour

The XML site export created "successfully" from Confluence 6.14.0 should be able to import into a new Confluence instance.

Alternatively, the export should be marked as Failed if it fails to produce a data integrity XML backup.

Actual behaviour

The Site XML is failing to import into a new Confluence instance with this reported error:

2019-05-31 09:37:22,819 ERROR [Long running task: Importing data] [atlassian.confluence.importexport.KeyInitPostImportTask] execute Problem when init Confluence key after a site import
 -- url: /longrunningtaskxml.action | referer: http://127.0.0.1:8090/admin/restore-local-file.action | traceId: 4e5c55de5f099999 | userName: admin | action: longrunningtaskxml

2019-05-31 09:37:24,325 ERROR [Long running task: Importing data] [springframework.transaction.interceptor.TransactionInterceptor] completeTransactionAfterThrowing Application exception overridden by commit exception
 -- url: /longrunningtaskxml.action | referer: http://127.0.0.1:8090/admin/restore-local-file.action | traceId: 4e5c55de5f099999 | userName: admin | action: longrunningtaskxml
com.atlassian.confluence.importexport.ImportExportException: java.lang.NullPointerException
	at com.atlassian.confluence.importexport.KeyInitPostImportTask.execute(KeyInitPostImportTask.java:25)
	at com.atlassian.confluence.importexport.Importer.doImport(Importer.java:82)
	at com.atlassian.confluence.importexport.DefaultImportExportManager.performImportInternal(DefaultImportExportManager.java:131)
	at com.atlassian.confluence.importexport.DefaultImportExportManager.doPerformImport(DefaultImportExportManager.java:119)
	at com.atlassian.confluence.importexport.DefaultImportExportManager.performImport(DefaultImportExportManager.java:114)
...
Caused by: java.lang.NullPointerException
	at java.security.MessageDigest.update(MessageDigest.java:335)
	at java.security.MessageDigest.digest(MessageDigest.java:410)
	at org.apache.commons.codec.digest.DigestUtils.md5(DigestUtils.java:351)
	at org.apache.commons.codec.digest.DigestUtils.md5(DigestUtils.java:376)
	at com.atlassian.confluence.security.trust.DefaultCurrentApplicationIdProvider.getAliasForSid(DefaultCurrentApplicationIdProvider.java:33)
	at com.atlassian.confluence.security.trust.DefaultCurrentApplicationIdProvider.getCurrentApplicationId(DefaultCurrentApplicationIdProvider.java:28)
	at com.atlassian.confluence.security.trust.DefaultTrustedApplicationsManager.getCurrentApplication(DefaultTrustedApplicationsManager.java:157)
	at com.atlassian.confluence.security.trust.DefaultTrustedApplicationsManager.initConfluenceKey(DefaultTrustedApplicationsManager.java:167)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:333)
	at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:190)
	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:157)
	at org.springframework.transaction.interceptor.TransactionInterceptor$1.proceedWithInvocation(TransactionInterceptor.java:99)
	at org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:282)
	at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:96)
	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
	at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:213)
	at com.sun.proxy.$Proxy240.initConfluenceKey(Unknown Source)
	at com.atlassian.confluence.importexport.KeyInitPostImportTask.execute(KeyInitPostImportTask.java:22)
	... 31 more

where:

	at com.atlassian.confluence.security.trust.DefaultCurrentApplicationIdProvider.getAliasForSid(DefaultCurrentApplicationIdProvider.java:33)

is referring to attempting to read the confluence.server.id from BANDANA.

Diving deeper, this is due to the entities.xml in the XML export missing this block:

<object class="ConfluenceBandanaRecord" package="com.atlassian.confluence.setup.bandana">
<id name="id">1</id>
<property name="context"><![CDATA[_GLOBAL]]></property>
<property name="key"><![CDATA[confluence.server.id]]></property>
<property name="value"><![CDATA[<string>B10L-****-****-****</string>]]></property>
</object>

Deeper comparison of the entities.xml with the Source Database, the exported entities.xml is actually missing a lot more BANDANA rows and other TABLE rows.

Validation

Reviewed Restoring Confluence XML site backups fails: Import failed. Check your server logs ... which has not helped.
Proceed with this check:

Obtain the total number of a few tables row count (e.g. BANDANA, BODYCONTENT, EVENTS, etc...) from the Source Database
```
select count(*) from BANDANA;
select count(*) from BODYCONTENT;
select count(*) from EVENTS;
```

Extract out the XML backup and run this GREP / FINDSTR to obtain how many BANDANA, BODYCONTENT, EVENTS rows are present in the entities.xml

On Windows

findstr "class=\"ConfluenceBandanaRecord\"" entities.xml | find /i "class" /c

findstr "class=\"BodyContent\"" entities.xml | find /i "class" /c

findstr "class=\"Events\"" entities.xml | find /i "class" /c

On Linux

grep -i 'class="ConfluenceBandanaRecord"' entities.xml | wc -l

grep -i 'class="BodyContent"' entities.xml | wc -l

grep -i 'class="Events"' entities.xml | wc -l

Also confirm that entities.xml is indeed missing the confluence.server.id row
On Windows
```
findstr "confluence.server.id" entities.xml
```
On Linux
```
grep -i 'confluence.server.id' entities.xml
```

The result of the Database row count of BANDANA, BODYCONTENT and EVENTS should match the number of BANDANA occurrences in entities.xml. If the numbers are vastly different - then you have encountered this issue.

Workaround

There is no reliable work around available for this bug.

Resolution

A bug has been identified in the XML export logic and we must upgrade to a fixed version of Confluence. For a complete XML backup:

Take a database level backup of your current Confluence Database
Upgrade to Confluence 6.15.9+ or Confluence 7.0+ in a Staging Environment
Perform the XML export on the upgraded version which will now produce an XML export zip file that can be imported into the destination instance (which should be the same version as the Exported instance)

It is currently advised to take database level backups or use database level backups when possible

mentioned in: Page Loading...; Page Loading...; Page Loading...; Page Loading...; Page Loading...; Page Loading...; Page Loading...; Page Loading...; Page Loading...; Page Loading...; Page Loading...; Page Loading...; Page Loading...; Page Loading...

(9 mentioned in)

Details

Description

Environment

Affected versions

Steps to reproduce

Expected behaviour

Actual behaviour

Validation

Workaround

Resolution

Attachments

Issue Links

Forms

Activity

People

Dates