You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Remy Maucherat <re...@apache.org> on 2005/04/14 20:10:43 UTC
Tomcat and APR
Hi,
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.
This will provide the following benefits (some small, others more
significant):
- zero GC IO API (APR is not object based)
- flexible handling of socket reads/writes using pollers and non blocking IO
- sendfile support
Which will allow:
- better scalability when using HTTP/1.1 keepalive, by eliminating the
need for tying a thread blocked on an IO read (one or more (one on Unix,
plenty on Windows) pollers will be used instead); this will allow
certain single machine servers which couldn't use keealive in order to
limit the amount of threads (to be able to have more simultaneous users)
to benefit from the (large) performance benefits of keepalive
- better performance and easier configuration when using AJP: one
of the issues of AJP at the moment is that the number of AJP processors
in Tomcat must be equal to the number of processors on the front end
native servers, or keepalive has to be disabled (resulting in
performance degradation); the benefit for AJP seems to actually be
greater than for HTTP (special thanks to Mladen who explained to me the
situation in detail)
- efficient static file serving (not done yet)
- (likely) better performance and reliability on free JVMs
- probably slightly better performance (over NIO, Mladen measured 10%,
while I measured 0%; as classic IO is a bit slower generally, I expect a
small improvement); unfortunately, maximum throughput suffers (maximum
throughput is measured by ab with keeplive enabled on localhost), as we
cannot just block on the read until the next request comes; the
benchmarks I use usually suck anyway ;)
- SSL support through OpenSSL (not done right now)
- access to certain useful native functions (detailed system status
information, random data generation, etc)
This would effectively make Tomcat more appealing to the lower end
servers and, hopefully, web hosting companies (due to lower resource
usage). Large sites would likely also benefit a little from the AJP
improvements.
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 updated socket channel yet, but after 3 days of hacking, HTTP
works (and the AJP stuff should be much faster to do).
Now the tricky points:
- is it appropriate for 5.5 ? I'd say yes, as it will be a separate
independent implementation
- will require APR, and a small JNI friendly wrapper library
tentatively named libtcnative by Mladen (Windows binaries - and likely
others - will be provided); portability should be good
- we'll need to improve performance (and especially fix the kludge that
is currently used to decide if a socket should be put inside a poller)
Comments ?
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Tomcat and APR
Posted by Peter Rossbach <pr...@objektpark.de>.
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/David_Mosberger/httperf.html
Peter
Mladen Turk schrieb:
> 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'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 connections without going over the thread limit.
>
> Not sure how to test that, but I suppose that test for
> standard installation should include much higher maxThreads
> value then for APR implementation.
>
> One other thing. Use some unix for Tomcat, or you will need to
> patch the APR for windows. The reason is that the APR uses
> standard windows FD_SETSIZE that is 64. I did recompile the
> apr with setting the FD_SETSIZE to 16384 before including
> winsock2.h, so we don't have that limit.
>
> I did that because I thought that unixes has unlimited FD_SETSIZE,
> but it seems that the common value is 1024, so that is probably
> our limit for now. Think that we'll need multiple Poller threads
> if higher number is required.
> Anyhow don't test more then 1024 concurrent users at the moment,
> or 64 if using vanilla APR on windows.
>
> More about testing:
> Right now the code waits for 50ms (configurable or will be) after
> the request for another keep-alive request, and then goes to the
> poller if the client didn't provide the request.
> So that would be valuable to test actually. Let's say that client
> sends each request with keep-alive in a 100+ ms rate.
> Not sure if JMeter can make a pause between the requests, but ab
> can not, and that is what we need to measure basically, since it's
> more close to the real-world then simply hitting the Tomcat in a
> loop.
>
> Regards,
> Mladen.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Tomcat and APR
Posted by Remy Maucherat <re...@apache.org>.
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 connections without going over the thread limit.
This wouldn't really happen, as keepalive gets a lot more aggressive
(ie, timeout is shorter) and keepalive is disabled when the amount of
busy threads gets too high.
However, this does put some strain on schedulers (should be ok with a
modern setup) and resource usage (allocating a thread and all its
related resources used for processing isn't insignificant, so dedicating
most of these threads to block on a read isn't that great).
The point is to allow getting the benefits of keepalive (much better
performance for page loading times and network usage) without the cost
(besides the cost of keeping a socket open which obviously cannot be
avoided). This should be good for one-machine web servers, and should
make Tomcat more appealing for that usage.
On the other end of the scalability scale, JK has issues if there are
too many frontend servers, and actually anytime the amount of processors
in Tomcat is not equal to the amount of processors on the front servers.
The only workaround for this use is to have processors timeout, but the
current implementation will be inefficient with that kind of setup.
> One other thing. Use some unix for Tomcat, or you will need to
> patch the APR for windows. The reason is that the APR uses
> standard windows FD_SETSIZE that is 64. I did recompile the
> apr with setting the FD_SETSIZE to 16384 before including
> winsock2.h, so we don't have that limit.
>
> I did that because I thought that unixes has unlimited FD_SETSIZE,
> but it seems that the common value is 1024, so that is probably
> our limit for now. Think that we'll need multiple Poller threads
> if higher number is required.
> Anyhow don't test more then 1024 concurrent users at the moment,
> or 64 if using vanilla APR on windows.
That's the only problem I can see. Could this default value be changed
unless there's a really good reason for it ? (from what I can see,
higher values work well on my Windows)
> More about testing:
> Right now the code waits for 50ms (configurable or will be) after
All the configuration should be ok now. This is the JMX view of the APR
HTTP connector.
Name: Catalina:type=ThreadPool,name=http-8080
modelerType: org.apache.tomcat.util.net.AprEndpoint
serverSocketPool: 53067816
running: true
firstReadTimeout: 100
soTimeout: 20000
threadPriority: 5
port: 8080
currentThreadsBusy: 2
soLinger: -1
maxSpareThreads: 0
maxThreads: 150
pollerSize: 512
pollTime: 100000
keepAliveCount: 0
tcpNoDelay: true
minSpareThreads: 0
daemon: true
paused: false
backlog: 100
currentThreadCount: 2
name: http-8080
- firstReadTimeout (in ms): timeout before a socket goes to the poller
- currentThreadsBusy: Number of workers doing some processing; it's
always +1 compared to what is expected as the acceptor will get a new
worker before calling accept on the server socket (so that there's no
chance that an accepted socket could wait for a worker to become available)
- pollerSize: Maximum amount of sockets which can be placed in the
poller, which means the amount of connections which can be keptalive
(previously, each one of these would have used a thread)
- keepAliveCount: Number of sockets currently in the poller
- pollTime (in microseconds): timeout for the poll call
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Tomcat and APR
Posted by Mladen Turk <mt...@apache.org>.
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'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 connections without going over the thread limit.
Not sure how to test that, but I suppose that test for
standard installation should include much higher maxThreads
value then for APR implementation.
One other thing. Use some unix for Tomcat, or you will need to
patch the APR for windows. The reason is that the APR uses
standard windows FD_SETSIZE that is 64. I did recompile the
apr with setting the FD_SETSIZE to 16384 before including
winsock2.h, so we don't have that limit.
I did that because I thought that unixes has unlimited FD_SETSIZE,
but it seems that the common value is 1024, so that is probably
our limit for now. Think that we'll need multiple Poller threads
if higher number is required.
Anyhow don't test more then 1024 concurrent users at the moment,
or 64 if using vanilla APR on windows.
More about testing:
Right now the code waits for 50ms (configurable or will be) after
the request for another keep-alive request, and then goes to the
poller if the client didn't provide the request.
So that would be valuable to test actually. Let's say that client
sends each request with keep-alive in a 100+ ms rate.
Not sure if JMeter can make a pause between the requests, but ab
can not, and that is what we need to measure basically, since it's
more close to the real-world then simply hitting the Tomcat in a
loop.
Regards,
Mladen.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Tomcat and APR
Posted by Peter Lin <wo...@gmail.com>.
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 <re...@apache.org> wrote:
> 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Tomcat and APR
Posted by Remy Maucherat <re...@apache.org>.
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
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Tomcat and APR
Posted by Peter Lin <wo...@gmail.com>.
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 <re...@apache.org> wrote:
> 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 benchmarking.
>
> If you're on Linux, then it should be easy to test: build APR (I'll let
> Mladen precise any version requirement), and then build the native stuff
> in j-t-c/jni. Then make sure both libs are available to the JVM. APR is
> more portable than certified JVMs at the moment, although gcj-4 looks to
> be a big improvement (although not certified).
>
> Then use protocol="org.apache.coyote.http11.Http11AprProtocol" on the
> connector element.
>
> Rémy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Tomcat and APR
Posted by Remy Maucherat <re...@apache.org>.
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 benchmarking.
If you're on Linux, then it should be easy to test: build APR (I'll let
Mladen precise any version requirement), and then build the native stuff
in j-t-c/jni. Then make sure both libs are available to the JVM. APR is
more portable than certified JVMs at the moment, although gcj-4 looks to
be a big improvement (although not certified).
Then use protocol="org.apache.coyote.http11.Http11AprProtocol" on the
connector element.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Tomcat and APR
Posted by Peter Lin <wo...@gmail.com>.
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 <re...@apache.org> wrote:
> Hi,
>
> 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.
>
> This will provide the following benefits (some small, others more
> significant):
> - zero GC IO API (APR is not object based)
> - flexible handling of socket reads/writes using pollers and non blocking IO
> - sendfile support
>
> Which will allow:
> - better scalability when using HTTP/1.1 keepalive, by eliminating the
> need for tying a thread blocked on an IO read (one or more (one on Unix,
> plenty on Windows) pollers will be used instead); this will allow
> certain single machine servers which couldn't use keealive in order to
> limit the amount of threads (to be able to have more simultaneous users)
> to benefit from the (large) performance benefits of keepalive
> - better performance and easier configuration when using AJP: one
> of the issues of AJP at the moment is that the number of AJP processors
> in Tomcat must be equal to the number of processors on the front end
> native servers, or keepalive has to be disabled (resulting in
> performance degradation); the benefit for AJP seems to actually be
> greater than for HTTP (special thanks to Mladen who explained to me the
> situation in detail)
> - efficient static file serving (not done yet)
> - (likely) better performance and reliability on free JVMs
> - probably slightly better performance (over NIO, Mladen measured 10%,
> while I measured 0%; as classic IO is a bit slower generally, I expect a
> small improvement); unfortunately, maximum throughput suffers (maximum
> throughput is measured by ab with keeplive enabled on localhost), as we
> cannot just block on the read until the next request comes; the
> benchmarks I use usually suck anyway ;)
> - SSL support through OpenSSL (not done right now)
> - access to certain useful native functions (detailed system status
> information, random data generation, etc)
>
> This would effectively make Tomcat more appealing to the lower end
> servers and, hopefully, web hosting companies (due to lower resource
> usage). Large sites would likely also benefit a little from the AJP
> improvements.
>
> 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 updated socket channel yet, but after 3 days of hacking, HTTP
> works (and the AJP stuff should be much faster to do).
>
> Now the tricky points:
> - is it appropriate for 5.5 ? I'd say yes, as it will be a separate
> independent implementation
> - will require APR, and a small JNI friendly wrapper library
> tentatively named libtcnative by Mladen (Windows binaries - and likely
> others - will be provided); portability should be good
> - we'll need to improve performance (and especially fix the kludge that
> is currently used to decide if a socket should be put inside a poller)
>
> Comments ?
>
> Rémy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Tomcat and APR
Posted by Remy Maucherat <re...@apache.org>.
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 Tomcat, i.e. to take a step forward in
> terms of performance, etc, without requiring native code? [I'm not
> saying NIO covers all the bases APR would or is as fast. Rather
> wondering whether performance efforts should not remain in the pure Java
> space until that is truly exhausted.]
Yes, and the grass is always greener on the other side of the fence.
For doing the same thing, it seems that APR is about as fast as NIO, and
the API is really simple to use, with a trivial programming model. NIO
has its uses, and is definitely a lot more "engineered".
What I hope is that the introduction of APR for the networking stack
makes Tomcat sort of a Java Apache HTTP Server, which would make it more
acceptable in production.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Tomcat and APR
Posted by Jess Holle <je...@ptc.com>.
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 take a step forward in
terms of performance, etc, without requiring native code? [I'm not
saying NIO covers all the bases APR would or is as fast. Rather
wondering whether performance efforts should not remain in the pure Java
space until that is truly exhausted.]
--
Jess Holle
Remy Maucherat wrote:
> Hi,
>
> 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.
>
> This will provide the following benefits (some small, others more
> significant):
> - zero GC IO API (APR is not object based)
> - flexible handling of socket reads/writes using pollers and non
> blocking IO
> - sendfile support
>
> Which will allow:
> - better scalability when using HTTP/1.1 keepalive, by eliminating the
> need for tying a thread blocked on an IO read (one or more (one on Unix,
> plenty on Windows) pollers will be used instead); this will allow
> certain single machine servers which couldn't use keealive in order to
> limit the amount of threads (to be able to have more simultaneous users)
> to benefit from the (large) performance benefits of keepalive
> - better performance and easier configuration when using AJP: one
> of the issues of AJP at the moment is that the number of AJP processors
> in Tomcat must be equal to the number of processors on the front end
> native servers, or keepalive has to be disabled (resulting in
> performance degradation); the benefit for AJP seems to actually be
> greater than for HTTP (special thanks to Mladen who explained to me the
> situation in detail)
> - efficient static file serving (not done yet)
> - (likely) better performance and reliability on free JVMs
> - probably slightly better performance (over NIO, Mladen measured 10%,
> while I measured 0%; as classic IO is a bit slower generally, I expect
> a small improvement); unfortunately, maximum throughput suffers
> (maximum throughput is measured by ab with keeplive enabled on
> localhost), as we cannot just block on the read until the next request
> comes; the benchmarks I use usually suck anyway ;)
> - SSL support through OpenSSL (not done right now)
> - access to certain useful native functions (detailed system status
> information, random data generation, etc)
>
> This would effectively make Tomcat more appealing to the lower end
> servers and, hopefully, web hosting companies (due to lower resource
> usage). Large sites would likely also benefit a little from the AJP
> improvements.
>
> 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 updated socket channel yet, but after 3 days of hacking, HTTP
> works (and the AJP stuff should be much faster to do).
>
> Now the tricky points:
> - is it appropriate for 5.5 ? I'd say yes, as it will be a separate
> independent implementation
> - will require APR, and a small JNI friendly wrapper library
> tentatively named libtcnative by Mladen (Windows binaries - and likely
> others - will be provided); portability should be good
> - we'll need to improve performance (and especially fix the kludge
> that is currently used to decide if a socket should be put inside a
> poller)
>
> Comments ?
>
> Rémy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Tomcat 5.5.9 runs on Kaffe 1.1.5 (was Re: Tomcat and APR)
Posted by Jason Brittain <ja...@brittainweb.org>.
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. Here
are the results:
Kaffe 1.1.5
250 users -- 205/sec throughput, 3.3 average, 0% error
500 users -- 307/sec throughput, 11.4 average, 0% error
1000 users -- 325/sec throughput, 370.7 average, 0% error
2000 users -- 138/sec throughput, 3048.8 average, 0% error
JDK 1.5.0
250 users -- 204/sec throughput, 2.8 average, 0% error
500 users -- 307/sec throughput, 42.2 average, 0% error
1000 users -- 390/sec throughput, 124.1 average, 0% error
2000 users -- 294/sec throughput, 130.8 average, 0% error
When the concurrency was high, Kaffe was quite a bit slower. But,
at the low end, it seems to keep up with Sun JDK 1.5.0 just fine.
I did see some problems though: several webapps I tried didn't work
due to random misc JVM problems in Kaffe. It's still looking a bit
incompletely implemented.
For the above test, I used jmeter CVS HEAD with Peter Lin's concurrent1
test plan (from http://cvs.apache.org/~woolfel/native_testplans.zip),
modified for my box's IP address, and to request /tomcat.gif.
The tested box is a Fedora Core 2 x86 32 box (running Tocmat 5.5.9).
The tester box is a Fedora Core 3 x86 32 box (running jmeter).
Remy: Maybe the slowness you saw with kaffe is on win32?
--
Jason Brittain
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Tomcat 5.5.9 runs on Kaffe 1.1.5 (was Re: Tomcat and APR)
Posted by Remy Maucherat <re...@apache.org>.
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 JMX wasn't found, that's all.
>
>
> Okay, I confirmed at least one way to make Tomcat 5.5.9 run on Kaffe 1.1.5.
> Adding the jmx.jar to the Kaffe's boot classpath works:
>
> # export CATALINA_BASE=/home/$USER/jakarta-tomcat-5.5.9
> # export CATALINA_OPTS="-Xbootclasspath/p:$CATALINA_BASE/bin/jmx.jar"
> # cd $CATALINA_BASE
> # bin/catalina.sh start
>
> 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.
With gij 4.0.0, you can do gij -jar ./bin/bootstrap.jar
gcjing select parts should make it much faster, but I'm lazy and didn't try.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Tomcat 5.5.9 runs on Kaffe 1.1.5 (was Re: Tomcat and APR)
Posted by Jason Brittain <ja...@brittainweb.org>.
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 all.
Okay, I confirmed at least one way to make Tomcat 5.5.9 run on Kaffe 1.1.5.
Adding the jmx.jar to the Kaffe's boot classpath works:
# export CATALINA_BASE=/home/$USER/jakarta-tomcat-5.5.9
# export CATALINA_OPTS="-Xbootclasspath/p:$CATALINA_BASE/bin/jmx.jar"
# cd $CATALINA_BASE
# bin/catalina.sh start
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. :)
Thanks for the help Remy.
--
Jason Brittain
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Tomcat and APR
Posted by Jason Brittain <ja...@brittainweb.org>.
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:
>>
>> [root@localhost jakarta-tomcat-5.5.9]# export
>> CLASSPATH=/home/jbrittain/jakarta-tomcat-5.5.9/bin/jmx.jar
>>
>> and then started it again, and it still didn't find JMX (same message
>> in catalina.out). If that's what you meant, it didn't work.
>
> CLASSPATH is obviously ignored. This has been like that for years.
At first I thought that was the case, so I had a brief look in 5.5.9's
catalina.sh script and found this:
# Add on extra jar files to CLASSPATH
if [ -n "$JSSE_HOME" ]; then
CLASSPATH="$CLASSPATH":"$JSSE_HOME"/lib/jcert.jar:"$JSSE_HOME"/lib/jnet.jar:"$JSSE_HOME"/lib/jsse.jar
fi
CLASSPATH="$CLASSPATH":"$CATALINA_HOME"/bin/bootstrap.jar:"$CATALINA_HOME"/bin/commons-logging-api.jar
... which is used farther down like:
"$_RUNJAVA" $JAVA_OPTS $CATALINA_OPTS \
-Djava.endorsed.dirs="$JAVA_ENDORSED_DIRS" -classpath "$CLASSPATH" \
...
It must not have the effect on the JVM that I thought it may.
So then to what classpath should I add jmx.jar?
--
Jason Brittain
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Tomcat and APR
Posted by Remy Maucherat <re...@apache.org>.
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:
>
> [root@localhost jakarta-tomcat-5.5.9]# export
> CLASSPATH=/home/jbrittain/jakarta-tomcat-5.5.9/bin/jmx.jar
>
> and then started it again, and it still didn't find JMX (same message
> in catalina.out). If that's what you meant, it didn't work.
CLASSPATH is obviously ignored. This has been like that for years.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Tomcat and APR
Posted by Jason Brittain <ja...@brittainweb.org>.
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 like that. I've tried
more than a few versions.
> but it could be that the classpath generation using the manifest from
> JARs doesn't work (it does in gij, where you can do a -jar
> bin/boostrap.jar). So add jmx.jar and tomcat-juli.jar to the classpath
> to fix it.
Just so you know, I unjarred bootstrap.jar (from 5.5.9) and here's what
the manifest looks like:
[root@localhost bootstrap]# cat META-INF/MANIFEST.MF
Manifest-Version: 1.0
Ant-Version: Apache Ant 1.6.2
Created-By: 1.4.2_06-b03 (Sun Microsystems Inc.)
Main-Class: org.apache.catalina.startup.Bootstrap
Specification-Title: Catalina
Specification-Version: 1.0
Class-Path: jmx.jar commons-daemon.jar commons-logging-api.jar tomcat-
juli.jar
Notice the "tomcat-\r juli.jar" in there!
> "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:
[root@localhost jakarta-tomcat-5.5.9]# export CLASSPATH=/home/jbrittain/jakarta-tomcat-5.5.9/bin/jmx.jar
and then started it again, and it still didn't find JMX (same message
in catalina.out). If that's what you meant, it didn't work.
--
Jason Brittain
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Tomcat and APR
Posted by Remy Maucherat <re...@apache.org>.
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
JARs doesn't work (it does in gij, where you can do a -jar
bin/boostrap.jar). So add jmx.jar and tomcat-juli.jar to the classpath
to fix it.
"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.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Tomcat and APR
Posted by Jason Brittain <ja...@brittainweb.org>.
Remy Maucherat wrote:
> Jason Brittain wrote:
>
>> Nope:
>>
>> [root@localhost 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: /usr/local/kaffe
>>
>> [root@localhost jakarta-tomcat-5.5.9]# cd logs
>> [root@localhost logs]# more catalina.out
>> WARNING: System property "java.util.logging.manager" should be the
>> name of a subclass of java.util.logging.LogManager
>
> If for some reason the java.util.logging impl isn't compatible with
> classpath, remove it (delete tomcat-juli.jar).
Okay. I did that, and tried it again. Now it doesn't give that warning, but
Tomcat still fails to run in the same way.
> For the rest, install the compat package.
You must not have read the paragraph in my last email that said:
"... And, this is *with* Tomcat's compat package installed properly."
--
Jason Brittain
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Tomcat and APR
Posted by Remy Maucherat <re...@apache.org>.
Jason Brittain wrote:
> Nope:
>
> [root@localhost 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: /usr/local/kaffe
>
> [root@localhost jakarta-tomcat-5.5.9]# cd logs
> [root@localhost logs]# more catalina.out
> WARNING: System property "java.util.logging.manager" should be the name
> of a subclass of java.util.logging.LogManager
If for some reason the java.util.logging impl isn't compatible with
classpath, remove it (delete tomcat-juli.jar).
For the rest, install the compat package.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Tomcat and APR
Posted by Jason Brittain <ja...@brittainweb.org>.
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 and reliability on free JVMs
>>
>> This sounds as though you're implying that Tomcat already runs on one or
>> more free JVM. Which ones? And, any particular version?
>
> gij-4.0 (so gcjing portions should work),
I haven't tried this one yet. It'll require some time to set up properly.
>kaffe 1.1.5,
Nope:
[root@localhost 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: /usr/local/kaffe
[root@localhost jakarta-tomcat-5.5.9]# cd logs
[root@localhost logs]# more catalina.out
WARNING: System property "java.util.logging.manager" should be the name of a subclass of java.util.logging.LogManager
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.
[root@localhost logs]# java -version
Kaffe Virtual Machine
Copyright (c) 1996-2004 Kaffe.org project contributors (please see
the source code for a full list of contributors). All rights reserved.
Portions Copyright (c) 1996-2002 Transvirtual Technologies, Inc.
The Kaffe virtual machine is free software, licensed under the terms of
the GNU General Public License. Kaffe.org is a an independent, free software
community project, not directly affiliated with Transvirtual Technologies,
Inc. Kaffe is a Trademark of Transvirtual Technologies, Inc. Kaffe comes
with ABSOLUTELY NO WARRANTY.
Engine: Just-in-time v3 Version: 1.1.5 Java Version: 1.1
... And, this is *with* Tomcat's compat package installed properly. This may
just be a bug in Tomcat's J2SE 5.0 detection code (bad expectations w.r.t. free
JVMs?). Or, maybe kaffe just doesn't implement what we know we need? Either
way, it doesn't work.
> probably others.
I wish I knew. None have worked so far for me.
[snip]
> Well, if you try the only VM which doesn't work ;)
No, like I said, I tried several brands & versions.
--
Jason Brittain
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Tomcat and APR
Posted by Remy Maucherat <re...@apache.org>.
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 free JVMs
>
> This sounds as though you're implying that Tomcat already runs on one or
> more free JVM. Which ones? And, any particular version?
gij-4.0 (so gcjing portions should work), kaffe 1.1.5, probably others.
> All of them that I have tried can't run Tomcat. Before, it was just that
> they each used the GNU Classpath core classes, which were (still are?) too
> incomplete, and even though the required classes were found and loaded,
> they
> were either incomplete (missing some methods for instance), or they were
> wrong
> somehow and caused random fatal startup problems. Most of the problems
> seemed
> to have to do with either reflection or JMX or both. Here's how my last
> attempt
> went (SableVM Version 1.1.10):
>
> [root@localhost jakarta-tomcat-5.5.8-with-compat]# java-sablevm
> -Djava.endorsed.dirs=/home/jbrittain/jakarta-tomcat-5.5.8-with-compat/common/endorsed
> -classpath
> :/home/jbrittain/jakarta-tomcat-5.5.8-with-compat/bin/bootstrap.jar:/home/jbrittain/jakarta-tomcat-5.5.8-with-compat/bin/commons-logging-api.jar
> -Dcatalina.base=/home/jbrittain/jakarta-tomcat-5.5.8-with-compat
> -Dcatalina.home=/home/jbrittain/jakarta-tomcat-5.5.8-with-compat
> -Djava.io.tmpdir=/home/jbrittain/jakarta-tomcat-5.5.8-with-compat/temp
> org.apache.catalina.startup.Bootstrap start Created MBeanServer with ID:
> [UID: 8594076,1109751203829,-32768]:localhost.localdomain:1
> java.lang.IllegalArgumentException: argument of incorrect type
> at java.lang.reflect.Method.invoke (Method.java:461)
> at org.apache.catalina.startup.Bootstrap.setAwait (Bootstrap.java:337)
> at org.apache.catalina.startup.Bootstrap.main (Bootstrap.java:407)
> at java.lang.VirtualMachine.invokeMain (VirtualMachine.java)
> at java.lang.VirtualMachine.main (VirtualMachine.java:108)
>
> So, I'm still looking for even one free/OSS JVM that is capable of
> running Tomcat.
Well, if you try the only VM which doesn't work ;)
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Tomcat and APR
Posted by Jason Brittain <ja...@brittainweb.org>.
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 though you're implying that Tomcat already runs on one or
more free JVM. Which ones? And, any particular version?
All of them that I have tried can't run Tomcat. Before, it was just that
they each used the GNU Classpath core classes, which were (still are?) too
incomplete, and even though the required classes were found and loaded, they
were either incomplete (missing some methods for instance), or they were wrong
somehow and caused random fatal startup problems. Most of the problems seemed
to have to do with either reflection or JMX or both. Here's how my last attempt
went (SableVM Version 1.1.10):
[root@localhost jakarta-tomcat-5.5.8-with-compat]# java-sablevm -Djava.endorsed.dirs=/home/jbrittain/jakarta-tomcat-5.5.8-with-compat/common/endorsed -classpath :/home/jbrittain/jakarta-tomcat-5.5.8-with-compat/bin/bootstrap.jar:/home/jbrittain/jakarta-tomcat-5.5.8-with-compat/bin/commons-logging-api.jar -Dcatalina.base=/home/jbrittain/jakarta-tomcat-5.5.8-with-compat -Dcatalina.home=/home/jbrittain/jakarta-tomcat-5.5.8-with-compat -Djava.io.tmpdir=/home/jbrittain/jakarta-tomcat-5.5.8-with-compat/temp org.apache.catalina.startup.Bootstrap start Created MBeanServer with ID: [UID: 8594076,1109751203829,-32768]:localhost.localdomain:1
java.lang.IllegalArgumentException: argument of incorrect type
at java.lang.reflect.Method.invoke (Method.java:461)
at org.apache.catalina.startup.Bootstrap.setAwait (Bootstrap.java:337)
at org.apache.catalina.startup.Bootstrap.main (Bootstrap.java:407)
at java.lang.VirtualMachine.invokeMain (VirtualMachine.java)
at java.lang.VirtualMachine.main (VirtualMachine.java:108)
So, I'm still looking for even one free/OSS JVM that is capable of
running Tomcat.
--
Jason Brittain
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Tomcat and APR
Posted by Remy Maucherat <re...@apache.org>.
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 the updated socket channel yet, but after 3 days of hacking, HTTP
>>works (and the AJP stuff should be much faster to do).
>
> If it's truly independent, with an alternative PoolTcpEndpoint java class
> and some additional dependencies (APR and the specific JNI wrapper), then
> +1.
Yes, it is fully independent. I did end up modifying the Processor
interface in coyote, but I think it is a useless interface. That's it.
> At least for the first few releases, users should have the choice to use
> this technology, and not have it be required. I think that's what you meant
> anyways, just stating it for clarity.
I don't think it can ever be required. We'll see.
> We can call it "experimental," advertise it, and get 3rd party (e.g. Peter
> Lin) benchmarks. It'd be a very nice selling point to have a non-blocking
> IO option ;)
Since the API stays really simple, you can go crazy on non blocking stuff.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
RE: Tomcat and APR
Posted by Yoav Shapira <yo...@MIT.EDU>.
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 updated socket channel yet, but after 3 days of hacking, HTTP
> works (and the AJP stuff should be much faster to do).
If it's truly independent, with an alternative PoolTcpEndpoint java class
and some additional dependencies (APR and the specific JNI wrapper), then
+1.
At least for the first few releases, users should have the choice to use
this technology, and not have it be required. I think that's what you meant
anyways, just stating it for clarity.
We can call it "experimental," advertise it, and get 3rd party (e.g. Peter
Lin) benchmarks. It'd be a very nice selling point to have a non-blocking
IO option ;)
> - is it appropriate for 5.5 ? I'd say yes, as it will be a separate
> independent implementation
I'd also say yes.
Yoav
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org