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
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
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
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
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
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
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 seem that
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 Windows gurus come to the
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 determines the number of times that
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
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
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
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! Thank you
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
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
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
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.
I've attached my
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
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
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 with GetTcpTable.
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
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 on
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.
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
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
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
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])
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
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
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 nothing is
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
32 matches
Mail list logo
