DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10401>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10401

waitfor task doesn't shut off socket conditions in every case

[EMAIL PROTECTED] changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX



------- Additional Comments From [EMAIL PROTECTED]  2002-07-03 03:14 -------
well, looks like you have found a corner case that the timeout doesnt address.
We do probe for things like apache.com being online in ant's build, but use
condition and take the time hit; you can go -Doffline=true to bypass the wait.

looking at the source, you will see that <waitfor> really reevauates the
condition every interval until timeout or success. if the condition takes a long
time to execute, waitfor is oblivious to the fact. 

0. fully off line system will fail dns lookups immediately. 

1. if DNS cant find a hostname, then it should fail <condition> immediately, so
a bad hostname is not a problem

2. no route to host through firewall or simply invalid IP address is a different
problem as it will cause an online system to send TCP SYN packets to give up,
that being an artifact of the TCP specification. 

3. We cant give up early, as that would nominally violate TCP. Also, unless you
know a java property to control it, a property that propagates to the underlying
plaftform across the board, then there is nothing that can be done.

I could see an ugly hack involving threads, but I couldnt see anyone in the ant
team motivating themselves to implement the code *or* the test. you are free to
do so yourself. 

I know that you are going to find this unsatisfactory, especially in the absence
of ping. Perhaps your platform's native ping returns an error code on timeout,
if this is the case <exec> could run it and test for the response.

Nb, if you want to add correcting text to the docs for waitfor or <socket> or
<http>, reopen the bug and add diffs to the files as patches.

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to