On Oct 13, 2008, at 4:42 PM, Ruediger Pluem wrote:
On 10/13/2008 10:04 PM, Jess Holle wrote:
Jess Holle wrote:
Ruediger Pluem wrote:
So if noone finds a registry entry to stop this RFC violating
behaviour
I'd love to see this solved by such a discovery, "option 0".
I see only two opti
Ruediger Pluem wrote:
On 10/13/2008 10:04 PM, Jess Holle wrote:
Jess Holle wrote:
Ruediger Pluem wrote:
So if noone finds a registry entry to stop this RFC violating behaviour
I'd love to see this solved by such a discovery, "option 0".
I see only two options o
Ruediger Pluem wrote:
On 10/13/2008 09:37 PM, Jess Holle wrote:
Ruediger Pluem wrote:
So if noone finds a registry entry to stop this RFC violating behaviour
I'd love to see this solved by such a discovery, "option 0".
I see only two options on Windows:
1. Fiddle around w
On 10/13/2008 10:04 PM, Jess Holle wrote:
> Jess Holle wrote:
>> Ruediger Pluem wrote:
>>> So if noone finds a registry entry to stop this RFC violating behaviour
>>>
>> I'd love to see this solved by such a discovery, "option 0".
>>> I see only two options on Windows:
>>>
>>> 1. Fiddle around
Hi,
I think the option of sub second connection timeouts is a good thing. It also
has the nice benefit of fixing windows interest RST behavior. It also means a
jk/http proxy can do things some L7 switches can't do. I've also had a need of
it in the past.
For most cases a connection is going t
Ruediger Pluem wrote:
>
> Not exactly. I would prefer to fix the basic issue with Windows. If we need to
> support milliseconds for connection timeouts seems to be another story for me.
> Can some of the Windows gurus come to the rescue to either confirm and explain
> why it takes that long for co
On 10/13/2008 09:37 PM, Jess Holle wrote:
> Ruediger Pluem wrote:
>> So if noone finds a registry entry to stop this RFC violating behaviour
>>
> I'd love to see this solved by such a discovery, "option 0".
>> I see only two options on Windows:
>>
>> 1. Fiddle around with GetTcpTable.
>>
>
Jess Holle wrote:
Ruediger Pluem wrote:
So if noone finds a registry entry to stop this RFC violating behaviour
I'd love to see this solved by such a discovery, "option 0".
I see only two options on Windows:
1. Fiddle around with GetTcpTable.
I've attached my incomplete code in this reg
Ruediger Pluem wrote:
> Correct and my statement didn't imply to set this registry value to 0. I think
> this is a dangerous road and could lead to other network problems.
>
While your statement didn't imply that, the microsoft knowledge base
article seems to imply that this registry setting sho
Ruediger Pluem wrote:
So if noone finds a registry entry to stop this RFC violating behaviour
I'd love to see this solved by such a discovery, "option 0".
I see only two options on Windows:
1. Fiddle around with GetTcpTable.
I've attached my incomplete code in this regard (as a diff agai
On 10/13/2008 07:46 PM, Rainer Jung wrote:
> Jess Holle wrote:
>> I just set this parameter to 0 and the issue went away entirely.
>
> And indeed
>
> http://support.microsoft.com/kb/175523
>
> confirms, that Microsoft has a different way of handling RST than Unixes.
>
>> Good catch, Ruediger!
Jess Holle wrote:
I just set this parameter to 0 and the issue went away entirely.
And indeed
http://support.microsoft.com/kb/175523
confirms, that Microsoft has a different way of handling RST than Unixes.
Good catch, Ruediger! Thank you -- and all who helped on this thread!
I think it
After a poke and a prod from someone else here about this delay
algorithm being used for timeouts, having that default to 0 doesn't seem
like it would be appropriate either as it could severely hamper network
connectivity in legitimate timeout cases.
It seems like MS' TCP stack seems to think a RS
I just set this parameter to 0 and the issue went away entirely.
Good catch, Ruediger! Thank you -- and all who helped on this thread!
It would appear that Microsoft's documentation slipped a decimal place
somewhere as it would appear there is about 0.3 second delay on the
initial retry and a
Ruediger Pluem wrote:
>>>
>>> According to the Microsoft
>>> (http://support.microsoft.com/default.aspx/kb/314053)
>>>
>>> TcpMaxConnectRetransmissions
>>> Key: Tcpip\Parameters
>>> Value Type: REG_DWORD - Number
>>> Valid Range: 0 - 0x
>>> Default: 2
>>> Description: This parameter determi
On 10/13/2008 03:54 PM, Rainer Jung wrote:
> Mladen Turk wrote:
>> Ruediger Pluem wrote:
>>>
>>>
>>> Not exactly. I would prefer to fix the basic issue with Windows. If
>>> we need to
>>> support milliseconds for connection timeouts seems to be another
>>> story for me.
>>> Can some of the Window
Mladen Turk wrote:
Ruediger Pluem wrote:
Not exactly. I would prefer to fix the basic issue with Windows. If
we need to
support milliseconds for connection timeouts seems to be another
story for me.
Can some of the Windows gurus come to the rescue to either confirm
and explain
why it takes tha
Mladen Turk wrote:
Ruediger Pluem wrote:
Not exactly. I would prefer to fix the basic issue with Windows. If we
need to
support milliseconds for connection timeouts seems to be another story
for me.
Can some of the Windows gurus come to the rescue to either confirm and
explain
why it takes
Ruediger Pluem wrote:
Not exactly. I would prefer to fix the basic issue with Windows. If we need to
support milliseconds for connection timeouts seems to be another story for me.
Can some of the Windows gurus come to the rescue to either confirm and explain
why it takes that long for connect t
Ruediger Pluem wrote:
Not exactly. I would prefer to fix the basic issue with Windows. If we need to
support milliseconds for connection timeouts seems to be another story for me.
Can some of the Windows gurus come to the rescue to either confirm and explain
why it takes that long for connect to
On 10/13/2008 11:46 AM, Jess Holle wrote:
> Ruediger Pluem wrote:
>> On 10/13/2008 12:50 AM, Jess Holle wrote:
>>
>>> Perhaps I misunderstand things here, but isn't this connection timeout
>>> setting used for more than just the timing out the initial formation of
>>> the connection? It would
Ruediger Pluem wrote:
On 10/13/2008 12:50 AM, Jess Holle wrote:
Perhaps I misunderstand things here, but isn't this connection timeout
setting used for more than just the timing out the initial formation of
the connection? It would seem that logical that there would be a
connection timeout f
Ruediger Pluem wrote:
On 10/13/2008 12:50 AM, Jess Holle wrote:
Perhaps I misunderstand things here, but isn't this connection timeout
setting used for more than just the timing out the initial formation of
the connection? It would seem that logical that there would be a
connection timeout f
On 10/13/2008 12:50 AM, Jess Holle wrote:
> Perhaps I misunderstand things here, but isn't this connection timeout
> setting used for more than just the timing out the initial formation of
> the connection? It would seem that logical that there would be a
> connection timeout for forming the ini
Perhaps I misunderstand things here, but isn't this connection timeout
setting used for more than just the timing out the initial formation of
the connection? It would seem that logical that there would be a
connection timeout for forming the initial connection and another for
timeouts of resp
Hi,
Send this to the wrong address first time. May have saved the GetTcpTable
coding.
Here is a usec timeout fix, although I wouldn't go below 100 milliseconds
without some testing under load. I'm not sure its the perfect way to do it, but
it avoids changing the "connectiontimeout" parameter
I've managed to create a workaround for this issue with GetTcpTable().
The only remaining issue I have is that I don't want to call this too
often. I want to hold on to the data with a time-to-live during which
I'll assume the data has not changed.
That's all easy enough except for locking. Th
Jess Holle wrote:
Ruediger Pluem wrote:
Did you check whether the currently running thread "proxy_ajp connect timeout
fix."
(http://mail-archives.apache.org/mod_mbox/httpd-dev/200810.mbox/[EMAIL
PROTECTED]
and
http://mail-archives.apache.org/mod_mbox/httpd-dev/200810.mbox/[EMAIL
PROTECTED])
d
Ruediger Pluem wrote:
Did you check whether the currently running thread "proxy_ajp connect timeout
fix."
(http://mail-archives.apache.org/mod_mbox/httpd-dev/200810.mbox/[EMAIL
PROTECTED]
and
http://mail-archives.apache.org/mod_mbox/httpd-dev/200810.mbox/[EMAIL
PROTECTED])
does fix your issue
On 10/09/2008 11:50 PM, Jess Holle wrote:
> P.S. Yes, I know this approach only has any hope of working when Apache
> and the proxy backends are on the same host.
>
> Jess Holle wrote:
>> I had previously discovered that mod_proxy_balancer takes over 1
>> second on Windows to determine that noth
P.S. Yes, I know this approach only has any hope of working when Apache
and the proxy backends are on the same host.
Jess Holle wrote:
I had previously discovered that mod_proxy_balancer takes over 1
second on Windows to determine that nothing is listening on the target
port. This becomes pro
I had previously discovered that mod_proxy_balancer takes over 1 second
on Windows to determine that nothing is listening on the target port.
This becomes problematic if you are balancing over a sparsely populated
set of proxy ports.
A Windows guru here found the Windows GetTcpTable which wou
32 matches
Mail list logo