Author server says Loading; for a long, long, long time

- Sensei Martin

When the Author server restarts, it can look, to the users, like it is hanging because as soon as they click on a node in the left hand nav tree they see "Loading" in the central pane. It just sits there saying "Loading" for a long, long, long time.

This can be caused by having lots of old Workflow instances hanging around (check /etc/workflow/instances). In which case, you should ensure that you install the Workflow purge tool from Adobe.

The purge tool by default will clear out any Workflow instances which are less than 14 days old (well the version I have says > 1 day but the code was actually > 14 days). It can be configured to only purge COMPELTED workflow, or ALL of them. However, beware that the default configuration (in my version 1.6.1 anyway) will only purge the following workflow models :-

  • "/etc/workflow/models/dam/dam_asset_syncer_and"
  • "/etc/workflow/models/dam/update_asset"
  • "/etc/workflow/models/dam/delete_asset"
  • "/etc/workflow/models/dam/delete_dam_asset"



Read the complete post at the My Day CQ blog.

Midnight at the lost and found

- Sensei Martin

Have you worked out that TAR Optimiser does not run at midnight? Normally, the OOTB default for running the TAR optimiser is 2am - 5am. This can be changed in the repository.xml/workspace.xml files. But, if you specify a start time of 00:00 it won't run. I'm sure I've posted this elsewhere but just to re-iterate you can make the TAR optimiser run faster & do more work by reducing the optimizeSleep parameter. We've managed to get away with 0.25 without any noticeable performance impact to the live servers (CQ 5.3).


This tip was originally posted at the My Day CQ Blog.

Handling DELETEs which flush the dispatcher cache

- Sensei Martin

I have been working on the following problemette, which was posted to the DAY-CQ mailing list on :-

Hi CQ Community,

Does anyone know how to stop the dispatcher invalidating on a DELETE command down a path?

The reason why I ask is because we have a lot of usergenerated content which is being reverse replicated. When the UGC is moved, for security, from /content/usergenerated to /content/mysite/blah/blah, then the /content/usergenerated/... node is deleted on the publish server. Each of these delete commands triggers the flush agent.

I have tried defining a rep:policy to deny jcr:all on a user in /content/usergenerated/. This works for node additions but, deletions are not recognised. So I cannot stop it here.

I have tried to alter the configuration in the /invalidate section of dispatcher.any file to no avail. Is this sdection defining what objects get invalidated rather than what objects trigger an invalidation?

I also noticed that in the release notes of the dispatcher the following, which makes me think that invalidate on delete might be hard-wired ...

Issues resolved in 4.0.5:

25169 - Support flush on every write

Any help would be greatly appreciated!



Read the complete post at My Day CQ Blog.

Logging Activates, Deactivates and Deletes

- Sensei Martin

To keep a log of who has activated or deactivated a page, add this to your logging :-

Log Level: Debug




Read the complete post at My Day CQ Blog.

Disk space growing on the CQ author server?

- Sensei Martin

If the disk space on the CQ5 author server is growing at 1-2GBs per day, then check on the filesystem, to see where the growth is at.

If you find that the "journal" directory is GigaBytes then check out this article:


With a default FileJournal configuration in place, depending on the activity on the repository, over time, many Journal log-files will be created. This eventually may cause a disk space issue and performance problems in applications that use CRX.



Read the full post at this URL.

Reverse Replication woes – solved

- Sensei Martin

Hot off the press/keyboard (i.e. not fully tested). With the help of an Adobe support engineer in Basel and an on-site Adobe consultant we discovered what the root cause of the reverse replication problem was.

Namely, that when a user voted in a poll, the new vote AND ALL previous votes were being reverse replicated. This caused a MASSIVE workload on the Author because each node in the /var/replication/outbox did not contain 1 corresponding vote; it actually contained ALL of the votes including the new additional one. This explains why the Author would take 20 minutes to process just 10 nodes in the outbox.



Read the complete post at this URL.

Reverse Replication woes

- Sensei Martin

So, in my previous post I said how wonderful FP37434 is (the replication stabilisation FP). Unfortunately, it did not solve our problem and we now have a large volume of content to reverse replicate (~50k nodes in /var/replication/outbox across all our publish servers).

We are currently facing 2 problems. When the RR agent polls, the publish server with FP37434 exhibits a huge native memory leak (approx 8GB of native memory is being claimed) causing a great deal of paging on the system.

When we batch this down to only 10 items in the outbox, we noticed that the author takes 30 minutes to process 10 nodes.

Adding extra logging ( at DEBUG level shows that the Author is doing valid work for 30 minutes processing just 10 nodes from the outbox.



Read the complete post at this URL.

Replication Stablization hotfix

- Sensei Martin

If the flush agent on a publish server stops working, then you probably need cq-5.3.0-featurepack-37434. This featurepack is a nice cumulative one - so no painful installation of dependencies (phew)! And it fixes a LOT of bugs mainly around stabilizing the replication services. We tried installing feature-pack 37434 via CRX package manager but, it broke the instance in that it would just serve up 404 pages. However, following the below procedure, we were able to install the feature pack.



Read the full blog post at this URL.

Improving performance with browser caching

- Sensei Martin

On requests, check that you are using browser caching.

Last-Modified should be set.

Expires should be set (seems to be dynamically set if max-age is set on cache-control). On cache-control - watch out for must-revalidate - this seems to bypass the cache.

This is not good:- Cache-Control max-age=0

This is OK:- Cache-Control max-age=1800, public, must-revalidate

NB, public is to allow caching on SSL links.

This is BEST:- Cache-Control max-age=18000, public

Are the flash files cached?


Read the original blog post at this URL.