Re: Web hosting services +tomcat support
Yeah, this is probably off-topic, but... I've had stuff hosted at SpinWeb (http://www.spinweb.net) for 1-2 years, and they've been a total pleasure to deal with. Their Developer Account, for $35/month gives you Apache / Tomcat 3.2.1, MySQL, PHP, JSP, all sorts of goodies. And they've been very accomodating of various bizarre config requests I've hit them with. -Dan Amey, Chris wrote: Hi, Can any one recommend a good web host that supports tomcat 3+ Bugdet $20-$30 per month -- Dan Milstein // [EMAIL PROTECTED]
Re: Misusing dynamic binding when static binding would do.
curmudgeon mode This post is really not appropriate for this mailing list. This list is for discussion of development of the Tomcat server. You're writing about web application design issues / patterns. See: http://jakarta.apache.org/site/mail.html. This list is periodically consumed by flame wars (or vigorous debate) about application-level issues which really don't affect Tomcat development at all. IIRC, one or two of those was started by your posting this sort of article for comments. I don't think this list should be used for discussion of these issues. Everyone else: if you agree with me, please do not reply to Brad on the list. If you have something to say to him, let's please take it off the list. Brad: I don't think this is the appropriate forum for you to ask for review of your articles. /curmudgeon mode -Dan Brad Cox wrote: I would appreciate comments on the following draft of an article I've just added to the Web Application site. Go to http://virtualschool.edu/wap and click The Problem in the left column for the original. -- Dan Milstein // [EMAIL PROTECTED]
Re: ThreadPool safety checks
Hector, First off, it looks like you've done some very, very helpful work. A few suggestions: 1) For info about how to contribute code, processes, etc, look at: http://jakarta.apache.org/site/getinvolved.html And, specifically, about the format for proposed code changes (i.e. patches instead of full files): http://jakarta.apache.org/site/source.html 2) You might take a look at 3.2.2 -- it has a lot of bugfixes, and should be released live very soon. I don't know if any work was done on this particular issue, but it would be worth a quick check. Info about how to obtain 3.2.2 can be found on the site. Thanks again, -Dan Hector Gonzalez wrote: Hi all, After performing stress testing on Tomcat 3.2.1 running on Linux, I found that performance would always decrease over time until the server stopped responding completely. I was accessing tomcat as an stand alone server on port 8080 and requesting a servlet that returned a null body (null servlet), tomcat was running on IBM 1.3 JVM, using native threads. The clients where three machines each running 20 threads requesting the null servlet. Initially tomcat would handle about 400 requests/sec, but after about 20 minutes requests per second would be down to about 20, and thereafter tomcat would completely stop. After looking at the code, I found out that all the threads in the thread pool of tcp connections were busy and none would become idle. The attached TcpWorkerThreads would not return from processing the request, I don't really know why. I modified ThreadPool.java to perform two sanity checks on the pool: 1. If a thread has been processing a request for too long (as specified in a parameter) the thread is stoped. 2. After a thread has already processed X requests or more (X TcpWorkerThreads have been attached), it is terminated and a new thread is created. The checks are performed by the Monitor thread, when it calls checkSpareControllers. After implementing these changes I ran the stress tests again with very good results: performance remains at around 400 requests/sec indefinetly. The safety checks can be completely disabled through configuration parameters if desired. As I am new to this list, I am not sure what the procedure to review and possibly incorporate my changes into the code are. I modified three files: org.apache.tomcat.util.ThreadPool, org.apache.tomcat.util.ThreadPoolRunnable and org.apache.tomcat.service.PoolTcpEndPoint.java. I am attaching the modified files. There is a lot of debugging info in those, I could clean them up if you decide that it is worth including the changes in the main branch of Tomcat. Regards Hector Gonzalez QuestionExchange - http://www.questionexchange.com [EMAIL PROTECTED] Voice: (617)451-1527 Fax: (617)451-1487 Name: ThreadPool.java ThreadPool.javaType: unspecified type (application/octet-stream) Encoding: quoted-printable Name: ThreadPoolRunnable.java ThreadPoolRunnable.javaType: unspecified type (application/octet-stream) Encoding: quoted-printable Name: PoolTcpEndpoint.java PoolTcpEndpoint.javaType: unspecified type (application/octet-stream) Encoding: quoted-printable -- Dan Milstein // [EMAIL PROTECTED]
Re: servlet upload data corruption (more)
);
count = istr.read(buf);
}
}
fstr.flush();
fstr.close();
OutputStream ostr = response.getOutputStream();
ostr.write(1); // positive response
} catch (Exception ex) {
ex.printStackTrace();
}
}
}
--
Dan Milstein // [EMAIL PROTECTED]
Re: [VOTE] Final release of Tomcat 3.2.2
+0 (I don't think I'll have time to do any support), but way to go Marc!!! -Dan Marc Saegesser wrote: The latest beta cycle for Tomcat 3.2.2 has completed with no new bugs identified. As the release manager I propose that we release the tomcat_32 branch as Tomcat 3.2.2. Please indicate your vote for the release using the ballot below. I will tabulate and post the results of this vote on Friday, May 25. At that time, if the vote has passed, I will tag, build and distribute the release. The vote must pass by majority approval which means the proposal must receive at least three +1 votes and more +1 votes than -1 votes. Marc Saegesser - Vote to release the tomcat_32 branch as Tomcat 3.2.2. [ ] +1. I agree with the proposal and I will help support the release. [ ] +0. I agree with the proposal but I will not be able to help support the release. [ ] -0. I don't agree with the proposal but I won't stop the release. [ ] -1. I disagree with the proposal and will explain my reasons. -- Dan Milstein // [EMAIL PROTECTED]
Re: [VOTE] New Committer: Jean-Frederic Clere
+1 GOMEZ Henri wrote: I would like to propose Jean-Frederic Clere as a new committer. He make many contribution in jakarta-tomcat, jakarta-tomcat-4.0 and now in jakarta-tomcat-connectors, and we help us with stuff like autoconf, APR and exotics systems :) Vote Please -- Dan Milstein // [EMAIL PROTECTED]
Re: Trying New Connectors Build Stuff
Pier, If you want to keep the mod_webapp stuff in the TC 4.x branch, I respect that (I'm not as big a proponent of the new j-t-c project as Henri). So I guess that makes me +0 on the question you posed to the list. However, I did want to ask you about this: Could you tell us what's the problem with JK ? A sort of 'not invented here syndrom' ?) (joke...) Go and read my comments in the past, I believe I've been pretty descriptive of what I don't like in JK... As I remember your comments from the past, your biggest gripe (and a quite reasonable one) was that the code was totally incomprehensible and therefore unmaintainable. Is there something else beyond that? I ask mostly because I've put a lot of effort into cleaning up and documenting that code, and I hope that it is now much more workable. If you still find it difficult to read/understand, I'd love to know how/where. I still hold out hope that at some point in the future the mod_webapp protocoal (warp?) could be supported by mod_jk, so there would be only one C code base to support. -Dan -- Dan Milstein // [EMAIL PROTECTED]
Re: [PROPOSAL AJP14] AJP13 Evolution
( the socket will be kept open ) - when apache sends a request I think that should be enough for what we need - if we make it more complex we may add too much overhead. ( and we may not be able to have good support for Apache1.3 ) We allways have the choice of using a real ORB - so there is a limit in AJP's complexity ( when it starts having all the features of an ORB, we shoud just replace it with a real one :-) Costin -- Dan Milstein // [EMAIL PROTECTED]
Re: [PROPOSAL AJP14] AJP13 Evolution
ajp13 reuses connections, but, in general for each worker there will be a pool of connections between the web server and the servlet engine. That way it can handle multiple requests concurrently, but still save on the socket creation time (since connections are reused for many requests). So deciding which connection to send the admin messages on is, in fact, important. Not only do we have to watch out for resending data, but we also have to make sure we send data to all the participating web servers (multiple Apaches can talk to one TC, and, if they do so, they can all hit the same port, in which case some ajp13 threads are talking to one, some to another). Maybe we should tag the TC-Apache admin messages with an id -- that way we could just send them out on all conections, and the various Apache children would make sure they only react to a given message once (possibly communicating w/ each other via shared memory). This will make the problem of informing all participating Apache instances go away, and we may need to play some shared memory games in any event, to make sure that all the Apache procs are brought up to date. -Dan Mike Braden wrote: Why not just handle each connection as if it is a connection from a different server, logging in each time. Are ajp13 requests serialized? ajp13 only connects to TC once to the port set in the config, right? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of jean-frederic clere Sent: Tuesday, May 08, 2001 5:19 AM To: [EMAIL PROTECTED] Subject: Re: [PROPOSAL AJP14] AJP13 Evolution Apjp13 requests are not multiplexed, so we need more that one connection. How could we decide on which connection we send the admin message? Otherwise we will the send the same data more than once. -- Dan Milstein // [EMAIL PROTECTED]
Re: [PROPOSAL AJP14] AJP13 Evolution
Henri, Lots of good stuff. A few ideas/possibilities: 1) We've talked about specifying a response packet to indicate that the engine (or the web server) doesn't recognize a packet sent over. This would allow us much more flexiblity to add packet types to ajpv14, without having to make ajpv15,16, etc. 2) What about specifying a separate, out of band control socket connection? If the web server opened up two connections, 1 for data, one for control, then we could have much better communication from the engine to the server (if it was shutting down contexts, for example). We could also have a heartbeat without interfering with the data channel. -Dan GOMEZ Henri wrote: Hi to all, You could find attached a proposal of evolution to the current Apache JServ Protocol version 1.3, also known as ajp13. Let start the comments, questions, remarks cycle. PS : I've not cover here the full protocol but only the add-on from ajp13. - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 Name: AJPv14.txt AJPv14.txtType: Plain Text (text/plain) Encoding: quoted-printable -- Dan Milstein // [EMAIL PROTECTED]
Re: [VOTE] New Committer: Kevin Seguin
+1 GOMEZ Henri wrote: I would like to propose Kevin Seguin as a new committer. He make a great job in developping the ajp13 protocol for Tomcat 4.0 and this code will be a great help for sites wanting to upgrade from 3.2.x to 4.0 while still using mod_jk Henri -- Dan Milstein // [EMAIL PROTECTED]
Re: ajp13 question
Kevin, Excellent -- something I can actually answer! BTW, I'm cc'ing the list -- let's try to have this conversation on the mailing list. That way, everyone can learn and/or participate. The jvm route, as the AJPv13 doc says: ...is used to support sticky sessions -- associating a user's sesson with a particular Tomcat instance in the presence of multiple, load-balancing servers. Let's say you have a single Apache server feeding multiple TC instances. Once a TC instance starts a session for a user, you want all future requests in that session to be forwarded to that instance (so that session data can be held in memory on that box). Load balancing is done by the jk_lb_worker. In jk_lb_worker.c, l 318, the jvm_route property of the service object is set to the name by which the load balancer knows the particular jk worker (which communicates with a particular TC instance). Assuming that that is then an instance of jk_ajp13_worker, this will then get sent over to the TC instance via jk_ajp13.c (ll. 456-458) (this is documented in AJPv13.html). (BTW, if it's an instance of ajp12, it will still work, but we won't go into that here, since no one is porting ajp12 to TC 4). On the Tomcat side, that jvm route is: - Read out of the packet from Apache (in Ajp13.java) - Stored in the request (also in Ajp13.java) - When the session id cookie is generated (jsessionid=...), the jvmroute is tacked onto the end (after a ';') (in modules/session/SessionIdGenerator, I believe). - This cookie is sent to the browser Then, when the browser sends back the session cookie, it will also be sending back the jvmroute, which is the name by which jk_lb_worker knows the right instance of TC to route to. The jk_lb_worker object then reads that (in get_session_route), and routes that particular request to the proper instance of TC. Phew. Okay, so how to make this work in TC 4? I'm not sure -- as you can see from the above description, it's pretty deep in the internals of TC 3 (in the core request object). If you could store it as an extra attribute of the request object, and then modify whatever code creates the session id, you might be in business. You might also ask the list (which has many TC 4 experts) about the best way to handle this. Basically, though, the path is: - jk_lb_worker knows the name, passes it via the jvmroute attribute to TC. - TC inserts that into the session cookie, which is sent back the browser. - jk_lb_worker reads the name back, and uses that for routing. If you wanted to cheat (fine with me!), you could cut this feature out for now, and get ajp13 working *without* load-balancing (still useful), document that fact, and return to it later (or beg for help to fix it once you get everything else working). To do that, just have TC ignore whatever jvmroute is sent over. Everything but load-balancing should still work just fine. Have fun, -Dan kevin seguin wrote: what is the jvm route attribute for in ajp13? there doesn't appear to be an equivalent to Request.setJvmRoute in catalina... thanks. -- Dan Milstein // [EMAIL PROTECTED]
Re: ERROR using multipart/form-data POST request
This specific bug has been fixed in 3.2.2, and the relevant function (doRead()) has been extensively cleaned up. The 3.2.2 support for ajp13 is much, much better than in 3.2.1. -Dan Andrey Kartashov wrote: On Fri, Apr 27, 2001 at 11:17:32AM -0700, Lucian Cionca wrote: The reason for this is a bug in the doRead() method of Ajp13ConnectorRequest, which causes the doRead(byte[] b, int off, int len) in that same class to prematurely end processing . The bug is in the conversion of the value read from the bodyBuff byte-array, to an integer result. Bytes can have values from -128 to 127, while the result is expected to be a positive integer (in the range 0 to 255). A result of -1 is interpreted in the doRead(byte[] b, int off, int len) method as an error/end of input. The patch to Tomcat sources is very simple. In function int doRead() in Ajp13ConnectorRequest.java instead of the line return bodyBuff[pos++]; the line return bodyBuff[pos++] 0xFF; should be used. Credit for the solution should go to Amir Nuri [EMAIL PROTECTED] who indicated the solution to me. On the other hand there is always the workaround to use ajp12 for the specific servlets that use multipart/form-data POST. [skpd] Thank you all for looking into this problem! I looked at doRead(...) function that you've mentioned and I think I'm going to stick with ajp12 for now:) It seems that this function is just a temporary hack anyway (at least this is what comment says). For one thing I'm not sure that it'll properly behave in all the cases because it always returns len. If I'm not mistaken - this means that it's possible to read more data than there is which may confuse some other code:) I compared it to the same function in Ajp12 implementation and I like ajp12 one better because it utilizes java's BufferedInputStream which I hope always does the right thing :) Anyway, thanks again for your help! -- oo Andrey oo oOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOo All mail clients suck. This one just sucks less. -- http://www.mutt.org/ Jeremy Blosser oOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOo -- Dan Milstein // [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/facade HttpServletResponseFacade.java
Marc,
In terms of connectors, I think request.isSecure() only works with ajp13.
So, if a user is connected via ajp12, and the web server tries to do a
url-rewriting of an https URL, I think this code will get it wrong. It
might be better to check the request url itself to see if it begins with
"https://" (case-insensitively).
-Dan
[EMAIL PROTECTED] wrote:
marcsaeg01/04/16 09:02:13
Modified:src/share/org/apache/tomcat/facade Tag: tomcat_32
HttpServletResponseFacade.java
Log:
Completes the fix for Bugzilla 578. In addtion to needing the protocol handler
for HTTPS, the URL encoder also needs to properly determine the default port for
secure connections in addition to normal HTTP connections.
PR: 578
Submitted by: [EMAIL PROTECTED] (Santiago Gala)
Revision ChangesPath
No revision
No revision
1.6.2.4 +10 -7
jakarta-tomcat/src/share/org/apache/tomcat/facade/Attic/HttpServletResponseFacade.java
Index: HttpServletResponseFacade.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/facade/Attic/HttpServletResponseFacade.java,v
retrieving revision 1.6.2.3
retrieving revision 1.6.2.4
diff -u -r1.6.2.3 -r1.6.2.4
--- HttpServletResponseFacade.java2001/03/06 17:38:13 1.6.2.3
+++ HttpServletResponseFacade.java2001/04/16 16:02:12 1.6.2.4
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/facade/Attic/HttpServletResponseFacade.java,v
1.6.2.3 2001/03/06 17:38:13 marcsaeg Exp $
- * $Revision: 1.6.2.3 $
- * $Date: 2001/03/06 17:38:13 $
+ * $Header:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/facade/Attic/HttpServletResponseFacade.java,v
1.6.2.4 2001/04/16 16:02:12 marcsaeg Exp $
+ * $Revision: 1.6.2.4 $
+ * $Date: 2001/04/16 16:02:12 $
*
*
*
@@ -353,11 +353,14 @@
return (false);
if (!request.getServerName().equalsIgnoreCase(url.getHost()))
return (false);
-// Set the URL port to HTTP default if not available before comparing
-int urlPort = url.getPort();
-if (urlPort == -1) {
+// Set the URL port to the HTTP(S) default if not available before comparing
+int urlPort = url.getPort();
+if (urlPort == -1) {
+if(request.isSecure())
+urlPort = 443;
+else
urlPort = 80;
-}
+}
if (request.getServerPort() != urlPort)
return (false);
String contextPath = request.getContext().getPath();
--
Dan Milstein // [EMAIL PROTECTED]
Re: CVS / mod_webapp / web-connector sub-project
In terms of integrating mod_jk/mod_webapp, I think this might be worthwhile -- specifically, mod_jk was built to handle a variety of protocols (ajp12, ajp13, etc.). So writing a protocol handler for the mod_webapp protocol would give a lot of benefits -- load-balancing, support for a variety of web servers, debugged C code. Pier had mentioned a while ago that the mod_jk code was completely incomprehensible. Gal Shachor basically wrote his own object system in C, which is very, very confusing at first. I've added a lot of comments in the 3.3 branch, particularly to common/jk_service.h, with the explicit goal of making it easier for people to write new protocol handlers and/or new web server plugins. One thing I can imagine being a problem right off the bat would be that the abstractions which allow mod_jk to deal with a variety of web servers may not support the fine-grained control over configuration which mod_webapp supports. Splitting off a connectors sub-project: I don't think I support this -- it was discussed on the list a few months ago, and my objections from then still hold. Sharing session-information around: feels way too complex -- I think there are better ways to get persistent sessions. Overloading the (already-complicated) web server/servlet container communication stream seems like asking for trouble we don't need. -Dan GOMEZ Henri wrote: Fine to see mod_webapp back to life :) 1) You added many features interesting in building (autoconf, apr) which we could study to adapt to mod_jk (at least autoconf). 2) I plan to update the mod_webapp RPM and hope the code will compile under GCC (it wasn't the case with tc 4.0b2/b3) 3) You still didn't tell us what you think into merging mod_webapp and mod_jk. Why not use mod_webapp/mod_jk to start the web-connector sub-project allowing us to remove many question related to connectors from Tomcat user/dev lists ? The same web-connector project could be used against Tomcat 3.2/3.3/4.0 but not be restricted to Tomcat. Any project understanding the concept of HTTP request/reply could use it. Much more what about using the connector to have the Apache store sessions (serialized) data from Tomcat. Here is the idea : - One Apache may be connected to multiple Tomcat (TomcatA/TomcatB). - Each Tomcat have sessions related data which may be good to see available to other Tomcats in case of failure : ie: TomcatA create a session and data in that session. When replying to Apache (via mod_jk or mod_webapp) it also send the session datas (serialized) when they are created (or updated). Apache store that informations for possible future use (db1/gdb) TomcatA fail (stopped, restarted, jvm dumped...) and Apache (via at least mod_jk) decide to route the request to TomcatB. TomcatB miss the session datas allready generated by TomcatA but Apache could route the request ALONG WITH THE previously saved session informations. TomcatB could then recreate the session, set the session data and then serve the request in the same condition that TomcatA. You get a real fault-tolerant system (no need to resign in some case). What do you think about that proposal (Costin, Craig, Dan, Jon, Pier...) - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -- Dan Milstein // [EMAIL PROTECTED]
Re: mod_webapp, mod_jk etc.
I can't speak to mod_webapp, but a mod_jk response: - I understand the need for the TCP connections to be persistent in mod_jk and mod_webapp, but I'm not sure why another connection wouldn't be attempted after the reuse of the previous connection fails; This was just added to the 3.3 branch (by Henri) for mod_jk -- if the Apache plugin detects a dead connection, it opens a new one (so you don't have to restart Apache when you restart Tomcat). Needs testing, but it's in there. -Dan -- Dan Milstein // [EMAIL PROTECTED]
Re: ajp13 and tomcat restart - next (final) release + AJ13 PROPOSAL
Henri, 1) Moving op-recoverable -- I looked more carefully, and you're right -- the uploadmode flag is guarding against the situation I was thinking about. So it's fine the way it was. One (minor) naming note -- that flag gets set if there is more than 8K of request data, which can happen due to a file upload, but could also just happen normally (via a few big TEXTAREA's, for instance). So it's more large_request_mode, than upload_mode. Just to mention it... 2) Adding context/webapp load/unload. Great idea, but... One of the biggest problems with ajp13 right now is that there is no general way for TC to send a message to the Web Server. The commands you're adding would need to be sent from Tomcat to Apache, but that can only be done once Apache has forwarded a request to Tomcat and is waiting for a response (and a user servlet has its hands on the connection at that point). So I'm not sure how to add the feature you're looking for. If we could add that, we could also have Tomcat inform the web server of a general shutdown, so we could be more proactive about recycling TCP connections. -Dan GOMEZ Henri wrote: Looks about ready for more general testing. I like the new ajp13_operation. Two things: 1) l. 648 (op-recoverable = JK_FALSE). I set op-recoverable to JK_FALSE just after detected upload mode (dropped var) Find included the latest .c since I miss diff cmd under W2K rigth now. Where could we put code in Ajp13Interceptor which could be informed of context load/unload ? I'd like to add context/webapp load/unload la mod_warp :) will be new cmds in JK : LOADEDCONTEXT + WEBAPP STRING #define JK_AJP13_LOADED_CONTEXT (unsigned char)8 UNLOADEDCONTEXT + WEBAPP STRING #define JK_AJP13_UNLOADED_CONTEXT (unsigned char)9 Another proposal Strongest ACL (LOGIN + SECRET STRING + PROTOCOL SETS) #define JK_AJP13_LOGIN (unsigned char)10 Comments ? Name: jk_ajp13_worker.c jk_ajp13_worker.cType: unspecified type (application/octet-stream) Encoding: quoted-printable -- Dan Milstein // [EMAIL PROTECTED]
Re: ajp13 and tomcat restart - next (final) release
Henri (+ Larry), Looks about ready for more general testing. I like the new ajp13_operation. Two things: 1) l. 672 (op-recoverable = JK_FALSE). I believe that should be outside of the if statement (i.e. immediately after the connection_tcp_send_message). The whole thing becomes unrecoverable as soon as the 2nd buffer of data gets sent over to TC (at line 669), not just if there was an error during that send. 2) Larry -- what's your feeling about putting this in the next 3.3 milestone? It's certainly a very heavily requested feature, but I wouldn't want to swear to its correctness/robustness just yet. -Dan GOMEZ Henri wrote: Hi, You could find here the latest patch for ajp13/mod_jk when tc is restarted. Seems fine and ready to be commited. PS: I'll add timestamp in mod_jk logs but I'd like also to remove the datasync in log since it's just to much I/O consuming in debug mode (Ok ?) Name: jk_ajp13_worker.c.diff jk_ajp13_worker.c.diffType: unspecified type (application/octet-stream) Encoding: quoted-printable -- Dan Milstein // [EMAIL PROTECTED]
Re: Mod_jk for Solaris 8- Apache 1.3.17-Tomcat 3.2.1
Take a look at the most recent 3.2.x code -- people have cleaned up some of the mod_jk docs, and there may be something there which will help you. You could either download TC 3.2.2b1 (or 2, once Marc gets that out), or pull the latest thing from cvs (the tomcat_32 tag). -Dan "Hardy, Maurice" wrote: Hi, I need to compile mod_jk for Tomcat 3.2.1 and Apache 1.3.17. Apparently, the source code directory structure doesn't match the Mod_jk compile instructions. On this particular source the file seems missing . Is there an easier or another way to compile this ? Are there some updated instructions on "How To Get Mod_jk Working" ? i need any help that you can offer. Thanks -M- Name: Notebook.jpg Notebook.jpgType: JPEG Image (image/jpeg) Encoding: base64 -- Dan Milstein // [EMAIL PROTECTED]
Re: Timestamps in mod_jk.log
Shahed, As one of the current mod_jk maintainers, I can tell you that (sadly), I'm not going to be able to work on that any time soon (there are a bunch of more pressing connector-related things on my plate). However, I *did* just finish adding a raft of comments to the mod_jk code, and I'm hoping to add more (that's high on my list). So, if you wanted to take a crack at this yourself, you might check out the most recent version of 3.3 (jakarta-tomcat), and take a look through the mod_jk code there. the src/native/mod_jk/common/jk_util.c has the logging code... -Dan Shahed Ali wrote: Hi, Could the developers of mod_jk please add timestamp logging and if possible request url to mod_jk.log ? Thanks Shahed. -- Dan Milstein // [EMAIL PROTECTED]
Re: [STATUS] Tomcat 3.2.2
Marc, I just want to say that it is fantastic that you have managed to corral all those loose bug reports. -Dan Marc Saegesser wrote: Well, it took longer than I had hoped, but we have finally managed to review *all* open bug reports against Tomcat-3! The only reports left in the NEW state are those specifically opened against Tomcat 3.3. All the others have either been closed as FIXED, WORKSFORME or INVALID. A big THANK YOU to everyone who helped make this happen. My plan is to use tomorrow, Thursday (3/22/01) for some final testing. On Friday morning (Central US time) I will tag and build Tomcat 3.2.2 beta 2. This beta will last two weeks, during which time the only commits to the tomcat_32 branch will be for fixing critical bugs identified during the beta period. At the end of the beta period I will call a vote for the release of Tomcat 3.2.2. Marc Saegesser -- Dan Milstein // [EMAIL PROTECTED]
Re: VHosting
Thom,
There was vigorous back and forth about this on the mailing list a few
weeks back -- I'll paste in the final message in the thread -- you could
also take a look in the archives for more details. This is from Henri:
-Dan
==
The correct config for mod_jk is :
in httpd.conf :
JkWorkersFile /etc/httpd/conf/workers.properties
JkLogFile /var/log/httpd/mod_jk.log
# set it to error since warn just load to many apache
JkLogLevel error
for virtuals
VirtualHost host1.com:80
DocumentRoot"/home/httpd/host1/html"
Directory "/home/httpd/host1/html"
Options FollowSymLinks MultiViews
AllowOverride AuthConfig
Order allow,deny
Allow from all
/Directory
ServerName host1.com
ServerAdmin [EMAIL PROTECTED]
ErrorLog/home/httpd/host1/var/log/httpd/error_log
TransferLog /home/httpd/host1/var/log/httpd/access_log
JkMount /app1/servlet/* workerhost1
JkMount /app1/*.jsp workerhost1
/VirtualHost
VirtualHost host1.com:443
DocumentRoot"/home/httpd/host1/htmls"
Directory "/home/httpd/host1/htmls"
Options FollowSymLinks MultiViews
AllowOverride AuthConfig
Order allow,deny
Allow from all
/Directory
Alias /usage/ "/home/httpd/host1/usage/"
Directory "/home/httpd/host1/usage"
Options Indexes MultiViews
AllowOverride None
Order allow,deny
Allow from all
/Directory
ServerName host1.com
ServerAdmin [EMAIL PROTECTED]
ErrorLog/home/httpd/host1/var/log/httpd/error_log
TransferLog /home/httpd/host1/var/log/httpd/access_log
SSLEngine on
SSLCipherSuite
ALL:!ADH:!EXP56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
SSLCertificateFile
/home/httpd/host1/etc/httpd/conf/ssl.crt/host1.com-server.crt
SSLCertificateKeyFile
/home/httpd/host1/etc/httpd/conf/ssl.key/host1.com-server.key
Files ~ "\.(cgi|shtml|phtml|php3?)$"
SSLOptions +StdEnvVars
/Files
Directory "/home/httpd/cgi-bin"
SSLOptions +StdEnvVars
/Directory
SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown
downgrade-1.0 force-response-1.0
CustomLog /home/httpd/host1/var/log/httpd/ssl_request_log "%t %h
%{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
JkMount /secureapp1/servlet/* workerhost1
JkMount /secureapp1/*.jsp workerhost1
/VirtualHost
.
Note the way to use SSL in this case to use secureapp1 webapp ;-)
Thom May wrote:
Folks,
has anything happened with vhost support with mod_jk/apache 1.3 in 3.3?
I've not had a chance to look recently and I really need it...
ta,
-Thom, stuck in wet and miserable london for the next 3 weeks
--
Dan Milstein // [EMAIL PROTECTED]
Re: ajp13 restart patch - next step
Henri, A few more problems: 1) Take a look at ll. 592-600. In case of a POST request, this will overwrite the initial buffer (imsg) with the POST data. If TC is then restarted, and that request is resent, it will be garbage (POST data instead of request data). How best to fix this? I would say, pass in *both* buffers to send_request function. I might call them request_msg and data_msg. Use request_msg up to l 592, and then, if there is extra data, send it over in data_msg. Will this be fully restartable? I'm not absolutely sure -- it all depends on whether or not we can reread the POST data from Apache after a restart (actually, from *all* of the servers supported by mod_jk). This depends on the read() function of the web_server_service object -- look in mod_jk.c ll. 219-241. I don't know the Apache API well enough to understand how this would work if called more than once for the POST data. To fully support the other web servers, we'd have to understand if the read() method allowed rereading the initial data. 2) is_recoverable_error is passed into send_request, and it's value is assigned to, but it is in no way checked/used. Was this also true of the old jk_ajp13 code? (I believe so, but I'm not sure). If it's genuinely not being used, we should remove it, but I would like to understand what it should be doing, and make sure we're not missing an error state somewhere. 3) Log message errors: l. 639 Should be "Error reading reply", I think. l. 663 should be "Error sending request data", I think. 4) Still using 4-space tabs. A quick look through some of the other C classes suggests that most of them don't use tabs at all (just spaces). Let's try to emulate that -- I'll try to stop using 8-space tabs. -Dan GOMEZ Henri wrote: Oups not the up to date code. Find attached the correct patch. It will correctly handle the tomcat failure (when restarted or down) during upload mode -Original Message- From: GOMEZ Henri [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 20, 2001 1:40 PM To: [EMAIL PROTECTED] Cc: Dan Milstein (E-mail); Keith Wannamaker (E-mail) Subject: ajp13 restart patch - next step Hi, You could find attached the latest patch for mod_jk ajp13_worker. The imsg buf stand now for initial msg. I fixed the naming. Thanks to comments before I commit it. Name: jk_ajp13_worker.c.diff jk_ajp13_worker.c.diffType: unspecified type (application/octet-stream) Encoding: quoted-printable -- Dan Milstein // [EMAIL PROTECTED]
Re: ajp13 restart patch - next step
Henri, You're right. I strongly didn't like to see that mixed use of buffer for both input and output. We have now system with Mb of RAM and trying to save some Kb is a pitty. We must use at least 2 differents buffers : One buffer apache = tomcat , another tomcat = apache That would be fine, but you'd actually need a third to hold the initial request data (since the apache = tomcat buffer can otherwise get overwritten by POST data -- even if there is no file upload). That could actually be nice -- that way you could hold onto the POST data in the apache = tomcat buffer, and you could do a safe restart if there was 8K of POST data / file upload. Will this be fully restartable? I'm not absolutely sure -- it all depends on whether or not we can reread the POST data from Apache after a restart (actually, from *all* of the servers supported by mod_jk). We must'nt assume that. In my actual patch by line 633 you'll see a canrecover var that I set to true when seeing a upload mode. In that case I consider the situation to be unrecoverable. The solution is in that case to save all upload datas to file and in case of error, redo from that file. Yes, but you're not setting that when there is POST data -- and it sounds like either a) you need a third buffer as above or b) you need to give up on requests with POST data. You would have to pass this back out of send_request (since that is where the POST data gets sent over). I incline towards (a). I'm not sure that in case of large upload (ie Mb) Apache store data from browser somewhere. Did HTTP allow us to reask to browser to restart the upload ? I just looked through the HTTP spec (RFC 2616), and the File Upload spec (RFC 1867), and I'm not seeing anything which would help us. There is a "503 Service Unavailable" return status code, but I would be astounded if most browsers handled this correctly (i.e. they pay attention to the "Retry-After" header). We could just send 503 with a Retry-After: of 1 second, and maybe it would work. I dunno. I feel okay with saying that, if the client is in the middle of a file upload or a large POST, they just get a server error (we are restarting TC, after all -- that's going to generate some error conditions). 2) is_recoverable_error is passed into send_request, and it's value is assigned to, but it is in no way checked/used. Was this also true of the old jk_ajp13 code? (I believe so, but I'm not sure). If it's genuinely not being used, we should remove it, but I would like to understand what it should be doing, and make sure we're not missing an error state somewhere. It is checked at line 737. If false we stop there. Yes, but, it is reset to JK_TRUE on 732. Which is *after* send_request is called. So, if send_request sets is_recoverable_error to JK_FALSE, it is prompty reset to JK_TRUE, get_reply is called, and only then is it checked on line 737. So whatever send_request is doing with is_recoverable_error is being totally ignored. This is what worries me. 4) Still using 4-space tabs. A quick look through some of the other C classes suggests that most of them don't use tabs at all (just spaces). Let's try to emulate that -- I'll try to stop using 8-space tabs. Yes, I'm not confortable with 4/8 tab switch between java and C. But not the 'core business' ;-) No worries -- I just fixed my .emacs so that it always uses spaces. I feel very virtuous now ;-). I'll modify jp_ajp13_worker.c and resend diff. After that one week of test (you too ?) and a commit after if nothing is broken. If I have time to test, I will. I don't think I'll have a lot of time, unfortunately. If you fix the buffer issue and can figure out what is_recoverable_error should be doing in send_request, I'd be happy to see it merged in. I would check with Larry, though -- I'm not sure how he would feel about a new feature going into 3.3 at this point (as the Release Manager). This is sort of hairy code we're playing with here. It would be great to see it in 3.3, but I would just check with him first. -Dan p.s. Can I mention again how great it is that you're working on this? Not having to constantly restart Apache will make me a happy, happy man. -- Dan Milstein // [EMAIL PROTECTED]
Merging mod_jk/mod_webapp (was [VOTE] New Committer: Amy Roh)
It would be nice to have this dicussion on tomcat-dev. I do think I have a useful understanding of mod_jk to offer, but I'm not going to be in France (and I'm not on the private thread)... Not that we have to have that conversation now, but I would like to be involved when/if it happens. -Dan "Pier P. Fumagalli" wrote: [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I still think it would be a good idea to merge mod_jk and mod_webapp, even if Pier is not going to touch 3.x code. Some of the ideas are good, and getting them into mod_jk will be good for the users - and that's what matters. That's what I've been telling Gomez in a private thread, we're going to meet later in April somewhere in the French alps with a BIG whiteboard... Pier (somewhere in Europe... Maybe London???) -- Pier Fumagalli http://www.betaversion.org/ mailto:[EMAIL PROTECTED] -- Dan Milstein // [EMAIL PROTECTED]
Re: [PROPOSAL] The Commons - web connector
For those who don't read jakarta-general (myself included), a draft of The 'Commons Proposal' can be found at: http://husted.com/about/commons/ -Dan GOMEZ Henri wrote: This can happen only if all of you agree ( and also Craig, Pier and Remy who are working on connectors too on the 4.0 side ). The goal of the proposal was to include all people involved on connectors from TC 3.1 up to 4.0. After reading the 'Commons Proposal' in jakarta-general I was thinking that web-connector could fall in that category of common/sharing project. I'm open to all proposition. Everything else ( list, cvs, integration with tomcat, etc ) is detail :-) Yep, administrative task. -- Dan Milstein // [EMAIL PROTECTED]
[VOTE] New committer: Mike Braden
I would like to propose Mike Braden ([EMAIL PROTECTED]) as a new committer. He has contributed very useful patches to the user docs, has fixed bugs in the ApacheConfig class, and has been a helpful presence on this list, both in discussing new features, and in answering questions. -Dan -- Dan Milstein // [EMAIL PROTECTED]
Re: Is Tomcat Stable Enough ?
The connection to Apache seems to be a big source of problems. Haven't tried it though -- standalone Tomcat works fine for me. If you're serving static content, you'd like to make it. TC 3.2.1 did have some serious connector issues (particularly with ajp13, which a lot of people used because of its SSL support). There are many bug fixes in 3.2.2 for the mod_jk and ajp13 code. It is much improved. Just so you know... -Dan -- Dan Milstein // [EMAIL PROTECTED]
Re: [PROPOSAL] The Commons - web connector
I don't see the advantages to having a separate project for the connectors.
Can someone explain that to me?
The main disadvantage that I see is that the connectors and Tomcat are very
tightly linked -- I think having one developer list for TC and the
connectors makes a lot of sense. I think having one bug system for TC and
the connectors makes a lot of sense (especially since it's not always clear
if the bug is in TC or in the connector when it is reported). Ditto for the
user list, where TC/connector configuration issues are ever popular.
Would this separate project include both C and Java code? It would have to,
if it would have any meaning (just working on one side of the protocols
would be a nightmare to sync up with a "separate" project). But if there's
Java code in there, there's going to have to be different code for each
different engine which the connector talks to (e.g. TC 3, TC 4). Pulling
that code out of the main projects makes no sense to me. It is totally
dependent on the rest of the project code.
I'm not sure if I'd want to be a committer on a different project -- once
3.3 is released, I'm planning on working on the 4.x branch. The first thing
I'd like to do (which I threatened to do a long time ago!), would be to
write an ajp13 connector and/or merge mod_webapp with mod_jk. That is
"connector" work, but I, personally, am more interested in the servlet
engine as a whole than on "just" the connectors.
-Dan
GOMEZ Henri wrote:
Still no response for this sub-project proposal.
The upcoming PMC could be an occasion to speak about it.
I saw at least 4 potentials commiters working on it :
- Dan Milstein, our resident hacker/expert of mod_jk.
- Keith Wannamaker, webdav specialist
- Pier P. Fumagalli, mod_jserv and mod_webapp father
- I, Henri Gomez, mod_jk and adaptation to Apache 2.0
We start speaking of an updated mod_jk with ajp13++ (ajp14)
which must fix current known problem like :
- lack of security between Apache / Tomcat
Tomcat accept connection from anybody to it's ajp12/ajp13
connector. We may add so trivial authentification scheme
at least at connect time.
Nothing too expensive but last days on Tomcat list there is
an interesting Thread on 'Encrypting password' ('challenge-response')
- problem with large upload between client - apache - tomcat.
If tomcat is broken between the upload we just couldn't do anything
with remaining data and load-balancing/fault-tolerant will be no help
there. We must have a persitant storage used in these upload case (flat
file ?)
- context loading/unloading information could be sent from
Tomcat to Apache to let him choose a working Tomcat for
the requested context. Indispensable in production site with
many virutal where admin will want to update specific context.
- mod_jk handle load-balancing but many will just want a simple
fault-tolerant configuration. I Tomcat1 fail just go to Tomcat2,
and just in that case.
Thanks to comment.
Hi to all,
What about a new sub-project, web connector, where all
the developpement on mod_jserv and mod_jk
(and why not mod_webapp) could live.
Apache 1.3 and 2.0 are allready supported by mod_jk but also
IIS, AOL, and NES (iPlanet) even JNI.
Tomcat's 3.x and 4.x provide interfaces (modules,
interceptor or whatever) that these connectors will implement :)
A project which could be in The Commons even if there is
still C code inside but also many java part (TC mod/interceptor).
We could (must) see Tomcat 4.x use mod_jk or Tomcat 3.x use
mod_webapp from Apache 2.0...
Comments ?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
--
Dan Milstein // [EMAIL PROTECTED]
Re: [VOTE] New Committer: Amy Roh
Sounds good -- I looked through the archives and found the messages which I had missed. Thanks for clearing that up -- I'll happily convert to +0 (I still don't feel like I've seen enough of her changes myself to vote +1, but it looks like plenty of other people have, which is great). I'll be +1 if Amy contribute to ALL TOMCAT current projects : ie : Tomcat 3.1, 3.2, 3.3 and 4.0 I strongly disagree -- if Amy is going to focus on 4.x, I think that's absolutely fine. We don't need every developer to work on all three branches -- we need enough developers committed to supporting each branch we're serious about releasing and maintaining. Adding someone who is going to focus on 4.x in no way impedes our support for 3.2/3.3. That is why the clear vote about who was going to work to support 3.3 was so useful -- some people are focusing on 3.3, some people are not. That's fine. I have not yet done much (read: any) work on 4.x. Does this mean that I am not fully contributing to the Tomcat project? I don't think so -- some of the project's programmers are currently working on pushing 3.3 towards release, some are working towards getting 3.2.2 out (go Marc!), and some are working on 4.x. There is some overlap, but I do not think it is important that everyone work on every branch. Please, please, please, let's not get into another debate about 3.x vs 4.x -- I am really enjoying this list being useful again, and not clogged with flame wars. -Dan -- Dan Milstein // [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: FW: problem w/ ajp13 - if Tomcat is shutdown
Henri, I think you're right about not trying to clean out the cache of endpoints. Too much work and not really necessary. I'd be happy to check your code, but I don't think I've seen it -- did you submit it to the list (I may have missed a few messages to the list)? -Dan GOMEZ Henri wrote: In the mean time, I have taken Henri's changes and back port it to 3.2.1 (because I need it on 3.2.1). Everything seems to work well. I've tested it in the normal scenarios (one Apache, one Tomcat) and in the load-balanced scenarios. Thanks for using the patch and tested it under LoadBalanced Tomcats. In the load-balanced scenarios, when I restart TC worker 1, the code properly close the dead sockets and re-establish new ones to the same worker (TC worker 1). The good connections to TC worker 2 are untouched. They stay connected. Normal procedure I did notice something wierd. But this is un-related to the code edits. This happens with or without Henri's changes. When I restart TC worker 1, but shut down TC worker 2, requests that supposed to go to TC worker 2 (because they belong to the same session, thus the load balancer try to foward it to the same TC worker 2) took sometime to get forwarded to TC worker 1. This maybe another one of those "improvements" that can be done to the load balancer worker. No problem here, when you shutdown a Tomcat in a load balancing architecture, you got request goes to the second even if there is a JVMROUTE set . Anyway, I'm pretty happy with Henri's changes. (Thanks Henri!). Henri, are you going to check in the changes? I'd like to see Dan check it since I created a second memory pool rmsg but I'm not too confident on it : +rmsg = jk_b_new((p-pool)); +jk_b_set_buffer_size( rmsg, DEF_BUFFER_SZ); + jk_b_reset(rmsg); See you - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] -- Dan Milstein // [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [VOTE] New Committer: Amy Roh
I have to say that I am a bit uncomfortable with this. The guidelines on the website say (http://jakarta.apache.org/site/roles.html): "Developers who give frequent and valuable contributions to a subproject of the Project can have their status promoted to that of a "Committer" for that subproject." It sounds like Amy has contributed good work which people at Sun have seen, but, as a developer who only communicates via the list, I haven't seen anything she's done (I haven't missed any things she's submitted, have I? I have this vague memory of ezmlm complaining about not being able reach me). I'm also not clear if her documentation and test cases are part of the TC 4.x code base or part of the JSP spec (since she's working on the "JSP/Servlet Team") I don't want this to turn into a Sun-bashing thread -- I think it is *fantastic* that Sun is giving excellent developers a chance to work full-time on an open source Tomcat. And I would love to have more people who can contribute to the project. But I think those guidelines are important -- in terms of our social organization, I think it is reasonable to require a new developer to submit patches and ideas to the list at large, so that, when they are proposed as a committer, everyone can feel that they're voting for a known quantity. Furthermore, since I've been involved, that process has actually occurred very quickly (which I think is great). Once someone has contributed a few solid patches, everyone is ready to give them commit access. If I'm missing part of the story, I'd be happy to change my mind, but I guess I'm -1 until I can better understand what Amy's "frequent and valuable contributions" have been. -Dan "Craig R. McClanahan" wrote: Amy has recently joined the JSP/Servlet team at Sun, and has contributed several documentation updates and new tests for the test harness. She would like to work on bug fixes, as well as participate in the development of better admin tools, primarily on the Tomcat 4.0 code base. Votes please? Craig McClanahan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] -- Dan Milstein // [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: FW: problem w/ ajp13 - if Tomcat is shutdown
r using the patch and tested it under LoadBalanced Tomcats. In the load-balanced scenarios, when I restart TC worker 1, the code properly close the dead sockets and re-establish new ones to the same worker (TC worker 1). The good connections to TC worker 2 are untouched. They stay connected. Normal procedure I did notice something wierd. But this is un-related to the code edits. This happens with or without Henri's changes. When I restart TC worker 1, but shut down TC worker 2, requests that supposed to go to TC worker 2 (because they belong to the same session, thus the load balancer try to foward it to the same TC worker 2) took sometime to get forwarded to TC worker 1. This maybe another one of those "improvements" that can be done to the load balancer worker. No problem here, when you shutdown a Tomcat in a load balancing architecture, you got request goes to the second even if there is a JVMROUTE set . Anyway, I'm pretty happy with Henri's changes. (Thanks Henri!). Henri, are you going to check in the changes? I'd like to see Dan check it since I created a second memory pool rmsg but I'm not too confident on it : +rmsg = jk_b_new((p-pool)); +jk_b_set_buffer_size( rmsg, DEF_BUFFER_SZ); + jk_b_reset(rmsg); See you - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] -- Dan Milstein // [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PATCH] Update to mod_jk-howto.html
Mike, First off, thanks for working on this doc -- it's great to see someone bringing the user docs for mod_jk up to date. However, two things: 1) If you can run 'diff -u' (if you've got it from cvs, 'cvs diff -u'), it will produce the diff in "unified" format, which makes it possible to merge changes via the patch program. Without that, I'd have to apply things more or less by hand. 2) Chris Pepper actually submitted some fixes to this same doc (mostly reformating the HTML and fixing typos), which I have, but haven't yet committed (my fault). I want to apply both of your fixes. I'm attaching a copy of his patch. If you want to make me a very happy committer, you could apply his patch to the current version under cvs, make your changes, and then produce a diff from that (I'll then apply that and credit you both). If you want to make me merely a fairly happy committer, you can say, "I'm too busy to do that Dan, so I'm just running diff -u for my fixes based on what's currently in cvs, and I'll send you that". Then I can merge your and Chris's work myself (which won't kill me, and will teach me to commit things which are sent in!). -Dan Mike Braden wrote: This patch updates the mod_jk-howto.html to include the latest changes for TC3.3's mod_jk configuration files. Updates: - Updated section on configuring Tomcat to include setting up the ApacheConfig / tag - Updated path references to the mod_jk.conf-auto and workers.properties from conf/ to conf/jk/ Mike. -- Mike Braden [EMAIL PROTECTED] [EMAIL PROTECTED] patchfile.txt Name: patchfile.txt patchfile.txtType: Plain Text (text/plain) Encoding: quoted-printable - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] -- Dan Milstein // [EMAIL PROTECTED] Index: mod_jk-howto.html === RCS file: /home/cvspublic/jakarta-tomcat/src/doc/mod_jk-howto.html,v retrieving revision 1.4 diff -u -d -b -r1.4 mod_jk-howto.html --- mod_jk-howto.html 2000/10/11 19:11:54 1.4 +++ mod_jk-howto.html 2001/02/28 15:24:04 @@ -61,7 +61,7 @@ Configuring Apache to use mod_jk Removing the mod_jserv directives -Obtaining mod_jk +Obtaining and building mod_jk Configuring Tomcat to use the Ajpv13 protocol Defining workers for mod_jk Configuring Apache to use mod_jk @@ -105,7 +105,7 @@ Definitions and terminology -During this document I am going to use a few terms, so lets define them: +During this document I am going to use a few terms, so let's define them: @@ -209,8 +209,8 @@ On NT -The redirector was developed using Visual C++ Ver.6.0, so having this -environment is a prereq if you want to perform a custom build. +The redirector was developed using Visual C++ version 6.0, so having this +environment is a prerequisite if you want to perform a custom build. The steps that you need to take are: @@ -240,53 +240,146 @@ For Apache - Make sure you have Perl 5 installed. The apxs script - used to build the module is written in Perl. + Make sure your Apache has DSO support. You can check this + with $APACHE_HOME/bin/httpd -l. If you see + "mod_so.c" in the output, DSO support is available. If it's + missing, you may have to recompile or reinstall Apache. + + Find out whether your Apache has EAPI support. If you + compiled it yourself from source, EAPI is probably not compiled + in, unless you added it yourself (perhaps with mod_ssl). You + need to build mod_jk.so with or without EAPI to match your + Apache configuration. If you install a mismatched mod_jk.so, + $APACHE_HOME/bin/apachectl configtest will warn + you. + Make sure you have Perl 5 installed. The apxs + script used to build the module is written in Perl. + Change directory to - jakarta-tomcat/src/native/apache1.3 (or apache2.0). + jakarta-tomcat/src/native/apache1.3 (or + apache2.0). - Build mod_jk.so. + + Build mod_jk.so. Following are three techniques you can try, + in order of simplicity: - Following are three alternate techniques you can try, in order of - simplicity. + + Run ./build-unix.sh, if present in this + directory. This script will set some variables, call + apxs as below, and try to copy mod_jk.so to + $APACHE_HOME/libexec. If it fails, you need to do + the following manually: - Option 1: Run ./build-unix.sh . This script will set some - variables, call apxs as below, and try to copy mod_jk.so to - $APACHE_HOME/libexec. If it fails, you may need to do the following: - - set JAVA_HOME in your shell, e.g. "set JAVA_HOME=/usr/local/jdk1.2.2; export JAVA_HOME" - set APACHE_HOME in your shell, e.g. &q
Re: FW: problem w/ ajp13 - if Tomcat is shutdown
In terms of invalidating the cache: The jk_ajp13_worker objects hold onto a cache of endpoints -- ep_cache. It would be relatively simple to loop through this cache and close all the connections in case of ECONNRESET (you do have to call a macro to enter a critical section -- take a look at reuse_connection()). However, this cache only holds onto endpoints which are *not* being used. When an endpoint is checked out of the cache (by get_endpoint), or if the open socket descriptor is transfered to another endpoint (in reuse_connection), that connection is replaced by NULL in the cache. So if we shut down all the connections in the cache, we won't shut down the other connections which are handling requests at that moment. My only fear then is that, when those connections get their own ECONNRESET errors, they, too, will try to shutdown all the connections in the cache. If TC hasn't come back up yet, this won't be a problem, because there won't be any connections in the cache. But it does make me a bit nervous. Hope that's helpful... -Dan GOMEZ Henri wrote: La prise de conscience de votre propre ignorance est un grand pas vers la connaissance. -- Benjamin Disraeli -Original Message- From: Dan Milstein [mailto:[EMAIL PROTECTED]] Sent: Friday, March 09, 2001 6:34 AM To: [EMAIL PROTECTED] Subject: Re: FW: problem w/ ajp13 - if Tomcat is shutdown Henri, You say that checking errno isn't safe in a multithreaded env (which would certainly makes sense to me, since it looks like a global var). However, after searching online, and reading up in "Programming Threads", by Kleiman, Shah and Smaalders, I find on p. 47: "Each thread has its own independent version of the errno variable. This allows different threads to make system calls that may change the value of errno without interfering with each other." They are describing Posix threads. "errno" is actually a macro, apparently, which accesses the correct, thread-specific errno variable. Right, I checked in Linux errno.h for pthread Now, I am the first to admit that I don't understand all the weird intersections between threads and sockets in C, but this looks to me like checking errno against ECONNRESET may be fine. More generally when you got a read error on TCP/IP stream you could consider that the link to your server (tomcat) is broken : - no more route to tomcat (broken lan or routers) - server not working (tomcat was stopped or server restarted) Are there platforms where that's not true? I've no idea but we migth have problems in differents interpretation of platform. The nice thing about getting that ECONNRESET error, is it lets us go ahead and close out that connection, and try another one. Done. We could even close out a whole cache of connections, which would most likely be the right thing to do. Good idea, I'll find how to do that. If we loop/retry, than how do we know to close the connection? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] -- Dan Milstein // [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Design Review for ajp13's changes: WAS problem w/ ajp13 - if Tomc at is shutdown
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 Shinta Tjio wrote: I'm having problem with mod_jk if ajp13 is used. The problem is often reproduced when Tomcat is shut down without Apache being shut down. When a request is fired through Apache as soon as Tomcat starts, I often get Internal Server Error. The mod_jk.log will have the following: [jk_uri_worker_map.c (344)]: Into jk_uri_worker_map_t::map_uri_to_worker [jk_uri_worker_map.c (406)]: jk_uri_worker_map_t::map_uri_to_worker, Found a match ajp13 [jk_worker.c (123)]: Into wc_get_worker_for_name ajp13 [jk_worker.c (127)]: wc_get_worker_for_name, done found a worker [jk_ajp13_worker.c (651
Re: FW: problem w/ ajp13 - if Tomcat is shutdown
Henri,
You say that checking errno isn't safe in a multithreaded env (which would
certainly makes sense to me, since it looks like a global var).
However, after searching online, and reading up in "Programming Threads", by
Kleiman, Shah and Smaalders, I find on p. 47:
"Each thread has its own independent version of the errno variable. This
allows different threads to make system calls that may change the value of
errno without interfering with each other."
They are describing Posix threads. "errno" is actually a macro, apparently,
which accesses the correct, thread-specific errno variable.
Now, I am the first to admit that I don't understand all the weird
intersections between threads and sockets in C, but this looks to me like
checking errno against ECONNRESET may be fine.
Are there platforms where that's not true?
The nice thing about getting that ECONNRESET error, is it lets us go ahead
and close out that connection, and try another one. We could even close out
a whole cache of connections, which would most likely be the right thing to
do. If we loop/retry, than how do we know to close the connection?
-Dan
GOMEZ Henri wrote:
Okay so this means, you would prefer my proposed solution #1?
That was my inclination too.
Proposed solution #1 without the errno check.
My idea :
get the service code in a loop
for (i = 0; i RETRIES; i++) {
if (send_request() 0)
continue;
if (read_reply() == 0)
break;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
--
Dan Milstein // [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: Patch for jk_sockbuf.c
Stefan,
Thanks for looking into this, but this bug has already been fixed in the 32
branch under cvs. If you check out the most recent version of tomcat_32, or
if you download 3.2.2b1, you can see that jk_sockbuf.c has been cleaned up
(Brian Vetter contributed the patch).
Thanks, though,
-Dan
p.s. For future patches, it would be very, very helpful if you could:
a) Use cvs diff -u, to get the diffs in the "unified" format, which patch
can read.
b) Attach your patches to your emails rather than pasting them in -- they
are much less likely to get mangled by email readers.
[EMAIL PROTECTED] wrote:
These changes fixes the following problem:
When using ajp12 with mod_jk, httpd procesess handling a request
will hang, using all cpu time, if tomcat is shut down before the headers
of the request have been sent from tomcat.
BR,
Stefan berg
***
/usr/local/src/apache/jakarta-tomcat-3.2.1-src/src/native/jk/jk_sockbuf.c
Tue Mar 6 10:10:40 2001
--- jk_sockbuf.cTue Mar 6 10:15:54 2001
***
*** 131,137
if(sb-end == sb-start) {
sb-end = sb-start = 0;
! if(!fill_buffer(sb)) {
return JK_FALSE;
}
}
--- 131,137
if(sb-end == sb-start) {
sb-end = sb-start = 0;
! if(fill_buffer(sb) 0) {
return JK_FALSE;
}
}
***
*** 169,175
return JK_TRUE;
}
}
! if(!fill_buffer(sb)) {
return JK_FALSE;
}
}
--- 169,175
return JK_TRUE;
}
}
! if(fill_buffer(sb) = 0 ) {
return JK_FALSE;
}
}
***
*** 205,215
SOCKBUF_SIZE - sb-end, 0);
if(ret 0) {
! return JK_FALSE;
}
sb-end += ret;
! return JK_TRUE;
}
-
--- 205,214
SOCKBUF_SIZE - sb-end, 0);
if(ret 0) {
! return ret;
}
sb-end += ret;
! return ret;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
--
Dan Milstein // [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
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 Shinta Tjio wrote: I'm having problem with mod_jk if ajp13 is used. The problem is often reproduced when Tomcat is shut down without Apache being shut down. When a request is fired through Apache as soon as Tomcat starts, I often get Internal Server Error. The mod_jk.log will have the following: [jk_uri_worker_map.c (344)]: Into jk_uri_worker_map_t::map_uri_to_worker [jk_uri_worker_map.c (406)]: jk_uri_worker_map_t::map_uri_to_worker, Found a match ajp13 [jk_worker.c (123)]: Into wc_get_worker_for_name ajp13 [jk_worker.c (127)]: wc_get_worker_for_name, done found a worker [jk_ajp13_worker.c (651)]: Into jk_worker_t::get_endpoint [jk_ajp13_worker.c (536)]: Into jk_endpoint_t::service [jk_ajp13.c (346)]: Into ajp13_marshal_into_msgb [jk_ajp13.c (480)]: ajp13_marshal_into_msgb - Done [jk_ajp13_worker.c (203)]: connection_tcp_get_message: Error - jk_tcp_socket_recvfull failed [jk_ajp13_worker.c (619)]: Error reading request [jk_ajp13_worker.c (489)]: Into jk_endpoint_t::done If I hit reload multiple times, eventually Tomcat will serve the servlet fine. Did anyone see this problem before? Is there anyway around this? shinta -- Dan Milstein // [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Patches in Bugzilla
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]
Re: Restricting Access to Tomcat 3.x and Tomcat 4.0 Connectors
In 3.x, the Ajp12 and Ajp13 Connectors currently accept connections from anywhere. People have proposed adding the ability to have an accept/deny list in the configs, but it hasn't been done (the Java code for this would be pretty easy, actually), and it would be backward compatible with the mod_jk C code (which wouldn't need to know about it at all, actually). As a minimal form of security, both connectors will only accept a shutdown if it issued from the same host as TC is running on (e.g. if socket.getLocalAddress and socket.getInetAddress are the same). Costin recently added an optional 'secret' -- either user-set or randomly generated by TC. If user-set, it can be added to worker.properties (I think), or if randomly generated, it can be read from a specific file in the config dir (the same way that httpd.pid can be read by apachectl). If useSecret is set, then the shutdown request is only acted on if it is followed by the secret. I don't know if Costin has documented this or not -- I haven't looked. With ajp13, the server is basically proxying requests, so some security issues don't arise. The biggest gotcha I'm aware of is that TC trusts the web server to establish the remote_user property (which the user might need to authenticate to prove). So someone could manufacture an ajp13 connection which would allow them to access servlets that they should be denied. I haven't actually created this exploit, but I believe the vulnerability is there. The spec for the Ajp2.1 (which was not, AFAIK, ever implemented) has an excellent section discussing "Security Hazards". Anyone interested can check that out at: http://java.apache.org/jserv/protocol/AJPv21.html -Dan Glenn Nielsen wrote: I have a general question about restricting access from remote hosts to common connectors used by Tomcat 3.x and Tomcat 4.0. Tomcat 3.x will use port 8007 for its Apache ajp12 connector, is there anyway to configure Tomcat 3.x so it will only accept connections on that port from localhost or a single remote host? What about shutdown, does the port only accept requests from localhost? Tomcat 4.0 will use port 8005 as its shutdown port, will this only accept connections from localhost? Is this configurable? Tomcat 4.0 will use port 8008 for its Warp Connector. Can this be filtered using the Request Filter Valve? The docs for the Request Filter refer to denying HTTP requests. 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] -- Dan Milstein // [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Proposed ApacheConfig.java change
Costin, I would strongly vote for turning the auto-config back on by default for the following reasons (other than the fact that I explicity turned it back on when Keith fixed the ApacheConfig class): 1) This is how 3.2 worked, and how the docs specify that 3.3 works. 2) Configuration of mod_jk is notoriously complicated. Giving people the auto generated file is a big, big win. 3) For the people who run it in standalone, we can provide a comment in the file telling them to "comment out the below". That way it would work out of the box for both types (standalone + behind Apache), and be very easy for people to tune to their needs. Since the syntax has changed (and I've never been a server.xml master), I'm not sure where the AutoConfig stuff would go now. -Dan [EMAIL PROTECTED] wrote: However, after upgrading to the latest and greatest tomcat 3.3 version out of CVS (as of last night) I've suddenly noticed that tomcat is no longer generating the mod_jk.conf-auto or tomcat-apache.conf files automatically. As near as I can tell, ApacheConfig.execute() is not being called. Yes, you need to insert the ApacheConfig module in server.xml. We can include it by default for the next milestone - but I would rather not, many people use tomcat standalone. ( a better solution be part of the new admin interface, but probably after 3.3 ) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] -- Dan Milstein // [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: autoconf / automake
Jon, Do you think these tools are *worth* using, or do they cause more problems than they solve? I've got a friend who is a pretty solid autoconf/automake guru, and I'm trying to tempt him into helping out with setting this up, but I won't do that if people with experience think it's going to make trouble down the road. Anyone? -Dan Jon Stevens wrote: on 3/2/01 9:12 AM, "Jones, Stephen" [EMAIL PROTECTED] wrote: Does anybody know how to use autoconf or automake? We could perhaps put an end to most of the mod_jk compilation problems if we had some good configure scripts that generated Makefiles. I don't know how complicated the tools are... Steve You can use JServ's system (which myself and Vadim) built as your basis. Needless to say, using those tools and getting them to work on a bazillion different platforms is a royal bitch. thanks, -jon -- -- Dan Milstein // [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [BUG] servlet life cycle
Thanks for these bug reports -- if you enter them into the Bug tracking tool (Bugzilla), there's a MUCH better chance that they'll get tracked/dealt with. The link is: http://nagoya.apache.org/bugzilla/enter_bug.cgi?product=Tomcat%203 -Dan "[EMAIL PROTECTED]" wrote: I think there is some problems in tomcat3.3m1 : 1/ the destroy() method of servlets isn't call on shutdown - state problem between Context.removeServletByName() and ServletHandler.destroy() 2/ if a servlet handler falls in STATE_DISABLED, the underlying servlet can't be reloaded and reinitialized - servlet 2.2 specs violation (see 3.3.2.1 and 3.3.3.2) 3/ in the Handler class, a comment says that there is a transition from STATE_DISABLED to STATE_ADDED via destroy() method - servlet 2.2 specs violation (see 3.3.2.1) What do you think ? Thibault FREY -- Jusqu' 60 heures gratuites pour toute souscription l'un des nouveaux Forfaits Liberty Surf http://register.libertysurf.fr/subscribe_fr/signup.php3 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] -- Dan Milstein // [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Bugzilla #512 is Bunk
Steve, Thanks so much! This is very, very helpful -- I am not master of Apache configuration, and the virtual host thing is important. I'll try to work this into the docs some time soonish... -Dan Stephen Jones wrote: The following bug is not a bug: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=512 In httpd.conf, you cannot do this: VirtualHost blah normal config for VirtualHost ... Include /usr/local/jakarta-tomcat/conf/mod_jk.conf-auto /VirtualHost There are three main purposes of including mod_jk.conf-auto: (1) To get the mod_jk Apache Module loaded, as follows: LoadModule jk_module libexec/mod_jk.so (2) To configure Apache for your Tomcat Contexts using Alias, Location, and Directory Apache Directives (3) To configure mod_jk itself using all the directives starting with Jk (JkWorkersFile, JkLogFile, JkMount, etc). The first (1) Apache directive is the problem: the LoadModule directive is illegal within the VirtualHost context. (See http://httpd.apache.org/docs/mod/mod_so.html#loadmodule ) The directives in (2) are definitely legal, but I don't know about those in (3) since they are custom. Does anyone know whether these would work within the VirtualHost context? The bug was reported by someone using Apache 1.3.14; they recieved a core dump dereferencing a null pointer to something that was supposed to contain Apache configuration info (a jk_server_conf_t). I am using Apache 1.3.17; I recieved this polite and informative (wow, from open source software?) error message: sudo /usr/local/apache/bin/apachectl startssl Syntax error on line 8 of /usr/local/tomcat/conf/mod_jk.conf-auto: LoadModule cannot occur within VirtualHost section /usr/local/apache/bin/apachectl startssl: httpd could not be started Provided that the custom directives (3) will work within a VirtualHost context, the solution to this problem is to create a custom configuration file based on mod_jk.conf-auto, move the LoadModule directive into it, and then Include it from within your VirtualHost context. If the directives (3) do work, another option would be for Tomcat to change the code to not generate the LoadModule directive, which prevents this level of configurability, and just make people type it in. Hope this is helpful, Steve Jones - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] -- Dan Milstein // [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/server Ajp13.java
Costin,
Glad I can help out -- I think I see another problem, though.
ll. 379-386 is still dealing with hBuf (which is bound to msg), and will
therefore still overwrite the headers. I'm attaching a patch which I think
fixes this (I don't have time to test/commit myself at this instant, and
this is a pretty big gotcha):
-Dan
[EMAIL PROTECTED] wrote:
costin 01/02/26 21:28:08
Modified:src/share/org/apache/tomcat/modules/server Ajp13.java
Log:
Fix the buffer problem ( need 2 input, one output - not 2 output on input).
Thanks again Dan.
Revision ChangesPath
1.16 +20 -17
jakarta-tomcat/src/share/org/apache/tomcat/modules/server/Ajp13.java
Index: Ajp13.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/server/Ajp13.java,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- Ajp13.java2001/02/27 03:02:47 1.15
+++ Ajp13.java2001/02/27 05:28:08 1.16
@@ -180,11 +180,14 @@
OutputStream out;
InputStream in;
-
-Ajp13Packet outBuf = new Ajp13Packet( MAX_PACKET_SIZE );
-Ajp13Packet inBuf = new Ajp13Packet( MAX_PACKET_SIZE );
+
+// Buffer used of output body and headers
OutputBuffer headersWriter=new OutputBuffer(MAX_PACKET_SIZE);
-Ajp13Packet hBuf=new Ajp13Packet(headersWriter);
+Ajp13Packet outBuf = new Ajp13Packet( headersWriter );
+// Buffer used for input body
+Ajp13Packet inBuf = new Ajp13Packet( MAX_PACKET_SIZE );
+// Boffer used for request head ( and headers )
+Ajp13Packet hBuf=new Ajp13Packet( MAX_PACKET_SIZE );
// Holds incoming reads of request body data (*not* header data)
byte []bodyBuff = new byte[MAX_READ_SIZE];
@@ -230,16 +233,16 @@
{
// XXX The return values are awful.
- int err = receive(inBuf);
+ int err = receive(hBuf);
if(err 0) {
return 500;
}
- int type = (int)inBuf.getByte();
+ int type = (int)hBuf.getByte();
switch(type) {
case JK_AJP13_FORWARD_REQUEST:
- return decodeRequest(req, inBuf);
+ return decodeRequest(req, hBuf);
case JK_AJP13_SHUTDOWN:
return -2;
@@ -495,28 +498,28 @@
{
// XXX if more headers that MAX_SIZE, send 2 packets!
- hBuf.reset();
-hBuf.appendByte(JK_AJP13_SEND_HEADERS);
-hBuf.appendInt(status);
+ outBuf.reset();
+outBuf.appendByte(JK_AJP13_SEND_HEADERS);
+outBuf.appendInt(status);
- hBuf.appendString(HttpMessages.getMessage( status ));
+ outBuf.appendString(HttpMessages.getMessage( status ));
int numHeaders = headers.size();
-hBuf.appendInt(numHeaders);
+outBuf.appendInt(numHeaders);
for( int i=0 ; i numHeaders ; i++ ) {
String headerName = headers.getName(i).toString();
int sc = headerNameToSc(headerName);
if(-1 != sc) {
-hBuf.appendInt(sc);
+outBuf.appendInt(sc);
} else {
-hBuf.appendString(headerName);
+outBuf.appendString(headerName);
}
-hBuf.appendString(headers.getValue(i).toString() );
+outBuf.appendString(headers.getValue(i).toString() );
}
-hBuf.end();
-send(hBuf);
+outBuf.end();
+send(outBuf);
}
/**
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
--
Dan Milstein // [EMAIL PROTECTED]
Index: Ajp13.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/server/Ajp13.java,v
retrieving revision 1.16
diff -u -r1.16 Ajp13.java
--- Ajp13.java 2001/02/27 05:28:08 1.16
+++ Ajp13.java 2001/02/27 22:38:37
@@ -376,14 +376,14 @@
if(contentLength 0) {
req.setContentLength( contentLength );
/* Read present data */
- int err = receive(msg);
+ int err = receive(inBuf);
if(err 0) {
return 500;
}
- blen = msg.peekInt();
+ blen = inBuf.peekInt();
pos = 0;
- msg.getBytes(bodyBuff);
+ inBuf.getBytes(bodyBuff);
}
return 200; // Success
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/server Ajp13.java
Costin, It's great to see you cleaning up Ajp13, performance-wise (and I'm glad the comments/code cleanup have helped). I do see something which seems like a major gotcha, though -- you remove a lot of String creation by creating MessageBytes objects which point directly into the underlying input buffer. *However*, if there is any data posted as part of the request, that will immediately overwrite the input buffer (l. 376), and any further data which is input will also overwrite the input buffer (refillReadBuffer()). Unless I'm missing something, this is going to result in the delayed string creation creating the wrong string if the post data overwrites the underlying input buffer. You could solve this by devoting a buffer to just that initial header info -- inHeadBuff, and then using a separate buffer for reading input. Of course, then you're adding an 8K buffer per Ajp13 thread. I had thought at one point that you could use a single buffer for input and output, but that's not the case -- the servlet can be in the middle of reading its way through the input stream when it starts to send output back to the browser. Is there a reason you don't want to use your new hBuf Ajp13Packet for general output as well as headers? It kind of looks like you could merge it with outBuf (since, even when it's built around an OutputBuffer, it still supports appendBytes(), which is all that doWrite() needs). If you did this, you could get rid of one of those 8K buffers per thread. -Dan [EMAIL PROTECTED] wrote: costin 01/02/26 19:02:47 Modified:src/share/org/apache/tomcat/modules/server Ajp13.java Log: Apply the same recycling as in Http connector. - no Strings ( use MessageBytes ) - use OutputBuffer instead of getBytes ( getBytes creates a stream and few buffers ) Nothing else is changed - the only "trick" is appendString(), where the buffer is shared between the OutputBuffer and Ajp13Packet ( each adding bytes ). Probably having Ajp13Packet extend OutputBuffer would be cleaner - or even better, turning Ajp13Packet in a better marshaling tool. Revision ChangesPath 1.15 +100 -33 jakarta-tomcat/src/share/org/apache/tomcat/modules/server/Ajp13.java Index: Ajp13.java -- Dan Milstein // [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Volunteer: Connectors?
Steve, Any help would be greatly, greatly appreciated. Here's my quick state of the union w/r/t Connectors: 1) First off, there are two totally distinct branches of development currently -- TC 3.x and TC 4.x. The underlying codebases are completely different. TC 4 is the future of the jakarta tomcat project, but has not had a production release yet. The 3.x branch has had a production release (3.2.1 is the latest), but has also been dramatically refactored since that time. So, there are a bunch of upcoming releases: 4.0 I'm not sure the schedule for this one -- there's been a milestone release, but there's been some serious reworking since then. I think this should happen within a few months. 3.3 This is the refactored version of the 3.x branch. There should be a release within about 2 months. There's also an imminent 3.2.2 release which has a bunch of bug fixes against 3.2.1 but does *not* contain the major refactoring. 2) Why am I explaining all of this? Well, the connectors are (currently) different for 3.x and 4.x. For TC 3.x the main connectors are built around the mod_jk plugin, which works with a variety of web servers (Apache 1.3, 2.0, Netscape, IIS, AOLServer), and talks a variety of protocols to communicate with TC (ajp12, ajp13). If you are interested in working on mod_jk, I could point you at some bugs which have been reported -- if you could verify them and fix them in the 3.x tree, you would be doing a great, great service. I understand mod_jk pretty well, and ajp13 quite well, and could help you get started with that. This would probably be a good way for you to learn your away around the current connector setup. The src/docs directory has a bunch of useful stuff. A few example mod_jk/ajp13 bugs in Bugzilla (some of which have been lying around in the bug system for a while, and may have been fixed in the 3.3 branch -- I haven't had time to verify): http://nagoya.apache.org/bugzilla/show_bug.cgi?id=484 http://nagoya.apache.org/bugzilla/show_bug.cgi?id=512 http://nagoya.apache.org/bugzilla/show_bug.cgi?id=356 If you fixed some bugs within the next month, we could put those fixes into the 3.3 release. For TC 4.x, the only current connector is mod_webapp, which is being written by Pier Fumagalli. It had an alpha release as part of TC 4.0m1, but I believe he's engaged in a decent-sized rewrite since then (removing multiplexing). I don't know if he's at a point where he could use help on that yet -- Pier? mod_webapp has some different design goals that mod_jk -- it should be much easier to configure (which would be a big, big win). There has been some discussion about merging mod_webapp and mod_jk down the road. Which is mostly just to say that any work done on mod_jk will almost definitely be used by many people for a long time -- within the 3.x branch, and possibly within the 4.x branch as well. Let me know if you'd like more info... -Dan "Jones, Stephen" wrote: Hi-- I work w/ Rational Software. We have been working with Tomcat for some time for our web product, RequisiteWeb. I'd like to volunteer to help out in the Tomcat Connectors department. I am a 1.5-year Java veteran w/ a CS bachelor's degree, wanting to help produce free software. Let me know where/if I can be of help. Thanks, Steve Jones PS Rational.com needs Java developers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] -- Dan Milstein // [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Some benchmarks
Now the only performance issue on my list is mod_jk ( the java side still need work to improve a bit the performance ). But fixing the bugs and making tomcat easier to use is far more important - and the connector module can be released independently, as a standalone module ( i.e. after 3.3 is released - stability is also more important than performance, I would vote for an ajp14 for performance and other "dev" enhancements, and making ajp13 the "stable" protocol instead of 12 ). +1. We're still shaking weird little bugs out of the ajp13 implementation(s), and people are relying on it for production use. I don't think we should muck around with the protocol itself. When ajp14 is developed, the spec should really contain a standard response for an "unknown packet", so new packet types (or messages) can be added to the protocol without breaking backward compatability. If we had this in ajp13, we could add some very nice things as negotiated features (e.g. encrypted and/or authenticated connections). However, because ajp13 has no way to respond to an unknown packet, the implementations generally behaves very badly if you send them something they're not expecting. -Dan -- Dan Milstein // [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Some benchmarks
[EMAIL PROTECTED] wrote: When ajp14 is developed, the spec should really contain a standard response for an "unknown packet", so new packet types (or messages) can be added to the protocol without breaking backward compatability. If we had this in ajp13, we could add some very nice things as negotiated features (e.g. encrypted and/or authenticated connections). However, because ajp13 has no way to respond to an unknown packet, the implementations generally behaves very badly if you send them something they're not expecting. Hmm. How difficult would be to fix this ? After all, I guess all we need is to add some code to behave nicely when unknown packets are received. If we can get this into ajp13 implementation - then ajp14 may have some backward compatiblities, and will be much easier to evolve. ( BTW, it would also be nice if ajp13 would call a unknown_packet function, so later we may hook into this, without changing anything else ) Costin I dunno. It kind of depends on what "behaving nicely" means. Currently, on the Java side, if it receives a strange packet type (while waiting for forwarded requests), it shuts down the (otherwise persistent) connection back to the web server. Maybe I shouldn't have called that "behaving very badly". It could leave the connection open and simply not respond. You could conceivably then write an ajp14 plugin which sent an exploratory packet and waited for some amount of time before giving up. I'm not crazy about that, though. Shutting down the connection does have the virtue of being predictable in the face of bizarre situations. On the C side, there isn't a general "wait for next request" loop (requests all originate from the C side). Once it's sent over a forwarded request, it does enter a loop of waiting for writes and such from the servlet engine. If it gets a strange packet there, it terminates handling that request, and signals and error of some sort to the rest of the web server (I think). I'm not sure what else it could do (again, it could ignore strange packets, but that seems chancy). I think this is more a problem with the protocol than anything else -- it's missing some ability to negotiate. We can try to make the implementations stable in the face of unexpected packets (which they pretty much are), but I basically think we should just accept ajp13 for what it is, and think about adding new features to ajp14 (with negotiation being the most important one). -Dan -Dan -- Dan Milstein // [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Updating Tomcat3 Bugzilla items
I've assigned most of the mod_jk connector bugs to myself, and will try to do this same work (verifying - resolving and/or markings as LATER). I've also closed out a few which I know are fixed. I've been marking them as part of the "Nightly Build" if the fixes are slated to be part of 3.2.2 (most of the bugs came from BugRat, and, as such aren't specified against a particular version). I think that makes sense, since they are fixed in the Nightly Build (even if they were reported against 3.2.1 or 3.1 or something). I haven't picked up any of the NT-related mod_jk bugs (and there are a few), since I have zero ability to test anything NT-related. -Dan Marc Saegesser wrote: I realize that the voting on Tomcat 3.2.2 is not complete yet, but I want to get a head start on reviewing/updating Bugzilla reports against Tomcat 3. There are currently 248 reports in the open/reopened/new states. All of these need to be reviewed and addressed prior to finalizing 3.2.2. I will be attempting to verify these bugs and either fix them, invalidate them (if they aren't really bugs) or mark them as resolution=LATER. I am not an expert in every detail of Tomcat and Jasper so if I can't determine if something is a real bug of not I'll most likely just set the resolution to LATER and move on. If I manage to get through 10 of these things a day (probably unreasonable) it will still take almost a month. Obviously the sooner I start the better. I would ask that anyone who has committed fixes to the tomcat_32 branch double check that the bug report has been closed. If anyone would like to help review and update these things it would be *greatly* appreciated. If you think I've incorrectly invalidated a bug please let me know. Marc Saegesser - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] -- Dan Milstein // [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: What about mod_jk/ajp as tomcat sub-project
To me, having a separate project doesn't make a lot of sense (yet, at least). There are different "levels" of mod_jk in TC 3.2 and TC 3.3 as you say, but it's really just the same as having new code in the 3.3 in general. Bug fixes should be committed in the 3.2 branch, but new features, performance improvements and refactorings should all be confined to 3.3. Until fairly recently, the mod_jk native code was so unsupported that no one was contributing anything to it, which kept it perfectly in sync with 3.3. However, as new work goes on, only the bug fixes are going into 3.2. Some things (like adding WebDAV support), are borderline, but my instinct is to be conservative about what we put into 3.2 -- we're trying to reestablish a level of trust in the stability of Tomcat, so I'd rather not take chances. You could argue that having the underlying protocols maintain backward compatability should be a design goal, so that running TC 3.3 with a mod_jk plugin built from 3.2 should work. I think this is very desirable, but not an absolute requirement. If someone downloads a new release, requiring them to rebuild their plugin might be reasonable -- it should be documented. I believe that it is currently possible to run TC 3.3 with the 3.2 version of mod_jk. I would love to see mod_jk connectors ported to TC 4 (and I am still hoping to do some of that work when I find the time). If and when that happens, it might make sense to consider a new sub-project. Until then, I think that would just add complexity to the build process. -Dan GOMEZ Henri wrote: My proposal come from the constat we have now 2 differents Tomcat distro 3.2.x and 3.3.x each one with a different level of mod_jk. Tomcat 4.x could also benefits from a port of mod_jk even if they have started working on mod_webapp. May be via a merge of both parts in mod_jk/mod_webapp. So why not a common connector related sub-project, with mod_jk native part and AJPx connectors (for TC 3.2/3.3/4.0) ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] -- Dan Milstein // [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: mod_jk TC 3.2.2 != TC 3.3
[I meant to send this to the list on Sunday, but apparently sent it only to Henri -- I'm sending it here just to keep you all up to date on the conversation.] I'm not sure if I support this -- the 3.2.2 release is supposed to be purely bug fixes. Some of the work which has gone into mod_jk 3.3 are really new features (support for WebDAV, for example). What do you see as the main reason for importing all changes into the 3.2 native code? I don't particularly want to multiply the codebases we support (and the differences between them), but, especially since we're nearing a 3.3 release, my instinct is to vote against applying all the 3.3 work to the 3.2 branch. I will take a look at the diffs and see if there any bug fixes which didn't make it into 3.2. I've tried to apply fixes to both branches. -Dan GOMEZ Henri wrote: I didn't received replies to my post on mod_jk differences between TC 3.3 and TC 3.2.2. I've proposed to copy all the mod_jk native code from TC 3.3 to TC 3.2.2 before release. They were many bugs fixed in both native and java parts, and it will be a pitty to let the release goes without that fixes. I think that both Dan and Keith have each time back ported the Java corrections in tomcat_32 but it must be validated with them. Another interest, is that mod_jk from TC 3.3 works with the latest Apache 2.0. -Original Message- From: GOMEZ Henri [mailto:[EMAIL PROTECTED]] Sent: Friday, February 09, 2001 12:15 PM To: [EMAIL PROTECTED] Cc: Dan Milstein; Keith Wannamaker Subject: mod_jk TC 3.2.2 != TC 3.3 = was RE: [PROPOSAL] Tomcat 3.2.2 Rele ase Plan While looking updating TC 3.2.2 with mod_jk for Apache 2.0 I notice that mod_jk from TC 3.2.2 and 3.3 are still differents I attached a list of diff without the version which are also different in each files. I propose that the whole TC 3.3 mod_jk native code (ap1.3, ap2.0 and common) are reimported in TC 3.2.2 to avoid confusion and mistake, and let us be sure we at the same level. What about ? Who could do that ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] -- Dan Milstein // [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [VOTE] Tomcat 3.2.2 Release Plan
[X] +1I am in favor of this plan and will help [ ] +0I am in favor of this plan, but am unable to help [ ] -0I am not in favor of this plan [ ] -1I am against this plan being executed, and my reason is: -Dan -- Dan Milstein // [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Updating the Jakarta Website
I just checked out a copy of the website and updated one of the pages (added my info to "Who We Are"), but, when I tried to check it back in, I got the following: Access denied: Insufficient Karma (danmil|jakarta-site2/docs/site) cvs server: Pre-commit check failed Access denied: Insufficient Karma (danmil|jakarta-site2/xdocs/site) cvs server: Pre-commit check failed cvs [server aborted]: correct above errors first! What gives? -Dan p.s. In case you're wondering, I *did* follow the instructions in the various docs (edited whoweare.xml, built whoweare.html). -- Dan Milstein // [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PATCH] for NetWare
Mike, I just tried to apply your fixes, and I'm totally failing -- the local diff command isn't recognizing the files as being at all similar (despite the fact that they look similar on visual inspection). I have a *very* strong suspicion that this has to do with line-ending characters. It looks like you are using a non-Unix system, which I am going to guess has a different convention for line-endings. The cvs client will magically fix this when you check files out and check them in (i.e. it translates non-Unix to Unix conventions transparently). So a 'cvs diff -u' should probably work, but, when you email me your checked out copy, it's got non-Unix line endings, so when I try to diff it against the copy I've checked out on my Linux box, diff thinks that every line is different. Short version: can you email me patches generated from 'cvs diff -u'? I'm fairly certain I can get those to work. Thanks, -Dan -- Dan Milstein // [EMAIL PROTECTED] Mike Anderson wrote: Attached are some patched files and a diff file for NetWare. These have been diffed against the latest version in the jakarta-tomcat tree. The jk_util.c and jk_nsapi_plugin.c are the same fixes that have been put into the tomcat-32 branch and I will submit the ApacheConf.java to the tomcat-32 branch as well. diff.txt - diffs of the files jk_util.c - Fixes a problem when shutting down the webserver on NetWare. The exit thread only has a 16k stack so we dynamically allocate the log buffer so that we don't blow the stack. jk_nsapi_plugin.c - Fixes a problem with the netbuf_getbytes function not being available on NetWare 5.x. ApacheConfig.java - Updated to write a correct mod_jk.conf-auto for NetWare. Thanks Mike Anderson Senior Software Engineer Platform Services Group [EMAIL PROTECTED] Novell, Inc., the leading provider of Net services software www.novell.com diff.txtName: diff.txt Type: Plain Text (text/plain) Name: jk_util.c jk_util.cType: unspecified type (application/octet-stream) Encoding: base64 Name: jk_nsapi_plugin.c jk_nsapi_plugin.cType: unspecified type (application/octet-stream) Encoding: base64 Name: ApacheConfig.java ApacheConfig.javaType: unspecified type (application/octet-stream) Encoding: base64 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] -- Dan Milstein // [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
3.2.2 Release?
There was some discussion about producing a 3.2.2 release at some point soonish. Where is that now? People have contributed some excellent fixes in the connector area, and I would love to see those available to the general public. I'm not in a position to function as the Release Manager, but I can help collect info about what fixes have been made in the mod_jk/connector area. -Dan -- Dan Milstein // [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
HTTPS Redirect/encodeURL problems (Bugzilla #269)
Within Tomcat Head / 3.3 there are a host of problems with https pages and
various url related methods (redirect, encodeURL, etc.) As Andreas
Stubenrauch notes in the above bug report, this is a very serious, show
stopper problem. What's more, he has found the source of the problem. In
org.apache.tomcat.facade.HttpServletResponseFacade.toAbsolute(String url)
There is a call to:
new URL(new URL(requrl), location)
Where requrl is a string representation of the current request, and location
is the page being encoded or redirected to. The inner URL() constructor is
going to try to obtain a URLStreamHandler for whatever scheme is associated
with the request url. However, with JDK 1.1 (and 1.2?), there is no https
URLStreamHandler included, so this throws a MalformedURLException, which
causes all the problems.
I've just done some looking around, and, unfortunately, an HTTPS
URLStreamHandler is a pretty complicated thing to come up with, and I'm not
seeing one which is available under a license by which we could include it.
We could require JSSE, but, that seems unacceptable to me, because of the
following (common) setup:
- User has SSL-enabled Apache (proprietary, open, whatever). It listens on
SSL 443, and forwards requests to TC.
- TC doesn't need to know anything about SSL, it only needs to be able to
generate https url's when it encodes or redirects.
To require users in that situation to obtain JSSE, with whatever
complexities encryption laws places on that process, seems ridiculous.
So, I'm thinking about writing a hack which handles https as a special case:
try {
url = new URL(new URL(requrl), location);
} catch (MalformedURLException e2) {
try {
if(requrl.startsWith("https://")) {
requrl = "http" + requrl.substring(5);
url = new URL(new URL(requrl), location);
return "https" + url.toString().substring(4);
}
}
catch(MalformedURLException e3) {}
return (location); // Give up
}
Other than the fact that this has the flavor of a disgusting hack, it seems
like a workable, pragmatic solution. But before I commit it, I wanted to
check with people who maybe have a deeper understanding of the way of the
URLStreamHandler and its friends. (I am trying the basic URL(requrl)
constructor first, so if the user does have an https URLStreamHandler
installed, it should find it). I think the above should respect
non-standard ports (another issue).
Can anyone tell me why the above is a bad idea? Or does it sound like a
reasonable way to go?
-Dan
--
Dan Milstein // [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: 3.2.2 Release?
Can someone who has functioned as a release manager for a dot release give me a quick overview of what's involved? I may be able to find the time, but I'm not totally clear on the scope of what needs to happen. I don't think Milestone releases would make sense -- from what it says on http://jakarta.apache.org/site/binindex.html, those sound like they should really be steps towards a major release of new functionality, not snapshots of bug fixes in a released product. Nightly builds I would be fine with, however. -Dan [EMAIL PROTECTED] wrote: I'm in the same boat right now. I'd love to a 3.2.2 released but I'm way too busy right now to manage a release. What about a "milestone" ? It doesn't have all the requirements of a release. I can add a nightly build of 3.2.x to my scripts too ? ( it'll not be a "blessed" release, but people who need the patches can use it ). Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] -- Dan Milstein // [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Publishing without Restarting Tomcat
If you're working with standalone containers, I have no idea. If you're working with containers behind web servers, here's what I know: In the JServ days there was, with mod_jserv, a way to do a "GRACEFUL_SHUTDOWN" (or something like that) of a particular container to which mod_jserv was sending requests. This would stop sending any new sessions to that container, but would continue to send already-established sessions there. This would give you the functionality you're looking for. I know very little about using mod_jserv with Tomcat (as opposed to with JServ) -- it's possible that this combination would give you what you want. This particular feature is *not* supported by the load balancing system in mod_jk, which is the current plugin of choice for the 3.x branch. It is a highly-requested feature, however, and there's been some discussion of it here lately. It's not impossible that it will get implemented within the next month or two. -Dan William Flanders wrote: Is there a system on the servlet container level which would, after a publish, redirect *new* users to a separate servlet container, but keep old users on the old servlet container? Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] -- Dan Milstein // [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Session Problem
Jim, How are you connecting Apache to Tomcat: - Are you using the mod_jk plugin? - Which connector are you using (ajp13, ajp12)? - Are you using load balancing? There was a bug with the load balancer in mod_jk which was causing it to fail to read the session from the cookie if there was more than one cookie being sent back by the web browser. That doesn't sound like exactly what you've been finding, but hey, who knows? The fix for that is in the cvs tree for 3.2 -- the file is src/native/jk/jk_lb_worker.c Good luck, -Dan Jim Urban wrote: This problem is happening on both Tomcat 3.1 and 3.2.1 on Windows NT with Apache. I have a servlet based application that is having session problems. The browser front end includes an applet which uses HTTP protocol to send and request data to and from the server. Sometimes, not always, the servlet is given a new session instead of the existing session whose id was sent from the applet. Here is an example of what the servlet is receiving: HTTP METHOD: POST CLIENT IP: ***.***.***.*** SESSION ID: vqbuezrxy2 SESSION ID VALID: true SESSION NEW: true SESSION CREATION TIME: Wed Jan 31 11:09:32 PST 2001 SESSION LAST ACCESS TIME: Wed Jan 31 11:09:32 PST 2001 SESSION ID STORED IN COOKIE: true SESSION ID STORED IN URL: false REQUEST HEADER: content-type = [application/x-www-form-urlencoded] connection = [keep-alive] cookie = [JSESSIONID=buxhcnqsi1] accept = [text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2] host = [***.***.***.***] content-length = [11] user-agent = [Java1.3.0] (I typed the *'s over the IP address for security reasons). As you can see, the session is new and has an id of vqbuezrxy2, while the request header contains a cookie with a session if of buxhcnqsi1. This results in our servlet failing since the new session does not contain any of the data the servlet needs. We are a week away from going live and I must resolve this issue. Any fix or work around will be greatly appreciated. Please reply to [EMAIL PROTECTED] -- Dan Milstein // [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Problem with mod_jk and ajp13
Peter, There was a bug with POST size 8K. This has been fixed in the 3.2 and 3.3 branches in cvs. I am almost certain that it was fixed in the 3.2.1 release available at: http://jakarta.apache.org/site/binindex.html If you are using the 3.2.1 release and are still seeing this problem, please let me know. -Dan Peter Dai wrote: Hi There, Has anyone seen this problem. 1) I hava been doing applet-servlet communication with both parameters and object, it has been working nicely for any size(upto ~50K) of the request in my application. 2) Then I tried mod_jk / ajp13. For small requests, it worked fine. But for large request, I got the following error: The request came in as a POST, so the size limitation for GET does not apply. 3) Looks like mod_jk and ajp13 can not handle large size POST request. Thanks for anyone who can help Peter Dai 2001-01-31 02:02:55 - Ctx( /dev ): Exception in: R( /dev + /servlet/ManagerServlet + null) - java.lang.ArrayIndexOutOfBoundsException at org.apache.tomcat.service.connector.Ajp13ConnectorRequest.doRead(Ajp13Connec torRequest.java, Compiled Code) at org.apache.tomcat.service.connector.Ajp13ConnectorRequest.doRead(Ajp13Connec torRequest.java, Compiled Code) at org.apache.tomcat.core.BufferedServletInputStream.doRead(BufferedServletInpu tStream.java, Compiled Code) at org.apache.tomcat.core.BufferedServletInputStream.read(BufferedServletInputS tream.java, Compiled Code) at javax.servlet.http.HttpUtils.parsePostData(HttpUtils.java:235) at org.apache.tomcat.util.RequestUtil.readFormData(RequestUtil.java, Compiled Code) at org.apache.tomcat.core.RequestImpl.handleParameters(RequestImpl.java, Compiled Code) at org.apache.tomcat.core.RequestImpl.getParameterValues(RequestImpl.java, Compiled Code) at org.apache.tomcat.core.RequestImpl.getParameter(RequestImpl.java, Compiled Code) at org.apache.tomcat.facade.HttpServletRequestFacade.getParameter(HttpServletRe questFacade.java, Compiled Code) at com.oplink.servlets.ManagerServlet.doGet(ManagerServlet.java, Compiled Code) at com.oplink.servlets.ManagerServlet.doPost(ManagerServlet.java, Compiled Code) at javax.servlet.http.HttpServlet.service(HttpServlet.java:760) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java, Compiled Code) at org.apache.tomcat.core.Handler.service(Handler.java, Compiled Code) at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java, Compiled Code) at org.apache.tomcat.core.ContextManager.internalService(ContextManager.java, Compiled Code) at org.apache.tomcat.core.ContextManager.service(ContextManager.java, Compiled Code) at org.apache.tomcat.service.connector.Ajp13ConnectionHandler.processConnection (Ajp13ConnectionHandler.java, Compiled Code) at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java, Compiled Code) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java, Compiled Code) at java.lang.Thread.run(Thread.java:479) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] -- Dan Milstein // [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [VOTE] CVS Commit: Keith Wannamaker Keith@Wannamaker.org
+1 Jon Stevens wrote: Ok, He has been sending lots of excellent patches as well as the fact that he already has an apache.org account. I think we should give him commit access. We need two more +1's from others with commit access. -jon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] -- Dan Milstein // [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [VOTE] Tomcat 3.3 Release Plan
Tomcat 3.3 Release Plan Ballot: [X] +1I am in favor of this plan and will help [ ] +0I am in favor of this plan, but am unable to help [ ] -0I am not in favor of this plan [ ] -1I am against this plan being executed, and my reason is: -Dan -- Dan Milstein // [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: TOMCAT + mod_jk or mod_webapp
Pier, Glad to hear that you're willing/interested in integrating the mod_webapp protocol into mod_jk. I don't know exactly how easy it would be, but I think it *would* be a big win (you'd get lots of tested C code, load balancing for free, easy upgrade path for users, etc). I've recently discovered that I'll have a chunk of free time in March. I'll try to use some of that to document/explain what is going on in the mod_jk C code (which I am pretty close to understanding, currently). Maybe we can work together then to try to support the mod_webapp protocol with mod_jk. BTW, I do think the mod_jk C code, for all it's initially forbidding lack of comments, is actually very intelligently thought out. Let's keep our eye on this going ahead. -Dan The protocol has been designed especially for solving webapp-related issues, and its implementation can be easily (???) done in JK, but I never understood that code at all. Right now I want to have a "final release" of WebApp before March the 10th (as I'll be returning to Europe shortly after that). After that, I'll be more than happy to consider anything, but right now I have only 6 weeks and a lot of stuff to write :) :) :) Pier -- Pier Fumagalli mailto:[EMAIL PROTECTED] I'm selling my Sony Vaio Z505. Check out http://www.betaversion.org/~pier/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] -- Dan Milstein // [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: jserv SHUTDOWN_GRACEFULLY functionality with mod_jk?
Thom May wrote: I posted a patch against the workers howto to the list a week or so ago, but I'd love to help with documentation. Sorry that it took me a while to get around to applying that patch. Any help with the documentation would be great. I don't have the best sense of how much of it is still accurate (it sounds like maybe you've been testing that, which would be doubly great). One particularly important thing is to clearly document any differences between 3.2 and the jakarta-tomcat HEAD (aka 3.3). In fact, if you do find any such (undocumented) differences, let me (and the list) know -- maybe we can find a way to eliminate some of them. Thanks, -Dan p.s. I have to say that promising to help with documentation is a very effective way to get an old patch applied ;-) -- Dan Milstein // [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PATCH] Ajpv13 webdav support
Keith, Thanks for all the good work. A few followups: 1) Which branch. I agree with Marc -- I think we should probably keep this work on the tomcat HEAD branch (aka TC 3.3). Admittedly, support for the WebDAV headers is right on the line between a bug and a feature, but I'm inclined to be conservative about what we put in TC 3.2. If anyone feels differently, please chime in. 2) As the commit message said, I modified your server.xml to turn the autogeneration of mod_jk.conf *on* by default, because that is how the mod_jk-howto specifies things. Just so you know. If you had some specific reason for setting things up that way, let me know. -Dan Keith Wannamaker wrote: This is a patch against cvs head to add support to ajpv13 for webdav methods: http://www.apache.org/~keith/jk/webdav1.txt Also, this is a patch against cvs head to update the win32 project files to reflect the new directory structure: http://www.apache.org/~keith/jk/win32.txt I'd be happy to backport both patches back to the 3.2 branch if they could get rolled with the pending release of 3.2.2. Keith - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] -- Dan Milstein // [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: TOMCAT + mod_jk or mod_webapp
Great to hear that you want to contribute some work! As to mod_jk / TC 4.0, that's a complicated question. mod_jk is currently used by a lot of people, and will continue to be for a while (I think), since I expect a lot of people to continue to be using the 3.x source in the near future. So any work you do there will definitely be greatly appreciated. It's also been around for a while, and isn't changing much day-to-day (and is thus a good place for you to work). I am working on an AJP13 connector for TC 4, which will allow people to use the mod_jk plugin with TC 4. OTOH, Pier is writing a brand new plugin/protocol/connector for TC 4 (mod_webapp), which promises some big improvements (mainly in ease of configuration and compliance with the servlet spec). It's not clear how mod_jk / mod_webapp will coexist in the future -- personally, I'd like to see the best pieces from both merge, but I don't know when/if/how that's going to happen. If he's interested in help, you could presumably work with him there. Some questions: Where in RFC 1867 (which I just spent a while looking through) does it discuss the issues you mention (early response by the servlet + consumption of the body)? Or is that in a different RFC? Or is it more in the nature of a bug in the current code? Just so I can understand clearly. Do you have test cases where this fails? If so, what version of TC, what web server and what connection protocol (e.g. ajp12, ajp13) were you using? File Upload was badly broken with mod_jk/ajp13 in both 3.2 and 3.x -- some basic bugs have been fixed in both of those repositories, but have not yet been released. Just so you know. Once I have a better understanding of what you're looking to do, I can help steer you towards the right place in the mod_jk C code (or the servlet engine-side java code). -Dan Keith Wannamaker wrote: Hi, I'd like to extend mod_jk to let servlets be RFC 1867 compliant. Specifically, when transmitting a (large) body of a request on the ajp connection: a) mod_jk should be prepared to receive a response from the servlet at any time during the send of the body; and b) mod_jk should consume the remainder (if any) of the request body if a servlet response is received prior to the completion of the transmission of the body. Two question- a) Does anyone have up-front input about making such a change? b) Is there a better place to do the work than on mod_jk in jakarta-tomcat? (ie jakarta-tomcat-4.x?) Thanks for the input, Keith - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] -- Dan Milstein // [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: jserv SHUTDOWN_GRACEFULLY functionality with mod_jk?
Stefan, Michael Kuz actually submitted a nice patch to do just this, which I've been intending to apply. The only thing which has held me back is that you have to restart apache to let it know that it should stop sending new sessions to a particular TC instance. Since you're interested in this area, can I ask you (and anyone else interested) two questions: 1) Do you think restarting apache is a problem? 2) Did the jserv code require restarting apache? Thanks, -Dan [EMAIL PROTECTED] wrote: Hi, are there any plans to add the functionality found in mod_jserv for managing high availability with load balancing? Secifically the shutdown functionality seems to be missing where you could take one tomcat off the load balancing pool and still send old sessions there for a while. Checking the code it would seem that the functionality from jserv_mmap.c and jserv_watchdog.c would need to be added to mod_jk and then jk_lb_worker.c would need to be changed a bit. Are there any forseeable problems with doing this? Maybe is something else planned to improve the high availability features of mod_jk in the direction of what mod_jserv has or maybe something better? If there is'nt I'll try to use the code from mod_jserv and see what comes of it. BR, Stefan berg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] -- Dan Milstein // [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: jserv SHUTDOWN_GRACEFULLY functionality with mod_jk?
Thom, Thanks for the feedback. 1) The mod_jk howto / vhosts The mod_jk user docs are (as far as I can tell) kind of a mess. I have a medium-term goal of overhauling them and cleaning them up, but I haven't done so yet. I'm not clear on what they say about vhosts, and, to be honest, I'm no major expert on vhost configuration. I'll try to take a look at this when I get a chance -- could you maybe send me the following: - A piece of a sample vhost config / mod_jk config which "should" work. - The specs for the system where it's currently not working. Specifically: Apache version, TC version, connector protocol (e.g. ajp12, ajp13). That would be very, very helpful. 2) Word-wrapping RED-FACED WITH SHAMEThanks for pointing this out -- I had totally forgotten that I had this set this way./SHAME Hopefully I have now fixed that. 3) Restarting Apache == Bad Makes sense to me. Anyone else? A heartbeat would be a nice addition -- however, in the case of the specific functionality requested (stopping new sessions from going to a TC instance), you still need to somehow let an administrator tell the system to stop using that instance for *new* sessions (while still sending current ones there). The instance is functioning fine, but you decide proactively that you'll want to shut it down soon. So you (the admin) somehow need to tell the lb_worker to move that instance onto a special list. Michael's code does a nice job of handling that "special list" -- he sets up a new flag for the workers being managed by the lb_workers, and does all the right things in terms of not sending new sessions, etc. If we don't restart Apache, does anyone have any grand ideas about how to communicate to the mod_jk plugin that it should shift a particular worker into this state? We could put it on the TC side, but then we'd have to modify all the protocols to communicate back to the plugin that they should no longer get new sessions. That seems tricky to me. Or maybe the lb_worker should open up an out-of-band communication channel with TC? That would be nice, because it could then control all of the workers, regardless of protocol. Opinions? Can anyone comment on how hard/easy this would be to do entirely on the Apache side? -Dan -- Dan Milstein // [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PROPOSAL] Tomcat 3.3 Release Plan
Larry, First off: +0 Actually, I'm planning on contributing bug fixes and documentation in the mod_jk/ajp areas, so I'm sort of a +.5 -- I don't think I can be one of the core Release Team, but I am planning on committing some real time to supporting this version pre- and post-release. Just so you (or whoever is the RM) knows. Secondly, some of the wording about release dates confused me: At the bottom of the Milestone 2 release (which is scheduled for Feb 8th, one week after M1), it says: "Should that not be the case, this release may be skipped since the beta release is expected a week later." But the Beta release is March 15th -- 5 weeks later. Is M2 supposed to March 8th? -Dan Larry Isaacs wrote: To complete the task of bringing the development on the jakarta-tomcat MAIN branch to a release, I offer the Tomcat 3.3 Release Plan. Though this version of Tomcat contains no major feature enhancements, it does contain a sufficient number of improvements and other changes to warrant being called Tomcat 3.3 to distinguish it from Tomcat 3.2 and its maintenance releases. The Tomcat 3.3 Release Plan may be found at: http://jakarta.apache.org/cvsweb/index.cgi/~checkout~/jakarta-tomcat/RELEASE-PLAN-3.3 Since I am volunteering to be the Release Manager for this plan, this document already has my name filled in. However, my support of this plan is not contingent on me being the Release Manager. I am will to support someone else if they wish to volunteer. In addition to the release plan, the STATUS.html document has been updated, and may be found at: http://jakarta.apache.org/cvsweb/index.cgi/~checkout~/jakarta-tomcat/STATUS.html This file documents some of the changes that have been completed and targeted for the milestone 1 release, but doesn't cover all the changes made since Tomcat 3.2. It also includes action items specifically addressing the task of releasing this version of Tomcat. Many of the action items left over from the Tomcat 3.2 version of this document have been moved to the "Ideas For The Future" section at the end. This is based on the assumption that work for these items wasn't completed. If I am in error on one of these items, or you know who should be added as having volunteered on any of them, please let me know. It should be noted that when this plan comes up for a vote, a +1 by a committer will constitute a commitment not only to helping with the release, but to provide maintenance support beyond the release. Thanks, Larry Isaacs __ Larry Isaacs [EMAIL PROTECTED] SAS Institute Inc. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] -- Dan Milstein // [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PROPOSAL] Tomcat 3.3 Release Plan
This has probably already been covered, but just to be sure... Once the proposed revisions and clarifications have been decided on (on GENERAL), can the final product be posted to this list? I do want to understand what my votes mean, but I am not planning on subscribing to the GENERAL list (I don't want to sit in on the debate, just understand the outcome). -Dan Hans told us he is going to submit (on GENERAL) his proposed revisions and clarifications to the voting rules sometime today -- if you care about these issues, and are not yet subscribed there, I would suggest doing so (send an empty message to [EMAIL PROTECTED]). Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] -- Dan Milstein // [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Call for volunteers
Costin, Although I don't think I'll have enough time to reproduce and fix general bugs which have been submitted, I will happily commit to working on any mod_jk / ajp13 issues which come up. In other words, I don't think I can be part of the core "release team", but I will definitely contribute whatever expertise I have in the connector area. -Dan [EMAIL PROTECTED] wrote: Hi, As you know, a number of people expressed interest on releasing a new dot version of tomcat3. They believe that the changes made so far to the main branch are making the code more maintainable and faster than 3.2. This cannot happen without your help. Before making an official proposal and asking for a vote, I need to have an idea about how much help can I get from tomcat commiters, non-commiters and users. -- Dan Milstein // [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: sendRedirect, include and forward don't work with mod_jk and non standard ssl port
Filip, Which connection protocol are you using? ajp12? ajp13? jserv? -Dan Filip Hanik wrote: neither of the above functions work properly when I am using a non standard port for https (ex: 445 instead of 443) Apache 1.3.14 Tomcat 3.2.1 + mod_jk.so Open SSL 0.9.6 mod_ssl 2.7.?-1.3.14 any idea why this is happening? Filip ~ Namaste - I bow to the divine in you. ~ Filip Hanik Technical Architect [EMAIL PROTECTED] -- Dan Milstein // [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: sendRedirect, include and forward don't work with mod_jk and non standard ssl port
I don't know if that will fix the problem, but if you could try that (i.e. using ajp13 and seeing if you still have this problem), that would definitely help me narrow this down (and since there seem to be some basic redirect problems in TC 3.2 / mod_jk, that would be very, very helpful). Thanks. -Dan p.s. What browser are you using? Filip Hanik wrote: ajp12 should I try ajp13? Filip ~ Namaste - I bow to the divine in you. ~ Filip Hanik Technical Architect [EMAIL PROTECTED] - Original Message - From: "Dan Milstein" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, January 19, 2001 4:18 PM Subject: Re: sendRedirect, include and forward don't work with mod_jk and non standard ssl port Filip, Which connection protocol are you using? ajp12? ajp13? jserv? -Dan -- Dan Milstein // [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: sendRedirect to PDF - repeats 3 times?
Are you using TC in standalone mode?
If not, are you using mod_jk? If so, which protocol are you using for your web server
talk to Tomcat (ajp13? ajp12? jserv?). Now that I mention it, what web server are you
using?
Thanks,
-Dan
Dave Frankson wrote:
Hello all,
I am experiencing a strange error, and I'm hoping someone can point me in the right
direction.
Using Tomcat 3.2.1 or the latest 3.3, I have a simple servlet that has two lines of
code in its doGet method which forwards a request to a pdf:
System.out.println("Forwarding to the PDF...");
response.sendRedirect("http://localhost:8080/campus/pdf/iep.pdf");
When I use IE 5.0 (version 5.00.2920.) and hit the servlet with a GET request,
the servlet executes three times and then fails to redirect to the pdf.
The weird thing is this doesnt happen in IE 5.5 and it doesnt happen in Netscape. I
need to get this fixed, and I was hoping someone could point me at the code I need to
work with.
Thanks,
Dave Frankson
--
Dan Milstein // [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
TC 4 / mod_jk
Craig, I assume I'm the person interested in porting mod_jk to TC 4 (if there's anyone else, please get in touch with me ;-). Thank you for clarifying the issue about the difference between the 2.2 and 2.3 specs -- I hadn't realized that. I do have a question: how would you feel about including mod_jk in TC 4 before it became totally 2.3 compliant? In other words, if I managed to write ajp13 and/or ajp12 connectors for TC 4, how would you feel about that being committed to cvs immediately, so that people could start using it (and using TC with various web servers), *before* making the extensive additions which would be necessary to bring it into 2.3 compliance? To my mind this would be worthwhile, and in keeping with TC 4 development in general -- there is the doc specifying the various degrees of "doneness" of 2.3 compliance. I see it as a very pragmatic path -- I believe that adding a functional web server connector would give many, many more people reason to start using TC 4, which can only be a good thing. And, I hope, that increased usage would bring more volunteer resources to bear on the connectors -- which could be mod_webapp or mod_jk. I ask this because I am honestly not sure how much time I can devote to the project -- I am hoping to write the ajp13 connector, but I am not sure if I will have the time to rewrite all the C code (something I'm not as expert at) to bring mod_jk into 2.3 compliance. If I can only offer the code for the current ajp13, would that be something you would be comfortable with merging into the TC 4 codebase? Thanks, -Dan "Craig R. McClanahan" wrote: GOMEZ Henri wrote: [finally ... a technical issue!] I still didn't understand why TC 4.0 didn't select mod_jk as their connector to WebServer. The code is clean and many bugs are removed. A web server connector is not an easy piece of cake so why reinvent the whell ?-( Tomcat 4.0 did not select mod_jk for several reasons. The most important ones are at the top: * MOD_JK (like MOD_JSERV before it) has no clue what a web application is. This forces you to configure many items twice -- once in the web.xml file and once in the Apache configuration, which is a pretty serious imposition on people trying to administer the combination. * While the 2.2 spec was silent in many areas, the 2.3 spec will require an Apache+Tomcat combination to obey *all* the requirements of the spec (same rules as for any other container). This means that the things in web.xml *must* be respected. For example, a security constraint in a web.xml file must be enforced, even on a static resource that is served by Apache instead of Tomcat. Substantial modifications to MOD_JK would be needed to make this work (primarily in adding a two-way exchange of configuration information). * MOD_JK had no committers interested in maintaining it, at the time that the decision was made. Subsequent to that time, several volunteers have surfaced, including at least one person interested in supporting MOD_JK under Tomcat 4.0. That would be fine with me, as long as the result obeys all the rules. Craig McClanahan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] -- Dan Milstein // [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PATCH] adapter in load balancing (version 1.2 - Tomcat 3.2.x)
Benoit, Thanks -- I actually just fixed this in the 3.2 branch. -Dan Benoit Derouet wrote: Hi, The load balancer worker fail to handle load balancing (with sticky sessions) if the application uses custom cookies. In some circumstances, the load balancer worker can't retreive the server name from the JSessionID cookie and is not able to redirect to the good server. The algorithm parse the cookie header to extract the server name from the JSessionID cookie. It find properly the end of the server name but fail to cut the chars after. So, it works fine if the cookie header contains only one cookie (or if JSessionID is the last cookie) but If they are custom cookie, the server name extracted will be: "servername;mycookieVal=myCookieValue .." The bug is fixed around line 170. (line id_end=NULL; replaced by id_end[0] = '\0'; ) 'hope this will be integrated in future versions ! (as our customers need sticky load balancing...) regards. Benoit -- Dan Milstein // [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: mod_jk and acl
I haven't had a chance to work on this yet, and I don't think I'll have an opportunity soon, so if you want to send some code along, that would be great. -Dan GOMEZ Henri wrote: Hi, What's the status of ACL to mod_jk ? I take a look at what to do on tc 3.3 to restrict connections to tomcat with rules la hosts.allow/hosts.deny but didn't know if Dan or Costin does something like this ? I could send some code if nothing is done yet... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] -- Dan Milstein // [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: acive session count?
Costin, Hmmm. On the one hand, I very much like your idea of a) moving these admin-type functions out of the mod_jk code and into a handler and b) not requiring a restart of the web server. On the other hand: 1) Michael's code doesn't actually modify the Ajp13 protocol -- it adds a new configuration option to mod_jk.conf, which alters how the web server behaves. So it's not adding any complexity to the protocol. 2) An admin handler would have to be controlling the behavior of the web server. Since one of the strengths of the mod_jk C code is that it works with many servers, any handler which ran in the web server's space would have to be written for a variety of servers. The configuration code which Michael modified is cross-platform, so this is not an issue. 3) Although I, too, fear creeping featurism, I think this function (having the load balancer stop sending new sessions to a container instance) is actually an important piece of what a load balancer does. 4) My instinct is that requiring a restart is probably not a tremendously evil thing. I'm inclined to commit his patch on the 3.3 branch -- I don't think it belongs on 3.2, because it's not really a bug fix. What do you think? -Dan [EMAIL PROTECTED] wrote: Hi, Solution: Dan Milstein is adding my patch to mod_jk. It forces an instance of Tomcat in the load balance list to reject new connections, but continue to service existing sessions. (by setting worker.name.active=0, and restarting my apaches) Question: can this be done _without_ restarting apache ? I was thinking about the whole "configuration/reconfiguration/signales" mechanism, and IMHO there is a simpler solution: instead of using signals and AJP13 extensions, it may be better to just use plain HTTP and normal servlets/apache handlers. Creating a simple /jk_admin is not difficult ( a simple handler that will accept an authenticated HTTP request and alter the configuration ). That will allow run-time addition of apps and workers without restarting apache. For tomcat side, few extra servlets on the admin app will be much easier and safer to develop than changing the protocols or other internals ( and will probably be more re-usable ). In general, using common servlets / handlers is much easier, will allow more people to contribute and can be done independently ( without change in the main distribution, so without too much to worry about tomcat release cycle or featurism ). ( For apache/server side - while changing mod_jk and adding /jk_admin inside it may look simple, we can also create a new module and then use it to manage jk - this will keep the mod_jk code simple ). Costin -- Dan Milstein // [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PATCH PROPOSAL] for mod_jk
Michael, I took a look at this patch, and it looks good to me. A very useful extension to what the load balancer is doing. I'll try to find some time to test and apply it soon. One caveat, however: I'm hesitant to add something like this without also adding documentation for it. Could you possibly add a few lines to an appropriate mod_jk doc and submit that as a patch? Thanks in advance, -Dan -- Dan Milstein // [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [VOTES] Tomcat 4.0-Beta-1 and New CVS Repositories
On the other hand, a separate repository causes no problems that I've
experienced, and avoids all of the issues listed above.
I agree that branches under CVS are way, way confusing, and so I'll support a separate
repository. The one disadvantage I do see, however, is that we'll lose the ability
for CVS to automatically merge changes from one branch into the other. For example,
if we have a 4.0 and a 4.1 ("Head") branch, then, *in theory*, we could make bugfixes
on 4.0, and then ask CVS to automatically merge those fixes into the "main" 4.1 branch.
With separate repositories, we'll have to do those merges by hand.
On the other hand, having worked extensively with CVS branches, those merges between
branches are very temperamental, so I want to emphasize the "in theory" part.
Just I thought I should point this out...
-Dan
* Branches are mysterious to CVS newbies, and make
the learning process that much harder than it needs to be.
It's also messier for folks (like me) who have to work on
multiple releases at the same time.
* Branches tend to be less visible to project newcomers --
for example, anyone who checks out the main branch of
"jakarta-tomcat" today is going to wonder why it is quite
different from the 3.2.1 source distribution that he or she
grabbed off the web site.
* Branches make life harder for "automated check out and build"
scripts like the one I use to create nightly distros of several of
the Jakarta packages, and like what Sam Ruby is building at:
http://oss.software.ibm.com/developerworks/opensource/jakarta/proto/index.html
You have to make special provisions in scripts like this to check
out branches other than the main one, which makes them more
fragile and error-prone.
--
Dan Milstein // [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Licensing / Source Question
In the course of some work I've been doing on Tomcat, I've been thinking about using a
Thread Pool. There is currently a bunch of code doing this in both TC 3 and TC 4,
but, no surprise, it's extremely difficult to understand and/or extend.
Doug Lea, author of Concurrent Programming in Java, has written a set of concurrency
utility classes, including a very nice-looking ThreadPool ("PooledExecutor")
implementation, and some good "Channels" for communication between threads. He
documents these at:
http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html
I'm interested in using his code, but I'm not sure if it can be included in the TC
source. Here's what he says about the license:
"All classes are released to the public domain and may be used for any purpose
whatsoever without permission or acknowledgment."
My suspicion would be that we couldn't bundle up his code as part of a TC download,
but I'm not totally clear.
Can anyone help me understand this?
Thanks,
-Dan
--
Dan Milstein // [EMAIL PROTECTED]
Re: [RFC] Distributed sessions in Catalina
I have a bit of fear that you're getting into extremely complex waters here, and I want to be sure you focus on the most useful bits first. Any form of distributed synchronization of data is very difficult to get right, IMHO. Which is not to say that it shouldn't be done, nor that your ideas below are off base, but rather that I would vote for focusing on a smaller piece of the puzzle first. For example, maybe fault tolerance is what seems most important (I think this would be my vote). Then you can look at distributed sessions as being about: - Allowing Tomcat instance A to back up session information to Tomcat instance B - Configuring whatever device is load-balancing among Tomcat instances to know that it should reroute A's session to B if instance A becomes unavailable. (Incidentally, Shai Fultheim is working on this problem at the moment -- he's at [EMAIL PROTECTED]). This would be a good-sized (but manageable) bit of work, and would provide a very important piece of functionality. It takes advantage of the existing solutions which make sessions sticky to a particular tomcat instance (e.g. mod_jserv/mod_jk load balancing, router-level solutions, etc). If you do allow multiple TC instances to update a given session at once, you have to worry about all sorts of hairy concurrency issues. Two requests from the same session could come in simultaneously (from a framed site, for example). If one goes to A and one goes to B, and both A and B try to update the session at the same time, the code to handle that is going to be very complex. The other main goal you cite is "improving performance by distributing load". Given that there are currently several ways to make sessions sticky to particular TC instances, I'm not sure how much work I would put towards that goal. So I guess my summary is that I see session replication in support of fault tolerance as very worth working towards, but a more general form of session replication as someting to hold off on. -Dan -- Dan Milstein // [EMAIL PROTECTED]
Re: mod_webapp / mod_jk
Another point of mod_jk is for Dan and about the question of security and or ligth crypto support. ajp12/ajp13 didn't support ACL to accept/deny connections from a list of known host, and the protocol is in clear text. Costin suggest using SSH tunnels which be a fast work-around but I really like to have this ACL+CRYPTO included in mod_jk/ajp13. I agree that some form of authentication (and possibly encryption) are high-priority things to add to mod_jk / ajp13. Before I dive into that work, though, I want to be sure that there is a future for the code -- that's why I'm proposing using it in TC 4 as well as TC 3. In some previous discussions about extending ajp13, there had been hope that it could be done fairly easily, since there are typed packets, so new packet types could be added without breaking the protocol. Unfortunately, I don't think that's going to work -- the current code does read packet types, but if it sees an unknown packet type, it closes the connection down. This makes it impossible to send packets in an exploratory manner. Fortunately, the ACL's should be implementable without touching the packet types (I think you suggested this, Henri). We can just add a list of safe hosts to the configuration directives for TC, and it will only allow connections if they come from the specified hosts. I think this would still leave us open to IP address spoofing, but it would certainly be an improvement over what we've got now. For encryption, we would have to introduce new packet types. Personally, my feeling is that encryption of the stream between the Web Server and TC is much less important than authenticating connections. Especially given that SSH tunnels are not that hard to set up, I am reluctant to add the complexity of crypto code to ajp13. Finally, going ahead. I think it would be a good idea to introduce ajp14 (once the bulk of the work above has been completed). I would propose it as a slight variant on ajp13. Basically, the same protocol, with a few new packet types (we need something to handle 8K of header information), *and* with provision for handling unknown packet types more intelligently. I think this would give us a protocol which we could live with more easily over time. We could add new features, but it could still communicate with old web server plugin versions. -Dan -- Dan Milstein // [EMAIL PROTECTED]
Re: VOTE: New Commiter Shai Fultheim (was:RE: Tomcat session replicator)
+1 Nacho wrote: Shai has contributed great bug fixes ( one specially difficult in 3.2, thanks Shai ) and he wants to contribute a distributed session manager It has been proposed as committer by Craig in a informal way, now it's proposed in a formal way :-) it has my +1 as well +1 from Craig in the message below. Votes , please. -- Dan Milstein // [EMAIL PROTECTED]
mod_webapp / mod_jk
Pier, I wanted to ask you some questions about mod_webapp, and how you might see it working with mod_jk. I seem to have become the default ajp13 / mod_jk expert, and people have been asking for various extensions. I'm reluctant to invest much work in mod_jk/ajp13, given that TC 4.0 is using mod_webapp. However, what would seem to make sense to me would be the following course of action: - Write connectors for TC 4.0 which talk ajp13, the mod_jk JNI protocol, and possibly ajp12. I would be very interested in doing this work. I believe it wouldn't take me very long, given that I could adapt the current 3.3 code wholesale (much of which I understand in detail). Then, TC 4.0 would suddenly be able to talk to all the web servers which mod_jk talks to: Apache 1.3, Apache 2.0, Netscape, IIS, AOLServer. This would be a huge win, and would (I believe) dramatically accelerate the adoption of TC 4. It would also provide a very smooth upgrade path to current users. The only disadvantage would be that we wouldn't see any of the advantages of mod_webapp. I've never seen a design doc for webapp, but my understanding is that one of its big advantages is that it will directly read the web.xml (and server.xml) files, which will greatly ease the configuration process. Could you possibly summarize some of its other features? The reason I ask is that I think the mod_jk C code (the various modules which plug into the web servers), is actually extremely well-written and flexible. It's totally undocumented, but, if necessary, I'd be willing to remedy that (I don't mind writing documentation). One of the best things about that C code is that it allows many different web servers to talk to many different protocols in a very clean way. So I wonder if it would be possible to make it to also talk whatever protocol you're developing as part of mod_webapp. This would mean basically merging mod_webapp into mod_jk (or merging mod_jk into mod_webapp, depending on your perspective ;-). What do you think of this course of action? I'm hoping that you and I can align our efforts so that we can take as much advantage of each other's work as possible. -Dan -- Dan Milstein // [EMAIL PROTECTED]
My Commiter Status
I'm wondering who I should bug about getting my committer login on locus. If I understand the process correctly, I was voted in a few weeks ago, but I haven't heard anything since. Thanks, -Dan -- Dan Milstein // [EMAIL PROTECTED]
Re: Socket Exception using Tomcat 3.2.1
A few questions: - Did you grab an RPM of 3.2.1, or did you build it from a cvs checkout (or tar download)? - Can you post a concise example of a servlet which used to work but no longer does? Thanks, -Dan Shahed Ali wrote: Hi, I upgraded from Tomcat 3.2 to 3.2.1 on Solaris Intel JDK 1.3 w/Apache 1.3.14 (Stronghold 3.0) I even recompiled mod_jk.so with the 3.2.1 src/native/apache1.3 .c file. (BTW a diff -b seems to indicate that both the TC 3.2 mod_jk.so and the 3.2.1 .so generated the same object code) I had 2 web app configured that worked just fine under Tomcat 3.2. Using exactly the same configuration (other than changing the paths etc) one of the apps works fine under TC 3.2.1, but the other gives me the following stack trace and I get a 500 Internal Server Error when I go past the login page in my application. Both the apps use the same framework for jdbc connection pooling / logging in etc etc. Dan Milstein // [EMAIL PROTECTED]
Ajp13 Patches for Tomcat 3.2
All,
I took some of the Ajp13 work I've been doing on the 3.3 branch and applied it to the
3.2 sources. The two attached files contain a fix for the file upload bug. As with
the 3.3 version, there are some changes to the mod_jk.so source files, so to get the
full effect, you'll need to rebuild mod_jk.so and hook it up to apache again.
Possibly, you'll get some benefit from just the java files, but I'm not certain how
that will work out.
WARNING: I have not had a chance to thoroughly test this fix. I do not think it is
ready for inclusion in the "stable" 3.2 builds. I'm offering it here so that 3.2
users who have a great need for the ajp13 / file upload combination can give it a shot.
Enjoy,
-Dan
--
Dan Milstein // [EMAIL PROTECTED]
Index: jk_ajp13_worker.c
===
RCS file: /home/cvspublic/jakarta-tomcat/src/native/jk/Attic/jk_ajp13_worker.c,v
retrieving revision 1.3.2.1
diff -u -r1.3.2.1 jk_ajp13_worker.c
--- jk_ajp13_worker.c 2000/09/13 23:06:25 1.3.2.1
+++ jk_ajp13_worker.c 2000/12/14 05:27:50
@@ -267,7 +267,7 @@
read_buf += 4; /* leave some space for the buffer headers */
read_buf += 2; /* leave some space for the read length */
-if(read_fully_from_server(r, read_buf, len) = 0) {
+if(read_fully_from_server(r, read_buf, len) 0) {
jk_log(l, JK_LOG_ERROR,
"read_into_msg_buff: Error - read_fully_from_server failed\n");
return JK_FALSE;
@@ -331,23 +331,25 @@
case JK_AJP13_GET_BODY_CHUNK:
{
- unsigned len = (unsigned)jk_b_get_int(msg);
+ unsigned len = (unsigned)jk_b_get_int(msg);
if(len MAX_SEND_BODY_SZ) {
len = MAX_SEND_BODY_SZ;
}
if(len ep-left_bytes_to_send) {
len = ep-left_bytes_to_send;
-}
-if(len 0) {
-if(read_into_msg_buff(ep, r, msg, l, len)) {
-return JK_AJP13_HAS_RESPONSE;
-}
-
-jk_log(l, JK_LOG_ERROR,
- "Error ajp13_process_callback - read_into_msg_buff
failed\n");
-return JK_INTERNAL_ERROR;
}
+ if(len 0) {
+ len = 0;
+ }
+
+ if(read_into_msg_buff(ep, r, msg, l, len)) {
+ return JK_AJP13_HAS_RESPONSE;
+ }
+
+ jk_log(l, JK_LOG_ERROR,
+ "Error ajp13_process_callback - read_into_msg_buff failed\n");
+ return JK_INTERNAL_ERROR;
}
break;
Index: Ajp13ConnectorRequest.java
===
RCS file:
/home/cvspublic/jakarta-tomcat/src/share/org/apache/tomcat/service/connector/Attic/Ajp13ConnectorRequest.java,v
retrieving revision 1.5.2.2
diff -u -r1.5.2.2 Ajp13ConnectorRequest.java
--- Ajp13ConnectorRequest.java 2000/12/12 09:41:43 1.5.2.2
+++ Ajp13ConnectorRequest.java 2000/12/14 05:20:40
@@ -250,24 +250,43 @@
public int doRead() throws IOException
{
if(pos = blen) {
-refeelReadBuffer();
-}
+ if( ! refillReadBuffer()) {
+ return -1;
+ }
+ }
return bodyBuff[pos++];
}
public int doRead(byte[] b, int off, int len) throws IOException
{
-// XX Stupid, but the whole thing must be rewriten ( see super()! )
-for(int i = off ; i (len + off) ; i++) {
-int a = doRead();
-if(-1 == a) {
-System.out.println("Y");
-return i-off;
-}
-b[i] = (byte)a;
-}
-
-return len;
+ if(pos = blen) {
+ if( ! refillReadBuffer()) {
+ return -1;
+ }
+ }
+
+ int toCopy = len;
+ while(toCopy 0) {
+ int bytesRemaining = blen - pos;
+ if(bytesRemaining 0)
+ bytesRemaining = 0;
+ int c = bytesRemaining toCopy ? bytesRemaining : toCopy;
+
+ System.arraycopy(bodyBuff, pos, b, off, c);
+
+ toCopy-= c;
+
+ off += c;
+ pos += c; // In case we exactly consume the buffer
+
+ if(toCopy 0) {
+ if( ! refillReadBuffer()) { // Resets blen and pos
+ break;
+ }
+ }
+ }
+
+ return len - toCopy;
}
public void recycle()
@@ -283,7 +302,7 @@
this.in = new BufferedServletInputStream(this);
}
-public void refeelReadBuffer() throws IOException
+public boolean refillReadBuffer() throws IOException
Re: TC 4.0M5 / TC 3.2.1
Wait -- there's a new patch for the 3.3 code which fixes some of the biggest problems -- I'm doing some testing on that now and will publish it to the list today -- but it's *not* in cvs yet. In particular, David -- I believe I've fixed the problem with Ajp13 randomly getting blank pages, but that is *not* yet under cvs. Just trying to keep things clear, -Dan GOMEZ Henri wrote: Unfortunately, the patches are all against a file which doesn't exist in 3.2 (modules/server/Ajp13.java). In 3.2, the relevant file is service/connector/Ajp13Connector.java. So it wouldn't just be a matter of patching. TC 3.3 use a new architecture... If people do like the patches (and no bugs are found in them after a few days), I can probably make a few of the simpler fixes to Ajp13Connector (e.g. fix the multiple cookies problem). Other things (e.g. multipart forms) are a lot more work, and I'm still trying to improve the 3.3 code in some basic ways. I think it will make more sense to try to bring 3.2 in line once I've got everything squared away. Does that make sense? I make sense ;-) If there is around Linux users who want to test the latest TC 3.3 (with the ajp13 patches), just take a look at : http://rpmized.free.fr/ -- Dan Milstein // [EMAIL PROTECTED]
Ajp13 / Tomcat 3.2
Well, I just poked through the Tomcat 3.2 which handles Ajp13, and, though the code's laid out a bit differently, as far as I can tell, the critical problem I described with reading request data is only in 3.3 -- the 3.2 code should not suffer from that particular problem. -Dan -- Dan Milstein // [EMAIL PROTECTED]
Re: TC 4.0M5 / TC 3.2.1
2) There is many workspatch done on AJP13 by Dan Milstein but only for TC3.3 AJP13. Will they be included in TC 3.2.1 ? I'm waiting for the patches on TC 3.3 to see how to incorporate in TC 3.2.1 If people running AJP13 think that the patches are good ones, I'd say let's go ahead and incorporate them in the "tomcat_32" branch so that they'll be included in 3.2.1. Unfortunately, the patches are all against a file which doesn't exist in 3.2 (modules/server/Ajp13.java). In 3.2, the relevant file is service/connector/Ajp13Connector.java. So it wouldn't just be a matter of patching. If people do like the patches (and no bugs are found in them after a few days), I can probably make a few of the simpler fixes to Ajp13Connector (e.g. fix the multiple cookies problem). Other things (e.g. multipart forms) are a lot more work, and I'm still trying to improve the 3.3 code in some basic ways. I think it will make more sense to try to bring 3.2 in line once I've got everything squared away. Does that make sense? -Dan -- Dan Milstein // [EMAIL PROTECTED]
More Ajp13 Patches
Okay, I've done some more basic testing of my new code, so here it is. Let me know if
you find any problems with it.
Here's what I've done:
- Fixed a basic problem with the way request data was read, which would have resulted
in sporadic failure to get all the request data from the client. Don't know if there
are bug reports with this, but from feedback on this list, this has affected a lot of
people. This was a critical problem -- I don't think anyone should be using ajp13 if
their code base has this bug. I'll check out a copy of the 3.2 release this afternoon
and see what's there.
- Fixed the problem with multiple headers (which was causing multiple cookie settings
to fail). I had submitted a patch for this, but I rewrote it at Costin's suggestion
to be more peformant. Bug report #371 (and several others).
- Clarified something in the Ajp13 protocol (if the container tries to read past the
end of the input stream, the server sends an empty packet back -- I'll add this to the
spec soon). This required modifications to some of the mod_jk C code, which I've
attached. This change is backward compatible with the old protocol (which simply hung
the container in this case, so it's not hard to be backward compatible ;-). To get
this fix to work, you'll need to rebuild and reinstall mod_jk.so.
- Fixed the problems with multipart form encodings. Bug Reports #536 + #542 and a
bunch of others. File upload is now working.
- Made some performance improvements (replaced a byte-by-byte copy with
System.arraycopy).
- Some basic code improvements: new methods, improved debugging dumps.
On the other hand, despite my fond hopes, I don't think I've fixed the Bug Report
#468, which hangs up the server when the client fails to send as many bytes as it
promises in its content-length header. I look into that a bit more.
I was also unable to test chunked-transfer -- can anyone supply me with a valid
HTTP/1.1 request which uses chunked transfer? I don't think browsers use this much,
but it'd be nice to be sure it worked.
From feedback on this list, it seems like the most important things to look at next
are:
- Authentication of connections between the web server and the container.
- Setting things up so that the Apache/Tomcat connection behaves better in case of
Tomcat shutting down or restarting. The current set up requires Apache to be
restarted.
I'll keep you all posted...
-Dan
--
Dan Milstein // [EMAIL PROTECTED]
Index: Ajp13.java
===
RCS file:
/home/cvspublic/jakarta-tomcat/src/share/org/apache/tomcat/modules/server/Ajp13.java,v
retrieving revision 1.6
diff -u -r1.6 Ajp13.java
--- Ajp13.java 2000/12/05 06:30:15 1.6
+++ Ajp13.java 2000/12/08 19:21:51
@@ -184,6 +184,9 @@
public void recycle()
{
+ // This is a touch cargo-cultish, but I think wise.
+ blen = 0;
+ pos = 0;
}
/**
@@ -257,7 +260,7 @@
req.serverName().setString( msg.getString());
req.setServerPort( msg.getInt());
- isSSL = (msg.getByte() != 0);
+ isSSL = msg.getBool();
// Decode headers
MimeHeaders headers = req.getMimeHeaders();
@@ -358,6 +361,7 @@
}
blen = msg.peekInt();
+ pos = 0;
msg.getBytes(bodyBuff);
}
@@ -374,7 +378,9 @@
public int doRead() throws IOException
{
if(pos = blen) {
-refillReadBuffer();
+if( ! refillReadBuffer()) {
+ return -1;
+ }
}
return bodyBuff[pos++];
}
@@ -386,30 +392,61 @@
* @param off The offset in the buffer at which to start filling.
* @param len The number of bytes to copy into the buffer.
*
- * @return The number of bytes actually copied into the buffer.
+ * @return The number of bytes actually copied into the buffer, or -1
+ * if the end of the stream has been reached.
*
* @see Ajp13Request#doRead
*/
public int doRead(byte[] b, int off, int len) throws IOException
{
-// XXX Rewrite to use System.arrayCopy (please!)
-for(int i = off ; i (len + off) ; i++) {
-int a = doRead();
-if(-1 == a) {
-return i-off;
-}
-b[i] = (byte)a;
-}
-
-return len;
+ if(pos = blen) {
+ if( ! refillReadBuffer()) {
+ return -1;
+ }
+ }
+
+ if(pos + len = blen) { // Fear the off by one error
+ // Sanity check b.length off + len?
+ System.arraycopy(bodyBuff, pos, b, off, len);
+ pos += len;
+ return len;
+ }
+
+ // Not enough data (blen pos + len)
+ int toCopy = len;
+ while(toCopy 0) {
+ int bytesRemaining = blen - pos;
+ if(bytesRemaining 0
Re: multiple cookies, PR 371, any news?
Costin, Right after I submitted that patch, I looked more carefully into the MimeHeaders code and came to exactly the conclusion you did (and also figured I would fix it as soon as I got commit access ;-). There's some nice code in Http10.java which will work much better (no extra creation of an Enumeration, and also would give me access to the underlying MimeHeader MessageBytes directly, so, with a tiny bit more work, I think I could avoid a bunch of Sring creation altogether). Yeah, MimeHeaders could use some work (it's got a disturbingly high rate of 'XXX' comments). Assuming I'll be able to commit fixes myself soon, I'll clean this all up at that point. Thanks for the feedback, -Dan [EMAIL PROTECTED] wrote: Hi Dan, I think you'll be able to commit the patch yourself very soon. I just have few comments - it's a good patch ( as it solves the problem), but it's not good for performance. We definitely need to do a refactoring of MimeHeaders :-) The idea behind MimeHeaders is to allow efficient storage and access to headers - without creating intermediary objects and with minimal pain. For example, output headers are stored by the servlet or container and most of the time are accessed only once, when the output is sent. In this case it's enough to do indexed access ( using size(), getName( int idx), getValue( int idx ) ). Creating an enumeration and all the string[] for each request is not a good idea IMHO. Costin -- Dan Milstein // [EMAIL PROTECTED]
More Ajp13 Work Completed
All, First off, I want to thank you for nominating me to be a committer. I'm very much looking forward to working on the project. What are the next steps? I just completed another good-sized chunk of work: I believe that I've fixed the multipart form bug (reports #536 and #542), and I rewrote the patch to fix the multiple cookies bug (no longer creating a new Enumeration for every request, as per Costin's suggestion). I'm kind of assuming that I should just hold onto these (rather than bombarding Costin and/or the list with patches), on the theory that I'll be able to commit them myself soon. Does that make sense? Or I could just post the fixes to the list, if that would be better. In the course of fixing multipart form, I modified doRead(byte[], int, int) to use System.arraycopy, which should make it much faster (and it's used for every single Post request, so that's good). I want to do a bit more testing but it's looking pretty good. The old code would also have died on a Request with a body but without a Content-Length (which is allowed for certain Transfer-Encodings by the HTTP/1.1 spec -- I just looked it up). Possibly, I fixed Bug Report #468, which has to do with the content-length not being equal to the actual number of bytes sent -- I'll look into that one. One other thing: in the course of getting this all working, I fixed what seemed to me to be a very serious bug with regard to the persistent connection between the web server and the container. Basically, the read position into the buffer of request data wasn't getting properly reset to 0 for each new request, so reads would start in the middle of the request data in certain cases. At least, that's what I found while I was working on this, but it seems inconceivable to me that this would have been out there without people complaining -- during my testing it was very confusing -- since it depended on what had happened during the previous Request, it seemed totally arbitrary. Does this ring any bells for anyone? If so, then I've fixed it ;-) -Dan -- Dan Milstein // [EMAIL PROTECTED]
Modifying the Ajp13 Protocol
As I'm working through the ajp13 code (C and Java), I'm discovering that there is some basic work which needs to be done on the protocol itself (as well as a lot of work on the implementations). Specifically: - If the request contains 8K of header/attribute information, the protocol fails. - There is no authentication step. I believe that this could result in some serious security violations if the web server is performing HTTP authentication (since remote_user is one of the attributes passed over). [side note: if anyone thinks otherwise, let me know] Since connections are maintained across many requests, there is no good reason not to do the authentication (IMHO). To fix these major issues will require modifying the protocol. I have some ideas on how to do so, but I want to get some feedback on the best way to go about making these changes. I could just modify the protocol itself, and change the mod_jk code and Ajp13 code in the tomcat-3.3 branch. My fear is that I'll be changing a protocol which is in production use, without changing its version number. This seems like asking for trouble. Should I therefore leave ajp13 where it is and work on ajp14? Or is that multiplying protocols needlessly? I realize that the new mod_webapp is being worked on, but it seems to me that getting mod_jk / ajp13 working right is probably still worth it -- there are plenty of people who are going to depend on that before Tomcat 4.0 is released. If I do change the protocol, it will require people who download the new version to update their mod_jk.so at the same time as they rebuild the Java classes. What do people think? -Dan -- Dan Milstein // [EMAIL PROTECTED]
Re: multiple cookies, PR 371, any news?
I thought I'd test out my new status as the resident Ajp13 expert by fixing this bug,
and I think I've got it. I'm attaching patches to util/MimeHeaders.java and
modules/server/Ajp13.java. I've done some minimal testing, and it seems to fix the
problem.
I also did a tiny bit of further cleanup in Ajp13 (in case you look at the patch in
detail).
-Dan
Palle Girgensohn wrote:
Hi!
Just installed tomcat 3.2 final.
I am forced to still use apj12 due to tomcat failing to create
multiple cookies at once when using ajp13 (and possibly also
redirect):
Cheers,
Palle
--
Partitur Informationsteknik AB
Wenner-Gren Center +46 8 566 280 02
113 46 Stockholm +46 70 785 86 02
Sweden [EMAIL PROTECTED]
--
Dan Milstein // [EMAIL PROTECTED]
Index: MimeHeaders.java
===
RCS file:
/home/cvspublic/jakarta-tomcat/src/share/org/apache/tomcat/util/MimeHeaders.java,v
retrieving revision 1.17
diff -u -r1.17 MimeHeaders.java
--- MimeHeaders.java2000/11/20 21:37:45 1.17
+++ MimeHeaders.java2000/12/06 05:11:38
@@ -210,18 +210,29 @@
//
/**
- * Returns an enumeration of strings representing the header field names.
- * Field names may appear multiple times in this enumeration, indicating
- * that multiple fields with that name exist in this header.
+ * Returns an enumeration of strings representing the header field
+ * names. Field names are unique in this enumeration (which is
+ * actually not that useful)
*/
public Enumeration names() {
return new NamesEnumerator(this);
}
+/**
+ * Return an enumeration of header values for a given name.
+ */
public Enumeration values(String name) {
return new ValuesEnumerator(this, name);
}
+/**
+ * Return an enumeration of 2-element String arrays representing pairs
+ * of header names and header values.
+ */
+public Enumeration getNamesValues() {
+ return new NamesValuesEnumerator(this);
+}
+
// Adding headers
@@ -419,6 +430,47 @@
findNext();
return current.toString();
}
+}
+
+/**
+ * Enumerate the names and values together -- cleans up handling of
+ * multiple headers with identical names (Set-Cookie, say). Each element
+ * of the enumeration is an array of length two: { name, value }
+ **/
+class NamesValuesEnumerator implements Enumeration {
+int pos;
+int size;
+MimeHeaders headers;
+String[] nextNameValuePair = new String[2];
+String[] returnNameValuePair = new String[2]; // Reused -- safe?
+
+NamesValuesEnumerator(MimeHeaders headers) {
+ pos = 0;
+ this.headers = headers;
+ size = headers.size();
+ findNext();
+}
+
+private void findNext() {
+ nextNameValuePair[0] = null;
+ if(pos size) {
+ nextNameValuePair[0] = headers.getName( pos ).toString();
+ nextNameValuePair[1] = headers.getValue( pos ).toString();
+ pos++;
+ }
+}
+
+public boolean hasMoreElements() {
+ return nextNameValuePair[0] != null;
+}
+
+public Object nextElement() {
+ returnNameValuePair[0] = nextNameValuePair[0];
+ returnNameValuePair[1] = nextNameValuePair[1];
+ findNext();
+ return returnNameValuePair;
+}
+
}
class MimeHeaderField {
Index: Ajp13.java
===
RCS file:
/home/cvspublic/jakarta-tomcat/src/share/org/apache/tomcat/modules/server/Ajp13.java,v
retrieving revision 1.6
diff -u -r1.6 Ajp13.java
--- Ajp13.java 2000/12/05 06:30:15 1.6
+++ Ajp13.java 2000/12/06 05:12:31
@@ -257,7 +257,7 @@
req.serverName().setString( msg.getString());
req.setServerPort( msg.getInt());
- isSSL = (msg.getByte() != 0);
+ isSSL = msg.getBool();
// Decode headers
MimeHeaders headers = req.getMimeHeaders();
@@ -444,16 +444,18 @@
outBuf.appendInt(headers.size());
-Enumeration e = headers.names();
+Enumeration e = headers.getNamesValues();
while(e.hasMoreElements()) {
-String headerName = (String)e.nextElement();
+String[] nameValuePair = (String[]) e.nextElement();
+ String headerName = nameValuePair[0];
+ String headerValue = nameValuePair[1];
int sc = headerNameToSc(headerName);
if(-1 != sc) {
outBuf.appendInt(sc);
} else {
outBuf.appendString(headerName);
}
-outBuf.appendString(headers.getHeader(headerName));
+outBuf.appendString(headerValue);
}
outBuf.end();
@@ -520,13 +522,13
Draft of ajp13 Documentation
Attached is a first draft of a document specifying how the Ajp13 protocol works. I wrote it based on what I found in both the C and Java sides of the implementation (in tomcat-3.3). There are a few things I want to add to it, but I hope it's pretty useful as is. If anyone has any feedback on this, please feel free to get in touch with me. I'd be happy to hear about any details I may have gotten wrong, and also any suggestions for improving the doc itself (layout, etc). Also, if anyone can help explain *why* certain choices were made, that would be excellent. Enjoy, -Dan -- Dan Milstein // [EMAIL PROTECTED] Title: Apache JServ Protocol version 1.3 Apache JServ Protocol version 1.3 Dan Milstein, [EMAIL PROTECTED], December 2000. This describes the Apache JServ Protocol version 1.3 (hereafter ajp13). There is, apparently, no current documentation of how the protocol works. This document is an attempt to remedy that, in order to make life easier for maintainers of mod_jk, and for anyone who wants to port the protocol somewhere (into jakarta 4.x, for example). Who Am I? I am not one of the designers of this protocol -- I believe that Gal Shachor was the original designer. Everything in this document is derived from the actual implementation I found in the tomcat 3.x code. I hope it is useful, but I can't make any grand claims to perfect accuracy. I also don't know why certain design decisions were made. Where I was able, I've offered some possible justifications for certain choices, but those are only my guesses. In general, the C code which Shachor wrote is very clean and comprehensible (if almost totally undocumented). The Java code is pretty much a mess. Design Goals According to email from Gal Shachor to the jakarta-dev mailing list, the original goals of mod_jk (and thus ajp13) were to extend mod_jserv and ajp12 by (I am only including the goals which relate to communication between the web server and the servlet container): Increasing performance (speed, specifically). Adding support for SSL, so that isSecure() and geScheme() will function correctly within the servlet container. The client certificates and cipher suite will be available to servlets as request attributes. Overview The ajp13 protocol is packet-oriented. A binary format was presumably chosen over the more readable plain text for reasons of performance. The web server communicates with the servlet container over TCP connections. To cut down on the expensive process of socket creation, the web server will attempt to maintain persistent TCP connections to the servlet container, and to reuse a connection for multiple request/response cycles. Once a connection is assigned to a particular request, it will not be used for any others until the request-handling cycle has terminated. In other words, requests are not multiplexed over connections. This makes for much simpler code at either end of the connection, although it does cause more connections to be open at once. Once the web server has opened a connection to the servlet container, the connection can be in one of the following states: Idle No request is being handled over this connection. Assigned The connecton is handling a specific request. Once a connection is assigned to handle a particular request, the basic request informaton (e.g. HTTP headers, etc) is sent over the connection in a highly condensed form (e.g. common strings are encoded as integers). Details of that format are below in Request Packet Structure. If there is a body to the request (content-length > 0), that is sent in a separate packet immediately after. At this point, the servlet container is presumably ready to start processing the request. As it does so, it can send the following messages back to the web server: SEND_HEADERS Send a set of headers back to the browser. SEND_BODY_CHUNK Send a chunk of body data back to the browser. GET_BODY_CHUNK Get further data from the request if it hasn't all been transferred yet. This is necessary because the packets have a fixed maximum size and arbitrary amounts of data can be included the body of a request (for uploaded files, for example). (Note: this is unrelated to HTTP chunked tranfer). END_RESPONSE Finish the request-handling cycle. Each message is accompanied by a differently formatted packet of data. See Response Packet Structures below for details. Basic Packet Structure There is a bit of an XDR heritage to this protocol, but it differs in lots of ways (no 4 byte alignment, for example). Byte order: I am not clear about the endian-ness of the individual bytes. I'm guessing the bytes are little-endian, because that's what XDR specifies, and I'm guessing that sys/socket library is magically making that so (on the C side). If anyone with a better knowledge of socket calls can step in, that would be great. There are four data ty
[PATCH] Code Cleanup/Reorg for Ajp13 Class
I've just completed a major cleanup/reorganization of:
org.apache.tomcat.modules.server.Ajp13
In the jakarta-tomcat branch, which I'm attaching as a patch against the current
version. I have done MINIMAL testing, since I am very new to working on Tomcat, and I
don't know what a standard set of tests might be (or if one exists). I have verified
that Tomcat can still talk to Apache, and that basic request info is being transfered.
That's about all I've been able to do.
The main goal of the rewrite was to clarify what is going on. To that end, I added a
lot of comments, and moved some code around to clarify what it was doing. I also:
- Fixed a minor bug in headerNameToSc -- response headers of type "WWW-Authenticate"
were not being encoded as integers, because of a typo in the Java code. Note that the
old behavior was less efficient (it would send the entire "WWW-Authenticate" string),
but not incorrect.
- Cleaned up all the import statements
- Stripped some unused code out of the internal Ajp13Packet class.
- Moved a lot of functionality out of tomcat.util.BuffTool into Ajp13Packet (where it
seemed much more natural). I believe that BuffTool can now be safely deleted (I just
deleted it and built Tomcat with no problems).
Enjoy,
-Dan
--
Dan Milstein // [EMAIL PROTECTED]
Index: Ajp13.java
===
RCS file:
/home/cvspublic/jakarta-tomcat/src/share/org/apache/tomcat/modules/server/Ajp13.java,v
retrieving revision 1.5
diff -u -r1.5 Ajp13.java
--- Ajp13.java 2000/11/30 04:58:45 1.5
+++ Ajp13.java 2000/12/05 04:25:53
@@ -59,27 +59,51 @@
package org.apache.tomcat.modules.server;
-import java.io.*;
-import java.net.*;
-import java.util.*;
-import org.apache.tomcat.core.*;
-import org.apache.tomcat.util.*;
-
+import java.io.IOException;
+import java.io.UnsupportedEncodingException;
+import java.io.InputStream;
+import java.io.OutputStream;
+import java.net.Socket;
+import java.util.Enumeration;
+
+import org.apache.tomcat.core.Request;
+import org.apache.tomcat.util.MimeHeaders;
+import org.apache.tomcat.util.MessageBytes;
+
+/**
+ * Represents a single, persistent connection between the web server and
+ * the servlet container. Uses the Apache JServ Protocol version 1.3 for
+ * communication. Because this protocal does not multiplex requests, this
+ * connection can only be associated with a single request-handling cycle
+ * at a time.P
+ *
+ * This class contains knowledge about how an individual packet is laid out
+ * (via the internal CODEAjp13Packet/CODE class), and also about the
+ * stages of communicaton between the server and the servlet container. It
+ * translates from Tomcat's internal servlet support methods
+ * (e.g. doWrite) to the correct packets to send to the web server.
+ *
+ * @see Ajp13Interceptor
+ */
public class Ajp13
{
public static final int MAX_PACKET_SIZE=8192;
-public static final int H_SIZE=4;
+public static final int H_SIZE=4; // Size of basic packet header
public static final int MAX_READ_SIZE = MAX_PACKET_SIZE - H_SIZE - 2;
public static final int MAX_SEND_SIZE = MAX_PACKET_SIZE - H_SIZE - 4;
+// Prefix codes for message types from server to container
public static final byte JK_AJP13_FORWARD_REQUEST = 2;
public static final byte JK_AJP13_SHUTDOWN = 7;
+// Prefix codes for message types from container to server
public static final byte JK_AJP13_SEND_BODY_CHUNK = 3;
public static final byte JK_AJP13_SEND_HEADERS = 4;
public static final byte JK_AJP13_END_RESPONSE = 5;
+public static final byte JK_AJP13_GET_BODY_CHUNK= 6;
+// Integer codes for common response header strings
public static final int SC_RESP_CONTENT_TYPE= 0xA001;
public static final int SC_RESP_CONTENT_LANGUAGE= 0xA002;
public static final int SC_RESP_CONTENT_LENGTH = 0xA003;
@@ -91,11 +115,10 @@
public static final int SC_RESP_SERVLET_ENGINE = 0xA009;
public static final int SC_RESP_STATUS = 0xA00A;
public static final int SC_RESP_WWW_AUTHENTICATE= 0xA00B;
-
-public static final byte JK_AJP13_GET_BODY_CHUNK = 6;
-public static final byte SC_A_CONTEXT = 1;
-public static final byte SC_A_SERVLET_PATH = 2;
+// Integer codes for common (optional) request attribute names
+public static final byte SC_A_CONTEXT = 1; // XXX Unused
+public static final byte SC_A_SERVLET_PATH = 2; // XXX Unused
public static final byte SC_A_REMOTE_USER = 3;
public static final byte SC_A_AUTH_TYPE = 4;
public static final byte SC_A_QUERY_STRING = 5;
@@ -103,9 +126,14 @@
public static final byte SC_A_SSL_CERT = 7;
public static final byte SC_A_SSL_CIPHER= 8;
public static final byte SC_A_SSL_SESSION = 9;
-public static final byte SC_
