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.
I'm pretty busy these days so I can't works on JK2 as I want to.
Some ideas/reflexions.
JK2 is very similar to JK, from the tomcat point of vue, since the same ajp13 protocol is used, and may be in such case we could see JK2 too similar to JK to see users switch to JK2 (for instance we're still using JK in-house).
In thread I read some says that JK2 is allready dead, and in such case, using JK2 to make what JK does, it may be true.
I'm working on an in-house project were I'm using jchannels to make some applications works with cluster of service servers and that's an idea which could be fine for JK2, or JK2++ or JK3.
Using this kind of high-level communication channels help make
automatic clusters, without the need on the client (on our case Apache/IIS) to know the topology.
I didn't know if a native (C/C++) jchannel implementation exist but if we could find one, I think we should think to use it to make JK2 more that just JK++.
The benefits are enormous, automatic detection of tomcats when added or removed from the group, determination of webapp/url which could be handled....
What about ?
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
