Sometimes, code from components you have no control over as a system administrator starts littering the error.log with useless (to you) INFOrmational messages. This causes logs to bloat, increasing disk I/O, storage costs and additional CPU cycles.
You can use the “Apache Sling Logging Logger Configuration" OSGi configuration at /system/console/configMgr to suppress a message such as follows:
28.02.2014 01:55:05.596 *INFO* [Thread-1078954] com.corporation.generics.services.services.impl.GsaServiceImpl »»» Entering the buildUrl method
1) Raise the “Log Level” threshold one step higher (from INFO to WARN)
2) In the “Logger” field, enter the name of the package causing trouble (com.corporation.generics.services.services.impl.GsaServiceImpl)
It takes effect immediately on saving - no re-start necessary.
The ”Day CQ WCM Page Statistics" OSGi configuration lets you configure the "publish" instances with the IP address of the "author" instance(s) so that page impressions statistics can be recorded in "author" using tracker.js ( /libs/wcm/stats/tracker.js ).
See screenshot below (replace localhost and 4502 with your “author” instance’s DNS name and port):
For example, loading the main Geometrixx Outdoors page on “publish” will trigger a GET request on “author” like this:
If configured properly, when you load up that page in “author” ( /siteadmin#/content/geometrixx-outdoors ), you should see that the number for that page under the “Impressions” column has gone up by 1.
If not configured properly, this will trigger an HTTP response of 403 Forbidden in “publish”.
You can also leave the URL blank to disable this altogether (thanks to my colleague Caleb Pryor for that suggestion).
Tracking page impressions does increase load on your “author” instance. If no one cares about keeping track of page impressions on “publish”, then you are better off disabling it. It is definitely NOT a good indicator of readership because you can get that information only from your CDN. If you don’t use a CDN, the authoritative information on readership will reside on the Apache (Dispatcher) logs.
In CQ 5.5 SP2 and later, PDF management (metadata extraction, thumbnail generation, sub-asset extraction etc.) is handled by Adobe’s “Gibson” PDF library (OSGi bundle name = “Adobe PDF Java Toolkit (com.adobe.granite.gibson)”) rather than the open-source Apache PDFBox library.
One of its components is FontManager which needs extra configuration with regard to the location of fonts on the server. If this is left unconfigured, rendered thumbnails of uploaded PDFs could look very different from what you’d expect and the error.log will report the following:
*INFO* [FelixStartLevel] com.day.cq.dam.handler.gibson.fontmanager.impl.FontManagerServiceImpl Using following directories for looking up fonts. Adobe Font Dir = null, Customer Font Dir = null,System Font Dir = null
You can configure this using the OSGi Configuration Manager for “CQ-DAM-Handler-Gibson Font Manager Service" (thanks to Adobe’s Sham Hassan Chikkegowda for this pointer):
Once done, the error.log will have a log entry that looks something like this (Windows example):
*INFO* [CM Event Dispatcher (Fire ConfigurationEvent: pid=com.day.cq.dam.handler.gibson.fontmanager.impl.FontManagerServiceImpl)] com.day.cq.dam.handler.gibson.fontmanager.impl.FontManagerServiceImpl Using following directories for looking up fonts. Adobe Font Dir = D:\CQ\author\crx-quickstart\fonts\adobe, Customer Font Dir = D:\CQ\author\crx-quickstart\fonts\custom,System Font Dir = C:\Windows\Fonts
When a PDF asset is ingested into DAM, you will see a log entry that looks something like this: