Re: [PROPOSAL AJP14] AJP13 Evolution
GOMEZ Henri wrote: 1) How did we share it in forked (apache 1.3) env ? = shared memory = MM or APR APR of course: MM is included in it. But APR is only available in Apache 2.0, what about Apache 1.3, NES and IIS ? And MM is still only for Unix OS APR is only related to Apache 2.0 because Apache 2.0 uses it. Unfornatunatly I am a Unix expert but totaly beginner for other plaforms, but I think that APR needs shared memory for all platforms it supports. 2) Ditto in a threaded architecture (Apache 2.0) at least in MPM mode (a forked child which will in turn thread child), but again how did we info we other forked. Also doubling the socket, will double the descriptors open and will be a problem under heavy load. In an HTTP architecture we need again to mix data (tons of messages) with control (very low traffic). And so we need to read for possible message at some time. 1) FORWARD REQUEST FROM WEB-SERVER TO SERVLET ENGINE 2) WAIT FOR END OF PREVIOUS REPLY AND EVENTUALLY ADMIN MESSAGE 3) GET ADMIN MESSAGE and evnetually RESPONSE 4) GET RESPONSE AND FORWARD TO WEB-SERVER. The admin message could be send() in socket at any time and will be handled when a request will came 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. The admin response could be sent on EACH AJP13 connections, and it will be web-server task to discard allready received admin message... What happends when the configuration is changed more than once and no request happend in the meantime... We could get a wrong configuration... If we have a DOWN event and then a UP event, the servlet engine send a DOWN message and then a UP message. The web-servlet will have to read ALL ADMIN messages and process the whole block...
Re: [PROPOSAL AJP14] AJP13 Evolution
On Sun, 13 May 2001, kevin seguin wrote: in the java side of ajp13, it is pretty much assumed that strings are iso-8859-1 encoded. (i'm not sure how things that deal with MessageBytes that come out of ajp13 deal with encoding...). MessageBytes is supposed to delay the conversion from bytes to strings until an encoding is found ( that can be as late as servlet execution time in servlet2.3 ). The default is 8859-1, as required by the servlet specs ( if no other encoding is specified ). I think the design is right - but there are many details that need to be resolved before this will work as expected. Few modules ( like the mapper ) are forcing a conversion to String for the URI, and very little testing has been done. BTW, there are few major problems I don't know how to resolve, like the (stupid) behavior of MSIE in the case of UTF8 in javascript ( they send % instead of %XX%XX - as EcmaScript requires ). I spent a lot of time reading and thinking about how to resolve the i18n, but it's a nightmare - and I'm not sure I have the energy to do it. is this a potential problem? i realize that for things like standard header names this will generally not be a problem. but would it be worthwhile to send an encoding across from the webserver to the container in ajp14? or, can iso-8859-1 be assumed, and if a content-type header is present and specifies an encoding, it can be pulled out of there? The webserver doesn't know the encoding ( unless it reads the encoding header ), it works with byte[]. It would be great if it can send the encoding in advance ( as parsing Content-Type is very expensive ), but most browsers do not send it... Costin
Re: [PROPOSAL AJP14] AJP13 Evolution
in the java side of ajp13, it is pretty much assumed that strings are iso-8859-1 encoded. (i'm not sure how things that deal with MessageBytes that come out of ajp13 deal with encoding...). is this a potential problem? i realize that for things like standard header names this will generally not be a problem. but would it be worthwhile to send an encoding across from the webserver to the container in ajp14? or, can iso-8859-1 be assumed, and if a content-type header is present and specifies an encoding, it can be pulled out of there? i'm sensitive to these issues now, as i'm currently going through the 'joy' of an i18n/l10n release ;) -kevin. 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
RE: [PROPOSAL AJP14] AJP13 Evolution
The question was the availability on system running NES (Windows/Unixes) and IIS (Windows). I really like APR, but having it at a pre-requisite to mod_jk for AJP14 will raise new questions. How could I build APR usinb Borland C++ 5.5 under Window Millenium ? - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: Jon Stevens [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 09, 2001 3:16 AM To: tomcat-dev Subject: Re: [PROPOSAL AJP14] AJP13 Evolution on 5/8/01 3:00 PM, GOMEZ Henri [EMAIL PROTECTED] wrote: But APR is only available in Apache 2.0, what about Apache 1.3, NES and IIS ? That isn't true. http://Apr.apache.org/ APR is just a library. -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/ymtd/ymtd.html
RE: [PROPOSAL AJP14] AJP13 Evolution
Regarding APR: I do remember the same discussion happened about one year ago, when mod_jk was starting up. And at that time we felt that APR is the best solution for us, for the long term - and the same is probably true today. The common dir in mod_jk was intended as a temporary substitute for APR, until APR is stable and released. The only questions are: When ? Who ? Why ? :-) Right now the common code works reasonably well, and I don't know any reason to _require_ a switch. There are other changes that are far more benefical for mod_jk - so if you have some time it would be better spent improving the configuration, or the performance. If you have a need for APR in mod_jk - I'm all +1. The effort is not in replacing the calls to jk_XXX to apr_XXX, but in testing on IIS, NES, AOLServer, and Apache1.3.9. I don't know any module that is using APR and works on those 3 platforms. I would also wait for the 1.0 release of APR before doing the switch - and maybe do the experiments and tests on other servers first. ( BTW, there is no reason for APR not to work out-of-box, except that someone needs to do the testing on those cases ). A good way to do that would be to use some C magic ( #define :-) to allow use of either common or apr. BTW, I did some homeworks ( one year ago ) and tried APR - I had few small problems, but in the end worked. For example, the version of APR used must match the one in Apache2.0 ( or symbol undefined may happen - and that may become more tricky for Apache2.1 ), there are problem on Apache1.3 ( probably IIS, etc) if more than a module is using APR and certain link options are used ( again, symbol conflits, etc). With a bit of work it can be resolved, but I don't think this is the biggest priority for mod_jk. Costin On Thu, 10 May 2001, GOMEZ Henri wrote: The question was the availability on system running NES (Windows/Unixes) and IIS (Windows). I really like APR, but having it at a pre-requisite to mod_jk for AJP14 will raise new questions. How could I build APR usinb Borland C++ 5.5 under Window Millenium ? - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: Jon Stevens [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 09, 2001 3:16 AM To: tomcat-dev Subject: Re: [PROPOSAL AJP14] AJP13 Evolution on 5/8/01 3:00 PM, GOMEZ Henri [EMAIL PROTECTED] wrote: But APR is only available in Apache 2.0, what about Apache 1.3, NES and IIS ? That isn't true. http://Apr.apache.org/ APR is just a library. -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/ymtd/ymtd.html
Re: [PROPOSAL AJP14] AJP13 Evolution - Second Pass
+1 I'll try to implement the Java side as you go with the C changes, unless someone else volunteers ( jasper is taking more than I expected, and xalan has a release planned in few weeks ). BTW, we'll need to discuss about the Java side - so optimizations on the lower level would work on any container. At minimum we need MessageBytes or equivalent, MimeHeaders or equivalent ( i.e. recyclable, low overhead, etc ), and a simple Request object that can be easily adapted to TC3.3 and TC4.0. This is not the easiest solution - from my point of view the easisest would be to just write the Ajp14Interceptor and use the existing and optimized 3.3 infrastructure. ( and use a reimplementation of the protocol for 4.0 - using their low-level objects ). Costin On Thu, 10 May 2001, GOMEZ Henri wrote: Find attached the modified AJP14 proposal which include the remarks and request from the list. Nota : The launch of Tomcat JVM by the mod_jk/jakarta-connector is not covered since we speak here only about protocol. That feature is something asked by many JServ users and may be added later in the native part, at least in Apache 1.3/2.0 mode. I'm not sure how it can be done when using IIS or NES. The automatic context update was an interesting subject and how we can have these kind of admin informations raised more questions than answers. Opening alternate sockets (control socket) we'll load more the web-server with more opened sockets : on forked environnement (ie Apache 1.3), 2 x forked (1 data + 1 admin) on threaded environnement (ie Apache 2.0), 1 x forked (x threaded data + 1 admin) A solution could be to use the URGENT DATA mode of TCP/IP socket but I'm not sure it's supported now in JDK 1.1/1.2/1.3 Another solution is to delay the automatic update mode. AJP14 have provision on NEGOCIATION phase to disactivate this feature. But we still need to know when a context is DOWN and later UP. * A lazy solution could be to have the servlet engine drop all AJP connections at each update of context (UP/DOWN). The web servlet will have then to re-open the connection and will received the UPDATED context list. * Another solution will be having the servlet engine sending a 'Context XXX Down' reply when the user send a request against a DOWN context. The servlet engine could then route the request to another engine (in LB mode), or to indicate the failure (in simple servlet engine mode). And when a context is marked DOWN, we need to know when it's UP again. Brute mode : the web-server continue to forward the requests to the servlet engine, and if it receive the 'Context XXX Down', it try another route. Clean mode : the web-server send a 'Context XXX Status' request, check if the reply is 'Context XXX Up', and if still down, try another route. This mode could be tuned. ie for a down context, ask for status each 10 or 50 requests. The context UP/DOWN is really a rare case, and we mustn't spend to much time in handling this type of event. The protocol must keep its speed. Another feature I'd like to have in mod_jk/jakarta-connector and present in mod_jserv is the backup mode : - In standard mode, a request is routed to only one servlet-engine (using a know worker). - In load balancing mode, a request is sent to a pool of servlet-engine, using a load factor. - We miss a backup mode, where all requests goes allways to the same servlet engine until the connection is broken (maybe the remote engine is down or network link closed). We define then one (or more) alternate engines to handle requests. In that mode, the web-servlet will try to detect later if the principal servlet engine is up each N requests (or after M seconds...) - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
RE: [PROPOSAL AJP14] AJP13 Evolution - Second Pass
The evolution will goes in jakarta-tomcat-connectors to avoid disturbing mod_jk/ajp13 in the to be released TC 3.3. Of course all bugs fixes from TC 3.3 mod_jk will be back ported to jakarta-tomcat-connectors. The auto-update will not be my premium priority and I think to delay it since it will add too much complexity for a first try. On the native part, I'll need help for autoconf stuff and the JServ like JVM start. Jon could you help us here since you were on it on JServ ? I'd like to see someone take a look at APR, and how we could use it. May be by adding some wrapper code to avoid having #ifde USE_APR sprayed in all mod_jk. Volunteers ? On the C side code, all help will be welcome. I'm confident with the code but all help is also welcome (toc toc toc Dan). May be via review of the regular code commit. I'm pleased to see the proposal was actively discussed and since many users ask about integration of mod_jk and mod_webapp, I reiterate here my invitation to Pier. I'll try to implement the Java side as you go with the C changes, unless someone else volunteers ( jasper is taking more than I expected, and xalan has a release planned in few weeks ). May be Kevin could help also and could commit it's AJP13 in jakarta-tomcat-connector. BTW, we'll need to discuss about the Java side - so optimizations on the lower level would work on any container. At minimum we need MessageBytes or equivalent, MimeHeaders or equivalent ( i.e. recyclable, low overhead, etc ), and a simple Request object that can be easily adapted to TC3.3 and TC4.0. AJP14 will be only available to TC 3.3/4.0 since the 3.2 is closed to new features. But did the AJP12/AJP13 in jakarta-tomcat-connectors will contains code for tomcat 3.2 tree also ? This is not the easiest solution - from my point of view the easisest would be to just write the Ajp14Interceptor and use the existing and optimized 3.3 infrastructure. ( and use a reimplementation of the protocol for 4.0 - using their low-level objects ).
RE: [PROPOSAL AJP14] AJP13 Evolution - Second Pass
On Thu, 10 May 2001, GOMEZ Henri wrote: AJP14 will be only available to TC 3.3/4.0 since the 3.2 is closed to new features. But did the AJP12/AJP13 in jakarta-tomcat-connectors will contains code for tomcat 3.2 tree also ? If anyone writes it - yes. Most tomcat users are using tocmat3.2, either in production or embeded in products, and the new connector will be a module that may be good for them. I wouldn't mind seeing the connector used for Jetty or other servlet containers ( the same as many containers are using jasper ) - code sharing is allways good. Costin
Re: [PROPOSAL AJP14] AJP13 Evolution - Second Pass
I wouldn't mind seeing the connector used for Jetty or other servlet containers ( the same as many containers are using jasper ) - code sharing is allways good. +100 :)
Re: [PROPOSAL AJP14] AJP13 Evolution - Second Pass
BTW, we'll need to discuss about the Java side - so optimizations on the lower level would work on any container. At minimum we need MessageBytes or equivalent, MimeHeaders or equivalent ( i.e. recyclable, low overhead, etc ), and a simple Request object that can be easily adapted to TC3.3 and TC4.0. This is not the easiest solution - from my point of view the easisest would be to just write the Ajp14Interceptor and use the existing and optimized 3.3 infrastructure. ( and use a reimplementation of the protocol for 4.0 - using their low-level objects ). i'm not 100% sure i understand what you're saying, but i'm pretty sure you're talking about something i've been thinking about :) in tc 3.x, the ajp stuff uses core tomcat classes like MessageBytes, OutputBuffer, Request, etc.. for my ajp13 implementation for tc 4, i removed refs to tc 3 classes, and used tc 4 classes where i could (i.e. HttpRequestBase). i was thinking that versions of MessageBytes, OutputBuffer, Request (and Response??), and other classes might find their way into jakarta-tomcat-connector, so they could be used with ajp code across different versions of different servlet containers. are you thinking this would be the right thing to do? seems like you might be suggesting multiple ajp13 implementations for multiple servlet containers. i think it would be better to have the core ajp13 code separate from servlet connector/adapter code. that way, hopefully, you could use the same ajp13 core with connectors for tc 3, tc 4, jetty, and so on. thoughts?
Re: [PROPOSAL AJP14] AJP13 Evolution - Second Pass
On Thu, 10 May 2001, kevin seguin wrote: This is not the easiest solution - from my point of view the easisest would be to just write the Ajp14Interceptor and use the existing and optimized 3.3 infrastructure. ( and use a reimplementation of the protocol for 4.0 - using their low-level objects ). i'm not 100% sure i understand what you're saying, but i'm pretty sure you're talking about something i've been thinking about :) I hope I'm talking about what I'm thinking, and the reverse :-) in tc 3.x, the ajp stuff uses core tomcat classes like MessageBytes, OutputBuffer, Request, etc.. for my ajp13 implementation for tc 4, i removed refs to tc 3 classes, and used tc 4 classes where i could (i.e. HttpRequestBase). i was thinking that versions of MessageBytes, OutputBuffer, Request (and Response??), and other classes might find their way into jakarta-tomcat-connector, so they could be used with ajp code across different versions of different servlet containers. Yes, that would be probably the best - as all those classes are quite well tuned. Most of tomcat3.3 performance comes from those 5-6 classes - and the fact that we use lazy evaluation in many cases. ( there are few other tricks in some modules, but most of the modules and the servlet 22 facade are mostly the same as in tomct3.1 - i.e. not tuned yet ). But we know some people have problems with tomcat3.3. are you thinking this would be the right thing to do? seems like you might be suggesting multiple ajp13 implementations for multiple servlet containers. It would be the right thing to do from a technical point of view. Politically - I don't know, I don't want to go into another war or argue about the benefits ( you can read the archives for that :-) i think it would be better to have the core ajp13 code separate from servlet connector/adapter code. that way, hopefully, you could use the same ajp13 core with connectors for tc 3, tc 4, jetty, and so on. thoughts? Again - that would be the right way to go. In most cases ( even for jetty - I took a quick look at their code ) using an optimized low-level representation for data will be good for performance. The whole idea is to avoid expensive operations until they are actually needed - most servlets don't read all the headers, so there's no need to create the strings and hash them. ( it's not even needed to convert from bytes to chars - another expensive operation ). But having separate adapters for each container is also a valid option. Costin
Re: [PROPOSAL AJP14] AJP13 Evolution - Second Pass
The whole idea is to avoid expensive operations until they are actually needed - most servlets don't read all the headers, so there's no need to create the strings and hash them. ( it's not even needed to convert from bytes to chars - another expensive operation ). i'm going to go with the get it to work first, optimize it later approach :)
Re: [PROPOSAL AJP14] AJP13 Evolution - Second Pass
On Thu, 10 May 2001, kevin seguin wrote: The whole idea is to avoid expensive operations until they are actually needed - most servlets don't read all the headers, so there's no need to create the strings and hash them. ( it's not even needed to convert from bytes to chars - another expensive operation ). i'm going to go with the get it to work first, optimize it later approach :) Good, as long as you remember you're going to do the later part :-) This is one of the critical pieces in the container performance. Costin
Re: [PROPOSAL AJP14] AJP13 Evolution
GOMEZ Henri wrote: 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. +1 In other words - both ends should deal with unknown packets - maybe by sending back an UNIMPLEMENTED message. Since AJP indicate size we could deal with unknow packets. But if we negociate at startup the common protocol level, we must avoid that situation. I like the idea of reject cmd, +1 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. I'm not sure - but I can see some benefits. Right now we have (almost) bidirectional communication - the protocol is based on message passing, and sort of token-based: each side sends a message, then waits for a message. The main reason for that is the single-threaded web server. ( Apache1.3, maybe other servers ). It is a bit difficult to deal with 2 connections in a single threaded env ( while keeping the code as simple as possible ). My feeling is that for most needs of a servlet container we can deal with the single socket protocol. I don't know any (major) use case or feature of tomcat that would require the second socket. Argh, all the subtility is here. Basically even if ajp13 is a bidirectional protocol, it's a request/reply protocol since it's how a web server function : 1) FORWARD REQUEST FROM WEB-SERVER TO SERVLET ENGINE 2) WAIT FOR RESPONSE 3) GET RESPONSE AND FORWARD TO WEB-SERVER. We could have a second socket for control but : 1) How did we share it in forked (apache 1.3) env ? = shared memory = MM or APR APR of course: MM is included in it. 2) Ditto in a threaded architecture (Apache 2.0) at least in MPM mode (a forked child which will in turn thread child), but again how did we info we other forked. Also doubling the socket, will double the descriptors open and will be a problem under heavy load. In an HTTP architecture we need again to mix data (tons of messages) with control (very low traffic). And so we need to read for possible message at some time. 1) FORWARD REQUEST FROM WEB-SERVER TO SERVLET ENGINE 2) WAIT FOR END OF PREVIOUS REPLY AND EVENTUALLY ADMIN MESSAGE 3) GET ADMIN MESSAGE and evnetually RESPONSE 4) GET RESPONSE AND FORWARD TO WEB-SERVER. The admin message could be send() in socket at any time and will be handled when a request will came 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. What happends when the configuration is changed more than once and no request happend in the meantime... We could get a wrong configuration...
RE: [PROPOSAL AJP14] AJP13 Evolution
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.
Re: [PROPOSAL AJP14] AJP13 Evolution
I think Costin has summed up the situation very well, in terms of the control/data issue. As the person who originally suggested thinking about a separate data channel, I am now strongly leaning away from that. The various complicated threading/process issues are not worth the grief. The only thing we really lose is the ability for the servlet engine to send a message to TC in between requests. And the main messages, as I see it, are: a) the entire engine is shutting down b) certain contexts are shutting down c) certain contexts are now live Henri, you're trying to cover that via the AJP_STATUS cmd, which the engine writes to the socket at the end of a request-handling cycle but which the web server only reads when it next goes to send a request over. Unless I misunderstand, the main reason for that delay is so that if the engine shuts down, and the socket dies, the web server will find out immediately (rather than sending across a request and only finding out on the subsequent read). [Socket trivia -- will this written-but-unread data cause any trouble during the TC shutdown process?] That part makes sense. However, you're also suggesting using that status command to send over config information via AJP_CONTEXT_(DOWN|UP|OK). I *do* like the idea of the engine sending over some control information at the end of every request-handling cycle, but I have two suggestions: 1) Don't use APR or OS-specific functions to see if there is more data. Instead, make a normal ajp13-style packet with a type of ajp_status_cmd, a length and a payload. That way you can fit arbitrarily large data (large numbers of changed contexts or config information, for example), and take advantage of the current ajp13 packet-handling functions. Conceivably, you could even set it up so that mod_jk could accept those packets *during* request handling, as well as at the end. BTW, currently, ajp13 sends over a single byte of status, which determines whether or not the connection should be reused. We'd basically just be expanding that. I like that idea a lot. 2) Have the web server read that config data immediately, but always have an extra dummy byte (or whatever) of padding at the end which the server can hold off on reading until the next request. That way, config information will flow up into the web server as soon as possible, and the logic will be much simpler (e.g. you won't get a situation where the server is about to forward a request and only then reads the config info which tells it that it can't forward that request). Then we just have to set up the Java code so that the context change information can get passed into an ajp13 thread which is servicing requests (so that it can tack it onto the end of the request cycle). Questions: what if multiple instances of Apache are forwarding requests to a single TC instance? How can TC know that? It has a single master socket, and then it hands off live sockets to individual threads, which hang onto them over many requests. If some of those threads are serving Apache 1, and some are serving Apache 2, then we have to make sure that the context change info goes into one thread from each group. And then on the Apache side, we have to bubble that config information up so that all the separate child processes change their config setup. (Is this true? Does Apache work differently than this somehow?) That sounds complicated. How is this handled in mod_webapp? Anyone? -Dan [EMAIL PROTECTED] wrote: Argh, all the subtility is here. Basically even if ajp13 is a bidirectional protocol, it's a request/reply protocol since it's how a web server function : 1) FORWARD REQUEST FROM WEB-SERVER TO SERVLET ENGINE 2) WAIT FOR RESPONSE 3) GET RESPONSE AND FORWARD TO WEB-SERVER. Well, I see it a bit different :-) 1. Apache sends a message to tomcat with the original request ( or part of it ! - for example it can send only some headers that are commonly used ), then start waiting. 2. Tomcat receives the message, start processing. When he needs something from apache ( like sendHead or get info or auth or admin commands ) it sends a message, then start waiting. 3. That goes on, with a message acting as a token. At any time one side is listening, and the other ( who reveived the last message ) has the control. In a way it's like a single virtual thread of execution, with the apache thread and tomcat thread passing control via messages. Now, I know this sounds complicated - but it's a good solution with very little overhead. This is not a general RPC protocol, but something specialized for tomcat, and it works very well with single-threaded processes. Even in Apache2.0 - creating threads 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 (
Re: [PROPOSAL AJP14] AJP13 Evolution
On Tue, 8 May 2001, Dan Milstein wrote: The only thing we really lose is the ability for the servlet engine to send a message to TC in between requests. And the main messages, as I see it, are: a) the entire engine is shutting down b) certain contexts are shutting down c) certain contexts are now live All of those are low-frequency events, equivalent with a configuration change in the web server ( like you edit the apache.conf and add a new virtual host, same thing for NES or IIS ). All servers have mechanisms to deal with such things - like a signal or some other thing, and that can be abstracted. ( in fact, this shouldn't even be part of mod_jk - but a different component ) For multithreaded servers ( or multi-process servers that maintain a communication chain between servers - like the scoreboard ) this can also be implemented as a normal server module, that would handle a special request, and tomcat can do a simple reconfigure request using HTTP. Yet another solution: mod_jk can send a ping ( let's say after every 100 requests - or before the first request if a certain timeout ). There are many solutions for this - without adding complexity to the common case. [Socket trivia -- will this written-but-unread data cause any trouble during the TC shutdown process?] Just an exception ( unless you read before closing the socket ), and of course only on some platforms ( that implement corectly the TCP spec ). That part makes sense. However, you're also suggesting using that status command to send over config information via AJP_CONTEXT_(DOWN|UP|OK). I *do* like the idea of the engine sending over some control information at the end of every request-handling cycle, but I have two suggestions: Let's first solve the first 90% of the problem: tomcat sending config at the beginning. That resolves most of the configuration problems ( most users will not have to touch any server config files ). The other 10% ( contexts added/removed/changed at runtime ) is identical with the problem of web server config changed - we shouldn't try to be smarter than the server ( for now ). Just using the normal server restart should be enough and clean. With Apache2.0 and most multithreaded servers we can do a normal HTTP request from tomcat to apache and make a config change ( the config can be changed at runtime ), with apache1.3 there is no better solution than a restart ( if we want to let apache do the mappings - the mapping tree is created at startup time AFAIK ). BTW, currently, ajp13 sends over a single byte of status, which determines whether or not the connection should be reused. We'd basically just be expanding that. I like that idea a lot. +1 (so that it can tack it onto the end of the request cycle). Questions: what if multiple instances of Apache are forwarding requests to a single TC instance? How can TC know that? It has a single master socket, and then it hands off live sockets to individual threads, which hang onto them over many requests. If some of those threads are serving Apache 1, and some are serving Apache 2, then we have to make sure that the context change info goes into one thread from each group. And then on the Apache side, we have to bubble that config information up so that all the separate child processes change their config setup. (Is this true? Does Apache work differently than this somehow?) On connection open we need to pass some more info, and we'll have to save and organize this information. But I think this is orthogonal on the communication problem. For Apache1.3 we could use a signal or the scoreboard to signal to all processes. Costin
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
1) How did we share it in forked (apache 1.3) env ? = shared memory = MM or APR APR of course: MM is included in it. But APR is only available in Apache 2.0, what about Apache 1.3, NES and IIS ? And MM is still only for Unix OS 2) Ditto in a threaded architecture (Apache 2.0) at least in MPM mode (a forked child which will in turn thread child), but again how did we info we other forked. Also doubling the socket, will double the descriptors open and will be a problem under heavy load. In an HTTP architecture we need again to mix data (tons of messages) with control (very low traffic). And so we need to read for possible message at some time. 1) FORWARD REQUEST FROM WEB-SERVER TO SERVLET ENGINE 2) WAIT FOR END OF PREVIOUS REPLY AND EVENTUALLY ADMIN MESSAGE 3) GET ADMIN MESSAGE and evnetually RESPONSE 4) GET RESPONSE AND FORWARD TO WEB-SERVER. The admin message could be send() in socket at any time and will be handled when a request will came 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. The admin response could be sent on EACH AJP13 connections, and it will be web-server task to discard allready received admin message... What happends when the configuration is changed more than once and no request happend in the meantime... We could get a wrong configuration... If we have a DOWN event and then a UP event, the servlet engine send a DOWN message and then a UP message. The web-servlet will have to read ALL ADMIN messages and process the whole block...
RE: [PROPOSAL AJP14] AJP13 Evolution
1) FORWARD REQUEST FROM WEB-SERVER TO SERVLET ENGINE 2) WAIT FOR RESPONSE 3) GET RESPONSE AND FORWARD TO WEB-SERVER. Well, I see it a bit different :-) 1. Apache sends a message to tomcat with the original request ( or part of it ! - for example it can send only some headers that are commonly used ), then start waiting. 2. Tomcat receives the message, start processing. When he needs something from apache ( like sendHead or get info or auth or admin commands ) it sends a message, then start waiting. 3. That goes on, with a message acting as a token. At any time one side is listening, and the other ( who reveived the last message ) has the control. In a way it's like a single virtual thread of execution, with the apache thread and tomcat thread passing control via messages. Now, I know this sounds complicated - but it's a good solution with very little overhead. This is not a general RPC protocol, but something specialized for tomcat, and it works very well with single-threaded processes. The only reserve will be about speed. Won't these write() and read() make web-server too slow. But that's interesting and will need testing in real condition. AJP14 could test these experimental schemas. Even in Apache2.0 - creating threads 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 ) More overhead will make ajp14 slower than ajp13, or even ajp12 and that's not the goal since admin message are only 1% of the real traffic
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). Each AJP14 thread in Tomcat must send admin messages. It will be the task of web-server to remove duplicate messages. 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. +1 for the ID of admin messages, which make the removing easier. shared memory will make mod_jk port on differents web-server/OS more harder, and we might introduce here the use of APR. But there is APR specialists around !=) -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
Many users have asked for more web-server env vars they like to use also in Tomcat. May be something to add to AJP14 will be the ability to define a list of env vars to be forwarded to Tomcat, the same way the SSL web-server vars are defined : # What is the indicator for SSL session (default is SSL_SESSION_ID) JkSESSIONIndicator SSL_SESSION_ID # What is the indicator for client SSL cipher suit (default is SSL_CIPHER) JkCIPHERIndicator SSL_CIPHER # What is the indicator for the client SSL certificated (default is SSL_CLIENT_CERT) JkCERTSIndicator SSL_CLIENT_CERT May be with the directive JkEnvVars MYVAR1 MYVAR2 MYVAR3 MYVAR4... The traffic will be more important but these informations will be usefull for some... What about that ? - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
RE: [PROPOSAL AJP14] AJP13 Evolution
On Wed, 9 May 2001, GOMEZ Henri wrote: May be with the directive JkEnvVars MYVAR1 MYVAR2 MYVAR3 MYVAR4... The traffic will be more important but these informations will be usefull for some... What about that ? +1 to add this to a TODO list, but low priority :-) Let's first get the auto configuration to work, as this seem the most requested feature, then we can add other callbacks and features. ( I do have few features I will need for some extra optimizations on tomcat, but again - it's low priority compared with getting things rolling and improving the config ). Costin
RE: [PROPOSAL AJP14] AJP13 Evolution
Just as a note, if you want AJP14 to be usable in a Servlet 2.3 environment, you *must* expose the cipher suite and key size (which might be implied from the cipher suite name) to Tomcat, because Tomcat must in turn expose them as request attributes to servlets processing SSL requests. In addition, if there is a client certificate included with the request, it also needs to be exposed, but I believe that is already being done, isn't it? Craig On Wed, 9 May 2001, GOMEZ Henri wrote: Many users have asked for more web-server env vars they like to use also in Tomcat. May be something to add to AJP14 will be the ability to define a list of env vars to be forwarded to Tomcat, the same way the SSL web-server vars are defined : # What is the indicator for SSL session (default is SSL_SESSION_ID) JkSESSIONIndicator SSL_SESSION_ID # What is the indicator for client SSL cipher suit (default is SSL_CIPHER) JkCIPHERIndicator SSL_CIPHER # What is the indicator for the client SSL certificated (default is SSL_CLIENT_CERT) JkCERTSIndicator SSL_CLIENT_CERT May be with the directive JkEnvVars MYVAR1 MYVAR2 MYVAR3 MYVAR4... The traffic will be more important but these informations will be usefull for some... What about that ? - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
Re: [PROPOSAL AJP14] AJP13 Evolution
on 5/8/01 3:00 PM, GOMEZ Henri [EMAIL PROTECTED] wrote: But APR is only available in Apache 2.0, what about Apache 1.3, NES and IIS ? That isn't true. http://Apr.apache.org/ APR is just a library. -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/ymtd/ymtd.html
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: [PROPOSAL AJP14] AJP13 Evolution
Lots of good stuff. A few ideas/possibilities: Happy to see you allready read it Dan :) 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. Could you develop ? 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. Good idea, but how could we be sure that we'll have only one control channel to a given servlet engine ? In multi-threaded environnement like Apache 2.0, it's easy to launch a thread to handle that, but in Apache 1.3 will have no others choice than having each child (forked) opening it's own control connection since each child is forked and so have it's own copy of 'servlet-engine infos But I like this approach of splitting data and control. -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: [PROPOSAL AJP14] AJP13 Evolution
GOMEZ Henri wrote: Lots of good stuff. A few ideas/possibilities: Happy to see you allready read it Dan :) 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. Could you develop ? I have an idea: To the LOGON COMP CMD from the WEB-SERVER (second message), Add a CString: WEB-SERVER INFO The string could be something like: Apache mod_jk AJP13 AJP14 AJP15 Tomcat would answer Tomcat AJP14 to tell that it supports protocol AJP14. 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. Good idea, but how could we be sure that we'll have only one control channel to a given servlet engine ? If we allow shutdown it could end confusing the user (which Apache has shutdown Tomcat?). So it could be good to have only one control channel. But what to do if more than one WebServer connect to Tomcat? In multi-threaded environnement like Apache 2.0, it's easy to launch a thread to handle that, but in Apache 1.3 will have no others choice than having each child (forked) opening it's own control connection since each child is forked and so have it's own copy of 'servlet-engine infos Probably we need shared memory... But I like this approach of splitting data and control. -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: [PROPOSAL AJP14] AJP13 Evolution
On Mon, 7 May 2001, Dan Milstein wrote: 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. +1 In other words - both ends should deal with unknown packets - maybe by sending back an UNIMPLEMENTED message. 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. I'm not sure - but I can see some benefits. Right now we have (almost) bidirectional communication - the protocol is based on message passing, and sort of token-based: each side sends a message, then waits for a message. The main reason for that is the single-threaded web server. ( Apache1.3, maybe other servers ). It is a bit difficult to deal with 2 connections in a single threaded env ( while keeping the code as simple as possible ). My feeling is that for most needs of a servlet container we can deal with the single socket protocol. I don't know any (major) use case or feature of tomcat that would require the second socket. ( that doesn't mean I'm -1 on such thing ) Costin
RE: [PROPOSAL AJP14] AJP13 Evolution
On Mon, 7 May 2001, Mike Braden wrote: +1 As for the security key, would it be possible to generate a unique key when mod_jk is first installed? Maybe we could create some basic mechanism, similar to the way ssh generates That's what tomcat3.3 does for ajp12 shutdown messages: at startup it generates a random password ( if none was explicitely set ). The code is quite simple to add for ajp14 too. Costin
RE: [PROPOSAL AJP14] AJP13 Evolution
In the doc, the secret key is a string present in web-server and servlet engine : must be defined for each workers: worker.myworker.port=8010 worker.myworker.type=ajp14 worker.myworker.host=myremotesystem worker.myworker.secretkey=myverysecretkey = in TC 3.2.x = Connector className=org.apache.tomcat.service.PoolTcpConnector Parameter name=handler value=org.apache.tomcat.service.connector.Ajp13ConnectionHandler/ Parameter name=port value=8009/ Parameter name=secretkey value=myverysecretkey/ /Connector = in TC 3.3 = RequestInterceptor className=org.apache.tomcat.modules.server.Ajp13Interceptor port=8009 secretkey=myverysecretkey / = in TC 4.0 = Connector className=org.apache.catalina.connector.ajp.Ajp13Connector port=8009 secretkey=myverysecretkey / AJP12/MOD_JSERV used the same system of allready know common key. The key is passed in md5 to get the 32 chars data - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
RE: [PROPOSAL AJP14] AJP13 Evolution
Will this be the next step to combining mod_webapp with mod_jk? Discussion is open and Pier is my guess, even if he loose an occasion to eat splendid 'pasta fresca'. Maybe this could be the first step to merging the two. ajp14 could offer some automatic configuration similar to mod_webapp, as you suggested in the proposal. I also think that a security mechanism is important. There should be some form of login for the connector to make sure that communication with the server is allowed. I think we should be careful with the security side, however. This could lead into a complex discussion over what is appropriate. My suggestion would be to go with something simple, as suggested in the proposal. The system is aimed to be simple, we don't want SSH/SSL here but just a basic 'protected' login. This level of security would cover most of the installations and when someone requires an additional level of security or interface to other security mechanisms, that could be added later. We can add native SSH tunneling for example using openssh. This proposal hits on the most important issues with mod_jk at this point. +1 As for the security key, would it be possible to generate a unique key when mod_jk is first installed? Maybe we could create some basic mechanism, similar to the way ssh generates a key when it is installed. This would avoid the possibility of having many TC servers out there that can be logged into with the default key or no key. It could avoid the problem that the admin webapp has with the password needing to be changed and trust being turned on. mod_jk could serve many tomcats on different systems. Each Tomcat could need a different secret key, but worker concept help here. Cf my previous mail about it Just a thought. Mike. -- Mike Braden [EMAIL PROTECTED] [EMAIL PROTECTED] -Original Message- From: GOMEZ Henri [mailto:[EMAIL PROTECTED]] Sent: Monday, May 07, 2001 8:40 AM To: [EMAIL PROTECTED] Subject: [PROPOSAL AJP14] AJP13 Evolution 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
RE: [PROPOSAL AJP14] AJP13 Evolution
2 things: The system is aimed to be simple, we don't want SSH/SSL here but just a basic 'protected' login. and that you can bind the socket to 127.0.0.1:PORT instead of *:PORT through a config change. This level of security would cover most of the installations and when someone requires an additional level of security or interface to other security mechanisms, that could be added later. We can add native SSH tunneling for example using openssh. You could do that already with no modifications to the ajp by using port forwarded SSH tunneling. Heck, you could do it with STunnel if you want to use RSA/SSL instead of SSH also without modifications to ajp. -- Nick Bauman Software Developer 3023 Lynn #22 Minneapolis, MN 55416 Mobile Phone: (612) 810-7406
RE: [PROPOSAL AJP14] AJP13 Evolution
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. +1 In other words - both ends should deal with unknown packets - maybe by sending back an UNIMPLEMENTED message. Since AJP indicate size we could deal with unknow packets. But if we negociate at startup the common protocol level, we must avoid that situation. I like the idea of reject cmd, +1 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. I'm not sure - but I can see some benefits. Right now we have (almost) bidirectional communication - the protocol is based on message passing, and sort of token-based: each side sends a message, then waits for a message. The main reason for that is the single-threaded web server. ( Apache1.3, maybe other servers ). It is a bit difficult to deal with 2 connections in a single threaded env ( while keeping the code as simple as possible ). My feeling is that for most needs of a servlet container we can deal with the single socket protocol. I don't know any (major) use case or feature of tomcat that would require the second socket. Argh, all the subtility is here. Basically even if ajp13 is a bidirectional protocol, it's a request/reply protocol since it's how a web server function : 1) FORWARD REQUEST FROM WEB-SERVER TO SERVLET ENGINE 2) WAIT FOR RESPONSE 3) GET RESPONSE AND FORWARD TO WEB-SERVER. We could have a second socket for control but : 1) How did we share it in forked (apache 1.3) env ? = shared memory = MM or APR 2) Ditto in a threaded architecture (Apache 2.0) at least in MPM mode (a forked child which will in turn thread child), but again how did we info we other forked. Also doubling the socket, will double the descriptors open and will be a problem under heavy load. In an HTTP architecture we need again to mix data (tons of messages) with control (very low traffic). And so we need to read for possible message at some time. 1) FORWARD REQUEST FROM WEB-SERVER TO SERVLET ENGINE 2) WAIT FOR END OF PREVIOUS REPLY AND EVENTUALLY ADMIN MESSAGE 3) GET ADMIN MESSAGE and evnetually RESPONSE 4) GET RESPONSE AND FORWARD TO WEB-SERVER. The admin message could be send() in socket at any time and will be handled when a request will came
RE: [PROPOSAL AJP14] AJP13 Evolution
2 things: The system is aimed to be simple, we don't want SSH/SSL here but just a basic 'protected' login. and that you can bind the socket to 127.0.0.1:PORT instead of *:PORT through a config change. In that case, you restrict to a web-sevlet/tomcat on the same machine, but yes we could do that (allready possible on TC 3.2/3.3) This level of security would cover most of the installations and when someone requires an additional level of security or interface to other security mechanisms, that could be added later. We can add native SSH tunneling for example using openssh. You could do that already with no modifications to the ajp by using port forwarded SSH tunneling. Heck, you could do it with STunnel if you want to use RSA/SSL instead of SSH also without modifications to ajp. I better use jonama (http://www.multimania.com/jonama/) to do SSL tunneling since I wrote this one ;)
