> -----Messaggio originale----- > Da: Mark Martinec [mailto:[EMAIL PROTECTED] > > 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, thank you for your precious hints: I found SA 3.2.3 to fix the matter. As you told me, however, I can't still specify a timeout in start_lookup(). Anyway, this isn't very important, because it seems to me that 3.2.3 raises the default to 6 seconds, which is pretty fine. I'll stick to 3.2.3 since I'm going to put this plugin into a production server and of course I would prefer not to tie it to "trunk" code. If I correctly understand you reply, the Async API didn't change too much in the trunk (apart for the timeout enhancement), thereby I'm going to expect this plugin to work against trunk too. If this will not be the case, I'll adjust to the future needs when they'll get out... Thank you again, Giampaolo > > Mark
