AW: mod_jk / Ajp13 config fix on heavily loaded system
what's about loadbalancing? say, we have defined local loadbalancing using 5 ajp13-worker at workers.properties, and we have at server.xml: Ajp13Connector port=8009 maxThreads=100 maxSpareThreads=50 minSpareThreads=10 / Does this mean, we can support through the loadbalancer 100 threads or 500 threads (100 * number of workers(5) = 500)? b.t.w, another question: when using local loadbalancing, does every worker has its own VM or are they sharing all the same VM? thank you, sebastian -Ursprüngliche Nachricht- Von: GOMEZ Henri [mailto:[EMAIL PROTECTED]] Gesendet: Dienstag, 13. November 2001 23:45 An: Tomcat Developers List Cc: [EMAIL PROTECTED] Betreff: mod_jk / Ajp13 config fix on heavily loaded system Hi to all, Some of you may have experienced problems on heavily loaded system with mod_jk and Tomcat 3.2/3.3 when using ajp13. As you may know, the Ajp13 connection is permanent and is created each time a WebServer task, for example an Apache child, have to forward a request to Tomcat. And in Apache server case, the child will stay alive, until the client requests load decrease, or when a child have passed 1000 requests (MaxRequestsPerChild 1000). And till the child close the connection, the Tomcat thread stay alive. By default Apache server support up to 150 childs : (MaxClients 150 in httpd.conf) But by default, the Ajp13 Interceptor won't use more than 100 threads, so you're stuck when the 101th Apache child want to forward a request and see the following infamous trace in mod_jk.log : [wed oct 31 11:03:21 2001] [jk_ajp13_worker.c (196)]: In jk_endpoint_t::connect_to_tomcat, failed errno = 111 [wed oct 31 11:03:21 2001] [jk_ajp13_worker.c (635)]: Error connecting to the Tomcat process. [wed oct 31 11:03:21 2001] [jk_ajp13_worker.c (848)]: In jk_endpoint_t::service, send_request failed in send loop 2 [wed oct 31 11:03:21 2001] [jk_ajp13_worker.c (228)]: connection_tcp_get_message: Error - jk_tcp_socket_recvfull failed [wed oct 31 11:03:21 2001] [jk_ajp13_worker.c (712)]: Error reading reply [wed oct 31 11:03:21 2001] [jk_ajp13_worker.c (845)]: In jk_endpoint_t::service, get_reply failed in send loop 0 [wed oct 31 11:03:21 2001] [jk_connect.c (143)]: jk_open_socket, connect() failed errno = 111 [wed oct 31 11:03:21 2001] [jk_ajp13_worker.c (196)]: In jk_endpoint_t::connect_to_tomcat, failed errno = 111 [wed oct 31 11:03:21 2001] [jk_ajp13_worker.c (635)]: Error connecting to the Tomcat process. In some case, Apache could be able to connect, since Tomcat listening thread will accept incoming connection, but will drop it later if it fail to give the socket to a new thread. In that case you'll see only in log : [wed oct 31 11:03:21 2001] [jk_ajp13_worker.c (848)]: In jk_endpoint_t::service, send_request failed in send loop 2 [wed oct 31 11:03:21 2001] [jk_ajp13_worker.c (228)]: connection_tcp_get_message: Error - jk_tcp_socket_recvfull failed [wed oct 31 11:03:21 2001] [jk_ajp13_worker.c (712)]: Error reading reply Fortunatly, the fix is easy, just configure Ajp13Connector in server.xml to support up to 150 threads (or whatever you define as MaxClients in Apache, didn't know how on IIS/iPlanet). Ajp13Connector port=8009 maxThreads=150 maxSpareThreads=50 minSpareThreads=10 / Also you should take care of the number of descriptors opened in your webapplication, which is : Tomcat used descriptors (sockets, files) + YouWebApp descriptors (files, sockets, jdbc...) The JVM, like any others process have a limit on the number of descriptors it could open (and of course on number of threads). So take care of closing no more used socket, files and so on. - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Portable SSL Support
Eric Rescorla wrote:
[EMAIL PROTECTED] writes:
Setting the socketFactory can force one behavior or another, but for
'regular' users it should be possible to just set secure and the code
to detect what is available and use it.
I can do this.
IMHO it's a mistake to rely on that behavior since it's kind of a
misfeature in JSSE and this is already a problem with PureTLS, which
does throw exceptions when the handshake fails. In the future Either
PoolTcpEndpoint will have to be more forgiving or we'll need to wrap
the socket so that it throws SocketException (which acceptSocket
handles more cleanly).
One simple workaround could be to abstract acceptSocket() too ( i.e. make
it a method in ServerSocketFactory or SSLSupport).
Yes, we could do that. It's a little ugly but it avoids having a wrapper
class around ServerSocket so I suppose it's worthwhile.
Does implAccept play something there?
A don't like this either ( and I didn't like too much the idea
of returning a socket that implements SSLSupport either ).
What I would do is:
SSLSupport {
String getFoo( Object socket, ... );
}
This makes me very nervous since the first thing you have to do is
a downcast. I hate downcasts. (Except when I love them :)
- PoolTcpConnector will just have a method 'setSSLSupport'
- SSLSupport will be an abstract class, and will contain code to do
reflection and create the exact implementation
- Code using SSL will call SSLSupport.getSSLSupport() ( and maybe
setProperty, etc ), then set it on PoolTcpConnector ( if sockets are
used), etc.
- SSLSupport should be independent of tomcat ( you may noticed that
tomcat.util is compiled without any other tomcat class in classpath,
i.e. it can't have any dependencies on any internal tomcat class ! )
Hmm... This seems like a kind of confusing merging of internal and
external interfaces. (The internal ones being the ones required to
create the socket factories and the external ones being those required to
manipulate the SSL data.)
I'm (more than) happy to replace SSLFactory at the external interface but
I don't like merging SSLSupport into the external class. So, using
another layer of abstraction.
interface SSLSupport {
public String getCipherSuite();
...
}
abstract class SSLImplementation {
static getInstance(); // Automatically picks out whatever there is
static getInstance(String classname); // gets a specific instance
SocketFactory getSocketFactory();
SSLSupport getSSLSupport(Socket sock);
}
class JSSEImplementation extends SSLImplementation {
...
}
class PureTLSImplementation extends SSLImplementation {
...
}
In general I'd expect SSLSupport to be implemented as a wrapper class.
E.g. a prototype PureTLSSSLSupport would be:
class PureTLSSSLSupport implements SSLSupport {
SSLSocket ssl;
PureTLSSSLSupport(SSLSocket s){
ssl=s;
}
public string getCipherSuite() {
int cipherSuite=ssl.getCipherSuite();
return SSLPolicyInt.getCipherSuiteame(cipherSuite);
}
...
}
Then the user can either do secure or secure and SSLImplementation=blah.
BTW, my personal preference is to avoid too many interfaces - in general I
prefer abstract classes if it is possible.
I have some of the same taste as well, but I want to use an interface for
SSLSupport to allow the possibility of not having wrapper classes
in some situations.
That said, having lots of interfaces does seem to be the Java way, no?
(Worse yet, I've been switching back and forth between Java and C++ so
I suffer from idiom inertia.)
-Ekr
--
[Eric Rescorla [EMAIL PROTECTED]]
http://www.rtfm.com/
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat: Distributed Session Management revisited
- Original Message - From: [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Wednesday, November 14, 2001 12:26 AM Subject: Re: Tomcat: Distributed Session Management revisited On Tue, 13 Nov 2001, Mika Goeckel wrote: I completely agree, that the API lacks proactive support for things in the background that may fail. But given the fact, that we support a reference implementation which has managed to provide really professional services to users (other ref implementations are just for demonstration, nobody would use them in production) and there are (commercial) solutions, that provide session fail-over in the limitations of this API, we **must** try to provide a Well, the cool thing about open source is that we _don't_ need to implement all the bloat that commercial solution have. Costin, I don't disagree with your opinion. We don't need to, because we work on a voluntary base. But don't you think that having the option to provide better or at least equally professional solutions is a good motivation? solution. The API does not specify, how often the container may try to provide that service or what means it utilizes to do that. Nothing is 100% and I think it is better to live with the uncertaincy we discuss here than with the more likely problem that an instance fails and there is no potential replacement. I think it's better to live with the certaincy that everything can ( and will ) fail and tomcat can't change this. The alternative is to give users the impression the data he puts in a session will be safe - and he may rely on that instead of using a transaction and a real API. Databases, EJB, etc are complex - but there's a reason to that. Well, we could argue about how much compexity is actually needed, but one thing is certain ( I hope ) - get/setAttribute is not enough, if you want data integrity you must use a different API ( in particular transactions ). Byte-comparison is not the worst solution. If we think about differential updates, byte comparison is a good candiate for that and surplus one that promises good performance. Byte compare every 5 seconds every object in session ? Let's say you just displayed the confirmation and charged the credit card, but the machine crashed just before you sent the order. ( or reverse - you sent it but didn't charged the credit card ). This should happen in below 5 seconds. Yep, but a single stand-alone instance is not invulnerable to that scenario. In fact a thoroughly designed cluster gives better chances. If the user wants to place things in a session that she does not need to be replicated, she has the option to declare them transient and write a getter that checks if the Attribute is present, otherwise reconstructs it (in the case of a picture, reloads it from disk). The user has the choice to design for performance or ease. We only need to document the options. So the user should change all his objects to implement some arbitrary pattern just to fit this into our solution ? What if the object is not user defined ( like most are ) ? Well, we have to create wrappers for each objects you store in a session. Try to explain this on tomcat-user ( or tomcat-dev ) ... If the only alternatice is to use a professional EJB server, he would need to change them as well. I don't say he has to mark these values transient, it's only an option. And transient is not an arbitrary option, it's core java since JLS1.1 (1998). Sessions have always been somewhat fragile, but as the container is free to use transactions when the session is passed to another instance, at least that can be made secure enough. So the guarantee to the user of the container would not be made weaker. If the transaction fails, the session stays with the JVM where it originally was. The fail-over functionality would not be possible, but the situation to the app-developer would stay stable. I think that the documentation must clearly communicate to app-developers the risks and shortfalls of a distributed application and then let them choose by themselves what best meets their requirements. Mika -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 3509] -
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3509. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3509 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] Summary|Apache 1.3.20 mod_webapp | |Tomcat 4b7 HANGS| -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Building mod_webapp on Solaris 8
Matt Goyer wrote: Add -R/path/to/gcc-3.0/lib to your LDFLAGS. Where exactly? (axps, tomcat, or apache?) In mod_webapp before the configure LDFLAGS=-R/path/to/gcc-3.0/lib \ ./configure --the_option_you_used_before Thanks, Matt -Original Message- From: Justin Erenkrantz [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 13, 2001 2:11 PM To: Tomcat Developers List Subject: Re: Building mod_webapp on Solaris 8 On Tue, Nov 13, 2001 at 01:55:51PM -0500, Matt Goyer wrote: I'm also having the same problem with libgcc when I try and build and compile my own mod_jk. Any pointers on where libgcc should be so that Apache/mod_xx finds it would be appreciated. Add -R/path/to/gcc-3.0/lib to your LDFLAGS. And this is the error I get when trying the pre-compiled mod_webapp for Solaris 8: Syntax error on line 206 of /usr/local/apache/conf/httpd.conf: Cannot load /usr/local/apache/libexec/mod_webapp.so into server: ld.so.1: /usr/local/apache/bin/httpd: fatal: relocation error: file /usr/local/apache/libexec/mod_webapp.so: symbol __lshrdi3: referenced symbol not found This is a known bug when mixing the Forte (Sun) compiler with GCC. You must compile Apache and mod_webapp with the same compiler. JF just checked in a patch to j-t-c that will detect this when building from source. -- justin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
AW: Tomcat: Distributed Session Management revisited
Hi all, I agree with both of you, but I can state that our developers love to work with TOMCAT and APACHE and I would like to suggest to implement failover- and loadbalacing techniques although not required by the specs. We've started with NAS/iPlanet and EJBs two years ago. Now we are developing with JSPs and SERVLETs 'only' (due to performance constraints) and our developers want us to use TC in production as well. I can only support that if we will be able to cluster TC and have session failover as well. TC is easy to work with, easy to understand and 100% spec. compliant what iPlanet for example isn't (at the moment). Will TC evolve in that direction in future or will it stay an impressive spec. reference ? Thanks for any comments ! Oliver AXA eSolutions GmbH AXA Konzern AG Germany Oliver Lauer Web Architect Wörthstraße 34 D-50668 Köln Germany Tel.: +49 221 148 31277 Fax: +49 221 148 43963 Mobil: +49 179 59 064 59 e-Mail: [EMAIL PROTECTED] _ -Ursprüngliche Nachricht- Von: Mika Goeckel [mailto:[EMAIL PROTECTED]] Gesendet: Mittwoch, 14. November 2001 11:26 An: Tomcat Developers List Betreff: Re: Tomcat: Distributed Session Management revisited - Original Message - From: [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Wednesday, November 14, 2001 12:26 AM Subject: Re: Tomcat: Distributed Session Management revisited On Tue, 13 Nov 2001, Mika Goeckel wrote: I completely agree, that the API lacks proactive support for things in the background that may fail. But given the fact, that we support a reference implementation which has managed to provide really professional services to users (other ref implementations are just for demonstration, nobody would use them in production) and there are (commercial) solutions, that provide session fail-over in the limitations of this API, we **must** try to provide a Well, the cool thing about open source is that we _don't_ need to implement all the bloat that commercial solution have. Costin, I don't disagree with your opinion. We don't need to, because we work on a voluntary base. But don't you think that having the option to provide better or at least equally professional solutions is a good motivation? solution. The API does not specify, how often the container may try to provide that service or what means it utilizes to do that. Nothing is 100% and I think it is better to live with the uncertaincy we discuss here than with the more likely problem that an instance fails and there is no potential replacement. I think it's better to live with the certaincy that everything can ( and will ) fail and tomcat can't change this. The alternative is to give users the impression the data he puts in a session will be safe - and he may rely on that instead of using a transaction and a real API. Databases, EJB, etc are complex - but there's a reason to that. Well, we could argue about how much compexity is actually needed, but one thing is certain ( I hope ) - get/setAttribute is not enough, if you want data integrity you must use a different API ( in particular transactions ). Byte-comparison is not the worst solution. If we think about differential updates, byte comparison is a good candiate for that and surplus one that promises good performance. Byte compare every 5 seconds every object in session ? Let's say you just displayed the confirmation and charged the credit card, but the machine crashed just before you sent the order. ( or reverse - you sent it but didn't charged the credit card ). This should happen in below 5 seconds. Yep, but a single stand-alone instance is not invulnerable to that scenario. In fact a thoroughly designed cluster gives better chances. If the user wants to place things in a session that she does not need to be replicated, she has the option to declare them transient and write a getter that checks if the Attribute is present, otherwise reconstructs it (in the case of a picture, reloads it from disk). The user has the choice to design for performance or ease. We only need to document the options. So the user should change all his objects to implement some arbitrary pattern just to fit this into our solution ? What if the object is not user defined ( like most are ) ? Well, we have to create wrappers for each objects you store in a session. Try to explain this on tomcat-user ( or tomcat-dev ) ... If the only alternatice is to use a professional EJB server, he would need to change them as well. I don't say he has to mark these values transient, it's only an option. And transient is not an arbitrary option, it's core java since JLS1.1 (1998). Sessions have always been somewhat fragile, but as the container is free to use transactions when the session is passed to another instance, at least that can be made secure enough. So the guarantee to the user of the container would not be
DO NOT REPLY [Bug 4862] - Directory checksum errors showed up while untaring jakarta-tomcat-3.2.3-src.tar
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4862. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4862 Directory checksum errors showed up while untaring jakarta-tomcat-3.2.3-src.tar --- Additional Comments From [EMAIL PROTECTED] 2001-11-14 04:06 --- You have to use gnu tar, not the one that comes with solaris. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Wrap an HttpServletRequest
Is there any way to wrap an HttpServletRequest in Tomcat 3.2.x and then forward the wrapped request to anoher servlet? We need a 'decorated request' with added functionality, more precisely, we need to add 'extra-parameters' to that request and then forward it to another servlet that process both the original and the added parameters. Thanks, diego -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat: Distributed Session Management revisited
[EMAIL PROTECTED] wrote: On Tue, 13 Nov 2001, Paul Speed wrote: I think the idea is that you'd byte compare on commit which ideally would happen at request boundaries. So in this case a single request becomes a transaction... which indeed opens up its own issues, but no bigger than the ones that were always there. Not good enough - when the request is completed the user already has the page confirming his order ( and maybe the card was already charged :-). Yes, but that all we have are requests in a session. In fact, that's the same case that fails in _every_ scenario that doesn't involve full EJB-like transaction support. As soon as you access one single piece of data that isn't covered by the transaction support, you lose some amount of failover recovery. And what's worse, far too many people will not realize that, and read the marketing stuff ( 'we support failover, session replication, etc') and believe it is a magic solution. That being said, there may still be a place for a session-based distribution mechanism that can support load balancing, hot-swapping of tomcats, and basic failover. It should definitely be an opt-in sort of thing though, ie: web apps that meet the restrictions can opt to setup tomcat to provide this feature. I agree it would be nice to have a tool that can store objects with fail-over, distribution, etc and using it as a _complement_ to the session ( maybe using the session id, expiration, etc ). I don't think this tool can be used using only the current servlet session API or that it should be used as a servlet session manager. distributed session environment. I think that's a given. Personally, I'm still trying to figure out if there are a large enough number of webapps that could be supported to make it worth the effort. (Heavy emphasis on effort.) I'm more worried about the number of webapps that would be written with the assumption that the session will be magically safe, instead of using transactions/database/EJB/ or whatever storage API. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 4866] New: - jakarta-tomcat-connector/webapp cvs instructions broken
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4866. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4866 jakarta-tomcat-connector/webapp cvs instructions broken Summary: jakarta-tomcat-connector/webapp cvs instructions broken Product: Tomcat 4 Version: 4.0 Final Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Webapps AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] The instructions for building jakarta-tomcat-connector/webapp are WRONG. The README.txt specifies the following: Once CVS downloads the WebApp module sources, we need to download the APR (Apache Portable Runtime) sources. To do this simply: cd ./jakarta-tomcat-connectors/webapp cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic \ checkout apr This is plan wrong. Try it. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 4866] - jakarta-tomcat-connector/webapp cvs instructions broken
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4866. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4866 jakarta-tomcat-connector/webapp cvs instructions broken [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Component|Webapps |WARP Connector Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2001-11-14 07:26 --- Nope they are perfectly right and work absolutely perfectly (also, it would be nice to see what kind of error you got out of CVS). I just did: [pier@bubbles] ~ $ cvs \ -d :pserver:[EMAIL PROTECTED]:/home/cvspublic login (Logging in to [EMAIL PROTECTED]) CVS password: anoncvs [pier@bubbles] ~ $ cvs \ -d :pserver:[EMAIL PROTECTED]:/home/cvspublic \ checkout jakarta-tomcat-connectors/webapp cvs server: Updating jakarta-tomcat-connectors/webapp U jakarta-tomcat-connectors/webapp/.cvsignore U jakarta-tomcat-connectors/webapp/INSTALL.txt [...] U jakarta-tomcat-connectors/webapp/support/sed.exe U jakarta-tomcat-connectors/webapp/support/template.pl cvs server: Updating jakarta-tomcat-connectors/webapp/webapplib [pier@bubbles] ~ $ cd ./jakarta-tomcat-connectors/webapp [pier@bubbles] ~/jakarta-tomcat-connectors/webapp $ cvs \ -d :pserver:[EMAIL PROTECTED]:/home/cvspublic \ checkout apr cvs server: Updating apr U apr/.cvsignore U apr/APRDesign [...] cvs server: Updating apr/user/win32 U apr/user/win32/groupinfo.c U apr/user/win32/userinfo.c [pier@bubbles] ~/jakarta-tomcat-connectors/webapp $ cvs --version Concurrent Versions System (CVS) 1.10 `Halibut' (client/server) Copyright (c) 1989-1998 Brian Berliner, david d `zoo' zuhn, Jeff Polk, and other authors CVS may be copied only under the terms of the GNU General Public License, a copy of which can be found with the CVS distribution kit. Specify the --help option for further information about CVS [pier@bubbles] ~/jakarta-tomcat-connectors/webapp $ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 4862] - Directory checksum errors showed up while untaring jakarta-tomcat-3.2.3-src.tar
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4862. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4862 Directory checksum errors showed up while untaring jakarta-tomcat-3.2.3-src.tar [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Portable SSL Support
jean-frederic clere [EMAIL PROTECTED] writes: Eric Rescorla wrote: [EMAIL PROTECTED] writes: One simple workaround could be to abstract acceptSocket() too ( i.e. make it a method in ServerSocketFactory or SSLSupport). Yes, we could do that. It's a little ugly but it avoids having a wrapper class around ServerSocket so I suppose it's worthwhile. Does implAccept play something there? I don't think so. The problem is that we're using the native ServerSocket of the SSL implementation so we need to wrap that call. -Ekr -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Portable SSL Support
William Barker [EMAIL PROTECTED] writes: If you decide on 2a, like Costin, I'd prefer it as a property of the SocketFactory (the base class can return null, since Ajp1x would use it's own mechanism) rather than an interface. However, it's your call. I ended up doing more or less what I proposed in my previous message. The master specification class is an SSLImplementation which contains methods allowing you to acquire ServerSocketFactories and SSLSupport objects. SSLImplementation knows how to automatically select whatever implementation is present (from the compiled in list) or you can provide an SSLImplementation property in the config file. This works fine. A few issues remain: (I) Is portability to JDK 1.1.x desirable/a requirement? Both the existing JSSE code and my new code rely upon java.security.cert.* which was introduced in JDK 1.2. Both JSSE and PureTLS provide more or less complete (less in the case of JSSE) certificate interfaces but they're of course different and we need a common interface presented to Tomcat. If JDK 1.1.x is a requirement I'll have to add a new abstraction layer, which can't inherit from java.security.cert because that didn't exist in 1.1. This isn't a problem (Simple Matter of Programming) but is only worth doing if necessary. (II) How to expose SSLSupport? Currently Request has access to SSLSupport but it's not obvious (at least to me) how best to expose this to the rest of Tomcat and to JSPs/servlets. The obvious choices are: (1) Simply provide a way to access the SSLSupport object (presumably via an attribute). (2) Break out what we believe the relevant information in SSLSupport is (i.e. ciphersuites, cert chain, etc) and store that as individual attributes. From a cursory scan of the code it's not clear to me what would be most consistent with traditional practice. Do people have opinions? -Ekr -- [Eric Rescorla [EMAIL PROTECTED]] Author of SSL and TLS: Designing and Building Secure Systems http://www.rtfm.com/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Portable SSL Support
jean-frederic clere [EMAIL PROTECTED] writes: Eric Rescorla wrote: A few issues remain: (I) Is portability to JDK 1.1.x desirable/a requirement? Both the existing JSSE code and my new code rely upon java.security.cert.* which was introduced in JDK 1.2. Both JSSE and PureTLS provide more or less complete (less in the case of JSSE) certificate interfaces but they're of course different and we need a common interface presented to Tomcat. If JDK 1.1.x is a requirement I'll have to add a new abstraction layer, which can't inherit from java.security.cert because that didn't exist in 1.1. This isn't a problem (Simple Matter of Programming) but is only worth doing if necessary. With JDK 1.1.x and AJP a null is returned. With JDK 1.1.x should the CC be returned as a String? (I thought it was). It's certainly not in the JSSE code I was porting. That code didn't even compile without JDK 1.2.x. from build.xml: exclude name=**/util/net/SSLSocketFactory.java unless=jdk12.present/ In any case, we can do something far more sophisticated than a String if we want to, even with JDK 1.1.x. (II) How to expose SSLSupport? Currently Request has access to SSLSupport but it's not obvious (at least to me) how best to expose this to the rest of Tomcat and to JSPs/servlets. You have to use request.getAttribute() in the JSPs/servlets. Right, but that doesn't mean that we have to expose the SSLSupport interface. Instead we could break out each individual property we cared about into it's own attribute. -Ekr -- [Eric Rescorla [EMAIL PROTECTED]] http://www.rtfm.com/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Session variables in TC 4.0.1 realms
On Mon, 12 Nov 2001, Andreas Graichen wrote: Date: Mon, 12 Nov 2001 12:49:00 +0100 From: Andreas Graichen [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED], [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Session variables in TC 4.0.1 realms Hi, I'm going to develop an authentication realm (based on FORM authentication) for TC 4.0.1 which performs a kind of challenge/response task: Put a challange into a session variable on the login page (.jsp). The expected password would then be the encrypted challenge. Whithin my realm the decryption of the response and the verification against the stored session variable has to be performed. The problem is that the HTTP request is not accessible whithin TC 4.x realms. This was possible in TC 3.x. Is there any possibility to access a session variable in a TC 4.x custom realm? Thank you. It sounds like you really want to create an Authenticator, not a Realm. You might also want to look at how DigestAuthenticator (which implements DIGEST login) deals with encrypted passwords coming in. Authenticators *do* things -- they actively decide whether a user has already been authenticated, and challenge him/her if not. And, of course, they have full access to the request and response (because they are Valves). The programming model for Valves is similar to that of Filters at the application level -- so Authenticators can (and do, if you look at the existing implementations) intercept the request and create authentication challenges back again. Realms are just a place to look up users and check their passwords. Think of a Realm as a database, not a participant in request processing. It's an interface to *any* underlying storage mechanism -- a black box that says yes, this user is valid or no, this user is not valid. In Tomcat 4, these concepts are separate from each other, because you really want to be able to mix and match *any* Authenticator with *any* Realm. In Tomcat 3.2, the concepts are mashed together in one class, which was totally messed up IMHO. Andreas Graichen Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Wrap an HttpServletRequest
On Wed, 14 Nov 2001, Diego del Río wrote: Date: Wed, 14 Nov 2001 10:16:16 -0300 From: Diego del Río [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Wrap an HttpServletRequest Is there any way to wrap an HttpServletRequest in Tomcat 3.2.x and then forward the wrapped request to anoher servlet? We need a 'decorated request' with added functionality, more precisely, we need to add 'extra-parameters' to that request and then forward it to another servlet that process both the original and the added parameters. In servlet 2.2 (Tomcat 3.x), it is not legal to wrap the request (or response) that you pass to a request dispatcher -- the only choice you have is to add request attributes. In servlet 2.3 (Tomcat 4.0), it is legal to wrap the request and response, as long as you subclass the provided wrapper base classes. You can do this for both request dispatchers and filters. Thanks, diego Craig McClanahan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat: Distributed Session Management revisited
To clarify: creating a Distributed Session Manager is a good idea, and something that would be great for users. My problem is with designing it at container-level, as an implementation of the servlet session API. Having all objects in a session distributed and no control or feedback is not good. You could have a DSMServlet that would have some init parameters in web.xml. There you can specify what classes/interfaces you want 'distributed', or even what attributes ( by name ). Then you can use the existing listeners and notifications to detect when those objects are saved in the session and do the distribution. You could also define a simple API allowing the user to control this - for example and update() method to be called after the user changes an object. What's different here is that the behavior of servlet sessions doesn't change - most objects can still be stored without an overhead. The user gets to choose what objects to persist/distribute and he has control over the process. And this will work in _any_ container, so the user can assume the objects he marks as persistent/distributable will be this way on any container ( you can't force people to switch to a different container to use your webapp ) You can also define specialized interfaces to be implemented by the objects that will be persisted/distributed. All of this can be done with only standard 2.3 support. A container may provide aditional hooks ( valves, interceptors, etc) of course. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docs jndi-resources-howto.xml
remm01/11/14 09:53:30 Modified:webapps/tomcat-docs jndi-resources-howto.xml Log: - Fix 4512. Revision ChangesPath 1.9 +1 -3 jakarta-tomcat-4.0/webapps/tomcat-docs/jndi-resources-howto.xml Index: jndi-resources-howto.xml === RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/jndi-resources-howto.xml,v retrieving revision 1.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 --- jndi-resources-howto.xml 2001/11/12 21:03:49 1.8 +++ jndi-resources-howto.xml 2001/11/14 17:53:30 1.9 @@ -514,9 +514,7 @@ /source pNote that the resource name (here, codejdbc/EmployeeDB/code) must -match the value specified in the web application deployment descriptor. -Customize the value of the codemail.smtp.host/code parameter to -point at the server that provides SMTP service for your network./p +match the value specified in the web application deployment descriptor./p pThis example assumes that you are using the HypersonicSQL database JDBC driver. Customize the codedriverClassName/code and -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 4512] - Typo in JDBC Data Sources
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4512. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4512 Typo in JDBC Data Sources [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2001-11-14 10:07 --- Fixed in the HEAD branch. Nightly from 11/15 will have the fix. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 4830] - Catalina class loader throws exception while getting a directory's URL using Class.getResource()
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4830. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4830 Catalina class loader throws exception while getting a directory's URL using Class.getResource() --- Additional Comments From [EMAIL PROTECTED] 2001-11-14 10:14 --- Ok, but you'll have to point me to the part in the Java spec that specifies this, otherwise, I won't fix it. The CL javadoc says (for the getResource method): Finds the resource with the given name. A resource is some data (images, audio, text, etc) that can be accessed by class code in a way that is independent of the location of the code. It seems to me that there's an emphasis on the resource being a file (instead of a directory). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Recycle objects in TomCat, Performance gain?
Hi, In TomCat's source code, I notice it recycles objects (e.g. RequestBase, StandardSession). But in Sun's documentation, with HotSpot Virtual machine, pooling objects will hinder performance (see below). Could someone please tell me are there advantages of using object pooling in TomCat? Thank you. Sam From Sun's Web Page. http://java.sun.com/docs/hotspot/PerformanceFAQ.html#15 Should I pool objects to help GC? Should I call System.gc() periodically? Should I warm up my loops first so that Hotspot will compile them? The answer to all of these is No! Pooling objects will cause them to live longer than necessary. The garbage collection methods will be much more efficient if you let it do the memory management. We strongly advise taking out object pools. Don't call System.gc(), HotSpot will make the determination of when its appropriate and will generally do a much better job. If you are having problems with the pause times for garbage collection or it taking too long, then see the pause time question above. Warming up loops for HotSpot is not necessary. HotSpot now contains On Stack Replacement technology which will compile a running (interpreted) method and replace it while it is still running in a loop. No need to waste your applications time warming up seemingly infinite (or very long running) loops in order to get better application performance. See also Tuning Garbage Collection with the 1.3.1 Java Virtual Machine. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Portable SSL Support
- Original Message - From: Eric Rescorla [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, November 14, 2001 9:17 AM Subject: Re: Portable SSL Support jean-frederic clere [EMAIL PROTECTED] writes: Eric Rescorla wrote: A few issues remain: (I) Is portability to JDK 1.1.x desirable/a requirement? Both the existing JSSE code and my new code rely upon java.security.cert.* which was introduced in JDK 1.2. Both JSSE and PureTLS provide more or less complete (less in the case of JSSE) certificate interfaces but they're of course different and we need a common interface presented to Tomcat. If JDK 1.1.x is a requirement I'll have to add a new abstraction layer, which can't inherit from java.security.cert because that didn't exist in 1.1. This isn't a problem (Simple Matter of Programming) but is only worth doing if necessary. With JDK 1.1.x and AJP a null is returned. With JDK 1.1.x should the CC be returned as a String? (I thought it was). It's certainly not in the JSSE code I was porting. That code didn't even compile without JDK 1.2.x. from build.xml: exclude name=**/util/net/SSLSocketFactory.java unless=jdk12.present/ In any case, we can do something far more sophisticated than a String if we want to, even with JDK 1.1.x. If it wasn't mandated to be a java.security.cert.X509Certificate [] by section 5.7 of the servlet spec :). (II) How to expose SSLSupport? Currently Request has access to SSLSupport but it's not obvious (at least to me) how best to expose this to the rest of Tomcat and to JSPs/servlets. You have to use request.getAttribute() in the JSPs/servlets. Right, but that doesn't mean that we have to expose the SSLSupport interface. Instead we could break out each individual property we cared about into it's own attribute. To be consistant with 2.3 containers, I'd go with individually named attributes. That is what the application programmer will be expecting. As an example (from the 2.3 spec) spec-quote Table 3: Protocol Attributes Attribute Attribute Name Java Type cipher suite javax.servlet.request.cipher_suite String bit size of the algo-rithmjavax.servlet.request.key_size Integer If there is an SSL certificate associated with the request, it must be exposed by the servlet container to the servlet programmer as an array of objects of type java.security.cert.X509Certificate and accessible via a ServletRequest attribute of javax.servlet.request.X509Certificate. /spec-quote -Ekr -- [Eric Rescorla [EMAIL PROTECTED]] http://www.rtfm.com/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] ** This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Portable SSL Support
William Barker [EMAIL PROTECTED] writes: jean-frederic clere [EMAIL PROTECTED] writes: Eric Rescorla wrote: A few issues remain: (I) Is portability to JDK 1.1.x desirable/a requirement? Both the existing JSSE code and my new code rely upon java.security.cert.* which was introduced in JDK 1.2. Both JSSE and PureTLS provide more or less complete (less in the case of JSSE) certificate interfaces but they're of course different and we need a common interface presented to Tomcat. If JDK 1.1.x is a requirement I'll have to add a new abstraction layer, which can't inherit from java.security.cert because that didn't exist in 1.1. This isn't a problem (Simple Matter of Programming) but is only worth doing if necessary. With JDK 1.1.x and AJP a null is returned. With JDK 1.1.x should the CC be returned as a String? (I thought it was). It's certainly not in the JSSE code I was porting. That code didn't even compile without JDK 1.2.x. from build.xml: exclude name=**/util/net/SSLSocketFactory.java unless=jdk12.present/ In any case, we can do something far more sophisticated than a String if we want to, even with JDK 1.1.x. If it wasn't mandated to be a java.security.cert.X509Certificate [] by section 5.7 of the servlet spec :). Well, I suppose that since JDK 1.1.x didn't stop you from putting classes in java. I could do my own version of java.security.cert.X509Certificate. A little gross but perhaps the best plan. The alternative is to blatantly violate the spec in 1.1 and just deliver something else. You have to use request.getAttribute() in the JSPs/servlets. Right, but that doesn't mean that we have to expose the SSLSupport interface. Instead we could break out each individual property we cared about into it's own attribute. To be consistant with 2.3 containers, I'd go with individually named attributes. Fine with me. Anyone object to this? -Ekr -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Distributed Session Management
Tomcat Developers: I'm going to try to synthesize the results of yesterdays discussion on Distributed Session Management into some working code. From what I can tell, there will be some changes and new objects in the org.apache.session package, and possibly some new objects in the org.apache.cluster package. I should have something to share in the next couple of days. I'll be creating JUnit tests as I write this code. Is there a standard place to put JUnit tests, or can I simply place them in the same package as the classes being tested? Regards, Tom Drake Email: [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Tomcat4, taglibs, and pageContext.include
Hi,
-Original Message-
From: Deacon Marcus [mailto:[EMAIL PROTECTED]]
Sent: Monday, November 12, 2001 10:42 PM
To: Tomcat Developers Mailing List
Subject: RE: Tomcat4, taglibs, and pageContext.include
Hi,
I need to upgrade to latest T4 ASAP, and I need to have my tags working...
;/
So, I guess I must get source and recompile after downgrading a
few files -
could you please recommend what files exactly I need to downgrade and to
what versions to get rid of the mentioned feature?
And, maybe the problem's worth a paragraph or two (plus links to
downloadable patch) in FAQ?
Would it be enough to change:
public void include(String relativeUrlPath)
throws ServletException, IOException
{
JspRuntimeLibrary.include((HttpServletRequest) request,
(HttpServletResponse) response,
// FROM:
relativeUrlPath, out, true);
// TO:
relativeUrlPath, out, false);
/*
String path = getAbsolutePathRelativeToContext(relativeUrlPath);
context.getRequestDispatcher(path).include(
request, new ServletResponseWrapperInclude(response, out));
*/
}
In org.apache.jasper.runtime.PageContextImpl ?
Greetings, deacon Marcus
-Original Message-
From: Rickard Öberg [mailto:[EMAIL PROTECTED]]
Sent: Saturday, October 27, 2001 4:14 PM
To: [EMAIL PROTECTED]
Subject: Tomcat4, taglibs, and pageContext.include
Hi!
Due to some recent subtle changes in Tomcat (Jasper and servlet API to
be precise) it is no longer possible to implement jsp:include tags. This
now results in the infamous May not flush in custom tags (or similar)
error message.
Two questions:
* Why was this change made? (It is likely to break any include-tag ever
written)
* How is one supposed to write such tags now? I found some code in
Tomcat4 suggesting one should use RequestDispatcher.include along with a
response wrapper that provides the JspWriter on getWriter, but it seems
hackish (and won't work well with 2.2 servlet engines).
Any explanations would be appreciated. I believe it was Craig who
committed these changes.
/Rickard
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Recycle objects in TomCat, Performance gain?
On Wed, 14 Nov 2001, Samuel Cheung wrote: Hi, In TomCat's source code, I notice it recycles objects (e.g. RequestBase, StandardSession). But in Sun's documentation, with HotSpot Virtual machine, pooling objects will hinder performance (see below). Could someone please tell me are there advantages of using object pooling in TomCat? Turning off recycling is quite easy ( just few lines to comment to prevent reseting the objects and reusing it ). The performance didn't go up - but down, about 30% ( under reasonable load ). Costin Thank you. Sam From Sun's Web Page. http://java.sun.com/docs/hotspot/PerformanceFAQ.html#15 Should I pool objects to help GC? Should I call System.gc() periodically? Should I warm up my loops first so that Hotspot will compile them? The answer to all of these is No! Pooling objects will cause them to live longer than necessary. The garbage collection methods will be much more efficient if you let it do the memory management. We strongly advise taking out object pools. Don't call System.gc(), HotSpot will make the determination of when its appropriate and will generally do a much better job. If you are having problems with the pause times for garbage collection or it taking too long, then see the pause time question above. Warming up loops for HotSpot is not necessary. HotSpot now contains On Stack Replacement technology which will compile a running (interpreted) method and replace it while it is still running in a loop. No need to waste your applications time warming up seemingly infinite (or very long running) loops in order to get better application performance. See also Tuning Garbage Collection with the 1.3.1 Java Virtual Machine. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: IIS and TC4
sorry to ask on this list as this is really a user question, but I'm not on Tomcat-User (too much noise :-) ) so I hope you'll bear with me. Sure Is there a connector available for IIS and TC4? I've searched the archives of both lists and not come up with a definitive answer. AJP13 is supported in Tomcat 4.0.1 and so you could use mod_jk. Can I use the Tomcat 3.3 IIS connector with Tomcat 4? ditto with list searches. Yes, you could use it to make Tomcat 4 and IIS work together -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: mod_jk / Ajp13 config fix on heavily loaded system
what's about loadbalancing? say, we have defined local loadbalancing using 5 ajp13-worker at workers.properties, and we have at server.xml: Ajp13Connector port=8009 maxThreads=100 maxSpareThreads=50 minSpareThreads=10 / You have the 5 tomcat running on different machines ? Does this mean, we can support through the loadbalancer 100 threads or 500 threads (100 * number of workers(5) = 500)? If you have 5 Tomcat, and that each one could eat up to 100 Ajp13 threads, yes you could have 500 threads working for you, but in that case the Apache web-server will have to be set to 500 MaxClients. b.t.w, another question: when using local loadbalancing, does every worker has its own VM or are they sharing all the same VM? I didn't understand well, you could specify your configuration... -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Recycle objects in TomCat, Performance gain?
There are several reasons to use pooling, including (but not limited to): -Eliminating object creation time -Managing expensive resources (really same as first) -Keeping memory usage constant (popular in embedded environments) -Reducing garbage collection Only the last one is addressed by the quotes below. And is especially visible in cases where a program may create, for example, 5000 Rectangle objects and then manage the pool as needed. The current GCs will be much better at managing these objects than a pool would. Tomcat benefits from all of the above reasons, but from a performance perspective, probably mostly from the first two. (Costin's analysis in the other response seems to bear proof of this.) -Paul Samuel Cheung wrote: Hi, In TomCat's source code, I notice it recycles objects (e.g. RequestBase, StandardSession). But in Sun's documentation, with HotSpot Virtual machine, pooling objects will hinder performance (see below). Could someone please tell me are there advantages of using object pooling in TomCat? Thank you. Sam From Sun's Web Page. http://java.sun.com/docs/hotspot/PerformanceFAQ.html#15 Should I pool objects to help GC? Should I call System.gc() periodically? Should I warm up my loops first so that Hotspot will compile them? The answer to all of these is No! Pooling objects will cause them to live longer than necessary. The garbage collection methods will be much more efficient if you let it do the memory management. We strongly advise taking out object pools. Don't call System.gc(), HotSpot will make the determination of when its appropriate and will generally do a much better job. If you are having problems with the pause times for garbage collection or it taking too long, then see the pause time question above. Warming up loops for HotSpot is not necessary. HotSpot now contains On Stack Replacement technology which will compile a running (interpreted) method and replace it while it is still running in a loop. No need to waste your applications time warming up seemingly infinite (or very long running) loops in order to get better application performance. See also Tuning Garbage Collection with the 1.3.1 Java Virtual Machine. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeans mbeans-descriptors.xml
craigmcc01/11/14 18:03:08 Modified:catalina/src/share/org/apache/catalina/mbeans mbeans-descriptors.xml Log: Fix a syntax error introduced on a recent change to this file. Revision ChangesPath 1.12 +2 -2 jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeans/mbeans-descriptors.xml Index: mbeans-descriptors.xml === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeans/mbeans-descriptors.xml,v retrieving revision 1.11 retrieving revision 1.12 diff -u -r1.11 -r1.12 --- mbeans-descriptors.xml2001/11/14 03:51:06 1.11 +++ mbeans-descriptors.xml2001/11/15 02:03:08 1.12 @@ -6,7 +6,7 @@ !-- Descriptions of JMX MBeans for Catalina - $Id: mbeans-descriptors.xml,v 1.11 2001/11/14 03:51:06 amyroh Exp $ + $Id: mbeans-descriptors.xml,v 1.12 2001/11/15 02:03:08 craigmcc Exp $ -- mbeans-descriptors @@ -692,7 +692,7 @@ operation name=createAccessLogger description=Create a new AccessLogger impact=ACTION - returnType=void/ + returnType=void /operation operation name=createHost -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 4830] - Catalina class loader throws exception while getting a directory's URL using Class.getResource()
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4830. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4830 Catalina class loader throws exception while getting a directory's URL using Class.getResource() [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2001-11-14 18:34 --- After some examination of the code, implementing the behavior you suggest apparently isn't too hard (although I'm not convinced it is required), so I'm committing the patch for it to the main branch. The nightly for 11/15 will include the fix. I'm not sure yet if the change will be ported to the 4.0.x branch, as patches which change the classloading behavior are by definition risky. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader WebappClassLoader.java
remm01/11/14 18:20:32
Modified:catalina/src/share/org/apache/catalina/loader
WebappClassLoader.java
Log:
- Fix 4830.
Revision ChangesPath
1.28 +56 -47
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java
Index: WebappClassLoader.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java,v
retrieving revision 1.27
retrieving revision 1.28
diff -u -r1.27 -r1.28
--- WebappClassLoader.java2001/11/14 00:10:44 1.27
+++ WebappClassLoader.java2001/11/15 02:20:32 1.28
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java,v
1.27 2001/11/14 00:10:44 remm Exp $
- * $Revision: 1.27 $
- * $Date: 2001/11/14 00:10:44 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java,v
1.28 2001/11/15 02:20:32 remm Exp $
+ * $Revision: 1.28 $
+ * $Date: 2001/11/15 02:20:32 $
*
*
*
@@ -122,7 +122,7 @@
*
* @author Remy Maucherat
* @author Craig R. McClanahan
- * @version $Revision: 1.27 $ $Date: 2001/11/14 00:10:44 $
+ * @version $Revision: 1.28 $ $Date: 2001/11/15 02:20:32 $
*/
public class WebappClassLoader
extends URLClassLoader
@@ -1546,7 +1546,7 @@
entry = findResourceInternal(name, classPath);
}
-if (entry == null)
+if ((entry == null) || (entry.binaryContent == null))
throw new ClassNotFoundException(name);
Class clazz = entry.loadedClass;
@@ -1653,10 +1653,9 @@
String fullPath = repositories[i] + path;
Object lookupResult = resources.lookup(fullPath);
-if (!(lookupResult instanceof Resource))
-continue;
-
-resource = (Resource) lookupResult;
+if (lookupResult instanceof Resource) {
+resource = (Resource) lookupResult;
+}
// Note : Not getting an exception here means the resource was
// found
@@ -1671,30 +1670,36 @@
(ResourceAttributes) resources.getAttributes(fullPath);
contentLength = (int) attributes.getContentLength();
entry.lastModified = attributes.getLastModified();
-try {
-binaryStream = resource.streamContent();
-} catch (IOException e) {
-return null;
-}
-// Register the full path for modification checking
-synchronized (paths) {
+if (resource != null) {
-int j;
-
-long[] result2 = new long[lastModifiedDates.length + 1];
-for (j = 0; j lastModifiedDates.length; j++) {
-result2[j] = lastModifiedDates[j];
+try {
+binaryStream = resource.streamContent();
+} catch (IOException e) {
+return null;
}
-result2[lastModifiedDates.length] = entry.lastModified;
-lastModifiedDates = result2;
+
+// Register the full path for modification checking
+synchronized (paths) {
+
+int j;
+
+long[] result2 =
+new long[lastModifiedDates.length + 1];
+for (j = 0; j lastModifiedDates.length; j++) {
+result2[j] = lastModifiedDates[j];
+}
+result2[lastModifiedDates.length] = entry.lastModified;
+lastModifiedDates = result2;
+
+String[] result = new String[paths.length + 1];
+for (j = 0; j paths.length; j++) {
+result[j] = paths[j];
+}
+result[paths.length] = fullPath;
+paths = result;
-String[] result = new String[paths.length + 1];
-for (j = 0; j paths.length; j++) {
-result[j] = paths[j];
}
-result[paths.length] = fullPath;
-paths = result;
}
@@ -1741,27 +1746,31 @@
return null;
}
-byte[] binaryContent = new byte[contentLength];
+if
DO NOT REPLY [Bug 4883] New: - Tomcan example jsp files don't work in 4.0.1
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4883.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4883
Tomcan example jsp files don't work in 4.0.1
Summary: Tomcan example jsp files don't work in 4.0.1
Product: Tomcat 4
Version: 4.0.1 Final
Platform: Sun
OS/Version: Solaris
Status: NEW
Severity: Normal
Priority: Other
Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
I have installed the latest binary version of tomcat on a Sun running
Solaris 7. After tomcat is started ($CATALINA_HOME/bin/startup.sh), an
attempt to run the jsp examples fails with an error that is duplicated
in the $CATALINA_HOME/logs/localhost* log files:
localhost_examples_log.2001-11-15.txt:
2001-11-15 13:32:17 WebappLoader[/examples]: Deploying class repositories to
work directory /usr/local/jakarta-tomcat-4.0.1/work/localhost/examples
2001-11-15 13:32:17 WebappLoader[/examples]: Reloading checks are enabled for
this Context
2001-11-15 13:32:17 StandardManager[/examples]: Seeding random number generator
class java.security.SecureRandom
2001-11-15 13:32:17 StandardManager[/examples]: Seeding of random number
generator has been completed
2001-11-15 13:32:19 ContextConfig[/examples]: Configured an authenticator for
method FORM
2001-11-15 13:32:19 ContextListener: contextInitialized()
2001-11-15 13:32:19 SessionListener: contextInitialized()
2001-11-15 13:32:19 ContextListener:
attributeReplaced('org.apache.catalina.WELCOME_FILES',
'[Ljava.lang.String;@4bf30e')
2001-11-15 13:32:19 StandardWrapper[/examples:default]: Loading container
servlet default
2001-11-15 13:32:20 default: init
2001-11-15 13:32:20 StandardWrapper[/examples:invoker]: Loading container
servlet invoker
2001-11-15 13:32:20 invoker: init
2001-11-15 13:32:20 jsp: init
2001-11-15 13:32:20 StandardContext[/examples]: Servlet /examples threw load()
exception
javax.servlet.ServletException: Servlet.init() for servlet jsp threw exception
at
org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:871)
at
org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3267)
at
org.apache.catalina.core.StandardContext.start(StandardContext.java:3384)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1123)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:612)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1123)
at
org.apache.catalina.core.StandardEngine.start(StandardEngine.java:307)
at
org.apache.catalina.core.StandardService.start(StandardService.java:388)
at
org.apache.catalina.core.StandardServer.start(StandardServer.java:505)
at org.apache.catalina.startup.Catalina.start(Catalina.java:776)
at org.apache.catalina.startup.Catalina.execute(Catalina.java:681)
at org.apache.catalina.startup.Catalina.process(Catalina.java:179)
at java.lang.reflect.Method.invoke(Native Method)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:243)
- Root Cause -
java.lang.NoSuchMethodError
at
org.apache.jasper.compiler.TldLocationsCache.processJars(TldLocationsCache.java:202)
at
org.apache.jasper.compiler.TldLocationsCache.init(TldLocationsCache.java:139)
at
org.apache.jasper.EmbededServletOptions.init(EmbededServletOptions.java:324)
at org.apache.jasper.servlet.JspServlet.init(JspServlet.java:266)
at
org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:852)
at
org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3267)
at
org.apache.catalina.core.StandardContext.start(StandardContext.java:3384)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1123)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:612)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1123)
at
org.apache.catalina.core.StandardEngine.start(StandardEngine.java:307)
at
org.apache.catalina.core.StandardService.start(StandardService.java:388)
at
org.apache.catalina.core.StandardServer.start(StandardServer.java:505)
at org.apache.catalina.startup.Catalina.start(Catalina.java:776)
at org.apache.catalina.startup.Catalina.execute(Catalina.java:681)
at org.apache.catalina.startup.Catalina.process(Catalina.java:179)
at java.lang.reflect.Method.invoke(Native Method)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:243)
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 4883] - Tomcat example jsp files don't work in 4.0.1
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4883. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4883 Tomcat example jsp files don't work in 4.0.1 [EMAIL PROTECTED] changed: What|Removed |Added Summary|Tomcan example jsp files|Tomcat example jsp files |don't work in 4.0.1 |don't work in 4.0.1 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Recycle objects in TomCat, Performance gain?
[EMAIL PROTECTED] wrote: Turning off recycling is quite easy ( just few lines to comment to prevent reseting the objects and reusing it ). The performance didn't go up - but down, about 30% ( under reasonable load ). The probable reason being that memery management isn't the only factor in pooling. Initialization costs are the probably cause of the effect pooling gives here, and indeed, all JSP compilers that use pooling are vastly faster than Jasper's (which is dead slow, at least in TC4). /Rickard -- Rickard Öberg -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
