ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 10401] - waitfor task doesn't shut off socket conditions in every case
Date Wed, 10 Jul 2002 16:51:17 GMT
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





------- Additional Comments From wtff@freenet.de  2002-07-10 16:51 -------
(sorry for my delayed reply)

@Gus:

thank you for saying that my englich is marvelous!
My teachers marveled less at it and found it rather marvelless. ;)

---

By "s.th." I indeed meant the word something. I got the abbreviation wrong.
By the way: if that already troubled you, then you should see my handwriting, 
hehe... ;) ;)


@steve:

Until this very day, I have only been an ant 'user' and haven't looked at any 
sources yet, but I'm looking forward do so in the near future...

Therefore, excuse me if the following might not be useful or new to you, but 
concerning the interruption of socket connections without any nasty thread 
issues, I think the following should do:

- Within the sdk javadoc for the Socket class, it says, that invoking 
socket.close() terminates the socket thread immediately and throws an exception 
to any waiting thread.

- The Socket class also has a method called setSO_Timeout() and in version 1.4 
there is also a constructor taking a timeout value as an argument.

Therefore, if I open a socket connection, I think that I am able to destroy it 
in a clean way at will, at any time I want. If that should really NOT be the 
case, then I am in serious trouble since the project I am working on and 
getting paid for, heavily depends on this assumption... somehow ;) 

---

Meanwhile I believe that the waitfor task, even if it interrupted its subtasks 
the way I would expect it to, would still not be what I need. Thanks for 
pointing this out to me. The timeout property is only set if a timeout occurs. 
Therefore, if the condition evaluates to true then this information would of 
course not go into any property. Hence, I really need to use the <condition> 
task, for it has the ability to evaluate the boolean result of a condition and 
to write it into a property. However, in the light of the example I gave,
a timeout attribute would have to be added to the <condition> task. If the 
condition cannot be evaluated within the alloted timespan, the resulting 
boolean value has to be set to false. This is what I would propose. 
If the feature freeze for ant 1.5 forbids the incorporation of this, then I 
would like to propose this for the next release.

Since the <socket> and <http> tasks already exist and their only imagineable 
purpose, as I see it, is to check on network stati, the whole apparatus does 
not really seem to be apt for any practical use as long as there is no such 
timeout attribute for the <condition> task, right?

I am willing to try to help coding this or to provide a prototype of an 
extended <condition> task that correctly deals with interrupting its subtasks, 
but of course, I would first need to know if you people at apache support the 
idea.

Until now I just have a user perspective on all this and
from a user perspective I would say that the condition task is pretty useless 
without a timeout mechanism.
However I do not yet know about any technical intricities and so on...

In any case I would like to thank you for your patience with me and for taking 
my problems seriously.

--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


Mime
View raw message