Giampaolo,
> Well, I have 3.2.1 and the excerpt from AsyncLoop.pm was from there.
> But anyway, how is supposed to be set the timeout value of a non-DNS query?
The current code in trunk is able to specify and honour individual
timeouts for each async request - and it defaults to rbl_timeout
if not specified otherwise. See sub AsyncLoop::start_lookup()
and $ent->{timeout} attribute in an object passed to it.
> Maybe my code stops due to a timeout: messages are non that clear...
See http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5589
The current code in trunk deals with timeouts more accurately.
The patch in Bug 5589 can be applied to 3.2.3, if one wants
to avoid running the bleeding edge trunk code.
> It may even be a timeout, then. It seems to me there is no way to set a
> lookup timeout in start_lookup() in AsyncLoop.pm. Right?
True in 3.2.3, not true in (3.3.0)SVN.
> By the way, it may be that the Async code is undergoing many changes.
> Is there any SA version in which it could be regarded as stable?
For doing new development it is best to start with the current code in
trunk, otherwise one could be solving problems which are already solved.
Of course running the leading edge code bears its risks and offers no
guarantees (but there are no real guarantees for 3.2.3 either, right?!),
so one should be prepared to peek into code and solve some glitch if
need arises - and subscribing to a 'dev' mailing list is advised.
Nevertheless, some people do run the trunk code in their test or even
in production environment. Generally the trunk code is supposed to
always be runnable on a mainstream environment - e.g. Perl 5.8.8 on Unix,
with recent versions of external Perl modules. If running older Perl
or being on Windows, chances are much higher that some feature is
not yet thouroughly tested. Mishaps do happen on occasion, but are
usually sorted in a day or two, and reverting to a revision before
a breakage is always a quick-fix workaround. The decision mostly
depend on your willingness to get hands dirty on occasion, benefits
are that there is a quickest response to problems, old and new.
In my experience the current trunk is well behaved and quite stable
as it stands at the moment, and is still compatible with 3.2.3,
so one can revert to 3.2.3 in an emergency.
Mark
