You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by bu...@apache.org on 2003/02/27 15:19:36 UTC
DO NOT REPLY [Bug 17487] -
waitForResponse is using busy wait
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=17487>.
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=17487
waitForResponse is using busy wait
------- Additional Comments From olegk@apache.org 2003-02-27 14:19 -------
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
Re: DO NOT REPLY [Bug 17487] - waitForResponse is using busy
wait
Posted by Michael Becke <be...@u.washington.edu>.
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: commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
>
Re: DO NOT REPLY [Bug 17487] - waitForResponse is using busy
wait
Posted by Michael Becke <be...@u.washington.edu>.
Oops. Other Mike:)
Mike Moran wrote:
> Oleg Kalnichevski wrote:
>
>> Mike
>> May I add your comments to the bug report?
>>
> Ye, sure.
>
Re: DO NOT REPLY [Bug 17487] - waitForResponse is using busy
wait
Posted by Mike Moran <mi...@mac.com>.
Oleg Kalnichevski wrote:
>Mike
>May I add your comments to the bug report?
>
Ye, sure.
--
Mike
Re: DO NOT REPLY [Bug 17487] - waitForResponse is using busy
wait
Posted by Oleg Kalnichevski <o....@dplanet.ch>.
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.
Re: DO NOT REPLY [Bug 17487] - waitForResponse is using busy
wait
Posted by Mike Moran <mi...@mac.com>.
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
Re: DO NOT REPLY [Bug 17487] - waitForResponse is using busy
wait
Posted by Michael Becke <be...@u.washington.edu>.
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: commons-httpclient-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
>
Re: DO NOT REPLY [Bug 17487] - waitForResponse is using busy
wait
Posted by Oleg Kalnichevski <o....@dplanet.ch>.
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: commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
>
Re: DO NOT REPLY [Bug 17487] - waitForResponse is using busy
wait
Posted by Ortwin Glück <or...@nose.ch>.
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?
Re: DO NOT REPLY [Bug 17487] - waitForResponse is using busy
wait
Posted by Ortwin Glück <or...@nose.ch>.
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
Re: DO NOT REPLY [Bug 17487] - waitForResponse is using busy
wait
Posted by Oleg Kalnichevski <o....@dplanet.ch>.
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: commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
>
Re: DO NOT REPLY [Bug 17487] - waitForResponse is using busy
wait
Posted by Laura Werner <la...@lwerner.org>.
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
Re: DO NOT REPLY [Bug 17487] - waitForResponse is using busy
wait
Posted by Oleg Kalnichevski <o....@dplanet.ch>.
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:
> bugzilla@apache.org 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: commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
>
Re: DO NOT REPLY [Bug 17487] - waitForResponse is using busy
wait
Posted by Ortwin Glück <or...@nose.ch>.
bugzilla@apache.org 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