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 byte
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 r
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
> > 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.
>
in looking at MessageBytes and the rest of the
org.apache.tomc
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 - an
> 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 wit
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 lo
> 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 t
> 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
> 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 :)
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 tocma
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
+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
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 t
0E6
>
>
>
> >-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 Hen
.oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
>-Original Message-
>From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
>Sent: Wednesday, May 09, 2001 1:59 AM
>To: [EMAIL PROTECTED]
>Subject: RE: [PROPOSAL AJP14] AJP13 Evolution
>
>
>Just as a
t;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
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 ne
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 additio
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 firs
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
g 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: Tu
>> 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
>I have the following idea:
>
>JServ has a nice feature "ApJServManual off", the mod_jserv
>starts the JVM and
>check via pings messages that is goes on running. It would be
>nice to put the
>feature in AJP14.
>JkStartTomcat path_name server_conf_name time_out
A feature asked by many JServ user
>> 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 (Apach
[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
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
>
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
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
Hi all,
I have the following idea:
JServ has a nice feature "ApJServManual off", the mod_jserv starts the JVM and
check via pings messages that is goes on running. It would be nice to put the
feature in AJP14.
JkStartTomcat path_name server_conf_name time_out
Where
path_name is a path to a C wr
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,
> 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 se
>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: instead
>of *:
>through a config change.
In that case, you restrict to a web-sevlet/tomcat on the same
machine, but yes we could
>> 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 -
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: instead of *:
through a config change.
>>This level of security would cover most of the installations
>>and when someone requires an ad
mcat
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]]
>
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 =>
<= in TC 3.3 =
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 st
, 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
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
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 mu
>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
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,
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
44 matches
Mail list logo
