Re: DO NOT REPLY [Bug 17487] - waitForResponse is using busywait
Agreed (for once) :-) Oleg Kalnichevski wrote: Laura CPU-bound polling is needed only under fairly unusual circumstances. I do think that any sort of thread based solution would be an overkill. I did my best to explain the rationale for not using threads in the bug report Cheers Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 17487] - waitForResponse is using busywait
Laura CPU-bound polling is needed only under fairly unusual circumstances. I do think that any sort of thread based solution would be an overkill. I did my best to explain the rationale for not using threads in the bug report Cheers Oleg On Thu, 2003-02-27 at 20:23, Laura Werner wrote: > Oleg Kalnichevski wrote: > > >Odi, are you sure you want to have an extra thread per HttpMethod? I do > >not think so > > > You can do threads fairly efficiently by pooling them. I do it in my > cache, since I have to allow a timeout on the whole transaction and > abort the transaction even in the middle of reading the response if it > takes too long. (The VoiceXML spec requires this.) But this is > probably overkill for httpclient. > > Laura > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 17487] - waitForResponse is using busywait
Oops. Other Mike:) Mike Moran wrote: Oleg Kalnichevski wrote: Mike May I add your comments to the bug report? Ye, sure. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 17487] - waitForResponse is using busywait
Oleg Kalnichevski wrote: Odi, are you sure you want to have an extra thread per HttpMethod? I do not think so You can do threads fairly efficiently by pooling them. I do it in my cache, since I have to allow a timeout on the whole transaction and abort the transaction even in the middle of reading the response if it takes too long. (The VoiceXML spec requires this.) But this is probably overkill for httpclient. Laura - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 17487] - waitForResponse is using busywait
Oleg Kalnichevski wrote: Mike May I add your comments to the bug report? Ye, sure. -- Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 17487] - waitForResponse is using busywait
Please do. Mike Oleg Kalnichevski wrote: Mike May I add your comments to the bug report? Oleg On Thu, 2003-02-27 at 19:01, Mike Moran wrote: Michael Becke wrote: Agreed. A second thread should not be needed though. It can be done using something like: [ ... ] Oleg Kalnichevski wrote: [ ... ] Oleg On Thu, 2003-02-27 at 15:36, Ortwin Glück wrote: Oleg Kalnichevski wrote: Odi, are you sure you want to have an extra thread per HttpMethod? I do not think so Oleg Better than a busy wait, isn't it? I just wanted to butt into this to point out that on some platforms, such as 2.2 linux, a thread equates to a process id, and you can quickly run out of them. In these cases, a busy wait is far preferable to a new Thread. Also firing off a Thread when things are slow can cause sudden spikes in Thread use. I've recently seen an analogous problem with an older version of jboss when doing RMI connections which was a pain in the arse to work around. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 17487] - waitForResponse is using busywait
Mike May I add your comments to the bug report? Oleg On Thu, 2003-02-27 at 19:01, Mike Moran wrote: > Michael Becke wrote: > > > Agreed. A second thread should not be needed though. It can be done > > using something like: > > [ ... ] > > > > > > > Oleg Kalnichevski wrote: > > [ ... ] > > >> > >> Oleg > >> > >> On Thu, 2003-02-27 at 15:36, Ortwin Glück wrote: > >> > >>> Oleg Kalnichevski wrote: > >>> > Odi, are you sure you want to have an extra thread per HttpMethod? > I do > not think so > Oleg > >>> > >>> > >>> Better than a busy wait, isn't it? > >> > > I just wanted to butt into this to point out that on some platforms, > such as 2.2 linux, a thread equates to a process id, and you can quickly > run out of them. In these cases, a busy wait is far preferable to a new > Thread. Also firing off a Thread when things are slow can cause sudden > spikes in Thread use. I've recently seen an analogous problem with an > older version of jboss when doing RMI connections which was a pain in > the arse to work around. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 17487] - waitForResponse is using busywait
Michael Becke wrote: Agreed. A second thread should not be needed though. It can be done using something like: [ ... ] Oleg Kalnichevski wrote: [ ... ] Oleg On Thu, 2003-02-27 at 15:36, Ortwin Glück wrote: Oleg Kalnichevski wrote: Odi, are you sure you want to have an extra thread per HttpMethod? I do not think so Oleg Better than a busy wait, isn't it? I just wanted to butt into this to point out that on some platforms, such as 2.2 linux, a thread equates to a process id, and you can quickly run out of them. In these cases, a busy wait is far preferable to a new Thread. Also firing off a Thread when things are slow can cause sudden spikes in Thread use. I've recently seen an analogous problem with an older version of jboss when doing RMI connections which was a pain in the arse to work around. -- Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 17487] - waitForResponse is using busywait
Agreed. A second thread should not be needed though. It can be done
using something like:
long overtime = System.currentTimeMillis() + timeout_ms;
while (System.currentTimeMillis() < overtime) {
if (isResponseAvailable()) {
return true;
} else {
synchronized(this) {
try {
this.wait(100);
} catch (InterruptedException e) {}
}
}
}
We might want to put a little more effort into determining how long to
wait, but the idea is the same.
Mike
Oleg Kalnichevski wrote:
I am not sure.
We do not need down to ms precision there. We might put the thread to
sleep for 10 to 25 ms prior to polling for data again. I would see it as
lesser of two evils
Oleg
On Thu, 2003-02-27 at 15:36, Ortwin Glück wrote:
Oleg Kalnichevski wrote:
Odi, are you sure you want to have an extra thread per HttpMethod? I do
not think so
Oleg
Better than a busy wait, isn't it?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 17487] - waitForResponse is using busywait
I am not sure. We do not need down to ms precision there. We might put the thread to sleep for 10 to 25 ms prior to polling for data again. I would see it as lesser of two evils Oleg On Thu, 2003-02-27 at 15:36, Ortwin Glück wrote: > Oleg Kalnichevski wrote: > > Odi, are you sure you want to have an extra thread per HttpMethod? I do > > not think so > > Oleg > > Better than a busy wait, isn't it? > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 17487] - waitForResponse is using busywait
Oleg Kalnichevski wrote: Odi, are you sure you want to have an extra thread per HttpMethod? I do not think so Oleg Better than a busy wait, isn't it? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 17487] - waitForResponse is using busywait
Odi, are you sure you want to have an extra thread per HttpMethod? I do not think so Oleg On Thu, 2003-02-27 at 15:27, Ortwin Glück wrote: > [EMAIL PROTECTED] wrote: > > waitForResponse should not block infinitely. It should be able to timeout after > > given number of ms if no response is forthcoming. If you see a more elegant Java > > 1.2.2 compatible solution, please advise us > > Oleg > > There is Object.wait(long) and Object.notify and Thread.sleep(long) > even in 1.2.2 > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 17487] - waitForResponse is using busywait
[EMAIL PROTECTED] wrote: waitForResponse should not block infinitely. It should be able to timeout after given number of ms if no response is forthcoming. If you see a more elegant Java 1.2.2 compatible solution, please advise us Oleg There is Object.wait(long) and Object.notify and Thread.sleep(long) even in 1.2.2 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
