Remy Maucherat wrote:
Jason Brittain wrote:
Jason Brittain wrote:
Now, Tomcat runs. I tried the JSP examples, and they work. I'll see
about benchmarking it versus JDK 1.4.x and 1.5.x. :)
It's really bad. APR might help a little.
Surprisingly, it looked reasonable when I benchmarked it today. He
Jason Brittain wrote:
Jason Brittain wrote:
Remy Maucherat wrote:
Jason Brittain wrote:
"This release of Apache Tomcat was packaged to run on J2SE 5.0
or later. It can be run on earlier JVMs by downloading and
installing a compatibility package from the Apache Tomcat
binary download page."
means JM
Jason Brittain wrote:
Remy Maucherat wrote:
Jason Brittain wrote:
"This release of Apache Tomcat was packaged to run on J2SE 5.0
or later. It can be run on earlier JVMs by downloading and
installing a compatibility package from the Apache Tomcat
binary download page."
means JMX wasn't found, that's
Remy Maucherat wrote:
Jason Brittain wrote:
"This release of Apache Tomcat was packaged to run on J2SE 5.0
or later. It can be run on earlier JVMs by downloading and
installing a compatibility package from the Apache Tomcat
binary download page."
means JMX wasn't found, that's all.
Yes.
I did:
[EMA
Jason Brittain wrote:
"This release of Apache Tomcat was packaged to run on J2SE 5.0
or later. It can be run on earlier JVMs by downloading and
installing a compatibility package from the Apache Tomcat
binary download page."
means JMX wasn't found, that's all.
Yes.
I did:
[EMAIL PROTECTED] jakarta-
Remy Maucherat wrote:
Jason Brittain wrote:
You must not have read the paragraph in my last email that said:
"... And, this is *with* Tomcat's compat package installed properly."
Maybe there's a regression. It used to work long before 1.1.5 anyway,
I'm curious to know which version of Tomcat ran l
Jason Brittain wrote:
You must not have read the paragraph in my last email that said:
"... And, this is *with* Tomcat's compat package installed properly."
Maybe there's a regression. It used to work long before 1.1.5 anyway,
but it could be that the classpath generation using the manifest from
Remy Maucherat wrote:
Jason Brittain wrote:
Nope:
[EMAIL PROTECTED] jakarta-tomcat-5.5.9]# bin/catalina.sh start
Using CATALINA_BASE: /home/jbrittain/jakarta-tomcat-5.5.9
Using CATALINA_HOME: /home/jbrittain/jakarta-tomcat-5.5.9
Using CATALINA_TMPDIR: /home/jbrittain/jakarta-tomcat-5.5.9/temp
U
Jason Brittain wrote:
Nope:
[EMAIL PROTECTED] jakarta-tomcat-5.5.9]# bin/catalina.sh start
Using CATALINA_BASE: /home/jbrittain/jakarta-tomcat-5.5.9
Using CATALINA_HOME: /home/jbrittain/jakarta-tomcat-5.5.9
Using CATALINA_TMPDIR: /home/jbrittain/jakarta-tomcat-5.5.9/temp
Using JRE_HOME: /
Remy Maucherat wrote:
Jason Brittain wrote:
Remy Maucherat wrote:
This has been hinted for a while ;) The purpose of this email is to
propose using APR (Apache Portable Runtime) as the network IO used by
Tomcat, instead of the JVM's IO.
[snip]
Which will allow:
[snip]
- (likely) better performance
Jason Brittain wrote:
Remy Maucherat wrote:
This has been hinted for a while ;) The purpose of this email is to
propose using APR (Apache Portable Runtime) as the network IO used by
Tomcat, instead of the JVM's IO.
[snip]
Which will allow:
[snip]
- (likely) better performance and reliability on fre
Remy Maucherat wrote:
This has been hinted for a while ;) The purpose of this email is to
propose using APR (Apache Portable Runtime) as the network IO used by
Tomcat, instead of the JVM's IO.
[snip]
Which will allow:
[snip]
- (likely) better performance and reliability on free JVMs
This sounds as
Mladen Turk wrote:
Peter Lin wrote:
I've done testing on SLES9/64 with JDK5 and
current apr release from apache (apr-1.1.1).
The performance is equal or APR is slightly faster,
but what's more important is the scalability for
keep-alive connections. Now you can have hundreds of
keep-alive connectio
At last week I use very successfull the httperf load tool to simulate
sessions request.
With httperf you can generate high load and it is easy to configure.
You can configure think time between requests. But with session handling
on, we see some corrupted requests.
http://www.hpl.hp.com/personal
Peter Lin wrote:
yeah, I can do that. ... I assume if i grab the nightly for 5.5.x and
APR1.1.x I should be ready to go. In the event I need some
assistance, you going to be around Mladen :) ?
Well, not at the midnight like your post was, but I'm
sure it wasn't a midnight at your time zone :).
I'
yeah, I can do that. ... I assume if i grab the nightly for 5.5.x and
APR1.1.x I should be ready to go. In the event I need some
assistance, you going to be around Mladen :) ?
peter lin
On 4/15/05, Remy Maucherat <[EMAIL PROTECTED]> wrote:
> Peter Lin wrote:
> > I'll wait until that's fixed an
Peter Lin wrote:
I'll wait until that's fixed and then run the full set of benchmarks.
that way we'll have direct comparison.
All right, the performance is now more or less decent, and polling seems
to work. You can try testing it :)
Mladen recommends APR 1.1.
Rémy
---
Henri Gomez wrote:
I've got no problem with APR stability but availability in the correct
version for some OS, ie iSeries or ... BS2000 :)
Right there is also the thread libraries APR should use the same the JMV is
using (no always easy to find).
On 4/15/05, jean-frederic clere <[EMAIL PROTECTED]
I've got no problem with APR stability but availability in the correct
version for some OS, ie iSeries or ... BS2000 :)
On 4/15/05, jean-frederic clere <[EMAIL PROTECTED]> wrote:
> Henri Gomez wrote:
> > Well I've no problems with using APR if we could still use a pure Java
> > implementation.
> >
Henri Gomez wrote:
Well I've no problems with using APR if we could still use a pure Java
implementation.
Some may not have APR on their boxes, or an incorrect version of APR,
or an invalid APR configuration (ie not multi-threaded).
Remember mod_webapp and the reasons why it failed, ie too many peo
Well I've no problems with using APR if we could still use a pure Java
implementation.
Some may not have APR on their boxes, or an incorrect version of APR,
or an invalid APR configuration (ie not multi-threaded).
Remember mod_webapp and the reasons why it failed, ie too many peoples
couldn't get
Hi,
> Apologies if I missed it, but I've seen responses to Yoav's and Peter's
> posts,
> but I have yet to see anything about Jess' NIO question. Since I agree
> with his
> observations, I was wondering if a reponse was in the works? (I assume
> it'll say
> something like, "Yes, a Java NIO soluti
I'll wait until that's fixed and then run the full set of benchmarks.
that way we'll have direct comparison.
peter
On 4/14/05, Remy Maucherat <[EMAIL PROTECTED]> wrote:
> Peter Lin wrote:
> > if I have time this weekend, I'll try to run the same benchmarks on
> > the latest code.
> >
> > is it
Jess Holle wrote:
Overall this seems well and good as long as this is not the default in
5.5 (i.e. by default Tomcat should be pure Java and run anywhere with a
good JVM without native code).
To play devil's advocate for a moment, however, would use of Java NIO
potentially make more sense for T
, April 14, 2005 1:53 PM
To: Tomcat Developers List
Subject: Re: Tomcat and APR
Peter Lin wrote:
> if I have time this weekend, I'll try to run the same benchmarks on
> the latest code.
>
> is it included in the nightly build? if not, can someone post a build
> for me to benchmark on
Peter Lin wrote:
if I have time this weekend, I'll try to run the same benchmarks on
the latest code.
is it included in the nightly build? if not, can someone post a build
for me to benchmark on my system?
We're going to have to resolve the issue I mentioned with keepalive
before doing serious ben
if I have time this weekend, I'll try to run the same benchmarks on
the latest code.
is it included in the nightly build? if not, can someone post a build
for me to benchmark on my system?
peter
On 4/14/05, Remy Maucherat <[EMAIL PROTECTED]> wrote:
> Hi,
>
> This has been hinted for a while ;)
Yoav Shapira wrote:
Hi,
The implementation would be an alternate endpoint implementation,
replacing PoolTcpEndpoint. Alternate HTTP/1.1 processor and socket
channel (for AJP) will be provided. Development required is actually
fairly small (significant testing will be required, however). I didn't
do
Hi,
> The implementation would be an alternate endpoint implementation,
> replacing PoolTcpEndpoint. Alternate HTTP/1.1 processor and socket
> channel (for AJP) will be provided. Development required is actually
> fairly small (significant testing will be required, however). I didn't
> do the upda
Overall this seems well and good as long as this is not the default in
5.5 (i.e. by default Tomcat should be pure Java and run anywhere with a
good JVM without native code).
To play devil's advocate for a moment, however, would use of Java NIO
potentially make more sense for Tomcat, i.e. to tak
30 matches
Mail list logo
