+---+
| Bugzilla Bug ID |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned
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
+1
Greg
On Fri, Oct 10, 2008 at 10:36 AM, Jim Jagielski [EMAIL PROTECTED] wrote:
Based on the positive feedback on the test tarballs, I'd
like to start a vote on releasing 2.2.10. I'm looking to
release on Tuesday, since I'll be traveling Monday, so I'll
close the vote on Tues AM.
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
On 10/09/2008 10:11 PM, Matt Stevenson wrote:
Had a bit more time, here is a patch that should work for Unix which have
apr_wait_for_io_or_timeout available. I can't test windows/others so that's
the reason for the ifdef.
ProxyPass / balance://hotcluster/
Proxy balance://hotcluster
#
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
My search has identified that:
- OpenSSL FIPS Object Model 1.1 is compatible with OpenSSL v0.9.7,
v0.9.7m above and was validated against FIPS 140-2 by 11/16/07 and
that OpenSSL FIPS Object Model 1.2 validation was pending and would be
compatible with an as yet unreleased OpenSSL v0.9..8
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
Hi All
I'm trying to use Aspect's J load time weaving feature using
WeavingURLClassLoader. Aspect that i write is defined on one method in
JServConnection class in ApacheJServ module.Basically i need to set class
loader(WeavingURLClassLoader, i guess using system property) to be used
when
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.
On 10/13/2008 10:35 PM, jetpilot wrote:
Hi All
I'm trying to use Aspect's J load time weaving feature using
WeavingURLClassLoader. Aspect that i write is defined on one method in
JServConnection class in ApacheJServ module.Basically i need to set class
loader(WeavingURLClassLoader, i
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
AspectJ's documentation should give some coverage to wedging use of this
ClassLoader into an existing app, but this really isn't the place for
such a question. If it were Tomcat, I'd suggest the Tomcat user's group
as some Tomcat user has likely done something similar, but there's no
such
Tnx for responses
I'm aware of 1.5 agent capabilities and that JServ is retired project, but
unfortunately not every customer have same environment, and older version of
Oracle AS use Jserv, so we need support for 1.4 + Jserv.As you pointed out
this isn't the best place to ask this question and
30 matches
Mail list logo
