[development] watchdog() does not always work - or am I missingsomething?

Frédéric G. MARAND fgm at osinet.fr
Wed Apr 22 06:16:02 UTC 2009


I've seen a similar case, where watchdog wouldn't work because the referer 
field was too long and the insert request in dblog failed almost silently 
instead of truncating that field (innodb engine, not checked with myisam 
engine): the request wasn't logged and the failure of that request wasn't 
stored either, IIRC for the same reason. Had to see it in a debugger to 
understand what was going on. You might want to try a debugger too.

----- Original Message ----- 
From: "David Cohen" <drupal at dave-cohen.com>
To: <development at drupal.org>
Sent: Wednesday, April 22, 2009 5:58 AM
Subject: [development] watchdog() does not always work - or am I 
missingsomething?



I'm debugging a situation where one of my drupal menu items is being
called via javascript, AJAX style.  To debug a problem, I've added
watchdog() calls to the callback - as a sanity check that the callback
is being reached, and so I can inspect some values.

The problem is that the log entries never show the messages I'm trying
to write.  Its as if the menu callback is never called.  However the
apache log shows that the path is being requested.  Let's say the path
is /drupal/my/callback.

Now, when I explicitly point a browser to the URL, lets say
http://example.com/drupal/my/callback, then the watchdog messages are
written to the log!  It's as if watchdog only succeeds when the browser
explicitly makes the request.

I've tried disabling drupal's cache.  I've tried refreshing the cache.
No matter what I do, either my callback is not being called (despite
apache logs to the contrary) or the watchdog calls fail without error
(which would be crazy).  But only fail when the call is made via
javascript.  When made explicitly from the browser everything works as
expected.

BTW, the apache logs indicate the proper number of bytes is returned by
the request, and I've changed the size of the page returned to confirm
this - evidence that caching is not the cause of this.

Has anyone seen this or have any ideas?  Many thanks.

-Dave



--------------------------------------------------------------------------------



No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.287 / Virus Database: 270.12.1/2071 - Release Date: 04/21/09 
08:30:00



More information about the development mailing list