Publishing errors

This page describes some errors that may occur when publishing content from the author instance to the public instance(s).

Communication between the Magnolia instances is a normal HTTP request between the author and the public instances with the URIs provided in the configuration. Ensure you have HTTP/S network visibility within the Magnolia instances and that ports are open. You can use utilities like nmap, lsof, ss, or netcat to check your network visibility for JCR nodes.

Publishing errors

Lock nodes when publishing content

This issue may appear for example if you try to publish some content at a second level but can’t publish it on the first level, or if you try to publish to one public instance but can’t publish it to a second public instance.

On the author instance, the log may contain an error such as:

ERROR info.magnolia.module.scheduler.CommandJob 26.07.2019 13:21:06 -- Cannot execute command {0}-{1}. info.magnolia.publishing.exception.PublicationException: <ul><li>magnoliaPublic1: [WEBAPP: [ROOT, publishing-receiver.locking.contentLocked]] Message: {1}</li></ul>

The log on the public instance may show:

INFO info.magnolia.publishing.locking.JcrLockManager 26.07.2019 13:02:06 -- Node / is locked. Will retry 10 more times.

To fix this locking issue, either find the locks in the mgnlSystem workspace using the JCR Browser and just remove them, or clean the mgnlSystem workspace on the public instance that’s failing with our cleaning tool.

Mismatching keys

If publishing fails due to a mismatch of the keys on the two instances, an error Handshake information for activation was incorrect is displayed. You can also find the error message in the logs:

2017-12-18 16:38:10,311 ERROR nfo.magnolia.publishing.command.PublicationCommand: Receiver: magnoliaPublic8080, error: [WEBAPP: magnoliaPublic] Message: Handshake information for activation was incorrect. Someone attempted to impersonate author instance. Incoming request was from 127.0.0.1.
info.magnolia.publishing.operation.SendOperation$OperationExecutionException: [WEBAPP: magnoliaPublic] Message: Handshake information for activation was incorrect. Someone attempted to impersonate author instance. Incoming request was from 127.0.0.1.
    at info.magnolia.publishing.sender.operation.HttpPublicationOperation.execute(HttpPublicationOperation.java:138) ~[magnolia-publishing-sender-1.0.jar:?]
    at info.magnolia.publishing.sender.operation.HttpPublicationOperation.execute(HttpPublicationOperation.java:74) ~[magnolia-publishing-sender-1.0.jar:?]
    at info.magnolia.publishing.transactional.sender.TransactionalSender$2.doRun(TransactionalSender.java:110) ~[magnolia-publishing-transactional-sender-1.0.jar:?]
    at info.magnolia.publishing.sender.AbstractSender$Task.run(AbstractSender.java:291) ~[magnolia-publishing-core-1.0.jar:?]
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[?:1.8.0_144]
    at com.google.common.util.concurrent.TrustedListenableFutureTask$TrustedFutureInterruptibleTask.runInterruptibly(TrustedListenableFutureTask.java:124) ~[guava-23.1-jre.jar:?]
    at com.google.common.util.concurrent.InterruptibleTask.run(InterruptibleTask.java:57) ~[guava-23.1-jre.jar:?]
    at com.google.common.util.concurrent.TrustedListenableFutureTask.run(TrustedListenableFutureTask.java:77) ~[guava-23.1-jre.jar:?]
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) ~[?:1.8.0_144]
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) ~[?:1.8.0_144]
    at java.lang.Thread.run(Thread.java:748) ~[?:1.8.0_144]

To resolve the issue, generate a new public key and copy it to the public instance.

See also Monitoring for more about logging and debugging Magnolia.

Handshaking errors

Simple exchange transport failed

When Java tries to connect to another application over SSL (such as HTTPS, IMAPS, or LDAPS), it can only connect if the application can be trusted. The way trust is handled in the Java world is through the use of a keystore, typically JAVA_HOME/lib/security/cacerts, also known as the truststore. The error message in this type of failure is like:

