Overview
| Artifact ID: | 10171c356f593f0ebb3c7197ea02f4ef4de60e54 |
|---|---|
| Ticket: | 7e0f5ae0f69146b1d73f450a7c1938210b429820
dns package |
| User & Date: | aku 2015-04-15 19:20:01 |
Changes
- closedate changed to: "2457128.30557052"
- closer changed to: "aku"
- icomment:
I can now confirm that executing a vwait $tok just after the dns::resolve command fixes the issue, for dns version 1.3.3. For 1.3.4 adding the vwait is a workaround as well. So, issue reproduced here. Looking into the version 1.3.4 code there should be some 'wait'ing happen automatically. But apparently not, or not correctly. Oh. The chosen protocol is UDP (*), and the auto-wait I see in dns::resolve is limited to TCP. (Ad *): I have the udp package installed and it got loaded automatically (as per output of [info loaded]). I now suspect that you have the same configuration, with the udp package (or ceptcl) available. Making that general ... is a fix. Basically, the vwait of the workaround is done internally, and automatically when -commmand is NOT set, regardless of transport. Very unclear why this was limited to tcp ... Hm ... Jan 30, 2003, commit [7109bd29408a8efb]. This added the udp support, and apparently missed the implication of having the auto-wait not extended to it. Fixed with revision [ca36641e9f]. Pushed. Version bumped to 1.3.5.
- login: "aku"
- mimetype: "text/x-fossil-wiki"
- resolution changed to: "Fixed"
- status changed to: "Closed"