Re:Patches in Bugzilla
I agree, i have the same problem when i try to get paches from that list. I use cc:mail that often makes emails understandable. Would it be possible to send a parts of code in attachments as a plain text? I think it is the solution. Regards, Tomasz Sucharzewski ING Bank Reply Separator Subject:Patches in Bugzilla Author: [EMAIL PROTECTED] Date: 01-03-06 13:10 I'm having a problem using Bugzilla, and I'm hoping someone can point me towards an easy solution. When people post bug reports, they often include patches in the text of the description (which is great). However, it's very difficult for me to get those patches into a file so that I can run the patch program to use them. Cut and paste does all kinds of weird line truncation things (which makes patch lose it's mind), and if you try to view source, there are all kinds of HTML escape codes. It's sort of like the Bugzilla system expects people to "attach" their proposed patches (which I could then download). But no one ever does (understandably). Am I missing a way to get the description saved as text without any HTML escapes? Or can we add something to the bug submission form to encourage people to attach their patches rather than paste them in? -Dan -- Dan Milstein // [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - ATTENTION: The information in this electronic mail message is private and confidential, and only intended for the addressee. Should you receive this message by mistake, you are hereby notified that any disclosure, reproduction, distribution or use of this message is strictly prohibited. Please inform the sender by reply transmission and delete the message without copying or opening it. Messages and attachments are scanned for all viruses known. If this message contains password-protected attachments, the files have NOT been scanned for viruses by the ING mail domain. Always scan attachments before opening them. - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Jasper JspRuntimeLibrary.java jspSetproperty with value= does not set the property
Hi
I've seen a Messagethread a while ago (dated 12.20.2000), where
is mentioned that it is impossible to set an empty String
in an property.
I've had the same Problem and here I want to commit my solution.
It migth be integrated in the class org.apache.jasper.JspRuntimeLibrary:
here is what I changed:
// original line:
//if(value == null || (param != null value.equals(""))) return;
//replaced to:
if(value == null || ((param != null value.equals(""))
(!type.equals(String.class return;
If I set an other property than a string property everithing stays
unchanged.
hope this is usefull for you
kind regards
Burkard Endres
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
ajp13 file upload bug
here we go... btw our system is Solaris 2.8 on Intel / Apache 1.3.17, compiled with gcc-2.95.2. Tomcat is run by jdk1.3. Maybe the problem is related with assumptions about header-sizes implemented in ajp13 ? Can you post this to the tomcat-dev mailing list? -jh- Stefan Busse wrote: Hi Jason, just stumbled across your post while looking for an answer for my own upload problems. In fact there seems to be an ajp13 bug. I just tried your demo-application because my own (primitive) upload-servlet stopped working when I switched from resin (connected through mod_caucho) to tomcat 3.2.1 (connected through mod_jk). Maybe ajp13 can't handle multipart-contents. There is no error in the logfiles, the servlet just seems to be stuck in a loop, as the browser uploads forever. Hope this helps, or maybe you can forward this to the wizard developing the ajp13-connector... * stefan busse -- To: [EMAIL PROTECTED] Subject: Possible ajp13 bug doing file upload posts From: Jason Hunter [EMAIL PROTECTED] Date: Sun, 07 Jan 2001 19:40:17 -0800 Hi, Here's a bug report in ajp13 from someone using my com.oreilly.servlet package to do file uploads. No real details, but I'm thinking perhaps someone with ajp13 running can test the file upload example? You can download the c.o.s. pkg from http://www.servlets.com/resources/com.oreilly.servlet. I'm happy to provide support. -jh- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: ajp13 file upload bug
I also had this problem, although I was using my own Multipart Handler class based on Javamail. The upload works correctly using ajp12, but puts jibberish in the logs when ajp13 is substituted in. R - Original Message - From: "Stefan Busse" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, March 07, 2001 11:47 PM Subject: ajp13 file upload bug here we go... btw our system is Solaris 2.8 on Intel / Apache 1.3.17, compiled with gcc-2.95.2. Tomcat is run by jdk1.3. Maybe the problem is related with assumptions about header-sizes implemented in ajp13 ? Can you post this to the tomcat-dev mailing list? -jh- Stefan Busse wrote: Hi Jason, just stumbled across your post while looking for an answer for my own upload problems. In fact there seems to be an ajp13 bug. I just tried your demo-application because my own (primitive) upload-servlet stopped working when I switched from resin (connected through mod_caucho) to tomcat 3.2.1 (connected through mod_jk). Maybe ajp13 can't handle multipart-contents. There is no error in the logfiles, the servlet just seems to be stuck in a loop, as the browser uploads forever. Hope this helps, or maybe you can forward this to the wizard developing the ajp13-connector... * stefan busse -- To: [EMAIL PROTECTED] Subject: Possible ajp13 bug doing file upload posts From: Jason Hunter [EMAIL PROTECTED] Date: Sun, 07 Jan 2001 19:40:17 -0800 Hi, Here's a bug report in ajp13 from someone using my com.oreilly.servlet package to do file uploads. No real details, but I'm thinking perhaps someone with ajp13 running can test the file upload example? You can download the c.o.s. pkg from http://www.servlets.com/resources/com.oreilly.servlet. I'm happy to provide support. -jh- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Jasper JspRuntimeLibrary.java jspSetproperty with value= does not set the property
Which version of Tomcat are you refering to?
I recall the discussion, and that a solution was implemented
in at least Tomcat 3.2. I am using jsp:setPorperty with value=""
in some JSP pages running in Tomcat 3.2.
Regards,
Glenn
Burkard Endres wrote:
Hi
I've seen a Messagethread a while ago (dated 12.20.2000), where
is mentioned that it is impossible to set an empty String
in an property.
I've had the same Problem and here I want to commit my solution.
It migth be integrated in the class org.apache.jasper.JspRuntimeLibrary:
here is what I changed:
// original line:
//if(value == null || (param != null value.equals(""))) return;
//replaced to:
if(value == null || ((param != null value.equals(""))
(!type.equals(String.class return;
If I set an other property than a string property everithing stays
unchanged.
hope this is usefull for you
kind regards
Burkard Endres
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
--
--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
--
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/examples/WEB-INF/classes LocalStrings_fr.properties
larryi 01/03/07 07:06:07 Modified:src/examples/WEB-INF/classes Tag: tomcat_32 LocalStrings_fr.properties Log: Add strings for updated SessionExample servlet. Submitted by: Henri Gomez Revision ChangesPath No revision No revision 1.1.2.2 +6 -1 jakarta-tomcat/src/examples/WEB-INF/classes/LocalStrings_fr.properties Index: LocalStrings_fr.properties === RCS file: /home/cvs/jakarta-tomcat/src/examples/WEB-INF/classes/LocalStrings_fr.properties,v retrieving revision 1.1.2.1 retrieving revision 1.1.2.2 diff -u -r1.1.2.1 -r1.1.2.2 --- LocalStrings_fr.properties2000/12/15 10:57:21 1.1.2.1 +++ LocalStrings_fr.properties2001/03/07 15:06:04 1.1.2.2 @@ -1,4 +1,4 @@ -# $Id: LocalStrings_fr.properties,v 1.1.2.1 2000/12/15 10:57:21 hgomez Exp $ +# $Id: LocalStrings_fr.properties,v 1.1.2.2 2001/03/07 15:06:04 larryi Exp $ # Default localized resources for example servlets # This locale is fr_FR @@ -36,3 +36,8 @@ sessions.adddata=Ajouter des données à votre session sessions.dataname=Nom de l''Attribut de Session: sessions.datavalue=Valeur de l''Attribut de Session: +sessions.requestedid=ID de Session demandé: +sessions.requestedidvalid=L''ID de Session demandé est valide: +sessions.fromcookie=L''ID de Session demandé vient d''un cookie: +sessions.fromurl=L''ID de Session demandé vient d''une URL: +sessions.isnew=Nouvelle Session: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/examples/WEB-INF/classes LocalStrings_fr.properties
larryi 01/03/07 07:06:59 Modified:src/examples/WEB-INF/classes LocalStrings_fr.properties Log: Add strings for updated SessionExample servlet. Submitted by: Henri Gomez Revision ChangesPath 1.3 +6 -1 jakarta-tomcat/src/examples/WEB-INF/classes/LocalStrings_fr.properties Index: LocalStrings_fr.properties === RCS file: /home/cvs/jakarta-tomcat/src/examples/WEB-INF/classes/LocalStrings_fr.properties,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- LocalStrings_fr.properties2000/12/15 11:24:15 1.2 +++ LocalStrings_fr.properties2001/03/07 15:06:59 1.3 @@ -1,4 +1,4 @@ -# $Id: LocalStrings_fr.properties,v 1.2 2000/12/15 11:24:15 hgomez Exp $ +# $Id: LocalStrings_fr.properties,v 1.3 2001/03/07 15:06:59 larryi Exp $ # Default localized resources for example servlets # This locale is fr_FR @@ -36,3 +36,8 @@ sessions.adddata=Ajouter des données à votre session sessions.dataname=Nom de l''Attribut de Session: sessions.datavalue=Valeur de l''Attribut de Session: +sessions.requestedid=ID de Session demandé: +sessions.requestedidvalid=L''ID de Session demandé est valide: +sessions.fromcookie=L''ID de Session demandé vient d''un cookie: +sessions.fromurl=L''ID de Session demandé vient d''une URL: +sessions.isnew=Nouvelle Session: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: cannot instantiate class exception in Realm
I located this myself eventually. Another example of the sealing violation
problem that's been discussed previously. Problem solved by using the
current build.
Tim
Dr. Tim Dudgeon, Head RD Informatics
British Biotech Pharmaceuticals
Watlington Road, Oxford, OX4 5LY, UK
Tel: (44) 1865 748747
Fax: (44) 1865 781034
email: [EMAIL PROTECTED]
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: 05 March 2001 1:52 PM
To: [EMAIL PROTECTED]
Subject: cannot instantiate class exception in Realm
I posted this to tomcat-user but got no replies.
Perhaps tomcat-dev is more appropriate, as it is a
programming problem. Can
anyone help?
Although I've been using tomacat for sometime, I'm now
needeing to start on
some work to match up the authentication and authorisation
within catalina
to our enviroment. To do this I'm putting together a
LDAPRealm. I have a
rudimentary LDAPRealm that works fine on its own (outside
catalina), but
when I run it within catalina I'm getting a cannot instantiate class
exception from within my code. Could someone give me a guide
into what I'm
doing worong. It's probably pretty basic, but I'm new to this.
What I did:
created a org.apache.catalina.realm.MyRealm class that contains an
authenticate() method that connects to the LDAP server as follows
public Principal authenticate(String username, String credentials) {
MyRealmPrincipal principal = new MyRealmPrincipal(username);
Hashtable env = new Hashtable(11);
env.put(Context.PROVIDER_URL,
"ldap://localhost:389/dc=britbio,dc=co,dc=uk");
env.put(Context.SECURITY_PRINCIPAL,
principal.getDistinguishedName());
env.put(Context.SECURITY_CREDENTIALS, credentials);
try {
// Create the initial directory context
DirContext ctx = new InitialDirContext(env);
// if we get here then we've bound OK
System.out.println("Authenticated for " +
principal.getDistinguishedName());
// get the groups from the JNDI context and define them as roles
getRoles(ctx, principal);
// unbind
ctx.close();
return(principal);
} catch (NamingException e) {
// could not bind - wrong password?
System.err.println("Failed to bind to directory for " +
username);
e.printStackTrace();
return(null);
}
this code works fine on its own (outside catalina). However
when I try to
run it within catalina (jar'd up the clases, put them in
$CATLINA_ROOT/server), my code gets called, but the bind to
the LDAP server
fails with the following exception
Failed to bind to directory for tom
javax.naming.NoInitialContextException: Cannot instantiate class:
com.sun.jndi.ldap.LdapCtxFactory. Root exception is
java.lang.ClassCastException: com.sun.jndi.ldap.LdapCtxFactory
at
javax.naming.spi.NamingManager.getInitialContext(NamingManager
.java:659)
at
javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:250)
at javax.naming.InitialContext.init(InitialContext.java:226)
at javax.naming.InitialContext.init(InitialContext.java:202)
at
javax.naming.directory.InitialDirContext.init(InitialDirCont
ext.java:87)
at
org.apache.catalina.realm.TimsRealm.authenticate(TimsRealm.java:109)
at
org.apache.catalina.authenticator.BasicAuthenticator.findPrinc
ipal(BasicAuth
enticator.java:214)
at
org.apache.catalina.authenticator.BasicAuthenticator.authentic
ate(BasicAuthe
nticator.java:160)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(Aut
henticatorBase
.java:481)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:975)
at
org.apache.catalina.core.StandardContext.invoke(StandardContex
t.java:2041)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHost
Valve.java:161
)
at
org.apache.catalina.valves.ValveBase.invokeNext(ValveBase.java:242)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValv
e.java:414)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:975)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEn
gineValve.java
:159)
at
org.apache.catalina.valves.ValveBase.invokeNext(ValveBase.java:242)
at
org.apache.catalina.valves.RequestDumperValve.invoke(RequestDu
mperValve.java
:215)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:975)
at
org.apache.catalina.connector.http.HttpProcessor.process(HttpP
rocessor.java:
818)
at
org.apache.catalina.connector.http.HttpProcessor.run(HttpProce
ssor.java:897)
at java.lang.Thread.run(Thread.java:484)
Any ideas as to why this runs outside catalina and not inside
it. The JVM,
and everything else I can think of is the same. My setup:
Tomcat-4.0-b1
JDK1.3
Linux
Advice on Realm implementation wanted.
I'm putting together a LDAPRealm implementation for catalina and have the basic setup working. I would welcome some advice on implementation issues. I would prefer to avoid a round trip to the LDAP server (presumably the same could apply for a JDBCRealm or whatever) for each page requested. Hence I could store the principal created in a hashmap as is done for the MemoryRealm (my usaage is for a small Intranet based usage, so keeping the whole user base in memory is not a problem) and verify the password against this stored principal rather than doing another (possibly expensive) round trip to the LDAP server. However when doing this the principal stays alive for the entire lifetime of tomcat. What I would like is that it only stays alive for that session, so that when the browser is quit and restarted a new round trip to the LDAP server is needed. My concern here is that if the LDAP administrator removed or invalidated a user, this should be picked up by tomcat pretty quickly. Clearly if LDAP is being hit for every page it would be picked up immediately. If however the pricipal was being stored permananently the invalid user would still be able to be authenticated until tomcat is restarted. A sensible compromise would seem to be to give the principal session scope so that once the browser is quit (assuming we're using cookies here for session maintenance) and a new session started, the LDAP server has to be consulted again. The implementation issues would seem to be, can the Realm get access to the seesion, and is the realm the right place for this in the first place? Comments or suggestions welcome. many thanks tim - Tim Dudgeon [EMAIL PROTECTED] -- DISCLAIMER: This message contains proprietary information some or all of which may be confidential and/or legally privileged. It is for the intended recipient only who may use and apply the information only for the intended purpose. Internet communications are not secure and therefore the British Biotech group does not accept legal responsibility for the contents of this message. Any views or opinions presented are only those of the author and not those of the British Biotech group. If you are not the intended recipient please delete this e-mail and notify the author immediately by calling ++44 (0)1865 748747; do not use, disclose, distribute, copy, print or rely on this e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: FW: problem w/ ajp13 - if Tomcat is shutdown
BTW we should redirect this to the tomcat-users list as I don't think its a development issue. I don't see anything wrong, and the only drastic difference from my previous setup was that I had used the default 8007 and 8009. Now This is purely a guess, but I seem to remember reading that ports 1 were special somehow and required root access for some functions. What I would suggest is put those to the default, see if they work, then (I'm assuming you had a reason for ding this) find an acceptable port between 8000-. If that doesn't work then we have a couple more "generic" possiblities (such as running out of file handles which is very common with tomcat on solaris). I wish I still had access to a solaris box to try this.. The only other difference was that I was using Jdk 1.3 (Sun). Which I'd recommend for server side stuff unless you have a compelling reason not to. Its more stable, has less glitches and is faster. Jdk 1.2.x was suns "wowee" and jdk 1.3.x is a performance and stability release (IMHO).. If you haven't tweaked your file handles at any point then there is a good chance that is in the way, unfortunately I do not remember what the strings were to fix this, but I'm sure their documented somewhere (and they're not intuitive).. Hope this helps some. -Andy -Original Message- From: Shinta Tjio To: 'oliver2, andy'; '[EMAIL PROTECTED] ' Cc: ''Dan Milstein' ' Sent: 3/6/01 7:51 PM Subject: RE: FW: problem w/ ajp13 - if Tomcat is shutdown Here's exactly what I did to reproduce the problem. Again, I'm running this on a Solaris 2.8 SunOS machine, using JDK1.2.2, Apache 1.3.14, Tomcat 3.2.1. 1. Start Apache 2. Start Tomcat 3. Start hitting Apache with multiple requests, such as /example/servlet/HelloWorldExample. Make sure there are some connections opened from Apache to Tomcat. To make sure, you can do netstat -a | grep Tomcat port where Tomcat port is the ajp13 port. It should show some socket in ESTABLISHED state. 4. While the connections are in the ESTABLISHED state (this should be the state because ajp13 reuse connections), shutdown Tomcat. Now you will notice the same netstat will show some sockets in FIN_WAIT2 and CLOSE_WAIT state. 5. Now restart Tomcat. 6. Repeat step 3. You will get Internal Server Error, up to the number of children Apache has. After that number, the page will be served. Attached is the server.xml, workers.properties, httpd.conf. My test servlet is called /mytest/servlet/testServlet but I think you can try it with any kind of servlet. I have been trying to code up the retry I mentioned below. I think I got it working. I just need to clean up the code some more. shinta -Original Message- From: oliver2, andy [ mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ] Sent: Tuesday, March 06, 2001 6:33 PM To: 'Shinta Tjio '; '[EMAIL PROTECTED] ' Cc: ''Dan Milstein' ' Subject: RE: FW: problem w/ ajp13 - if Tomcat is shutdown I was running recently with that exact same configuration but did not experience that problem. Can you show some config files. -Andy -Original Message- From: Shinta Tjio To: [EMAIL PROTECTED] Cc: 'Dan Milstein' Sent: 3/6/01 7:01 PM Subject: RE: FW: problem w/ ajp13 - if Tomcat is shutdown I am using Tomcat 3.2.1, Apache 1.3.14, running on Solaris 2.8, Sun machines. After various attempts of debugging this, I have more information. 1. Even though I'm setting the worker's property cache_size to default (1), I'm finding there are up to 6 connections opened from Apache to Tomcat. I deduce this by looking at the mod_jk.conf and by doing netstat. I finally find out, this is so because my Apache is set to spawn minimum of 6 children and each of those children are making separate connections to Tomcat. This is very bad because, I ended up having to reload 6 times before Tomcat starts serving me the page again. Each time it uses a different Apache children that has defunct socket. So the more Apache children I have, the longer it takes me to recover from this problem. 2. It seems when Tomcat dies restarts, the send() called by ajp13's jk_tcp_socket_sendfull() does not get an error. But the recv() does get an error, with errno ECONNRESET. After which, the socket is properly closed. 3. When I shutdown Tomcat, those sockets that were opened between Apache/Tomcat showed up in state CLOSE_WAIT, and FIN_WAIT2. I think this is normally solved by calling the shutdown() API after closing the socket. However, this would have to be done from the Tomcat side in Ajp13ConnectionHandler.java. I can't find the corresponding method of Socket in Java. So.. based on all of these, the only fix I can think of putting is to make mod_jk retry the send() if recv() comes back with an error ECONNRESET. The retry should happen after the old socket is properly
cvs commit: jakarta-tomcat/src/admin/WEB-INF/scripts run-test.sh
costin 01/03/07 12:36:17
Modified:src/admin/WEB-INF/scripts run-test.sh
Log:
Fix in the test script
Revision ChangesPath
1.2 +4 -3 jakarta-tomcat/src/admin/WEB-INF/scripts/run-test.sh
Index: run-test.sh
===
RCS file: /home/cvs/jakarta-tomcat/src/admin/WEB-INF/scripts/run-test.sh,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- run-test.sh 2001/01/29 06:46:19 1.1
+++ run-test.sh 2001/03/07 20:36:15 1.2
@@ -10,9 +10,10 @@
cp=$CLASSPATH
-CLASSPATH=${TOMCAT_HOME}/lib/tomcat_util.jar:$CLASSPATH
-CLASSPATH=${TOMCAT_HOME}/lib/parser.jar:$CLASSPATH
-CLASSPATH=${TOMCAT_HOME}/lib/jaxp.jar:$CLASSPATH
+CLASSPATH=${TOMCAT_HOME}/lib/container/tomcat_util.jar:$CLASSPATH
+CLASSPATH=${TOMCAT_HOME}/lib/common/core_util.jar:$CLASSPATH
+CLASSPATH=${TOMCAT_HOME}/lib/container/parser.jar:$CLASSPATH
+CLASSPATH=${TOMCAT_HOME}/lib/container/jaxp.jar:$CLASSPATH
CLASSPATH=${TOMCAT_HOME}/webapps/admin/WEB-INF/lib/ant.jar:$CLASSPATH
CLASSPATH=${TOMCAT_HOME}/webapps/admin/WEB-INF/classes:$CLASSPATH
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/facade22/org/apache/tomcat/facade HttpServletResponseFacade.java
larryi 01/03/07 13:29:45
Modified:src/facade22/org/apache/tomcat/facade
HttpServletResponseFacade.java
Log:
Port changes from tomcat_32 by Marc Saegesser
This fixes some additional problems uncovered by the fix for
Bugzilla 160.
The isEncodable() method used isRequestedSessionIdValid() to determine
if there was an active session.This is incorrect, because the requested
session id may have expired or been invalidated and a new session created.
isEncodeable() now encodes sessions that are new (i.e. we don't know yet
if the client will be sending cookies or not) or if, if the session
is not new (meaning the requested session id was a valid session) and
the requested session id did not come from a cookie.
Revision ChangesPath
1.19 +19 -15
jakarta-tomcat/src/facade22/org/apache/tomcat/facade/HttpServletResponseFacade.java
Index: HttpServletResponseFacade.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/facade22/org/apache/tomcat/facade/HttpServletResponseFacade.java,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -r1.18 -r1.19
--- HttpServletResponseFacade.java2001/02/27 02:42:38 1.18
+++ HttpServletResponseFacade.java2001/03/07 21:29:38 1.19
@@ -1,4 +1,8 @@
/*
+ * $Header:
/home/cvs/jakarta-tomcat/src/facade22/org/apache/tomcat/facade/HttpServletResponseFacade.java,v
1.19 2001/03/07 21:29:38 larryi Exp $
+ * $Revision: 1.19 $
+ * $Date: 2001/03/07 21:29:38 $
+ *
*
*
* The Apache Software License, Version 1.1
@@ -135,8 +139,7 @@
*/
public String encodeRedirectURL(String location) {
if (isEncodeable(toAbsolute(location)))
- return (toEncoded(location,
- response.getRequest().getRequestedSessionId()));
+ return (toEncoded(location, response.getRequest().getSession(false)));
else
return (location);
}
@@ -150,8 +153,7 @@
public String encodeURL(String url) {
if (isEncodeable(toAbsolute(url)))
- return (toEncoded(url,
- response.getRequest().getSessionId()));
+ return (toEncoded(url, response.getRequest().getSession(false)));
else
return (url);
}
@@ -330,15 +332,16 @@
if (location.startsWith("#"))
return (false);
- // Are we in a valid session that is not using cookies?
+// Are we in a valid session that is not using cookies?
Request request = response.getRequest();
- HttpServletRequestFacade reqF=(HttpServletRequestFacade)request.
- getFacade();
-
- if (!reqF.isRequestedSessionIdValid() )
- return (false);
- if ( reqF.isRequestedSessionIdFromCookie() )
- return (false);
+ ServerSession session = request.getSession(false);
+ if(session == null || !session.isValid())
+ return false;
+ // If the session is new, encode the URL
+ if(!session.getTimeStamp().isNew()
+ ((HttpServletRequestFacade)request.getFacade()).
+ isRequestedSessionIdFromCookie())
+ return false;
// Is this a valid absolute URL?
URL url = null;
@@ -415,13 +418,14 @@
* suitably encoded.
*
* @param url URL to be encoded with the session id
- * @param sessionId Session id to be included in the encoded URL
+ * @param session Session whose id is to be included in the encoded URL
*/
-private String toEncoded(String url, String sessionId) {
+private String toEncoded(String url, ServerSession session) {
- if ((url == null) || (sessionId == null))
+ if ((url == null) || (session == null))
return (url);
+ String sessionId = session.getId().toString();
String path = null;
String query = null;
int question = url.indexOf("?");
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
RE: FW: problem w/ ajp13 - if Tomcat is shutdown
Title: RE: FW: problem w/ ajp13 - if Tomcat is shutdown BTW we should redirect this to the tomcat-users list as I don't think its a development issue. Sorry about that. I don't see anything wrong, and the only drastic difference from my previous setup was that I had used the default 8007 and 8009. Now This is purely a guess, but I seem to remember reading that ports 1 were special somehow and required root access for some functions. What I would suggest is put those to the default, see if they work, then (I'm assuming you had a reason for ding this) find an acceptable port between 8000-. I think you get that backwards. Programs listening on port1024 will require root access. Anything larger than that, it doesn't require special priviledge. If that doesn't work then we have a couple more generic possiblities (such as running out of file handles which is very common with tomcat on solaris). I wish I still had access to a solaris box to try this.. The only other difference was that I was using Jdk 1.3 (Sun). Which I'd recommend for server side stuff unless you have a compelling reason not to. Its more stable, has less glitches and is faster. Jdk 1.2.x was suns wowee and jdk 1.3.x is a performance and stability release (IMHO).. If you haven't tweaked your file handles at any point then there is a good chance that is in the way, unfortunately I do not remember what the strings were to fix this, but I'm sure their documented somewhere (and they're not intuitive).. Thanks for the tips. We can't switch JDK for this release we're having. But next release, we are hoping to use JDK 1.3 shinta
Design Review for ajp13's changes: WAS problem w/ ajp13 - if Tomcat is shutdown
Title: Design Review for ajp13's changes: WAS problem w/ ajp13 - if Tomcat is shutdown Hi, all, I would like to propose some changes to eliminate the requirement to restart Apache, when you restart Tomcat. I'm willing to give the code to anyone who needs it, when I'm done testing. But I need some help/suggestions so that I can put in the right code. If any of the proposed changes below should not exists ever, I'm open to other suggestions. This is my first time looking at mod_jk's ajp13 code. So any clue to make these better would be appreciated. Right now, if you use ajp13 and you restart Tomcat, you have to also restart Apache. See details in previous postings. For us, having to restart Apache is not a feasible solution in our customers' environment. After looking at the code, I have two possible solutions: 1. From mod_jk, I can detect that the socket has been closed by Tomcat. This is normally indicated by the recv() returning ECONNRESET. The recv() is called after the request has been sent to the socket. The send() unfortunately, doesn't give you an error. The proposed fixed is to check for errno ECONNRESET, then set the is_recoverable_error flag to TRUE, in the service() function in jk_ajp13_worker.c. I also add a code in mod_jk.c, to check for this flag, and call the service() method again if the flag is set TRUE. The 2nd time the service() method is called, it will reconnect to Tomcat like normal. 2. Another solution would be to put in a select() on the socket prior to send(), looking for the socket being read ready. Under normal condition, this select() should return nothing. But if Tomcat shuts down the socket, this select() should return the socket being read ready. When this happen, I issue a read() of 1 bytes. If the read() comes back with return code 0, this should be an indication that the socket was closed on the remote end. Then I will proceed to close the socket. The remaining logic already handles the reconnect, etc. I have both of these solution prototyped and minimally tested. They both Anyone care to comment which solution fits better with the overall code? Anyone voluteer to review the code? thanks, shinta -Original Message- From: Shinta Tjio To: [EMAIL PROTECTED] Cc: 'Dan Milstein' Sent: 3/6/01 7:01 PM Subject: RE: FW: problem w/ ajp13 - if Tomcat is shutdown I am using Tomcat 3.2.1, Apache 1.3.14, running on Solaris 2.8, Sun machines. After various attempts of debugging this, I have more information. 1. Even though I'm setting the worker's property cache_size to default (1), I'm finding there are up to 6 connections opened from Apache to Tomcat. I deduce this by looking at the mod_jk.conf and by doing netstat. I finally find out, this is so because my Apache is set to spawn minimum of 6 children and each of those children are making separate connections to Tomcat. This is very bad because, I ended up having to reload 6 times before Tomcat starts serving me the page again. Each time it uses a different Apache children that has defunct socket. So the more Apache children I have, the longer it takes me to recover from this problem. 2. It seems when Tomcat dies restarts, the send() called by ajp13's jk_tcp_socket_sendfull() does not get an error. But the recv() does get an error, with errno ECONNRESET. After which, the socket is properly closed. 3. When I shutdown Tomcat, those sockets that were opened between Apache/Tomcat showed up in state CLOSE_WAIT, and FIN_WAIT2. I think this is normally solved by calling the shutdown() API after closing the socket. However, this would have to be done from the Tomcat side in Ajp13ConnectionHandler.java. I can't find the corresponding method of Socket in Java. So.. based on all of these, the only fix I can think of putting is to make mod_jk retry the send() if recv() comes back with an error ECONNRESET. The retry should happen after the old socket is properly closed. Anyone wants to comment? shinta -Original Message- From: Dan Milstein [ mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ] Sent: Tuesday, March 06, 2001 12:00 PM To: [EMAIL PROTECTED] Subject: Re: FW: problem w/ ajp13 - if Tomcat is shutdown What version of TC are you using? What version of Apache? I would look into the mod_jk docs -- I think this is the spec'd behavior (which, admittedly, is not great, but that makes it more of a feature request than a bug ;-). With ajp13, Apache opens up a persistent TCP/IP connection TC -- if TC restarts, I think that connection may just hang up and then timeout (since Apache doesn't know that TC has restarted). If anyone wants to work on this, you would have the undying thanks of the rest of the TC community -- having to restart Apache all the time bugs a *lot* of people. -Dan
Re: Tomcat startup time
Petr Jiricka [EMAIL PROTECTED] wrote: I noticed that the time to serve the first servlet or a JSP has increased dramatically. I traced this down to the initialization of java.security.SecureRandom, which is used for generating the session IDs. On is there a way to configure the server.xml file to force tomcat to initialize the Secure Random Number Generator? Currently we are using a plopping a .war file in the tomcat/webapps directory to force the initialization. -- Richard F. Wan email: [EMAIL PROTECTED] Phone: 403 263 3287 Fax: 403 265 5690 Servidium Inc. Suite 800, 840 7th Ave SW Calgary, Alberta, Canada T2P 3G2 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util/depend DependManager.java Dependency.java
costin 01/03/07 15:39:21
Modified:src/share/org/apache/tomcat/util/depend DependManager.java
Dependency.java
Log:
Add "reset" - this remove the need to replace the DependManager on
reloading, and most of the extra setup.
Revision ChangesPath
1.5 +11 -0
jakarta-tomcat/src/share/org/apache/tomcat/util/depend/DependManager.java
Index: DependManager.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/depend/DependManager.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- DependManager.java2000/12/13 18:48:43 1.4
+++ DependManager.java2001/03/07 23:39:20 1.5
@@ -88,6 +88,17 @@
public DependManager() {
}
+/** Reset the depend manager - all dependencies are reset too.
+ This will be called after a reload
+*/
+public void reset() {
+ expired=false;
+ for( int i=0; idepsCount; i++ ) {
+ Dependency d=deps[i];
+ d.reset();
+ }
+}
+
public void setDelay( int d ) {
delay=d;
}
1.3 +5 -0
jakarta-tomcat/src/share/org/apache/tomcat/util/depend/Dependency.java
Index: Dependency.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/depend/Dependency.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- Dependency.java 2000/12/13 18:48:43 1.2
+++ Dependency.java 2001/03/07 23:39:20 1.3
@@ -94,6 +94,11 @@
return lastModified;
}
+public void reset() {
+ expired=false;
+ lastModified=origin.lastModified();
+}
+
/**
* If set, the dependency will be "local", i.e. will be marked as
* expired but the DependManager will not triger an expire at a higher
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/config AutoDeploy.java
costin 01/03/07 15:48:59
Modified:src/share/org/apache/tomcat/modules/config AutoDeploy.java
Log:
Added 1/2 of the code to support "reloadable", tested it ( i.e. the
change in .war is detected ).
Reloading still needs more testing, the first request after a reload
seems to get 503.
Revision ChangesPath
1.4 +42 -4
jakarta-tomcat/src/share/org/apache/tomcat/modules/config/AutoDeploy.java
Index: AutoDeploy.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/config/AutoDeploy.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- AutoDeploy.java 2001/02/20 03:16:51 1.3
+++ AutoDeploy.java 2001/03/07 23:48:58 1.4
@@ -61,6 +61,7 @@
import org.apache.tomcat.core.*;
import org.apache.tomcat.util.io.FileUtil;
+import org.apache.tomcat.util.depend.*;
import java.io.*;
import java.net.*;
import java.util.*;
@@ -81,7 +82,11 @@
String src="webapps";
String dest="webapps";
+boolean redeploy=false;
+// map destination dir ( used in Ctx docBase ) - File ( war source)
+Hashtable expanded=new Hashtable();
+
public AutoDeploy() {
}
@@ -112,10 +117,9 @@
/**
* Re-deploy the context if the war file is modified.
- * XXX Not implemented.
*/
public void setRedeploy( boolean b ) {
-
+ redeploy=b;
}
// Implementation
@@ -178,19 +182,53 @@
String fname=name.substring(0, name.length()-4);
File appDir=new File( destD, fname);
+ File srcF=new File( srcD, name );
+ File destF=new File( destD, fname );
+ expanded.put( destF.getAbsolutePath(), srcF );
+
if( ! appDir.exists() ) {
// no check if war file is "newer" than directory
// To update you need to "remove" the context first!!!
appDir.mkdirs();
// Expand war file
try {
- FileUtil.expand(srcD.getAbsolutePath() + "/" + name,
- destD.getAbsolutePath() + "/" + fname );
+ FileUtil.expand(srcF.getAbsolutePath(),
+ destF.getAbsolutePath() );
+
} catch( IOException ex) {
log("expanding webapp " + name, ex);
// do what ?
}
}
+}
+
+public void contextInit( Context context)
+ throws TomcatException
+{
+ if( redeploy ) {
+ String ctxBase=context.getAbsolutePath();
+ File warFile=(File)expanded.get( ctxBase );
+ if( warFile == null || ! warFile.exists() )
+ return;
+
+ DependManager dm=(DependManager)context.getContainer().
+ getNote("DependManager");
+ if( dm!=null ) {
+ log( "Adding dependency " + context + " - " + warFile );
+ Dependency dep=new Dependency();
+ dep.setTarget("web.xml");
+ dep.setOrigin( warFile );
+ dep.setLastModified( warFile.lastModified() );
+ dm.addDependency( dep );
+ context.getContainer().setNote( "autoDeploy.war", warFile );
+ }
+ }
+}
+
+public void reload( Request req, Context context) throws TomcatException {
+ File war=(File)context.getContainer().getNote( "autoDeploy.war" );
+ if( war==null ) return;
+ log( "XXX not implemented - need to re-expand " + war );
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/config LoaderInterceptor11.java
costin 01/03/07 15:51:08
Modified:src/share/org/apache/tomcat/modules/config
LoaderInterceptor11.java
Log:
Simplified reloading - the DependManager is set by ReloadInterceptor,
if the user wants to enable reloading.
LoaderInterceptor will use it if available, but will not force reloading
( as before ) if the user doesn't have ReloadInterceptor.
Also, on reload we just reset the DependManager ( and create a new
class loader, as normal )
Revision ChangesPath
1.8 +27 -18
jakarta-tomcat/src/share/org/apache/tomcat/modules/config/LoaderInterceptor11.java
Index: LoaderInterceptor11.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/config/LoaderInterceptor11.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- LoaderInterceptor11.java 2001/02/27 16:56:24 1.7
+++ LoaderInterceptor11.java 2001/03/07 23:51:08 1.8
@@ -151,11 +151,9 @@
DependManager dm=(DependManager)context.getContainer().
getNote("DependManager");
- //context.getDependManager();
+
if( dm==null ) {
- dm=new DependManager();
- context.getContainer().setNote("DependManager", dm);
- //setDependManager( dm );
+ // No depend manager - that means no ReloadInterceptor.
}
ClassLoader parent=null;
@@ -166,22 +164,30 @@
else
parent=this.getClass().getClassLoader();
- // Construct a class loader. Use URLClassLoader if Java2,
- // replacement ( SimpleClassLoader ) if not
- // SimpleClassLoader loader=new SimpleClassLoader(classP, parent);
ClassLoader loader=jdk11Compat.newClassLoaderInstance( classP, parent);
- DependClassLoader dcl=new DependClassLoader( dm, loader);
if( debug 0 )
log("Loader " + loader.getClass().getName() + " " + parent);
- context.setClassLoader( dcl );
+
+ if( dm != null ) {
+ // If depend manager is present, create a wrapper loader
+ // that will add dependencies for reloading ( using depentManager)
+ loader=new DependClassLoader( dm, loader);
+ }
+ // If another reloading scheme is implemented, you'll
+ // have to plug it in here.
+
+ context.setClassLoader( loader );
+
// support for jasper and other applications
- context.setAttribute( "org.apache.tomcat.classloader",
- context.getClassLoader());
+ context.setAttribute( "org.apache.tomcat.classloader",loader);
}
public void reload( Request req, Context context) throws TomcatException {
log( "Reload event " + context.getPath() );
+ DependManager dm=(DependManager)context.getContainer().
+ getNote("DependManager");
+
ContextManager cm = context.getContextManager();
URL urls[]=context.getClassPath();
if( debug5 ) {
@@ -190,9 +196,11 @@
log("" + urls[i].toString() );
}
- DependManager dm=new DependManager();
- context.getContainer().setNote("DependManager", dm);
- //setDependManager( dm );
+ if( dm!=null ) {
+ // we are using a util.depend for reloading
+ dm.reset();
+ }
+ // construct a new loader
ClassLoader oldLoader=context.getClassLoader();
int oldLoaderNote=cm.getNoteId( ContextManager.CONTAINER_NOTE,
"oldLoader");
@@ -210,10 +218,11 @@
// replacement ( SimpleClassLoader ) if not
// SimpleClassLoader loader=new SimpleClassLoader(urls, parent);
ClassLoader loader=jdk11Compat.newClassLoaderInstance( urls, parent);
- DependClassLoader dcl=new DependClassLoader( dm, loader);
- context.setClassLoader( dcl );
- context.setAttribute( "org.apache.tomcat.classloader",
- ctx.getClassLoader());
+
+ if( dm!=null )
+ loader=new DependClassLoader( dm, loader);
+ context.setClassLoader( loader );
+ context.setAttribute( "org.apache.tomcat.classloader", loader);
}
//
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
RE: Tomcat startup time
This has been fixed in 3.2.2 (currently in beta) and 4.0. I think its fixed in 3.3, too, but I'm not positive. -Original Message- From: Richard Wan [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 07, 2001 5:25 PM To: [EMAIL PROTECTED] Subject: Re: Tomcat startup time Petr Jiricka [EMAIL PROTECTED] wrote: I noticed that the time to serve the first servlet or a JSP has increased dramatically. I traced this down to the initialization of java.security.SecureRandom, which is used for generating the session IDs. On is there a way to configure the server.xml file to force tomcat to initialize the Secure Random Number Generator? Currently we are using a plopping a .war file in the tomcat/webapps directory to force the initialization. -- Richard F. Wan email: [EMAIL PROTECTED] Phone: 403 263 3287 Fax: 403 265 5690 Servidium Inc. Suite 800, 840 7th Ave SW Calgary, Alberta, Canada T2P 3G2 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/mappers ReloadInterceptor.java
costin 01/03/07 15:52:49
Modified:src/share/org/apache/tomcat/modules/mappers
ReloadInterceptor.java
Log:
Set the DependManager on contextAdd, it'll be available in contextInit
( no need to check/create, all options are set in the ReloadInterceptor,
where reloading is configured ) ( assuming someone adds the config
options - right now they are not exposed )
Revision ChangesPath
1.4 +12 -6
jakarta-tomcat/src/share/org/apache/tomcat/modules/mappers/ReloadInterceptor.java
Index: ReloadInterceptor.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/mappers/ReloadInterceptor.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- ReloadInterceptor.java2001/02/27 16:56:30 1.3
+++ ReloadInterceptor.java2001/03/07 23:52:48 1.4
@@ -94,6 +94,18 @@
public void setFullReload( boolean full ) {
fullReload=full;
}
+
+public void addContext( ContextManager cm, Context context)
+ throws TomcatException
+{
+ DependManager dm=(DependManager)context.getContainer().
+ getNote("DependManager");
+ if( dm==null ) {
+ dm=new DependManager();
+ context.getContainer().setNote("DependManager", dm);
+ }
+
+}
/** Example of adding web.xml to the dependencies.
* JspInterceptor can add all taglib descriptors.
@@ -104,12 +116,6 @@
ContextManager cm = context.getContextManager();
DependManager dm=(DependManager)context.getContainer().
getNote("DependManager");
- // getDependManager();
- if( dm==null ) {
- dm=new DependManager();
- context.getContainer().setNote("DependManager", dm);
- //setDependManager( dm );
- }
File inf_xml = new File(context.getAbsolutePath() +
"/WEB-INF/web.xml");
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: Design Review for ajp13's changes: WAS problem w/ ajp13 - ifTomc at is shutdown
Hi Shinta, It's sounds like a solution to a real problem, please send a patch, I'm sure someone will read it. Dan and Henri are the best people to ask about this, I can also help a bit ( I've been using RPMs lately, it's too easy to get them and not worry about compile :-) My only sugestion/concern is that the code should work on both Windows and unix - or at least compile :-) Costin I would like to propose some changes to eliminate the requirement to restart Apache, when you restart Tomcat. I'm willing to give the code to anyone who needs it, when I'm done testing. But I need some help/suggestions so that I can put in the right code. If any of the proposed changes below should not exists ever, I'm open to other suggestions. This is my first time looking at mod_jk's ajp13 code. So any clue to make these better would be appreciated. Right now, if you use ajp13 and you restart Tomcat, you have to also restart Apache. See details in previous postings. For us, having to restart Apache is not a feasible solution in our customers' environment. After looking at the code, I have two possible solutions: 1. From mod_jk, I can detect that the socket has been closed by Tomcat. This is normally indicated by the recv() returning ECONNRESET. The recv() is called after the request has been sent to the socket. The send() unfortunately, doesn't give you an error. The proposed fixed is to check for errno ECONNRESET, then set the is_recoverable_error flag to TRUE, in the service() function in jk_ajp13_worker.c. I also add a code in mod_jk.c, to check for this flag, and call the service() method again if the flag is set TRUE. The 2nd time the service() method is called, it will reconnect to Tomcat like normal. 2. Another solution would be to put in a select() on the socket prior to send(), looking for the socket being read ready. Under normal condition, this select() should return nothing. But if Tomcat shuts down the socket, this select() should return the socket being read ready. When this happen, I issue a read() of 1 bytes. If the read() comes back with return code 0, this should be an indication that the socket was closed on the remote end. Then I will proceed to close the socket. The remaining logic already handles the reconnect, etc. I have both of these solution prototyped and minimally tested. They both Anyone care to comment which solution fits better with the overall code? Anyone voluteer to review the code? thanks, shinta -Original Message- From: Shinta Tjio To: [EMAIL PROTECTED] Cc: 'Dan Milstein' Sent: 3/6/01 7:01 PM Subject: RE: FW: problem w/ ajp13 - if Tomcat is shutdown I am using Tomcat 3.2.1, Apache 1.3.14, running on Solaris 2.8, Sun machines. After various attempts of debugging this, I have more information. 1. Even though I'm setting the worker's property cache_size to default (1), I'm finding there are up to 6 connections opened from Apache to Tomcat. I deduce this by looking at the mod_jk.conf and by doing netstat. I finally find out, this is so because my Apache is set to spawn minimum of 6 children and each of those children are making separate connections to Tomcat. This is very bad because, I ended up having to reload 6 times before Tomcat starts serving me the page again. Each time it uses a different Apache children that has defunct socket. So the more Apache children I have, the longer it takes me to recover from this problem. 2. It seems when Tomcat dies restarts, the send() called by ajp13's jk_tcp_socket_sendfull() does not get an error. But the recv() does get an error, with errno ECONNRESET. After which, the socket is properly closed. 3. When I shutdown Tomcat, those sockets that were opened between Apache/Tomcat showed up in state CLOSE_WAIT, and FIN_WAIT2. I think this is normally solved by calling the shutdown() API after closing the socket. However, this would have to be done from the Tomcat side in Ajp13ConnectionHandler.java. I can't find the corresponding method of Socket in Java. So.. based on all of these, the only fix I can think of putting is to make mod_jk retry the send() if recv() comes back with an error ECONNRESET. The retry should happen after the old socket is properly closed. Anyone wants to comment? shinta -Original Message- From: Dan Milstein [ mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ] Sent: Tuesday, March 06, 2001 12:00 PM To: [EMAIL PROTECTED] Subject: Re: FW: problem w/ ajp13 - if Tomcat is shutdown What version of TC are you using? What version of Apache? I would look into the mod_jk docs -- I think this is the spec'd behavior (which, admittedly, is not great, but that makes it
cvs commit: jakarta-tomcat/src/doc/appdev source.html
marcsaeg01/03/07 16:56:42 Modified:src/doc/appdev Tag: tomcat_32 source.html Log: The source for the example bulid.bat was incorrect. There is a missing %CP% on the second set. The example build.bat file was fixed ages ago but the documentation hadn't gotten updated. PR: 447 Revision ChangesPath No revision No revision 1.2.4.3 +3 -3 jakarta-tomcat/src/doc/appdev/source.html Index: source.html === RCS file: /home/cvs/jakarta-tomcat/src/doc/appdev/source.html,v retrieving revision 1.2.4.2 retrieving revision 1.2.4.3 diff -u -r1.2.4.2 -r1.2.4.3 --- source.html 2000/11/27 22:45:49 1.2.4.2 +++ source.html 2001/03/08 00:56:41 1.2.4.3 @@ -208,7 +208,7 @@ pre #!/bin/sh # build -- Build Script for the "Hello, World" Application -# $Id: source.html,v 1.2.4.2 2000/11/27 22:45:49 craigmcc Exp $ +# $Id: source.html,v 1.2.4.3 2001/03/08 00:56:41 marcsaeg Exp $ # Identify the custom class path components we need CP=$TOMCAT_HOME/lib/ant.jar:$TOMCAT_HOME/lib/servlet.jar @@ -227,13 +227,13 @@ pre @echo off rem build.bat -- Build Script for the "Hello, World" Application -rem $Id: source.html,v 1.2.4.2 2000/11/27 22:45:49 craigmcc Exp $ +rem $Id: source.html,v 1.2.4.3 2001/03/08 00:56:41 marcsaeg Exp $ set _CP=%CP% rem Identify the custom class path components we need set CP=%TOMCAT_HOME%\lib\ant.jar;%TOMCAT_HOME%\lib\servlet.jar -set CP=%TOMCAT_HOME%\lib\jaxp.jar;%TOMCAT_HOME%\lib\parser.jar +set CP=%CP%;%TOMCAT_HOME%\lib\jaxp.jar;%TOMCAT_HOME%\lib\parser.jar set CP=%CP%;%JAVA_HOME%\lib\tools.jar rem Execute ANT to perform the requird build target - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
tag handler pooling ideas
I am planning on implementing tag handler pooling and would like to throw out a few ideas for feedback: assumptions: - Tag handlers can only be reused if the same set of attributes are used for the tag. - Tag.relese is called only once -- at some point before the handler is garbage collected. basic idea: My general idea was to have a collection of named pools. Jasper could then render code to use the named pool to obtain handler instances instead of newing them each time. more info: Each tag handler pool would have a name that would include the tag's short name and the set of attributes that were used on the tag. This would give us the correct reuse level. So for the following tags there would be two named pools (after taking into account attributes): x:tag1 attr1="a" attr2="b"/ x:tag1 attr1="xyz" attr2="123"/ x:tag1 attr1="a"/ To eliminate the need to lookup the pool by name each time a tag was needed, pool references could be rendered and initialized (looked up) when the jsp is initialized. Inside the main jsp method (_jspService), the pool references would be used directly. When the pools are removed (shutdown, reload, etc.) Tag.release will be called for each of the handlers. I assume that pools need to be per web application, but haven't given it a lot of thought. Any comments / suggestions? -Casey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[Bug 189] New - Session BugRat Report#275
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=189 *** shadow/189 Wed Mar 7 16:50:04 2001 --- shadow/189.tmp.12567Wed Mar 7 16:50:05 2001 *** *** 0 --- 1,19 + ++ + | Session BugRat Report#275 | + ++ + |Bug #: 189 Product: Tomcat 3| + | Status: RESOLVEDVersion: 3.2.1 Final | + | Resolution: WORKSFORME Platform: PC | + | Severity: Normal OS/Version: All | + | Priority: High Component: Jasper | + ++ + | Assigned To: [EMAIL PROTECTED]| + | Reported By: [EMAIL PROTECTED]| + | CC list: Cc: | + ++ + | URL: | + ++ + | DESCRIPTION | + I have a little application with Servlet, which loads jsp, which is just a frameset +and loads three jsps in three different frames. From one of this jsps user can get to +the first Servlet(submit the form), that loads the jsp frameset again and so on. The +Servlet updates session's attribute and the jsp in one of the frames uses it. After +some such loadings the jsp which reads attribute from session, gets not updated value. + + - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/config ProfileLoader.java
costin 01/03/07 16:59:42
Modified:src/share/org/apache/tomcat/modules/config
ProfileLoader.java
Log:
Another step in ProfileLoader implementation. Now it has support
for separate class loaders for each profile, allowing groups
of application that share a certain set of common jars without
affecting the rest ( i.e. in configs with many applications, you
can partition both the config and the shared classes )
The code is not very clean ( a lot of cutpaste), but this is not used
by default.
I'll propose moving this to the "outside-of-stable-release" area, so
that (likely) changes in ProfileLoader will not delay or affect the release
quality.
Revision ChangesPath
1.2 +194 -39
jakarta-tomcat/src/share/org/apache/tomcat/modules/config/ProfileLoader.java
Index: ProfileLoader.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/config/ProfileLoader.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- ProfileLoader.java2001/02/27 17:16:50 1.1
+++ ProfileLoader.java2001/03/08 00:59:41 1.2
@@ -67,6 +67,8 @@
import org.apache.tomcat.util.res.StringManager;
import org.apache.tomcat.util.io.FileUtil;
import org.apache.tomcat.util.xml.*;
+import org.apache.tomcat.util.compat.*;
+import org.apache.tomcat.util.IntrospectionUtils;
import org.apache.tomcat.core.*;
import org.apache.tomcat.modules.server.*;
import org.apache.tomcat.util.log.*;
@@ -85,6 +87,8 @@
*/
public class ProfileLoader extends BaseInterceptor {
Hashtable profiles=new Hashtable();
+ClassLoader parentLoader;
+static final Jdk11Compat jdk11Compat=Jdk11Compat.getJdkCompat();
public ProfileLoader() {
}
@@ -99,7 +103,7 @@
public void addProfile( Profile p ) {
String name=p.getName();
- if( debug -1 ) log ( "Adding " + name );
+ if( debug 0 ) log ( "Adding " + name );
if( name==null ) return;
profiles.put( name, p );
}
@@ -113,18 +117,29 @@
{
String ctxProfile=ctx.getProperty("profile");
if( ctxProfile==null ) ctxProfile="default";
-
Profile p=(Profile)profiles.get( ctxProfile );
if( p==null ) {
log( "Can't find profile " + ctxProfile );
p=(Profile)profiles.get("default");
}
+
if( p==null ) throw new TomcatException( "Can't load profile");
+
+ URL[] cp=p.commonClassPath;
+ for (int i=0; icp.length; i++ ) {
+ ctx.addClassPath( cp[i]);
+ }
+ cp=p.sharedClassPath;
+ for (int i=0; icp.length; i++ ) {
+ ctx.addClassPath( cp[i]);
+ }
+
+
Enumeration en=p.getModules();
while( en.hasMoreElements()) {
BaseInterceptor bi=(BaseInterceptor)en.nextElement();
- log( ctx + " " + bi );
+ if( debug 0 ) log( ctx + " " + bi );
ctx.addInterceptor( bi );
}
}
@@ -140,11 +155,13 @@
{
if( this != module ) return;
+ parentLoader=cm.getParentLoader();
+
XmlMapper xh=new XmlMapper();
xh.setDebug( debug );
addProfileRules( xh );
- addTagRules( cm, xh );
+ addTagRules( cm, ctx, xh );
if (configFile == null)
configFile=DEFAULT_CONFIG;
@@ -165,60 +182,194 @@
// Xml reading details
-public void addTagRules( ContextManager cm, XmlMapper xh )
+public void addTagRules( ContextManager cm, Context ctx, XmlMapper xh )
throws TomcatException
{
Hashtable modules=(Hashtable)cm.getNote("modules");
if( modules==null) return;
Enumeration keys=modules.keys();
+
while( keys.hasMoreElements() ) {
String name=(String)keys.nextElement();
String classN=(String)modules.get( name );
String tag="Profile" + "/" + name;
- xh.addRule( tag ,
- xh.objectCreate( classN, null ));
- xh.addRule( tag ,
- xh.setProperties());
- xh.addRule( tag, new XmlAction() {
- public void end(SaxContext ctx ) throws Exception {
- BaseInterceptor obj=(BaseInterceptor)
- ctx.currentObject();
- Profile parent=(Profile)
- ctx.previousObject();
-
- parent.addModule( obj );
- }
- });
+ xh.addRule( tag, new TagAction(classN));
}
}
public void addProfileRules( XmlMapper xh ) {
- xh.addRule( "Profile", new XmlAction() {
- public void start(SaxContext ctx ) throws Exception {
-
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util IntrospectionUtils.java
costin 01/03/07 17:06:01
Modified:src/share/org/apache/tomcat/util IntrospectionUtils.java
Log:
Added replaceProperties - cutpaste from ant, with dependencies removed.
It can be used with a Hasthable storing properties or with a
simple adapter ( the PropertySource - it's used to support default
or "dynamic"/runtime values ).
( before anyone start screaming "duplication" - I wrote part of the code
that deal with properties in ant, and it'll be moved in commons as soon
as possible - if ant people also agree to share it. )
Revision ChangesPath
1.6 +57 -2
jakarta-tomcat/src/share/org/apache/tomcat/util/IntrospectionUtils.java
Index: IntrospectionUtils.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/IntrospectionUtils.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- IntrospectionUtils.java 2001/03/04 03:37:16 1.5
+++ IntrospectionUtils.java 2001/03/08 01:06:00 1.6
@@ -197,8 +197,7 @@
If found, call the method ( if param is int or boolean we'll convert
value to the right type before) - that means you can have setDebug(1).
*/
-public static void setProperty( Object o, String name, String value )
-{
+public static void setProperty( Object o, String name, String value ) {
if( dbg 1 ) d("setProperty(" +
o.getClass() + " " + name + "=" +
value +")" );
@@ -281,6 +280,52 @@
}
}
+/** Replace ${NAME} with the property value
+ */
+public static String replaceProperties(String value,
+Object getter )
+{
+StringBuffer sb=new StringBuffer();
+int i=0;
+int prev=0;
+// assert value!=nil
+int pos;
+while( (pos=value.indexOf( "$", prev )) = 0 ) {
+if(pos0) {
+sb.append( value.substring( prev, pos ) );
+}
+if( pos == (value.length() - 1)) {
+sb.append('$');
+prev = pos + 1;
+}
+else if (value.charAt( pos + 1 ) != '{' ) {
+sb.append( value.charAt( pos + 1 ) );
+prev=pos+2; // XXX
+} else {
+int endName=value.indexOf( '}', pos );
+if( endName 0 ) {
+ sb.append( value.substring( pos ));
+ prev=value.length();
+ continue;
+}
+String n=value.substring( pos+2, endName );
+ String v= null;
+ if( getter instanceof Hashtable ) {
+ v=(String)((Hashtable)getter).get(n);
+ } else if ( getter instanceof PropertySource ) {
+ v=((PropertySource)getter).getProperty( n );
+ }
+ if( v== null )
+ v = "${"+n+"}";
+
+sb.append( v );
+prev=endName+1;
+}
+}
+if( prev value.length() ) sb.append( value.substring( prev ) );
+return sb.toString();
+}
+
/** Reverse of Introspector.decapitalize
*/
public static String capitalize(String name) {
@@ -292,6 +337,16 @@
return new String(chars);
}
+// Get property
+// This provides a layer of abstraction
+
+public static interface PropertySource {
+
+ public String getProperty( String key );
+
+}
+
+
// debug
static final int dbg=0;
static void d(String s ) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util/xml XmlMapper.java
costin 01/03/07 17:08:07
Modified:src/share/org/apache/tomcat/util/xml XmlMapper.java
Log:
Added code to replace the attributes using ${property}, ant-style,
as proposed. This works for all attributes set using SetProperties
( i.e. automatic introspection )
( also setVariable renamed setVar, it was overriding another method ).
Revision ChangesPath
1.32 +65 -17
jakarta-tomcat/src/share/org/apache/tomcat/util/xml/XmlMapper.java
Index: XmlMapper.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/xml/XmlMapper.java,v
retrieving revision 1.31
retrieving revision 1.32
diff -u -r1.31 -r1.32
--- XmlMapper.java2001/03/04 03:42:53 1.31
+++ XmlMapper.java2001/03/08 01:08:06 1.32
@@ -196,6 +196,24 @@
root=o;
}
+// Support for ${prop} replacement --
+
+Object propSource;
+
+public void setPropertySource( Object src ) {
+ this.propSource=src;
+}
+
+public Object getPropertySource() {
+ return propSource;
+}
+
+public String replaceProperties( String k ) {
+ if( propSource==null ) return k;
+ return IntrospectionUtils.replaceProperties( k, propSource);
+}
+
+
// Utils
// Debug ( to be replaced with the real thing )
public void setDebug( int level ) {
@@ -233,7 +251,7 @@
public Object getVariable( String name ) {
return variables.get( name );
}
-
+
public XmlMapper getMapper() {
return this;
}
@@ -526,14 +544,21 @@
/** Set object properties using XML attributes
*/
-public XmlAction setProperties( ) {
+public XmlAction setProperties() {
return new SetProperties();
}
/** Set a variable varName using the value of an attribute
+ */
+public XmlAction setVar( String varName, String attName ) {
+ return new SetVar( varName, attName );
+}
+
+/** Set a variable varName using the value of an attribute
*/
-public XmlAction setVariable( String varName, String attName ) {
- return new SetVariable( varName, attName );
+public XmlAction setVar( String varName, String nameAtt,
+ String valueAtt, boolean reset) {
+ return new SetVar(varName, nameAtt, valueAtt, reset);
}
/** For the last 2 objects in stack, create a parent-child
@@ -679,19 +704,23 @@
/** Set object properties using XML attribute list
*/
class SetProperties extends XmlAction {
-
public SetProperties() {
}
public void start( SaxContext ctx ) {
Object elem=ctx.currentObject();
AttributeList attributes = ctx.getCurrentAttributes();
-
+ XmlMapper xh=ctx.getMapper();
+
for (int i = 0; i attributes.getLength (); i++) {
String type = attributes.getType (i);
String name=attributes.getName(i);
String value=attributes.getValue(i);
+ String value1=xh.replaceProperties( value );
+ if( !value1.equals(value) ctx.getDebug() -1 )
+ ctx.log( "Replace " + value + " " + value1 );
+
IntrospectionUtils.setProperty( elem, name, value );
}
}
@@ -886,29 +915,48 @@
/**
*/
-class SetVariable extends XmlAction {
+class SetVar extends XmlAction {
String varName;
-String attributeN;
+String nameAtt;
+String valAtt;
+boolean reset=false;
-public SetVariable(String varName, String attributeN) {
+public SetVar(String varName, String attributeN) {
super();
this.varName=varName;
- this.attributeN=attributeN;
+ this.valAtt=attributeN;
+ reset=true;
}
+public SetVar(String varName, String nameAtt, String valueAtt,
+boolean reset) {
+ super();
+ this.varName=varName;
+ this.nameAtt=nameAtt;
+ this.valAtt=valueAtt;
+ this.reset=reset;
+}
+
public void start( SaxContext ctx) throws Exception {
AttributeList attributes = ctx.getCurrentAttributes();
- ctx.setVariable( varName,
- attributes.getValue(attributeN));
+ String n=varName;
+ if( n==null )
+ n=attributes.getValue( nameAtt );
+ String v=attributes.getValue( valAtt );
+
+ if( n!=null v!=null )
+ ctx.setVariable( n, v);
+
if( ctx.getDebug() 0 )
- ctx.log("setVariable " + varName + " " + attributeN + " " +
- attributes.getValue( attributeN ));
+ ctx.log("setVariable " + n + " " + v );
}
public void cleanup( SaxContext ctx) {
-
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/generators StaticInterceptor.java
costin 01/03/07 17:09:53
Modified:src/share/org/apache/tomcat/modules/config
ContextXmlReader.java ServerXmlReader.java
src/share/org/apache/tomcat/modules/generators
StaticInterceptor.java
Log:
Added code to support ant properties in the config file.
This is not completed, but should work fine for global
modules.
This doesn't/shouldn't affect the code stability in any way - if you don't
use properties nothing will change in tomcat's behavior.
This should allow us to clean/clarify the paths and what's relative
to what, and provide more flexibility in the configuraton.
Revision ChangesPath
1.7 +1 -1
jakarta-tomcat/src/share/org/apache/tomcat/modules/config/ContextXmlReader.java
Index: ContextXmlReader.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/config/ContextXmlReader.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- ContextXmlReader.java 2001/02/27 17:09:37 1.6
+++ ContextXmlReader.java 2001/03/08 01:09:50 1.7
@@ -152,7 +152,7 @@
xh.setParent("setContextManager") );
// Virtual host support - if Context is inside a Host
- xh.addRule( "Host", xh.setVariable( "current_host", "name"));
+ xh.addRule( "Host", xh.setVar( "current_host", "name"));
xh.addRule( "Host", xh.setProperties());
xh.addRule( "Context", new XmlAction() {
1.8 +46 -0
jakarta-tomcat/src/share/org/apache/tomcat/modules/config/ServerXmlReader.java
Index: ServerXmlReader.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/config/ServerXmlReader.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- ServerXmlReader.java 2001/02/27 17:09:37 1.7
+++ ServerXmlReader.java 2001/03/08 01:09:50 1.8
@@ -70,6 +70,7 @@
import org.apache.tomcat.core.*;
import org.apache.tomcat.modules.server.*;
import org.apache.tomcat.util.log.*;
+import org.apache.tomcat.util.IntrospectionUtils;
import org.xml.sax.*;
/**
@@ -115,6 +116,7 @@
XmlMapper xh=new XmlMapper();
xh.setDebug( debug );
xh.addRule( "ContextManager", xh.setProperties() );
+ setPropertiesRules( cm, xh );
setTagRules( xh );
addDefaultTags(cm, xh);
addTagRules( cm, xh );
@@ -161,6 +163,48 @@
}
}
+static class CMPropertySource
+ implements IntrospectionUtils.PropertySource
+{
+ ContextManager cm;
+
+ CMPropertySource( ContextManager cm ) {
+ this.cm=cm;
+ }
+
+ public String getProperty( String key ) {
+ if( "tomcat.home".equals( key ) ) {
+ return cm.getHome();
+ }
+ // XXX add other "predefined" properties
+ return cm.getProperty( key );
+ }
+}
+
+public void setPropertiesRules( ContextManager cm, XmlMapper xh )
+ throws TomcatException
+{
+ CMPropertySource propS=new CMPropertySource( cm );
+ xh.setPropertySource( propS );
+
+ xh.addRule( "ContextManager/property", new XmlAction() {
+ public void start(SaxContext ctx ) throws Exception {
+ AttributeList attributes = ctx.getCurrentAttributes();
+ String name=attributes.getValue("name");
+ String value=attributes.getValue("value");
+ if( name==null || value==null ) return;
+ XmlMapper xm=ctx.getMapper();
+
+ ContextManager cm1=(ContextManager)ctx.currentObject();
+ // replace ${foo} in value
+ value=xm.replaceProperties( value );
+ if( cm1.getDebug() 0 )
+ cm1.log("Setting " + name + "=" + value);
+ cm1.setProperty( name, value );
+ }
+ });
+}
+
public void addTagRules( ContextManager cm, XmlMapper xh )
throws TomcatException
{
@@ -224,6 +268,7 @@
public static Vector getUserConfigFiles(File master) {
File dir = new File(master.getParent());
String[] names = dir.list();
+ // System.out.println("getUserConfigFiles " + dir );
String masterName=master.getAbsolutePath();
@@ -231,6 +276,7 @@
String ext=FileUtil.getExtension( masterName );
Vector v = new Vector();
+ if( names==null ) return v;
for (int i=0; inames.length; ++i) {
if( names[i].startsWith( base )
( ext==null || names[i].endsWith( ext )) ) {
1.6 +3 -1
RE: Design Review for ajp13's changes: WAS problem w/ ajp13 - if Tomc at is shutdown
Title: RE: Design Review for ajp13's changes: WAS problem w/ ajp13 - if Tomc at is shutdown Attached are the unified diffs for the proposed changes. They are diffs against the 3.2.1 release code. I hope this is sufficient. I haven't got to use Solaris patch tool yet. These are tested on Solaris 2.8. Changes #1 is the one that's less platform specific, since I don't call any socket APIs. I will test these on Windows 2000 tomorrow. As of other UNIXes, we don't have those in house. So if someone can volunteer testing it on other UNIX flavors, that will be great! Unified diffs for the proposed changes #1: jk_ajp13_worker.c.1.diff mod_jk.c.1.diff Unified diffs for the proposed changes #2: jk_ajp13_worker.c.2.diff jk_connect.c.2.diff thanks so much! shinta -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 07, 2001 6:57 PM To: '[EMAIL PROTECTED] ' Subject: Re: Design Review for ajp13's changes: WAS problem w/ ajp13 - if Tomc at is shutdown Hi Shinta, It's sounds like a solution to a real problem, please send a patch, I'm sure someone will read it. Dan and Henri are the best people to ask about this, I can also help a bit ( I've been using RPMs lately, it's too easy to get them and not worry about compile :-) My only sugestion/concern is that the code should work on both Windows and unix - or at least compile :-) Costin I would like to propose some changes to eliminate the requirement to restart Apache, when you restart Tomcat. I'm willing to give the code to anyone who needs it, when I'm done testing. But I need some help/suggestions so that I can put in the right code. If any of the proposed changes below should not exists ever, I'm open to other suggestions. This is my first time looking at mod_jk's ajp13 code. So any clue to make these better would be appreciated. Right now, if you use ajp13 and you restart Tomcat, you have to also restart Apache. See details in previous postings. For us, having to restart Apache is not a feasible solution in our customers' environment. After looking at the code, I have two possible solutions: 1. From mod_jk, I can detect that the socket has been closed by Tomcat. This is normally indicated by the recv() returning ECONNRESET. The recv() is called after the request has been sent to the socket. The send() unfortunately, doesn't give you an error. The proposed fixed is to check for errno ECONNRESET, then set the is_recoverable_error flag to TRUE, in the service() function in jk_ajp13_worker.c. I also add a code in mod_jk.c, to check for this flag, and call the service() method again if the flag is set TRUE. The 2nd time the service() method is called, it will reconnect to Tomcat like normal. 2. Another solution would be to put in a select() on the socket prior to send(), looking for the socket being read ready. Under normal condition, this select() should return nothing. But if Tomcat shuts down the socket, this select() should return the socket being read ready. When this happen, I issue a read() of 1 bytes. If the read() comes back with return code 0, this should be an indication that the socket was closed on the remote end. Then I will proceed to close the socket. The remaining logic already handles the reconnect, etc. I have both of these solution prototyped and minimally tested. They both Anyone care to comment which solution fits better with the overall code? Anyone voluteer to review the code? thanks, shinta -Original Message- From: Shinta Tjio To: [EMAIL PROTECTED] Cc: 'Dan Milstein' Sent: 3/6/01 7:01 PM Subject: RE: FW: problem w/ ajp13 - if Tomcat is shutdown I am using Tomcat 3.2.1, Apache 1.3.14, running on Solaris 2.8, Sun machines. After various attempts of debugging this, I have more information. 1. Even though I'm setting the worker's property cache_size to default (1), I'm finding there are up to 6 connections opened from Apache to Tomcat. I deduce this by looking at the mod_jk.conf and by doing netstat. I finally find out, this is so because my Apache is set to spawn minimum of 6 children and each of those children are making separate connections to Tomcat. This is very bad because, I ended up having to reload 6 times before Tomcat starts serving me the page again. Each time it uses a different Apache children that has defunct socket. So the more Apache children I have, the longer it takes me to recover from this problem. 2. It seems when Tomcat dies restarts, the send() called by ajp13's jk_tcp_socket_sendfull() does not get an error. But the recv() does get an error, with errno ECONNRESET. After which, the socket is properly closed. 3. When I shutdown Tomcat, those sockets
Tomcat 4 server.xml Listener ... / bug
We are trying to implement a Listener ... / to be configured in the Tomcat 4 server.xml within a Context ... / or DefaultContext ... /. When Tomcat starts up the Context and tries to add the Listener Class a ClassNotFoundException is thrown for the org.apache.catalina.LifecycleListener interface which it has to implement in order to be a Listener. Has anyone tried to implement and test a Listener recently in Tomcat 4? org.apache.catalina.LifecycleListener is located in /server/lib/catalina.jar, so the ClassLoader hierarchy is Server - Common - System - Bootstrap. I suspect the problem is that the code that tries to setup the Listener is in the ClassLoader hierarchy Webapp - Shared - Common - System - Bootstrap. Regards, Glenn -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: tag handler pooling ideas
Casey Lucas wrote: I am planning on implementing tag handler pooling and would like to throw out a few ideas for feedback: assumptions: - Tag handlers can only be reused if the same set of attributes are used for the tag. - Tag.relese is called only once -- at some point before the handler is garbage collected. I believe you must add one more restriction on reuse: you can only reuse tag handlers that are on the same nesting level. For instance, this case requires two tag handler instances even though they have the same set of attributes: x:tag1 attr1="a" attr2="b" x:tag1 attr1="xyz" attr2="123"/ /x:tag1 basic idea: My general idea was to have a collection of named pools. Jasper could then render code to use the named pool to obtain handler instances instead of newing them each time. more info: Each tag handler pool would have a name that would include the tag's short name and the set of attributes that were used on the tag. If by "short name", you mean something that identifies both the tag library and the tag, I'm with you. The prefix is not enough. The prefix is assigned per page, and you can actually use different prefixes for the same library in different pages, so you need another unique name for the tag library as such. The same problem exists with the taglib uri attribute value. Maybe you can use the context-relative path to the TLD; no matter how the TLD is identified by the taglib directive's uri attribute, it must always be resolved to a path to the TLD, and that must be unique within one app. This would give us the correct reuse level. So for the following tags there would be two named pools (after taking into account attributes): x:tag1 attr1="a" attr2="b"/ x:tag1 attr1="xyz" attr2="123"/ x:tag1 attr1="a"/ To eliminate the need to lookup the pool by name each time a tag was needed, pool references could be rendered and initialized (looked up) when the jsp is initialized. Inside the main jsp method (_jspService), the pool references would be used directly. I'm not sure I follow. When the pools are removed (shutdown, reload, etc.) Tag.release will be called for each of the handlers. I assume that pools need to be per web application, but haven't given it a lot of thought. Right. Hans -- Hans Bergsten [EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: tag handler pooling ideas
Just a quick note - my experience so far with server-side performance is that it doesn't matter how many objects you create, as long as you do it only once ( and not for each request ). I don't think doing any reuse inside a page ( i.e. same tag instance beeing reused during a request ) is worth the effort at this stage - you'll get most of the benefit and improvements by just using a pool and reusing the tags from request to request - if possible. Later you can do more advanced things. Another note - it would be nice if the pool interface is not very hardcoded in the implementation. Most of the time there is a sync() that is hard to avoid in pools, and you get a good improvement by using thread data ( in a form or another ). This is a bit hard because the same page may be accessed in multiple threads - so you'll have to keep tag instances duplicated per thread - but there are solutions to control it without affecting the response time, and most of the times few pages get most of the hits - so it's not like all the tags from all the pages will be cached at all times. Costin On Wed, 7 Mar 2001, Casey Lucas wrote: I am planning on implementing tag handler pooling and would like to throw out a few ideas for feedback: assumptions: - Tag handlers can only be reused if the same set of attributes are used for the tag. - Tag.relese is called only once -- at some point before the handler is garbage collected. basic idea: My general idea was to have a collection of named pools. Jasper could then render code to use the named pool to obtain handler instances instead of newing them each time. more info: Each tag handler pool would have a name that would include the tag's short name and the set of attributes that were used on the tag. This would give us the correct reuse level. So for the following tags there would be two named pools (after taking into account attributes): x:tag1 attr1="a" attr2="b"/ x:tag1 attr1="xyz" attr2="123"/ x:tag1 attr1="a"/ To eliminate the need to lookup the pool by name each time a tag was needed, pool references could be rendered and initialized (looked up) when the jsp is initialized. Inside the main jsp method (_jspService), the pool references would be used directly. When the pools are removed (shutdown, reload, etc.) Tag.release will be called for each of the handlers. I assume that pools need to be per web application, but haven't given it a lot of thought. Any comments / suggestions? -Casey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/core Container.java
costin 01/03/07 19:51:27
Modified:src/share/org/apache/tomcat/core Container.java
Log:
Small fix - getContextManager() instead of contextM.
Probably some of those lazy-initialziations should be removed - it's
great for performance when it's in the critical path, but for initialization
it doesn't matter.
Revision ChangesPath
1.49 +10 -4 jakarta-tomcat/src/share/org/apache/tomcat/core/Container.java
Index: Container.java
===
RCS file: /home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/Container.java,v
retrieving revision 1.48
retrieving revision 1.49
diff -u -r1.48 -r1.49
--- Container.java2001/02/27 06:59:14 1.48
+++ Container.java2001/03/08 03:51:26 1.49
@@ -374,12 +374,14 @@
}
public Object getNote( String name ) throws TomcatException {
- int id=contextM.getNoteId( ContextManager.CONTAINER_NOTE, name );
+ int id=getContextManager().getNoteId( ContextManager.CONTAINER_NOTE,
+ name );
return getNote( id );
}
public void setNote( String name, Object value ) throws TomcatException {
- int id=contextM.getNoteId( ContextManager.CONTAINER_NOTE, name );
+ int id=getContextManager().getNoteId( ContextManager.CONTAINER_NOTE,
+ name );
setNote( id, value );
}
@@ -399,8 +401,10 @@
public static final int H_postService=10;
public static final int H_postRequest=11;
public static final int H_handleError=12;
-public static final int H_engineInit=13;
-public static final int H_COUNT=14;
+public static final int H_getInfo=13;
+public static final int H_setInfo=14;
+public static final int H_engineInit=15;
+public static final int H_COUNT=16;
Hooks hooks=new Hooks();
BaseInterceptor hooksCache[][]=null;
@@ -420,6 +424,8 @@
hooks.registerHook( "postService", H_postService );
hooks.registerHook( "postRequest", H_postRequest );
hooks.registerHook( "handleError", H_handleError );
+ hooks.registerHook( "getInfo", H_getInfo );
+ hooks.registerHook( "setInfo", H_setInfo );
hooks.registerHook( "engineInit", H_engineInit );
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
RE: tag handler pooling ideas
Thanks for the comments. Just a quick note - my experience so far with server-side performance is that it doesn't matter how many objects you create, as long as you do it only once ( and not for each request ). Right. I was planning on using a web-application-wide collection of pools. I don't think doing any reuse inside a page ( i.e. same tag instance beeing reused during a request ) is worth the effort at this stage - you'll get most of the benefit and improvements by just using a pool and reusing the tags from request to request - if possible. Later you can do more advanced things. True. I didn't plan on tackling that one yet. So, each time a new handler is needed in a page, it will be retrieved from its pool. Another note - it would be nice if the pool interface is not very hardcoded in the implementation. Do you mean using interfaces, etc? If so, I agree. Most of the time there is a sync() that is hard to avoid in pools, and you get a good improvement by using thread data ( in a form or another ). This is a bit hard because the same page may be accessed in multiple threads - so you'll have to keep tag instances duplicated per thread - but there are solutions to control it without affecting the response time, and most of the times few pages get most of the hits - so it's not like all the tags from all the pages will be cached at all times. Well I can do a pool per thread, but my assumption is that there could possibly be a lot of tag handlers sitting around. Should this be a concern? Also, I don't know the exact thread pooling model that Tomcat uses, but if it creates and destroys worker thread, that will hurt the pool-per-thread model. By doing a web application wide collection of pools, there will be a synchronized pop (or similar) per handler retrieval and a synchronized push (or similar) per handler return to the pool. The synchronization will occur for handlers that are in the same pool across pages. Do you think this might be a problem? I was thinking of a simple approach to the size of the pools: make sure that a handler is always available. This means that the size of each pool will grow to the max number of concurrent handlers used. This case is not any worse than the current case (newing one each time). -casey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: tag handler pooling ideas
On Wed, 7 Mar 2001, Casey Lucas wrote: Well I can do a pool per thread, but my assumption is that there could possibly be a lot of tag handlers sitting around. Should this be a concern? Also, I don't know the exact thread pooling model that Tomcat uses, but if it creates and destroys worker thread, that will hurt the pool-per-thread model. It doesn't matter what tomcat uses - this should work on other containers and models as well ( most decent containers are reusing the threads, if they don't probably the performance is bad anyway, or they have special needs - like small footprint ). It's important to just keep in mind that maybe later it should be possible to "tune" this and use some other mechanisms ( in adition or instead of the pool ). You probaly don't have to do anything right now - pool is a good start. By doing a web application wide collection of pools, there will be a synchronized pop (or similar) per handler retrieval and a synchronized push (or similar) per handler return to the pool. The synchronization will occur for handlers that are in the same pool across pages. Do you think this might be a problem? One collection per webapplication sounds good. Synchronization is not a big problem right now ( after you 2x the performance it'll be a bit more visible ). Keep in mind that a GC is also synchronizing, and object allocation does a sync() too ( most of the time ). Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/core BaseInterceptor.java Request.java
costin 01/03/07 23:23:05
Modified:src/share/org/apache/tomcat/core BaseInterceptor.java
Request.java
Log:
My last change for M2 - replaced the attempted get/setNote with
get/setInfo.
The hook is intended for lazy evaluation of request informations like
the encoding and for more flexibility in attributes like the SSL chain.
Tomcat performance is due in part to the lazy evaluation - certain fields
in request are not used in all requests, and pre-computing them is a waste.
There is another problem - supporting attributes like the SSL chain
no longer requires the SSL module to set an attribute ( i.e. the chain ),
but can be delayed until and if the request needs it.
In the case of encoding - while this doesn't change too much in the
current implementation, it allows modules to provide smarter mechanisms
to detect the charset and more optimizations.
Revision ChangesPath
1.44 +14 -2
jakarta-tomcat/src/share/org/apache/tomcat/core/BaseInterceptor.java
Index: BaseInterceptor.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/BaseInterceptor.java,v
retrieving revision 1.43
retrieving revision 1.44
diff -u -r1.43 -r1.44
--- BaseInterceptor.java 2001/03/04 03:31:52 1.43
+++ BaseInterceptor.java 2001/03/08 07:23:01 1.44
@@ -253,11 +253,23 @@
return 0;
}
-public Object getNote( Request request, int id ) {
+/** Hook for lazy evaluation of request info.
+ This provides and uniform mechanism to allow modules to evaluate
+ certain expensive request attributes/parameters when they are
+ needed ( if ever ), and allows specialized modules and
+ better integration with the web server/server modules.
+
+ This replaces a number of hard-coded constructs and should
+ clean up the core for un-needed dependencies, as well as provide
+ flexibility in key areas as encoding, etc.
+*/
+public Object getInfo( Context ctx, Request request,
+int id, String key ) {
return null;
}
-public int setNote( Request request, int id, Object obj ) {
+public int setInfo( Context ctx, Request request,
+ int id, String key, Object obj ) {
return DECLINED;
}
1.96 +75 -0 jakarta-tomcat/src/share/org/apache/tomcat/core/Request.java
Index: Request.java
===
RCS file: /home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/Request.java,v
retrieving revision 1.95
retrieving revision 1.96
diff -u -r1.95 -r1.96
--- Request.java 2001/02/27 19:10:14 1.95
+++ Request.java 2001/03/08 07:23:02 1.96
@@ -76,13 +76,37 @@
import java.util.Hashtable;
/**
+ * This is a low-level, efficient representation of a server request. Most fields
+ * are GC-free, expensive operations are delayed until the user code needs the
+ * information.
*
+ * Most processing is delegated to modules, using a hook mechanism.
+ *
+ * This class is not intended for user code - it is used internally by tomcat
+ * for processing the request in the most efficient way. Users ( servlets ) can
+ * access the information using a facade, which provides the high-level view
+ * of the request.
+ *
+ * For lazy evaluation, the request uses the getInfo() hook. The following ids
+ * are defined:
+ * ul
+ * lireq.encoding - returns the request encoding
+ * lireq.attribute - returns a module-specific attribute ( like SSL keys, etc ).
+ * /ul
+ *
+ * Tomcat defines a number of attributes:
+ * ul
+ * li"org.apache.tomcat.request" - allows access to the low-level
+ * request object in trusted applications
+ * /ul
+ *
* @author James Duncan Davidson [[EMAIL PROTECTED]]
* @author James Todd [[EMAIL PROTECTED]]
* @author Jason Hunter [[EMAIL PROTECTED]]
* @author Harish Prabandham
* @author Alex Cruikshank [[EMAIL PROTECTED]]
* @author Hans Bergsten [[EMAIL PROTECTED]]
+ * @author Costin Manolache
*/
public class Request {
public static final String SESSIONID_FROM_COOKIE="cookie";
@@ -219,8 +243,13 @@
return context;
}
+int encodingInfo;
+int attributeInfo;
+
public void setContextManager( ContextManager cm ) {
contextM=cm;
+ encodingInfo=cm.getNote( ContextManager.REQUEST_NOTE,"req.encoding" );
+ attributeInfo=cm.getNote( ContextManager.REQUEST_NOTE,"req.attribute" );
}
public ContextManager getContextManager() {
@@ -356,6 +385,22 @@
public String getCharacterEncoding() {
if(charEncoding!=null) return charEncoding;
+
+ Object result=null;
+ Context