2017-12-18 17:19:51,920 ERROR nfo.magnolia.publishing.command.PublicationCommand: Receiver: magnoliaPublic8080, error: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
    at sun.security.ssl.Alerts.getSSLException(Alerts.java:192) ~[?:1.8.0_144]
    at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1959) ~[?:1.8.0_144]
    at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:302) ~[?:1.8.0_144]
    at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:296) ~[?:1.8.0_144]
    at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1514) ~[?:1.8.0_144]
    at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:216) ~[?:1.8.0_144]
    at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1026) ~[?:1.8.0_144]
    at sun.security.ssl.Handshaker.process_record(Handshaker.java:961) ~[?:1.8.0_144]
    at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1072) ~[?:1.8.0_144]
    at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1385) ~[?:1.8.0_144]
    at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1413) ~[?:1.8.0_144]
    at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1397) ~[?:1.8.0_144]
    at org.apache.http.conn.ssl.SSLConnectionSocketFactory.createLayeredSocket(SSLConnectionSocketFactory.java:396) ~[httpclient-4.5.3.jar:4.5.3]
    at org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:355) ~[httpclient-4.5.3.jar:4.5.3]
    at org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:142) ~[httpclient-4.5.3.jar:4.5.3]
    at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:359) ~[httpclient-4.5.3.jar:4.5.3]
    at org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:381) ~[httpclient-4.5.3.jar:4.5.3]
    at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:237) ~[httpclient-4.5.3.jar:4.5.3]
    at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:185) ~[httpclient-4.5.3.jar:4.5.3]
    at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89) ~[httpclient-4.5.3.jar:4.5.3]
    at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:111) ~[httpclient-4.5.3.jar:4.5.3]
    at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185) ~[httpclient-4.5.3.jar:4.5.3]
    at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83) ~[httpclient-4.5.3.jar:4.5.3]
    at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:108) ~[httpclient-4.5.3.jar:4.5.3]
    at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:56) ~[httpclient-4.5.3.jar:4.5.3]
    at info.magnolia.publishing.sender.operation.HttpPublicationOperation.execute(HttpPublicationOperation.java:111) ~[magnolia-publishing-sender-1.0.jar:?]
    at info.magnolia.publishing.sender.operation.HttpPublicationOperation.execute(HttpPublicationOperation.java:74) ~[magnolia-publishing-sender-1.0.jar:?]
    at info.magnolia.publishing.transactional.sender.TransactionalSender$2.doRun(TransactionalSender.java:110) ~[magnolia-publishing-transactional-sender-1.0.jar:?]
    at info.magnolia.publishing.sender.AbstractSender$Task.run(AbstractSender.java:291) ~[magnolia-publishing-core-1.0.jar:?]
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[?:1.8.0_144]
    at com.google.common.util.concurrent.TrustedListenableFutureTask$TrustedFutureInterruptibleTask.runInterruptibly(TrustedListenableFutureTask.java:124) ~[guava-23.1-jre.jar:?]
    at com.google.common.util.concurrent.InterruptibleTask.run(InterruptibleTask.java:57) ~[guava-23.1-jre.jar:?]
    at com.google.common.util.concurrent.TrustedListenableFutureTask.run(TrustedListenableFutureTask.java:77) ~[guava-23.1-jre.jar:?]
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) ~[?:1.8.0_144]
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) ~[?:1.8.0_144]

To fix this, make sure that -Djavax.net.ssl.trustStore is present in your JVM arguments. Java uses the keystore specified in that argument.

Cipher mismatch

If the cipher set in the magnolia.properites file doesn’t match in the author and public instances, or if they were updated at different times, a mismatch occurs between data encryption and description during publishing, and an exception like this is thrown:

2023-07-13 00:17:09,570 ERROR nfo.magnolia.publishing.command.PublicationCommand: Receiver: magnoliaPublic8080, error: [WEBAPP: magnoliaPublic] Message: Handshake information for activation was incorrect. Someone attempted to impersonate the author instance. Incoming request was from {0}.
info.magnolia.publishing.operation.SendOperation$OperationExecutionException: [WEBAPP: magnoliaPublic] Message: Handshake information for activation was incorrect. Someone attempted to impersonate the author instance. Incoming request was from {0}.
	at info.magnolia.publishing.sender.operation.HttpPublicationOperation.execute(HttpPublicationOperation.java:155) ~[magnolia-publishing-sender-1.3.10.jar:?]
	at info.magnolia.publishing.sender.operation.HttpPublicationOperation.execute(HttpPublicationOperation.java:80) ~[magnolia-publishing-sender-1.3.10.jar:?]
	at info.magnolia.publishing.sender.AbstractSender$2.doRun(AbstractSender.java:334) ~[magnolia-publishing-core-1.3.10.jar:?]
	at info.magnolia.publishing.sender.AbstractSender$Task.run(AbstractSender.java:356) ~[magnolia-publishing-core-1.3.10.jar:?]
    ...

To fix this, you must update the cipher set in the magnolia.properties file for all the instances at the same time.

Cleaning the errors

