[EMAIL PROTECTED] wrote:
Author: mturk
Date: Tue Jul 18 08:38:14 2006
New Revision: 423119
URL: http://svn.apache.org/viewvc?rev=423119view=rev
Log:
Add svn:eol-style:native.
We'll probably need to do that for the entire repository.
-1. This will screw up diffs, which will create much bigger
Author: remm
Date: Wed Jul 19 00:05:45 2006
New Revision: 423388
URL: http://svn.apache.org/viewvc?rev=423388view=rev
Log:
- get/setProperty are used by IntrospectionUtils. Oops.
Modified:
tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Http11Protocol.java
Modified:
Remy Maucherat wrote:
[EMAIL PROTECTED] wrote:
Author: mturk
Date: Tue Jul 18 08:38:14 2006
New Revision: 423119
URL: http://svn.apache.org/viewvc?rev=423119view=rev
Log:
Add svn:eol-style:native.
We'll probably need to do that for the entire repository.
-1. This will screw up diffs, which
In
http://www.apache.org/dev/version-control.html
the ASF suggests:
Committers will need to properly configure their svn client. One
particular issue is OS-specific line-endings for text files. When you
add a new text file, especially when applying patches from Bugzilla,
first ensure that
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=40072.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
Well a new show stopper for 1.2.18 ;(
2006/7/18, David Rees [EMAIL PROTECTED]:
On 7/18/06, Jess Holle [EMAIL PROTECTED] wrote:
Is the 60 seconds hard-coded?
I'd hope not...
Once you have some interesting web apps in Tomcat it often takes a bit
longer than 10 seconds -- and on my laptop
Rainer Jung wrote:
Maybe we need to set everything to native, checkout, convert those that
have the wrong endings and commit?
No need for co/commit.
svn propset will convert current line endings to the virtual
one I suppose, and then each client depending on the platform
will have correct
Henri Gomez wrote:
Well a new show stopper for 1.2.18 ;(
Why it would be?
JK 1.2.18 is still not tagged.
--
Mladen.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
No, I think it's not:
1) This is not a regression, it was always implemented like that.
2) The recover feature is used in the load balancer and the first way of
avoiding errors is meant to be retries, the second way is failover. Only
then comes recovery.
3) A worker that goes into error
Author: mturk
Date: Wed Jul 19 02:49:02 2006
New Revision: 423418
URL: http://svn.apache.org/viewvc?rev=423418view=rev
Log:
Allow to have the recover timeout less then default
60 second. If someone needs the lower latency, then
he can set worker.name.recover_time=xxx where the
xxx is value in
Henri Gomez wrote:
Well a new show stopper for 1.2.18 ;(
Committed a fix that allows to have a
worker.name.recover_time lower then 60 seconds.
Previously the minimum value was 60 seconds, and
now is 1 second.
The default is still the same (60 seconds)
Regards,
Mladen.
Rainer Jung wrote:
6) We could make the interval configurable, but there is a real danger
of users thinking, that a low recovery interval, like 10 seconds would
make things better, whereas it is very likely, that it would make there
whole system kind of oscillate.
Well, I don't wish to
Rainer Jung wrote:
No, I think it's not:
1) This is not a regression, it was always implemented like that.
Right, and the reason it was never changed was because
no one gave any reason to change it.
Like said, 60 seconds recover timeout was probably used
since someone thought it should be
Rainer Jung wrote:
Mladen Turk wrote:
Anyhow, why would 60 second be optimal value?
It could as well be 90, 100, 180, etc...
Increasing is something totally different. I just want to avoid people
ending with a system that changes error/ok states with a high frequency,
so that the whole
I'm OK with your change.
I think we should try to educate the users via doc, that they need to be
careful when lowering these values to very small numbers. I don't know,
if that's the right term, but the system needs some damping to keep it
from switching very frequently between states. At
Henri Gomez wrote:
Well a new show stopper for 1.2.18 ;(
Why ? With the current implementation, low values will have extremely
bad behavior in some cases. You should actually configure long
intervals, without retries.
Rémy
Rainer Jung wrote:
No, I think it's not:
1) This is not a regression, it was always implemented like that.
2) The recover feature is used in the load balancer and the first way of
avoiding errors is meant to be retries, the second way is failover. Only
then comes recovery.
3) A worker that
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=40072.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
Rainer Jung wrote:
I'm OK with your change.
I think we should try to educate the users via doc, that they need to be
careful when lowering these values to very small numbers. I don't know,
if that's the right term, but the system needs some damping to keep it
from switching very frequently
Rainer Jung wrote:
No, I think it's not:
1) This is not a regression, it was always implemented like that.
2) The recover feature is used in the load balancer and the first way
of avoiding errors is meant to be retries, the second way is failover.
Only then comes recovery.
3) A worker
The next problem is to find a way to tell TC that its connexions have
been closed (by a stupid firewall that eats the closes for example).
That is nice to recover but how to make sure the TC part knows that
something has went wrong.
FW who eat the FIN-CLOSE ?
Henri Gomez wrote:
The next problem is to find a way to tell TC that its connexions have
been closed (by a stupid firewall that eats the closes for example).
That is nice to recover but how to make sure the TC part knows that
something has went wrong.
FW who eat the FIN-CLOSE ?
Yes, if
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=40070.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
Author: fhanik
Date: Wed Jul 19 06:00:42 2006
New Revision: 423453
URL: http://svn.apache.org/viewvc?rev=423453view=rev
Log:
Fixed chunked input filter to parse the header correctly. Performs strict
parsing according to the RFC2616, so if the header is invalid it bails out.
Modified:
Author: mturk
Date: Wed Jul 19 08:34:18 2006
New Revision: 423497
URL: http://svn.apache.org/viewvc?rev=423497view=rev
Log:
Added branches top level directory
Added:
tomcat/tc6.0.x/branches/
-
To unsubscribe, e-mail:
Author: mturk
Date: Wed Jul 19 08:35:12 2006
New Revision: 423498
URL: http://svn.apache.org/viewvc?rev=423498view=rev
Log:
made a copy
Added:
tomcat/tc6.0.x/branches/svn_props/
- copied from r423497, tomcat/tc6.0.x/trunk/
Testing complete: +1
On Jul 18, 2006, at 12:48 PM, Jim Jagielski wrote:
I haven't done exhaustive testing yet, but it's looking
good :)
On Jul 18, 2006, at 10:44 AM, Henri Gomez wrote:
Good, so we're ready for a 1.2.18 release ?
2006/7/18, Jim Jagielski [EMAIL PROTECTED]:
On Jul 18,
I'd say that it's a feature enhancement, not a show stopper.
And not a regression nor a bug :)
On Jul 19, 2006, at 5:16 AM, Henri Gomez wrote:
Well a new show stopper for 1.2.18 ;(
2006/7/18, David Rees [EMAIL PROTECTED]:
On 7/18/06, Jess Holle [EMAIL PROTECTED] wrote:
Is the 60 seconds
Author: mturk
Date: Wed Jul 19 08:51:29 2006
New Revision: 423503
URL: http://svn.apache.org/viewvc?rev=423503view=rev
Log:
Remove branch
Removed:
tomcat/tc6.0.x/branches/svn_props/
-
To unsubscribe, e-mail: [EMAIL
Hi,
I have created a branch that shows the difference between
current trunk and the new one wit correctly set
svn:eol-style and svn:executable
For example the
java/org/apache/catalina/Context.java when checked
out on linux has DOS line endings with those ugly ^M.
The same file with
Author: mturk
Date: Wed Jul 19 09:53:59 2006
New Revision: 423523
URL: http://svn.apache.org/viewvc?rev=423523view=rev
Log:
Thumbs.db is not part of the servlet spec
I suppose. Seems someone committed that from the
Windows with folder image thumbnail cache.
Removed:
On 7/19/06, Mladen Turk [EMAIL PROTECTED] wrote:
Hi,
I have created a branch that shows the difference between
current trunk and the new one wit correctly set
svn:eol-style and svn:executable
For example the
java/org/apache/catalina/Context.java when checked
out on linux has DOS line endings
Author: fhanik
Date: Wed Jul 19 10:49:47 2006
New Revision: 423544
URL: http://svn.apache.org/viewvc?rev=423544view=rev
Log:
Comet connection handling. When the response.getWriter().close() method has
been called,
the comet connection is setup for closure instead of waiting for a timeout.
This
I would support this effort, I've been nailed a few times by line
endings and them being inconsistent.
there are so many files in SVN for TC right now that have windows line
endings.
Filip
Costin Manolache wrote:
On 7/19/06, Mladen Turk [EMAIL PROTECTED] wrote:
Hi,
I have created a branch
Author: fhanik
Date: Wed Jul 19 11:03:23 2006
New Revision: 423548
URL: http://svn.apache.org/viewvc?rev=423548view=rev
Log:
Adjusted comment
Modified:
tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java
Modified:
Hi,
+1. Why wouldn't we want native line endings?
Yoav
On 7/19/06, Filip Hanik - Dev Lists [EMAIL PROTECTED] wrote:
I would support this effort, I've been nailed a few times by line
endings and them being inconsistent.
there are so many files in SVN for TC right now that have windows line
Author: fhanik
Date: Wed Jul 19 12:06:24 2006
New Revision: 423569
URL: http://svn.apache.org/viewvc?rev=423569view=rev
Log:
added bug to do
Modified:
tomcat/container/tc5.5.x/modules/groupcom/to-do.txt
Modified: tomcat/container/tc5.5.x/modules/groupcom/to-do.txt
URL:
On 7/19/06, Mladen Turk [EMAIL PROTECTED] wrote:
Committed a fix that allows to have a
worker.name.recover_time lower then 60 seconds.
Previously the minimum value was 60 seconds, and
now is 1 second.
The default is still the same (60 seconds)
Thanks that should work around my issue quite
On 7/19/06, Rainer Jung [EMAIL PROTECTED] wrote:
No, I think it's not:
1) This is not a regression, it was always implemented like that.
Really? I know it's been like this for a few releases now, but I
remember some very old versions of mod_jk (from a couple years ago?)
used to recover nearly
David Rees wrote:
On 7/19/06, Rainer Jung [EMAIL PROTECTED] wrote:
No, I think it's not:
1) This is not a regression, it was always implemented like that.
Really? I know it's been like this for a few releases now, but I
remember some very old versions of mod_jk (from a couple years ago?)
On 7/19/06, Jean-frederic Clere [EMAIL PROTECTED] wrote:
But when all your workers are down, what is the harm in trying to
recover more quicky?
Because the TC on the other side is probably busy and you may cause a
huge increase of threads (X2)... And that will not help for the recovery.
On 7/19/06, Mladen Turk [EMAIL PROTECTED] wrote:
Committed a fix that allows to have a
worker.name.recover_time lower then 60 seconds.
Previously the minimum value was 60 seconds, and
now is 1 second.
The default is still the same (60 seconds)
While the change you made allows you to configure
Author: rjung
Date: Wed Jul 19 14:45:45 2006
New Revision: 423621
URL: http://svn.apache.org/viewvc?rev=423621view=rev
Log:
Part two of: allow recovery interval below 60 seconds.
Caution: This fix for the status worker is still not complete,
since we need to be able to set the maintain time also.
Author: rjung
Date: Wed Jul 19 17:37:08 2006
New Revision: 423683
URL: http://svn.apache.org/viewvc?rev=423683view=rev
Log:
Tagging tomcat-connectors 1.2.18.
Added:
tomcat/connectors/tags/jk1.2.x/JK_1_2_18/
- copied from r423681, tomcat/connectors/trunk/
Author: rjung
Date: Wed Jul 19 18:24:27 2006
New Revision: 423695
URL: http://svn.apache.org/viewvc?rev=423695view=rev
Log:
Revert the tag, nothing yet published.
There's still a 1.2.17 in the files (iis installer).
Removed:
tomcat/connectors/tags/jk1.2.x/JK_1_2_18/
Author: rjung
Date: Wed Jul 19 18:25:33 2006
New Revision: 423697
URL: http://svn.apache.org/viewvc?rev=423697view=rev
Log:
Yet another version number to increment.
Modified:
tomcat/connectors/trunk/jk/native/iis/installer/isapi-redirector-win32-msi.ism
Modified:
Author: rjung
Date: Wed Jul 19 18:27:25 2006
New Revision: 423699
URL: http://svn.apache.org/viewvc?rev=423699view=rev
Log:
Tagging tomcat-connectors 1.2.18.
Added:
tomcat/connectors/tags/jk1.2.x/JK_1_2_18/
- copied from r423697, tomcat/connectors/trunk/
David Rees wrote:
While the change you made allows you to configure the worker to a
recover_time lower than 60 seconds, it doesn't let you change it to a
value lower than 60 using the status worker.
Still investigating, but it looks like there are a number of other
places it should be changed.
David Rees wrote:
Thanks that should work around my issue quite nicely. I'll check out
SVN and give a whirl (unless a new tag is to be rolled again shortly?)
Try 1.2.18.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For
Hi,
thanks to everyone who tested 1.2.17. We had one bug related to special
types used in the networking code. Furthermore there was one request for
enhancement we included in the next version 1.2.18.
Today this version 1.2.18 of the Apache Tomcat mod_jk web server
connector has been
50 matches
Mail list logo
