Troubleshooting

[shivangim985778]

how to troubleshoot data if there is some issues when transferring data from author to publish

[cquser1]

Hi,

Are you referring to the replication process or something else.

[shivangim985778]

yes for replication

[shivangim985778]

how to troubleshoot data in queue author to publish?

[VeenaVikraman]

Hi Shivangi

What exactly you want to troubleshoot ? You can check the replication logs to check what content is getting pushed from author to publish and whether it is published or not

Thanks

Veena

[shivangim985778]

i want to know how to troubleshoot any data in queue when we transfer our data from author to publish

[VeenaVikraman]

Are you asking about the replication queue ?

[shivangim985778]

where is this setting?

[shivangim985778]

443 port not working how to troubleshoot?

[shivangim985778]

what type of problem can we find when we send data from autor to publish? and how to troubleshoot it

[vaibhavs7024655]

shivangim98577885​ You can refer the doc[1] and [2] which provides great resources to troubleshoot replication.

[1] Troubleshooting AEM Replication

[2] Replication queue issues 

[shivangim985778]

i have already follow up these docs

[cquser1]

Hi,

Can you provide some info as to what exactly you want to troubleshoot? What exactly is the issue you are facing and the solution you are looking for?

[shivangim985778]

i m just searching for learning purpose if i get any issue in the queue when i will transfer data from author to publish so what will be the issue which i can face and how to troubleshoot them

[VeenaVikraman]

shivangim98577885​

  This was what we wer asking you from beginning. We were not sure what is that you wanted to troubleshoot. Now your query makes more sense.

Coming back to your question, You can troubleshoot replication based on the issues you might face

1) In case you think that the content is not getting replicated to publish as expected , you can go to the agents on author section http://localhost:4502/etc/replication/agents.author.html  and do a test connection to on your publish servers. Your publish servers will be listed here and find them click and go inside the page . eg:-

You will see a Test Connection button. Click on that to make sure there is an active connection to your publish server from your author. It should return you response as below

You can do this on all of your publish instance configuration to  make sure your publish servers are active and is connected from author.

2)whenever you do a replication , under your server /crx-quickstart/logs ; you will have a replication.log file which will log all your replication requests and status of that

A sample of the content of the file is pasted below

Here you can see that the log clearly says that the reverse replication failed due to connection timeout, which means that the server is not able to connect to the other server for many reasons. Either the other server is not started, or a firewall might be blocking.

3) When all of the above looks good and logs don't show any error too, may be that your publish connection is slow or something and all your request are still pending in your author. To verify that you can check the replication queue and see if anything is pending there. Same page you checked the test connection you will find the replication queue

Hope this helps a bit. Let me know if you have any more questions

Thanks

Veena

[shivangim985778]

i am using aem 6.4 so i want information related to 6.4 only

[Akash_Kapoor]

Hi shivangim98577885​,

Apart from testing the basic setup of author-publisher replication that is if the replication agent is configured correctly and the test connection works fine. In case you want to troubleshoot any issue related to replication then you can simply enable debug logging specific to replication by going at host:port/system/console/slinglog and adding a debug logger for api "com.day.cq.cq-replication" and print the debug logs in any custom file like rep.log/replication.log.

The above basically is part of generic troubleshooting in AEM for any specific issue like workflow or replication. You can enable debug logs for a particular api to understand where exactly it failed and why.