Re: Misusing dynamic binding when static binding would do.
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. -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: 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: 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: [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: servlet upload data corruption (more)
out.println("Using byte-by-byte read");
> for (int i=0; i fstr.write(istr.read());
> }
> else {
> System.out.println("Using byte-array read");
> byte [] buf = new byte[8192];
> int count = istr.read(buf);
> while (count != -1) {
> if (count > 0)
> fstr.write(buf, 0, count);
> 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] 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
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
hreads for each tomcat callback and using > additional sockets is significant overhead given the time constraints. > > The problem is that the "admin" commands can be passed only on certain > moments: > - when apache connects for the first time ( 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
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: what is the deal with tomcat 4 and web server connectors??
Kevin, One thing which I think would be useful (which I wanted to do myself, but don't think I'll have time to do), would be to write an ajp13 connector for TC 4. This would allow TC 4 users to use mod_jk as their plugin (which supports iPlanet and IIS). If you are interested in doing some development, I think that would be an excellent contribution. Steps: - Take a look through the Ajp13 doc in the 3.3 branch (src/doc/AJPv13.html) -- this explains how the protocol works. - Review the ajp13 connector code in 3.3 (share/org/apache/tomcat/modules/server/Ajp13.java and Ajp13Interceptor.java). - Adapt that code to the TC 4 codebase (basing on HttpConnector, or WarpConnector, possibly). Wins: connect to multiple servers (including netscape and iis), load balancing, debugged C code. Losses: painful to configure Although I don't have time to write this code myself, I can contribute some help (I understand the 3.3 ajp13 code pretty thoroughly). -Dan > Kevin Seguin wrote: > > i want to move from tomcat 3.x to tomcat 4. i absolutely must be able to > use tomcat 4 with netscape/iplanet and microsoft (iis) web servers. as > near as i can tell, the only connector that will be available in the > foreseeable future is for apache 1.3. is this true? > > i have come across very little (almost no) information regarding this new > webapp lib (which appears to be undergoing some significant change > recently) and the warp thing... does *anybody* have anything to share?? > i'm willing to help out with connector development, or even write my own > connectors... if i could only figure out where to start... -- 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: 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: 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: jk_ajp13_worker.c
I would say go for it. It's a hotly desired feature, so hopefully it will see some good testing. Nice work, -Dan GOMEZ Henri wrote: > > Could I commit the latest jk_ajp13_worker.c I send to list ? > > It works fine for more than 1 week... -- 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: Internal Server Errors while/after restarting Tomcat with mod_jk
Jan, Henri Gomez is working on a patch to solve this very problem as we speak -- he is setting it up so that the mod_jk plugin will detect that TC has died, and will attempt to open new connections. Hopefully, that will be testable within a week or two... -Dan Jan Ploski wrote: > > Hi, > > I have two questions regarding mod_jk's way of dealing with Tomcat > going away. > > (1) > > Can mod_jk be extended safely to retry connecting for a certain > time instead of immediately reporting an Internal Server Error if > a Tomcat process is temporarily unavailable? I have modified the > function jk_open_socket to do just that (keep trying for a minute > in 2 second intervals before giving up). However, I am not sure > if this is the correct place and whether it would have negative > side effects in some configurations (for example, I can imagine > that in a clustered setup, mod_jk should not wait for Tomcat to > recover, but fail over to another instance). Any ideas whether this > feature could be made optional or what a better place to implement > it would be? > > The purpose of all that is to make Tomcat restarts (which are inevitable, > as we develop our applications; automatic class reloading doesn't always > do the trick) transparent to the web server. > > (2) > > I observed that stopping and restarting Tomcat while Apache with mod_jk > is running results in Internal Server Errors starting to appear randomly > in further requests. I guess that this is caused by mod_jk trying to > use a now dead Tomcat instance to service a request. However, I looked > into mod_jk code (jk_ajp13_worker.c) and it seems that it should attempt > reconnecting if it detects a bad socket. Perhaps it ought to also remove > the worker from its pool and fail over to the next available one instead > of spitting out an Internal Server Error. I am not sure because I don't > know how workers announce their presence to mod_jk and have not found > any tech docs for mod_jk besides of install/configuration issues. > Here is a snippet from the log illustrating what happens: > > [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 (606)]: Error sending request body > [jk_ajp13_worker.c (489)]: Into jk_endpoint_t::done > > Can someone confirm that restarting a Tomcat worker is unsupported by > mod_jk and will lead to problems? If so, could someone knowledgeable > in this code advise how to work around this problem or whether it would > be a major effort to implement a transparent failover? It seems silly > to restart Apache every time (one of) Tomcats needs to be reinitialized, > just for mod_jk's sake. > > Thanks in advance for any hints. > > -JPL -- 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
DocumentRoot"/home/httpd/host1/html"
Options FollowSymLinks MultiViews
AllowOverride AuthConfig
Order allow,deny
Allow from all
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
DocumentRoot"/home/httpd/host1/htmls"
Options FollowSymLinks MultiViews
AllowOverride AuthConfig
Order allow,deny
Allow from all
Alias /usage/ "/home/httpd/host1/usage/"
Options Indexes MultiViews
AllowOverride None
Order allow,deny
Allow from all
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
SSLOptions +StdEnvVars
SSLOptions +StdEnvVars
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
.
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: [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: 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: 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.jpg Type: JPEG Image (image/jpeg) >Encoding: base64 -- 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]
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: [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]
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]
[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: Ajpv13 protocol docs
In the TC 3.3 branch (jakarta-tomcat), read src/doc/AJPv13.html ... for a description of the ajp13 protocol. Also, you might check the 3.3 source code for mod_jk: src/native/mod_jk/common/jk_service.h And the java code in 3.3: src/share/org/apache/tomcat/modules/server/Ajp13.java -Dan > Robson Ribas wrote: > > I'm working on a Java application that needs to communicate with Apache. > It reads the request headers and does some processing. It is possible to > use mod_jk and Ajpv13 to do this integration ? Where can I find docs about > Ajpv13 ? -- 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: 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: [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: [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 >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] > <> > > > 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 fa
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). Going ahead, it would be good for folks working at Sun to be careful about passing bug fixes among each other rather than on the list (I realize you say that below, but I do want to emphasize it). Speaking as a volunteer, it's very important that I feel that I am fully involved in the process (i.e. that the volunteers are in no way second-class citizens). I'm sorry if I'm belaboring this -- I don't think this instance is a particularly big deal, but I do think it's an important area to be careful about. -Dan "Craig R. McClanahan" wrote: > > Two specific things she has contributed (via posting to the list) were > porting the Application Developer's Guide from 3.2 to 4.0 (which has been > integrated) and several additions to the "tester" app (which have been > posted on TOMCAT-DEV but not yet committed -- my fault because I was on > the East Coast for the last two weeks. > > She has also reported several bug fixes directly to other committers (not > through the list -- you're right about appropriate guidelines, and they > should have been posted as patches). > > > -Dan > > > > 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: FW: problem w/ ajp13 - if Tomcat is shutdown
k > >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
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: 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: 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: Design Review for ajp13's changes: WAS problem w/ ajp13 - if Tomc at is shutdown
de. > > > So any clue to make these better would be appreciated. > > > > > > Right now, if you use ajp13 and you restart Tomcat, you > > > have to also restart Apache. See details in previous > > > postings. For us, having to restart Apache is not a > > > feasible solution in our customers' environment. > > > > > > After looking at the code, I have two possible solutions: > > > > > > 1. From mod_jk, I can detect that the socket has been > > >closed by Tomcat. This is normally indicated by the > > >recv() returning ECONNRESET. The recv() is called > > >after the request has been sent to the socket. The > > >send() unfortunately, doesn't give you an error. > > > > > >The proposed fixed is to check for errno ECONNRESET, > > >then set the is_recoverable_error flag to TRUE, in > > >the service() function in jk_ajp13_worker.c. I also > > >add a code in mod_jk.c, to check for this flag, and > > >call the service() method again if the flag is set > > >TRUE. The 2nd time the service() method is called, > > >it will reconnect to Tomcat like normal. > > > > > > 2. Another solution would be to put in a select() on the > > >socket prior to send(), looking for the socket being > > >read ready. Under normal condition, this select() > > >should return nothing. But if Tomcat shuts down > > >the socket, this select() should return the socket > > >being read ready. When this happen, I issue a read() > > >of 1 bytes. If the read() comes back with return code > > >0, this should be an indication that the socket was > > >closed on the remote end. Then I will proceed to close > > >the socket. The remaining logic already handles the > > >reconnect, etc. > > > > > > I have both of these solution prototyped and minimally > > > tested. They both Anyone care to comment which solution fits better > > > with the overall code? Anyone voluteer to review the code? > > > > > > thanks, > > > shinta > > > > > > > -Original Message- > > > > From: Shinta Tjio > > > > To: [EMAIL PROTECTED] > > > > Cc: 'Dan Milstein' > > > > Sent: 3/6/01 7:01 PM > > > > Subject: RE: FW: problem w/ ajp13 - if Tomcat is shutdown > > > > > > > > I am using Tomcat 3.2.1, Apache 1.3.14, running on > > > > Solaris 2.8, Sun machines. > > > > > > > > After various attempts of debugging this, I have > > > > more information. > > > > > > > > 1. Even though I'm setting the worker's property > > > > cache_size to default (1), I'm finding there > > > > are up to 6 connections opened from Apache to > > > > Tomcat. I deduce this by looking at the mod_jk.conf > > > > and by doing netstat. > > > > > > > > I finally find out, this is so because my Apache > > > > is set to spawn minimum of 6 children and each > > > > of those children are making separate connections > > > > to Tomcat. > > > > > > > > This is very bad because, I ended up having to > > > > reload 6 times before Tomcat starts serving me > > > > the page again. Each time it uses a different > > > > Apache children that has defunct socket. So the > > > > more Apache children I have, the longer it takes > > > > me to recover from this problem. > > > > > > > > 2. It seems when Tomcat dies & restarts, the send() > > > > called by ajp13's jk_tcp_socket_sendfull() does not > > > > get an error. But the recv() does get an error, with > > > > errno ECONNRESET. After which, the socket is properly > > > > closed. > > > > > > > > 3. When I shutdown Tomcat, those sockets that were > > > > opened between Apache/Tomcat showed up in state > > > > CLOSE_WAIT, and FIN_WAIT2. I think this is normally > > > > solved by calling the shutdown() API after closing > > > > the socket. However, this would have to be done from > > > > the Tomcat side in Ajp13ConnectionHandler.java. > > > > I can't find the corresponding method of Socket > > > > in Java. > > > > > > > > So.. based on all of these, the only fix I can think > > > > of putting is to make mod_jk retry the send()
Some exciting new mod_jk internal documentation
I've finally added a little key documentation to the C code in mod_jk. I wanted to mention it here, because all the key information is, basically, in one file: jk_service.h If anyone is looking into bug fixes on mod_jk, or just wants to understand how it's working, I'd recommend starting with that file. If I continue to be snowed in here in Boston, I can maybe find time to document more of the C code... ;-) Enjoy, -Dan -- 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: 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]
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: 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: 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: 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: [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: > > > normal config for VirtualHost ... > Include /usr/local/jakarta-tomcat/conf/mod_jk.conf-auto > > > 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 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: 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: 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: 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: 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: 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: 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: [VOTE] Tomcat 3.2.2 Release Plan
Jon, No, it's not in the release plan. Henri had proposed it at the end of last week (in an email, not in a plan). We need to discuss it on the list, but, unless someone convinces me otherwise, I don't support it -- there has been work done on the native portions of 3.3 which is not just bug fixes, and that shouldn't go into 3.2.2. I'm not seeing an overriding reason for keeping all the native code sync'd up (it's largely in sync, now, but there are some differences). -Dan Jon Stevens wrote: > > on 2/11/01 7:54 AM, "GOMEZ Henri" <[EMAIL PROTECTED]> wrote: > > > I could help port of latest native mod_jk stuff from TC 3.3, > > if everybody agrees. So we could have both apache 1.3 and 2.0 > > connectors, and be at the same level between TC 3.2.2/3.3 > > Is that in the release plan? > > -jon > > -- > If you come from a Perl or PHP background, JSP is a way to take > your pain to new levels. --Anonymous > <http://jakarta.apache.org/velocity/> && <http://java.apache.org/turbine/> > > --------- > 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]
Tomcat 3 Connector Default Bug Owner
Craig (or anyone who has admin control over Bugzilla), I notice that you're set as the "default owner" for the "connectors" component for bugs within Tomcat 3. I'd like to volunteer to take that role over (for the time being, at least), but I don't know how to reset that. Can someone set this up / explain to me how to do so? -Dan -- Dan Milstein // [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: 3.2.2 Release?
tomcat_32 is the right place -- it is a branch which is up to date for all fixes which have been made against 3.2 (including 3.2.1). The other various 3.2 looking things in cvs (e.g. 321_final) are tags but not branches. I'm working on urlencoding stuff right now, so I await your patch with bated breath ;-). -Dan David Weinrich wrote: > > On a somewhat unrelated note... > I noticed a bugrat report this morning on an urlencoding that I had > submitted a patch for a little while back ( which was flawed/incomplete ). > In the process of redoing the patch and grabbing the source from cvs I came > up against this issue: what the heck tag is appropriate to use to submit > bugfixes against for the 3.2.x version of Tomcat? I am assuming that > tomcat_32 is the appropriate place but... -- 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]
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]
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]
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]
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: 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: [VOTE] CVS Commit: Keith Wannamaker
+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: 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] 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: 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: 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: [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: 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 Thanks for pointing this out -- I had totally forgotten that I had this set this way. 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: 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: 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: [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: [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: 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]
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, 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: 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: Tomcat 4.0 w/Apache question
Matthew, > Couple of simple questions to help us get TC 4.0 going like we had for > Tomcat 3.1 > > 1. Which Apache connectors can we use to talk to TC 4.0? I know of > mod_jserv, mod_jk, and mod_webapp. Which of these work with TC4.0 and which > one is best given our requirements. Currently, the only connector for joining Apache to TC 4.0 is mod_webapp. By my understanding, this connector is *not* ready for production use. I believe it has serious problems with regard to cookies and some other issues. Sadly, this renders the rest of your questions moot ;-). -Dan -- Dan Milstein // [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Problem with apj13/jk_mod and multiple cookies!
Jason,
This has been fixed in the cvs tree for TC 3.2 -- the relevant file is:
src/share/org/apache/tomcat/service/connector/Ajp13ConnectorResponse.java
You can get a patch from that, or just grab that file. Check the jakarta website for
details on getting the file from cvs.
-Dan
Jason Pell wrote:
>
> Hi,
>
> I have been having heaps of problems with multiple cookies not being set
> with tomcat.
>
> I have managed to track the problem down, but do not have enough
> understanding of
> the APJ13/mod_jk C source to fix.
>
> First of all multiple cookies work when I access tomcat directly
> (bypassing apache), but then
> as I have stated previously they all fail to be set, bar the first one.
>
> This fragment of jakarta-tomcat-3.2-src/src/native/jk/jk_apj13.c
>
> } else {
> d->header_names[i] = (char *)jk_b_get_string(msg);
> if(!d->header_names[i]) {
> jk_log(l, JK_LOG_ERROR,
>"Error ajp13_unmarshal_response - Null
> header name\n");
>
> return JK_FALSE;
> }
> }
>
> d->header_values[i] = (char *)jk_b_get_string(msg);
> if(!d->header_values[i]) {
> jk_log(l, JK_LOG_ERROR,
>"Error ajp13_unmarshal_response - Null header
> value\n");
>
> is where the headers are processed, and jk_b_get_string(msg); is
> returning "ERROR" for
> all but my first cookie, as demonstrated by the log I obtained.
> Log fragment from mod_jk.log
>
>
>
> [jk_ajp13.c (576)]: ajp13_unmarshal_response: Header[1] [Set-Cookie] =
> [cookie1=hello;Domain=kuru.its.deakin.edu.au;Path=/connect/se
> rvlet]
> [jk_ajp13.c (576)]: ajp13_unmarshal_response: Header[2] [ERROR] =[ERROR]
>
> [jk_ajp13.c (576)]: ajp13_unmarshal_response: Header[3] [ERROR] =[ERROR]
>
> [jk_ajp13.c (576)]: ajp13_unmarshal_response: Header[4] [ERROR] =[ERROR]
>
> [jk_ajp13.c (576)]: ajp13_unmarshal_response: Header[5] [ERROR] =[ERROR]
>
> [jk_ajp13.c (576)]: ajp13_unmarshal_response: Header[6] [ERROR] =[ERROR]
>
>
>
>
> Please, Please, Please help me I do not know what to do. I am desperate
> now!!!
>
> Thankyou
> Jason Pell
>
> --
> Jason Pell
> Senior Analyst/Programmer - Web Developer
> Callista Software Services Pty Ltd
> 12 Gheringhap St, Geelong Victoria 3220 Australia
> Phone: 03 5227 8858 International: +61 3 5227 8858
> Fax: 03 5227 8907 International: +61 3 5227 8907
> E-mail [EMAIL PROTECTED]
> http://www.dssonline.com.au
> Customer Support Hotline: 1800 620 497
>
> "Callista - the brightest solution in university management"
>
> ---
> Important Notice: The contents of this email transmission,
> including attachments, may be privileged and confidential.
> Any unauthorised use of the contents is expressly prohibited.
> If you have received this transmission in error, please advise
> the sender by return email or telephone immediately and
> destroy all versions.
> ---
>
> -
> 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]
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: BugRat Report #690 has been filed.
There have been some pretty major bugs fixed in the mod_jk / ajp13 world. The broken File Upload problem, which people repost as a bug pretty often, and a load-balancing bug, which also seems to cause a lot of pain. Just to factor that into whatever else has been fixed... -Dan > Glenn (and others), > > Have we accumulated enough bug fixes where it's worth creating a 3.2.2 release, or >are there more issues that should be > dealt with first? -- 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: Any solution for bug#696?
Tomcat 3.2.1 / mod_jk / ajp13 has a bug with File Upload which has been fixed and committed in the most recent 3.2 sources. It *is* more likely to affect binary files, so I'm going to guess that that's what you're seeing (assuming you're using ajp13). You can check out the most recent version of the 3.2 branch from cvs (see the website for details), or you can patch the file: src/share/org/apache/tomcat/service/connector/Ajp13ConnectorRequest.java I *think* patching that file will capture the whole fix -- you may want to get an updated version of the mod_jk files as well. -Dan Jin-Ling Kwang wrote: > > Dear TomCat Bugs Team, > > I also encountered the same problem as described in bug#696. > (Actually it also happened to '.doc' and '.ppt' and '.ps' file types > too.) > > Could you please advise if you have any soluation for that problem > so far? > > Please advise. > > Thanks, > > Best Regards, > Jin-Ling > > - > 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: 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: [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]
3.2 Branch Release Management
Does anyone have any opinions on a process for making commits to the 3.2 branch? Now that I've got my new fancy committer status, I'd like to check in some bug fixes there (to mod_jk / ajp13). However, before I do that, I wanted to check if there is anyone who is functioning as a Release Manager or anything like that. I'm only planning on checking in some tested bug fixes, just to be clear. -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: Tomcat session replicator - more thoughts !!!
Shai, I don't fully understand what you're proposing, and I want to make sure I do. It kind of sounds like you're saying that the web server would be configured to point to a single TC instance, and that that instance would then do load-balancing (and could also have enough information to send that request to the right place after a server failed). Is that right? If so, I don't think I can support that, because we're then making that "master" TC instance a single point of failure. The current load-balancing code in mod_jk will balance among several containers, and, if one of them dies, it will a) stop sending requests to that one and then b) after 60 seconds, will try to reopen a connection. If a servlet container dies while in the middle of handling a request, the web server thread which triggered that request will hang up on the TCP connection until it times out. I think the rest of the web server should go on happily serving requests (assuming that it's got other containers to talk to). Adding packet types to ajp13: Unfortunately, ajp13 currently doesn't handle unknown packet types. So adding new packets would throw off current installations (if they were using an "old" ajp13 web server with a "new" ajp13 container). I think this does merit a new protocol number, since people are, I believe, using ajp13 in production environments. If we do create an ajp14, we should specify a way to handle unknown packet types, so that we can make life easier on ourselves in the future. -Dan p.s. I get a little confused when you refer to things as "server-side" and "client-side" with regards to mod_jk. I've been trying to use "web server" and either "servlet container" or "Tomcat". > THE NEW IDEA is, assuming all of what I have stated above is working. We can > take apache out of the picture. > HOW COME? I can point the load-balancing switch to the tomcat themselves. > Each tomcat will forward requests based on sessionID (we will need to move > mod_jk client side to into tomcat. Dan, would you like to take that?) is the > exist to the right tomcat (if there's no sessionID - will create one > locally). If Tomcat can't connect to master, it will forward the request to > the buddy. > > Basically, I'm working on the replication protocol. I can make it > stand-alone or put it into mod_jk (server side). If someone willing to write > mod_jk client side into http connector, it will allow getting apache out of > the picture. 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]
