At 04:43 AM 2/19/2005, Remy Maucherat wrote:
>William A. Rowe, Jr. wrote:
>>It definately seems like j-t-c should be a first candidate
>>for svn conversion. The other jakarta-tomcat repositories
>>are considerabily more complex.
>>But it would be good to have line endings straightened out
>>before
William A. Rowe, Jr. wrote:
It definately seems like j-t-c should be a first candidate
for svn conversion. The other jakarta-tomcat repositories
are considerabily more complex.
But it would be good to have line endings straightened out
beforehand.
I find svn quite confusing to work with. Especiall
William A. Rowe, Jr. wrote:
> It definately seems like j-t-c should be a first candidate
> for svn conversion. The other jakarta-tomcat repositories
> are considerabily more complex.
>
Yes, if everyone else agree we should consider moving to svn.
The problem is only with Tomcat build process. If a
It definately seems like j-t-c should be a first candidate
for svn conversion. The other jakarta-tomcat repositories
are considerabily more complex.
But it would be good to have line endings straightened out
beforehand.
This checkout was with the cvs Win32 client. It seems, from
all the trouble
William A. Rowe, Jr. wrote:
Here's a list of all mixed up line endings currently
in jakarta-tomcat-connectors/jk/ ...
The Mismatch'ed files all represent files with mixed line endings
(some cr/lf, some cr/cr/lf.)
Two things.
See no CRLFs for any .h or .c inisde j-t-c.
Also Bill, will you be OK a
At 12:56 PM 2/17/2005, Rainer Jung wrote:
>Hi,
>
>first: thanks a lot to Mladen for adding all the beautiful features [and
>removing CRLF :) ]. Big leap forward!
Here's a list of all mixed up line endings currently
in jakarta-tomcat-connectors/jk/ ...
The Mismatch'ed files all represent files w
Hans Schmid wrote:
Thanks, Mladen,
as long as this disabled feature does not prevent the failover case, I am fine
;)
OK. So basically you have two tomcat boxes where the second is used
only when you wish to put the first on maintenance?
Both Tomcats are always running, but the second one is used
Re: AW: mod_jk release policy - was: JK 1.2.9-dev test results
>
>
> Hans Schmid wrote:
> > Hi,
> >
> > I just want to describe our usecase because we make heavy use of the
> > local_worker and local_worker_only flags right now.
> >
>
>
> > We us
Rainer Jung wrote:
With stickyness and session id one would have:
- sticky worker (the correct one)
- failover for the preferred (your redirect)
- any other in the same replication cluster (domain)
- the rest (loose session but can start the app again from the beginning)
Your redirect concept and m
So I don't see the point of forking 1.3. Both config and core features
are the same. Of course some advanced configuration properties where
changes, lot new added, but from the outside its still old mod_jk.
OK, understood from below. I agree concerning JNI deprecation. But read
comments about loca
Hans Schmid wrote:
Hi,
I just want to describe our usecase because we make heavy use of the
local_worker and local_worker_only flags right now.
We use those flags for 'maintenance' mode and failover very successfuly.
Cool ;).
But please see our setup and usecase below.
We only use one tomcat at a
> Von: Mladen Turk [mailto:[EMAIL PROTECTED]
> Gesendet: Donnerstag, 17. Februar 2005 20:34
> An: Tomcat Developers List
> Betreff: Re: mod_jk release policy - was: JK 1.2.9-dev test results
>
>
> Rainer Jung wrote:
> > Hi,
> >
> > first: thanks a lot
Rainer Jung wrote:
Hi,
first: thanks a lot to Mladen for adding all the beautiful features [and
removing CRLF :) ]. Big leap forward!
Still, I cope with those on a daily basis.
I think that until Monday we were still in the progress of adding
features, and fixing bugs. 1.2.8 changed a lot intern
- Original Message -
From: "Mladen Turk" <[EMAIL PROTECTED]>
To: "Tomcat Developers List"
Sent: Thursday, February 17, 2005 7:27 AM
Subject: Re: JK 1.2.9-dev test results
> Henri Gomez wrote:
> > Good works Mladen.
> >
> > I found jk
Hi,
first: thanks a lot to Mladen for adding all the beautiful features [and
removing CRLF :) ]. Big leap forward!
I think that until Monday we were still in the progress of adding
features, and fixing bugs. 1.2.8 changed a lot internally, but most was
functionally compatible to 1.2.6. Release
Henri Gomez wrote:
Good works Mladen.
I found jk a bit faster and it's good to see that we could speed it up a little.
The next step could be to use larger AJP packets (4k too small)
Sure ;).
For 100K file the speed is the same, as expected.
On large files we are measuring the network throughput
no
Good works Mladen.
I found jk a bit faster and it's good to see that we could speed it up a little.
The next step could be to use larger AJP packets (4k too small)
On Thu, 17 Feb 2005 14:11:28 +0100, Mladen Turk <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Henri said that he noticed current dev version
Hi,
Henri said that he noticed current dev version
of mod_jk being quite faster then previous (1.2.8).
Although it was not the primary intention to
be faster, I think no one will object :).
So here are some benchmark results from my side:
JK 1.2.8 single thread
Requests per second:784.31 [#/sec
18 matches
Mail list logo