During the publishing process Magnolia makes a copy of the current content on the public instance and stores it in the mgnlSystem workspace. The system rolls back any changes using the backup copy if transactional publishing fails for some reason. If publishing succeeds, the system overwrites the current content with the published content and removes the backup copy.

The tips and tools mentioned below could help you either detect the issue or clean up unnecessary content before publishing:

Debugging publishing
Checking at startup
Cleaning tool
Visual inspection

Debugging the publishing process

On the public instance, the steps of a publishing process can be viewed by turning the XAReceiveFilter to DEBUG using the Log Tools app. See below an example showing the steps of publishing /travel/about/company:

Publishing the page /travel/about/company

About to begin publish of website:8fa4a73f-51c3-40ac-b698-715595216186:/travel/about/company
parent path:/travel/about
580:1513612417237 Got clearance for JCR lock on parent node /travel/about
580:1513612417237 Requesting XA lock
session-admin-285 DID locked website:/travel/about
580:1513612417237 Starting content publication
580:1513612417237 Checking for existence of content website:8fa4a73f-51c3-40ac-b698-715595216186
580:1513612417237 Content 8fa4a73f-51c3-40ac-b698-715595216186 was located under path website:/travel/about/company
Stored content website:/travel/about/company:8fa4a73f-51c3-40ac-b698-715595216186 for rollback later
Importing main into parent path /travel/about/company
Importing 00 into parent path /travel/about/company/main
Importing 01 into parent path /travel/about/company/main
Importing footer into parent path /travel/about/company
Importing footer1 into parent path /travel/about/company/footer
Importing footer2 into parent path /travel/about/company/footer
Importing footer3 into parent path /travel/about/company/footer
Importing footer4 into parent path /travel/about/company/footer
Importing lastLinks into parent path /travel/about/company/footer
580:1513612417237 User superuser successfully published website:/travel/about/company on magnoliaPublic.
Ordering company before what-we-believe
session-admin-285 DID unlocked website:/travel/about
About to begin commit of website:8fa4a73f-51c3-40ac-b698-715595216186:/travel/about/company
node uuid:8fa4a73f-51c3-40ac-b698-715595216186
578 Got clearance for JCR lock on parent node /travel/about/company
session-admin-290 DID locked website:/travel/about/company
578 Proceeding with commit of content 8fa4a73f-51c3-40ac-b698-715595216186
578 Commited node 8fa4a73f-51c3-40ac-b698-715595216186
session-admin-290 DID unlocked website:/travel/about/company

It is possible that something goes wrong while Magnolia is publishing some content. For example, the server process is killed or the server loses power. This means that the backup copy may have been left in the mgnlSystem workspace, never cleaned up properly after publishing the content.

Checking at startup

The system will automatically check for nodes. The following message will be recorded in the public log if a node is found in the mgnlSystem workspace after initiating the Clean mgnlSystem workspace action (in the Publishing tools app).

WARN PUBLIC [main] info.magnolia.publishing.transactional.receiver.util.PublishingTransactionalUtil#PublishingTransactionalUtil: Removing backup copy of /company from mgnlSystem, please verify that page was activated correctly to this public instance.

This is a sign that the server went down during the publishing process. The backup copy remains, indicating that the commit step was never reached. This means that the page may have not been published correctly.

Cleaning tool

After a successful publication, a cleanup procedure is run to remove the backup copies. This is performed during the commit step. If for some reason it can’t cleanup, then a message as the following will occur in the log:

2017-12-18 17:01:51,503 ERROR actional.receiver.util.PublishingTransactionalUtil: Failed to cleanup backup of b06b82a2-74b0-4994-8015-028c4fd60716. Publication of this content will not be possible until manual cleanup of mgnlSystem workspace is performed.

To try resolve the issue, clean the mgnlSystem workspace yourself on the public instance. There is a cleaning tool in the Publishing Tools app. This is the same procedure that’s run during startup but triggered manually using this app:

Cleaning tool in the Publishing Tools app

After running the action be sure to check the log. If you see repository exceptions, then you need to take other actions. For example, restarting the server to release any locks that may still be present. Restarting it will automatically call the cleanup procedure described above. If locks was the issue, then you should see the system successfully remove the backup copies during the restart. However, if you still see repository exceptions in your log during startup, then you most likely have a repository corruption issue. In that case probably the best course of action would be to recreate the workspace from scratch.

Visual inspection

The JCR Browser app will allow you to visually inspect the workspace as well.

The mgnlSystem workspace should normally be empty if no publishing action is in progress. After cleaning, make sure the website tree is OK on your public instance.

Publishing errors