Rather than look at different architectures for implementing a web server connector to Tomcat I would rather focus on improving the connector.
Digging into jk2 has been on my list of things to do but I haven't had time yet. mod_jk 1.2 with Apache 2 is working well enough for me. I like the concept of JMX in JK2 for the purpose of application monitoring. Some things that could be improved whether in jk or jk2 are: Switching jk to use APR everywhere possible to make portability easier between operating systems. Develop a way to use a global connection pool to Tomcat. The current way connectors are allocated where they are tied to the httpd process use up too many resources with idle connections. One idea I had was to follow the model used by Apache 2 for mod_cgid when using the worker MPM. mod_cgid runs as a separate process which the httpd process communicates with to execute CGI's. We could use the same model but have the process spawn threads for handling requests being forwarded to Tomcat. This would make the most efficient use of the connectors to Tomcat and allow us to do more sophisticated load balancing by tracking information in this process for each worker's performance. Regards, Glenn On Wed, Jan 07, 2004 at 09:52:06AM +0100, Mladen Turk wrote: > > > > -----Original Message----- > > From: Bill Barker > > Sent: 7. sije?anj 2004 9:22 > > To: Tomcat Developers List > > Subject: Re: Jk2 object model > > > > > > > > > > I'm interested if jk2 could "plug" into more applications - > > there aren't > > > that many generic "connectors". KDE has one specialized for > > konqueror, > > > and mozilla has one - both are mostly for applet support, > > with xconnect > > > hardly used ( and I heard pretty slow ). If jk2 would > > support (XP)COM or > > > gtk object model - it may be possible to access and control various > > > desktop application with some simple web-like requests. > > > > > > > The big problem that I see is that currently jk2 uses > > 'abstract classes' to > > enable it to handle the fact that that the 'implementing > > class' needs to > > control I/O (reading the Request, writing the Response). > > This doesn't fit > > well with other frameworks. IMHO, this part would need to be > > re-writen to > > work on something more like a Listener model (certainly > > required for a COM > > implementation :). However, this may mean a performance hit > > when using the > > standard Apache/IIS/SunOne modules. > > > > I was allways looking at a JK2 from that perspective, meaning, enabling it > to embed the TC inside web server (acting like a COM proxy). > > What I was thinking is to pull all the AJP logic and configuration from C to > Java, leaving only JNI to comunicate with that new proxy. > The client Java part would be able in that case to constuct the AJP messages > in case of out-of the process server, or what ever comunication channel. > > Since this changes the things conceptualy, I see this as a new product > living together with JK. > > > MT. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] ---------------------------------------------------------------------- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder | MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | ---------------------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
