On Feb 23, 2006, at 03:13, Robin Bowes wrote:
John Peacock said the following on 02/23/2006 02:09 AM:
Robin Bowes wrote:
Am I doing something wrong, is this a "bug", or is what I'm
trying to do
not possible?
Now that I read through the full discussion, I believe Johan was
mistaken when
he said that you could add a second queue plugin and it would be
called only if
the real queue plugin suceeded. That is *not* the way that
qpsmtpd operates.
The only time multiple plugins will fire for a given hook is if
they all return
DECLINED (see lib/Qpsmtpd.pm:348).
I figured that out for myself, right down the the module and line
number! (see my subsequent posts)
This was why the original adaptive plugin hook'd
reset_transaction; there isn't
hook after queue but before post-connection. I think that Johan's
earlier
suggestion of looking at the transaction object to see which time
you want the
logging to actually emit something (the middle reset_transaction,
in other words).
About 1 hour ago it would have saved me ... about 1 hour of hacking!
I apologise for wasting your time, it occured to me that the queue
plugin probably emits DONE and that my suggestion wouldn't work, but
I'd switched the iBook off for the night...
If you wanted to be sure that nothing bad happened in the queue
plugin, you could store the "real" result in a transaction note and
use that for return value in your plugin.
So line 79 (and 80) become [untested again, sorry]
$transaction->notes('queue_result', DONE);
$transaction->notes('queue_text', "Queued! " . time . " qp $child
$msg_id");
return (DECLINED, "Queued! " . time . " qp $child $msg_id");
and your plugin would end
return ($transaction->notes('queue_result', DONE),
$transaction->notes('queue_text', "Queued! " . time . " qp $child
$msg_id"))
Which probably is a good idea because as things are now the text
won't be shown to the connecting peer, so the queue ID won't be in
their logs which sometimes makes error localisation more difficult.
-Johan
