You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Eoghan Glynn <eo...@progress.com> on 2008/12/12 10:08:47 UTC
JMS clientReceiveTimeout default value
Folks,
Is a default value of 2000ms reasonable for the JMS clientReceiveTimeout?
For even moderately long-lived requests, this seems *way* too tight to me.
A timeout in the ballpark of 2s seems more appropriate for localhost demo-type situation where you want the user to get rapid feedback if they've set things up wrong, or for tests where again you want things to fail fast. But if that's the motivation, couldn't the demos/tests just configure an appropriately tight timeout, but leave much more slack in the default?
Cheers,
Eoghan
RE: JMS clientReceiveTimeout default value
Posted by Eoghan Glynn <eo...@progress.com>.
Yeah 60s seems a lot more reasonable for a default.
Cheers,
Eoghan
-----Original Message-----
From: Willem Jiang [mailto:willem.jiang@gmail.com]
Sent: Fri 12/12/2008 14:05
To: dev@cxf.apache.org
Subject: Re: JMS clientReceiveTimeout default value
Hi Eoghan,
How about set it to be 60s?
I think we take the http client timeout(60s) as an example.
Cheers,
Willem
Eoghan Glynn wrote:
>
> Folks,
>
> Is a default value of 2000ms reasonable for the JMS clientReceiveTimeout?
>
> For even moderately long-lived requests, this seems *way* too tight to me.
>
> A timeout in the ballpark of 2s seems more appropriate for localhost demo-type situation where you want the user to get rapid feedback if they've set things up wrong, or for tests where again you want things to fail fast. But if that's the motivation, couldn't the demos/tests just configure an appropriately tight timeout, but leave much more slack in the default?
>
> Cheers,
> Eoghan
>
Re: JMS clientReceiveTimeout default value
Posted by Willem Jiang <wi...@gmail.com>.
I just filled a JIRA for it [1], and committed a quick fix for it.
[1] https://issues.apache.org/jira/browse/CXF-1946
Willem
Christian Schneider wrote:
> +1
> From me too
>
> Freeman Fang schrieb:
>> +1 to set it to be 60s.
>> I also encounter lots of timeout problem with current default 2s.
>>
>> Freeman
>>
>> Willem Jiang wrote:
>>> Hi Eoghan,
>>>
>>> How about set it to be 60s?
>>> I think we take the http client timeout(60s) as an example.
>>>
>>> Cheers,
>>>
>>> Willem
>>>
>>> Eoghan Glynn wrote:
>>>
>>>> Folks,
>>>>
>>>> Is a default value of 2000ms reasonable for the JMS
>>>> clientReceiveTimeout?
>>>>
>>>> For even moderately long-lived requests, this seems *way* too tight
>>>> to me.
>>>>
>>>> A timeout in the ballpark of 2s seems more appropriate for localhost
>>>> demo-type situation where you want the user to get rapid feedback if
>>>> they've set things up wrong, or for tests where again you want
>>>> things to fail fast. But if that's the motivation, couldn't the
>>>> demos/tests just configure an appropriately tight timeout, but leave
>>>> much more slack in the default?
>>>>
>>>> Cheers,
>>>> Eoghan
>>>>
>>>
>>>
>>>
>>
>>
>
>
Re: JMS clientReceiveTimeout default value
Posted by Christian Schneider <ch...@die-schneider.net>.
+1
From me too
Freeman Fang schrieb:
> +1 to set it to be 60s.
> I also encounter lots of timeout problem with current default 2s.
>
> Freeman
>
> Willem Jiang wrote:
>> Hi Eoghan,
>>
>> How about set it to be 60s?
>> I think we take the http client timeout(60s) as an example.
>>
>> Cheers,
>>
>> Willem
>>
>> Eoghan Glynn wrote:
>>
>>> Folks,
>>>
>>> Is a default value of 2000ms reasonable for the JMS
>>> clientReceiveTimeout?
>>>
>>> For even moderately long-lived requests, this seems *way* too tight
>>> to me.
>>>
>>> A timeout in the ballpark of 2s seems more appropriate for localhost
>>> demo-type situation where you want the user to get rapid feedback if
>>> they've set things up wrong, or for tests where again you want
>>> things to fail fast. But if that's the motivation, couldn't the
>>> demos/tests just configure an appropriately tight timeout, but leave
>>> much more slack in the default?
>>>
>>> Cheers,
>>> Eoghan
>>>
>>
>>
>>
>
>
--
Christian Schneider
---
http://www.liquid-reality.de
Re: JMS clientReceiveTimeout default value
Posted by Freeman Fang <fr...@gmail.com>.
+1 to set it to be 60s.
I also encounter lots of timeout problem with current default 2s.
Freeman
Willem Jiang wrote:
> Hi Eoghan,
>
> How about set it to be 60s?
> I think we take the http client timeout(60s) as an example.
>
> Cheers,
>
> Willem
>
> Eoghan Glynn wrote:
>
>> Folks,
>>
>> Is a default value of 2000ms reasonable for the JMS clientReceiveTimeout?
>>
>> For even moderately long-lived requests, this seems *way* too tight to me.
>>
>> A timeout in the ballpark of 2s seems more appropriate for localhost demo-type situation where you want the user to get rapid feedback if they've set things up wrong, or for tests where again you want things to fail fast. But if that's the motivation, couldn't the demos/tests just configure an appropriately tight timeout, but leave much more slack in the default?
>>
>> Cheers,
>> Eoghan
>>
>>
>
>
>
Re: JMS clientReceiveTimeout default value
Posted by Willem Jiang <wi...@gmail.com>.
Hi Eoghan,
How about set it to be 60s?
I think we take the http client timeout(60s) as an example.
Cheers,
Willem
Eoghan Glynn wrote:
>
> Folks,
>
> Is a default value of 2000ms reasonable for the JMS clientReceiveTimeout?
>
> For even moderately long-lived requests, this seems *way* too tight to me.
>
> A timeout in the ballpark of 2s seems more appropriate for localhost demo-type situation where you want the user to get rapid feedback if they've set things up wrong, or for tests where again you want things to fail fast. But if that's the motivation, couldn't the demos/tests just configure an appropriately tight timeout, but leave much more slack in the default?
>
> Cheers,
> Eoghan
>