If activation fails due to a mismatch of the keys on the two instances,
Handshake information for activation was incorrect is
displayed. You can also find the error message in the logs:
ERROR info.magnolia.module.exchangetransactional.TransactionalSyndicator 29.11.2013 12:46:50 -- Failed to activate content. info.magnolia.cms.exchange.ExchangeException: Message received from subscriber: Handshake information for activation was incorrect. Someone attempted to impersonate author instance. Incoming request was from 127.0.0.1 at info.magnolia.module.activation.BaseSyndicatorImpl.activate(BaseSyndicatorImpl.java:425) at info.magnolia.module.exchangetransactional.TransactionalSyndicator$2.run(TransactionalSyndicator.java:175) at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Thread.java:724)
To resolve the issue, generate a new public key and copy it to the public instance.
See Monitoring for more about logging and debugging Magnolia.
If you activate SSL certificates on your magnolia public instance, and
configure everything so that any http request is redirected to https by
default but leave the subscriber on the author instance configured to
http://, any activation request will fail with the following
Non EE subscriber detected on xxx.
URL property in the configuration at the
/server/activation/subscribers/<subscriber-name>@URL path. Make sure
it starts with
Whenever Java attempts to connect to another application over SSL
(e.g. HTTPS, IMAPS or LDAPS), it will only be able to connect to that
application if it can trust it. The way trust is handled in the Java
world is that you have a keystore, typically
JAVA_HOME/lib/security/cacerts, also known as the truststore. The
error message in this type of failure will look like as follows:
Can't activate: : info.magnolia.cms.exchange.ExchangeException: 1 error detected: Simple exchange transport failed: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target on xxx.
To fix this, make sure that
-Djavax.net.ssl.trustStore is present in
your JVM arguments. Java will use the keystore specified with that
During the activation process Magnolia makes a copy of the current
content on the public instance and stores it in the
workspace. The system rolls back any changes using the backup copy if
activation fails for some reason. If the activation succeeds, the
system overwrites the current content with the activated content and
removes the backup copy.
Below tips and tools could help you either detect the issue or clean up unnecessary content before publishing:
The steps of an activation on Public can be viewed by turning the
DEBUG using the
Log Tools app. Here we
see an example of the steps during page activation.
Activation of page /travel/about/company
Activation of page /travel/about/company
About to begin activate of website:8fa4a73f-51c3-40ac-b698-715595216186:/travel/about/company Got clearance for JCR lock on parent node /travel/about Requesting XA lock About to perform activate Starting content update Checking for existence of content website:8fa4a73f-51c3-40ac-b698-715595216186 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 User superuser successfully activated /travel/about/company on magnoliaPublic. User superuser attempted to activate 8fa4a73f-51c3-40ac-b698-715595216186 on magnoliaPublic. Finished activate of website:8fa4a73f-51c3-40ac-b698-715595216186:/travel/about Activate was executed in total of 0.757 seconds About to begin commit of website:8fa4a73f-51c3-40ac-b698-715595216186:/travel/about/company Got clearance for JCR lock on parent node /travel/about/company About to perform commit Proceeding with commit of content 8fa4a73f-51c3-40ac-b698-715595216186 Commited content 8fa4a73f-51c3-40ac-b698-715595216186 User transaction committed on MgnlUser - superuser [51ae3379-67cf-4994-9e05-f97cb8bc3e4a]. Finished commit of website:8fa4a73f-51c3-40ac-b698-715595216186:/travel/about/company Commit was executed in total of 0.073 seconds
It is possible that something goes wrong while Magnolia is activating
the content. For example, the server process is killed or the server
loses power. This means that the backup copy may have gotten left in the
mgnlSystem workspace. Never clean up properly after the activation
during the commit step.
The system will automatically check for nodes. If a node is found in the
mgnlSystem workspace during startup this message will be recorded in
the public log.
WARN PUBLIC [main] info.magnolia.module.exchangetransactional.ExchangeTransactionalUtil: 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 activation step. The backup copy remains indicating that the commit step was never reached. This means that the page may have not been activated correctly.
After a successful activation a cleanup procedure is run to remove the backup copies. This is performed during the commit step. If for some reason it cannot cleanup then a message like this will occur in the log.
ERROR info.magnolia.module.exchangetransactional.XAReceiveFilter - Failed to cleanup backup of a1918662-8cbe-4346-ac5a-1b24a9950e2b. Activation of this content will not be possible until manual cleanup of mgnlSystem workspace is performed.
To try and resolve the issue, clean the
mgnlSystem workspace yourself
on the public instance. There is a cleaning tool in the
Activation Tools app. This
is the same procedure that is run during startup but triggered manually
using this app.
After running 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 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.
The JCR Browser app will allow you to visually inspect the workspace as well.
mgnlSystem workspace should normally be empty if there is no
activation in progress. After cleaning, make sure the website tree is OK
on your public instance.