Labels

accessibility (2) ADF (1) archiver (3) cmu (1) contributor (13) cookie (1) DAM (3) date (3) download (3) dynamic list (4) ephox (5) fatwire (1) fck (1) filters (1) folders (4) headers (2) IBR (3) ImageAlchemy (3) java (4) javascript (2) layout/template (4) link (6) locale (2) multilingual (1) rendition (3) replicator (4) rules (1) schema (1) search (11) sites (1) sitestudio (24) ssp/sspu (5) SSUrlFieldName (2) stellent (4) timezone (1) urm (1) weblogic (1) workflow (2)

Sunday 8 June 2008

Useful SSPU logging

Well I haven't started rewriting the hyperlink wizard, my apologies. I've been wrestling with SSPU which has failed to publish our site repeatedly over the last two weeks. In an effort to work out what the hell was going on we turned on all the logging, right up to "debug for all". It was too much to be helpful... so after reviewing the logs I was able to come up with some meaningful logging levels.

PRIMARY LOG (FILE)
default: ERROR
syndicator: INFO
date-time: CRITICAL
analyser: CRITICAL
replicator: INFO
packagemanager: INFO
ice.cache: VERBOSE
delivery: INFO
delivery.ice: VERBOSE

SECONDARY LOG (DATABASE)
default: ERROR

Ok let's start with the database log. I know it sounds counter-intuitive but database logging slows down the software tremendously - it needs to read the entire database to display the SSPU status page (so make sure you purge often!) When you're viewing the SSPU website the only thing you care about is errors. Ignore everything else.

The primary log file is what you turn to when there is a problem. Set Syndicator to INFO to report the overall status of SSPU. It also includes info about database purges. Set Analyzer to CRITICAL to ignore messages about malformed links (they won't affect the publish anyway.) Set Replicator to INFO - this reports which files are actually being processed. It also includes final summaries and error counts. Set Delivery to INFO to report when a job is pushed to the subscription client/FTP (subagent). Set Delivery.ice to VERBOSE in order to report the status of the subagent's delivery and see an actual confirmation message that the publish succeeded. Finally there is a meaningless bug in the interface so I set date-time to CRITICAL so it won't get reported.

There are two additional settings you might consider. Set Packagemanager to INFO in order to see exactly which files have been selected (or skipped) for update. Set Ice.cache to VERBOSE in case there are some undelivered files floating around - it reports what items are waiting to be delivered.

One final important tip - Delivery.ice may report warnings about ice 501 errors. These can safely be ignored. They simply mean that SSPU was asking for confirmation that the job was finished but the subscription client (subagent) was too busy processing the job to respond. SSPU will keep resending the job until it receives a 200 confirmation - but subagent will only process the first push and ignore the rest. Once subagent finishes it sends confirmation, SSPU stops pushing and subagent discards all the repeated pushes. This is the intended behaviour.

Oh and the problem with our publish? Too many broken links!

1 comment:

  1. Thanks for the info on SSPU logs. And the tip at the end - I suspected the ice 501 errors could be ignored since it showed the site was successfully published.

    ReplyDelete