Costin Manolache wrote:
Sven Köhler wrote:
3. On top of regular request/response. Almost everything related with
auth, pings, discovery, reconfiguration can be implemented by just using
regular Ajp13 requests - with a special URL. That is by far my favorite
mechanism. It also has the advantage th
Costin Manolache wrote:
Henri Gomez wrote:
Another point is that adding new message to protocol make
it incompatible with olders java implementations or with alternate
This is not entirely true.
It is quite easy to configure what messages get sent by mod_jk - the
admin is supposed to know wha
Sven Köhler wrote:
...
> special URLs are by far the best mechanism?
> the next simpson-episode should start with bart writing "special urls
> are by far the worst mechanism ever" to the board.
>
> it's working around a missing feature - nothing more, nothing less.
> it's the worse method i could
Sven Köhler wrote:
>> 3. On top of regular request/response. Almost everything related with
>> auth, pings, discovery, reconfiguration can be implemented by just using
>> regular Ajp13 requests - with a special URL. That is by far my favorite
>> mechanism. It also has the advantage that it can reu
3. On top of regular request/response. Almost everything related with auth,
pings, discovery, reconfiguration can be implemented by just using regular
Ajp13 requests - with a special URL. That is by far my favorite mechanism.
It also has the advantage that it can reuse other parts of tomcat - mappe
Sorry, my previous mail got a bit long ( and a bit unfriendly :-)
The short version:
There are 3 ways to extend jk2:
1. With a completely different protocol module - marshalling and all low
level stuff. I'm +1 on such a thing if the new marshalling is a standard
one - and I think XDR is the right
Sven Köhler wrote:
>>>I took a short look at the ajp13 protocol draft, and the design of the
>>>protocol is really simple, too simple.
>>
>> There are few knwon problems with the protocol - both sides of jk2 are
>> designed to support multiple protocols and extensions.
>
> yes, but how? how can
I took a short look at the ajp13 protocol draft, and the design of the
protocol is really simple, too simple.
There are few knwon problems with the protocol - both sides of jk2 are
designed to support multiple protocols and extensions.
yes, but how? how can either client or server guess, which ext
Henri Gomez wrote:
> Another point is that adding new message to protocol make
> it incompatible with olders java implementations or with alternate
This is not entirely true.
It is quite easy to configure what messages get sent by mod_jk - the
admin is supposed to know what type of worker it co
Sven Köhler wrote:
>> There is another problem with how mod_jk handles the ajp connetor
>> sockets. That is the one to one mapping of apache child process to an ajp
>> connector. On an apache server that serves normal http requests you can
>> end up with many idle socket connections to Tomcat, and
So, we had a problem trying to port mod_jk2 to NetWare, and that is why
we decided to stick with mod_jk. Basically the problem was that mod_jk2
assumed that some data table that existed when Apache does its first
load will still be there when apache unloads mod_jk and reloads it.
This is not the
Henri Gomez wrote:
[EMAIL PROTECTED] wrote:
Why not restart work on mod_webapp? I still wonder why it got dropped.
Because there was only one developper, Pier, with little help from JF
Clere.
BTW, jk2 is here, it's modular and use solid foundations.
Why not works on it ?
And JK2 support also
[EMAIL PROTECTED] wrote:
Why not restart work on mod_webapp? I still wonder why it got dropped.
Because there was only one developper, Pier, with little help from JF Clere.
BTW, jk2 is here, it's modular and use solid foundations.
Why not works on it ?
Glenn Nielsen wrote:
Henri Gomez wrote:
Sven Köhler wrote:
When Apache will be closing connections at a high rate, you make Tomcat
spend precious cycle to catch exceptions, and so you'll slow tomcat also.
FYI, Apache close ajp13 connections each time it recycle/kill a child
and under heavy load o
i guess server-admins want to distinguish between normal-server
operation and network-errors.
currently the log is flooded with unimportant log-messages that are the
result of bad error-detection (i hope, i can do better)
Without specifics add-ons on the protocol, I doubt you could
distinguiss b
Why not restart work on mod_webapp? I still wonder why it got dropped.
Travis
Original Message
From: =?ISO-8859-1?Q?Sven_K=F6hler?= <[EMAIL PROTECTED]>
Sent: 2003-02-27
To: [EMAIL PROTECTED]
Subject: Re: socket errors in catalina.out and mod_jk.log
> There is another problem
There is another problem with how mod_jk handles the ajp connetor sockets.
That is the one to one mapping of apache child process to an ajp connector.
On an apache server that serves normal http requests you can end up with
many idle socket connections to Tomcat, and Tomcat will spawn many more
Con
Henri Gomez wrote:
Sven Köhler wrote:
When Apache will be closing connections at a high rate, you make Tomcat
spend precious cycle to catch exceptions, and so you'll slow tomcat also.
FYI, Apache close ajp13 connections each time it recycle/kill a child
and under heavy load on webserver, it happen
Yes, Exception is a special object which is costly to create and costly
to trap.
i hope, that catching Exception is optimized by the Java, because it
happens quite often in java-programs.
creating on exception object, throwing it etc. should happen quite seldom.
When Apache will be closing conne
read-error should not happen, as mod_jk could send a quit-paket or
something (analog to the ftp-protocol)
read-error happen BECAUSE APACHE HTTPD server close client
when it recycle them.
i hoped, you would react on this one.
What's the problem with this connection closing handling ?
tomcat detect
Sven Köhler wrote:
i looked into these sources, and i am shocked!!!
this.receive() uses this.read(), and this method finally calls the
InputStream.read(). as everybody should know, InputStrean.read()
returns -1 if the end of the inputstream is reached.
this case is checked, but instead of doing
Sven Köhler wrote:
read-error should not happen, as mod_jk could send a quit-paket or
something (analog to the ftp-protocol)
read-error happen BECAUSE APACHE HTTPD server close client
when it recycle them.
i hoped, you would react on this one.
What's the problem with this connection closing ha
i looked into these sources, and i am shocked!!!
this.receive() uses this.read(), and this method finally calls the
InputStream.read(). as everybody should know, InputStrean.read()
returns -1 if the end of the inputstream is reached.
this case is checked, but instead of doing something useful, t
read-error should not happen, as mod_jk could send a quit-paket or
something (analog to the ftp-protocol)
read-error happen BECAUSE APACHE HTTPD server close client
when it recycle them.
i hoped, you would react on this one.
i'm not very much into apache httpd's internals, but i guess, that a
ch
Sven Köhler wrote:
Could you give us more information :
- jk version you're using (jk or jk2)
mod_jk (not mod_jk 2) version 1.2.2
- Apache webserver (1.3/2.0)
apache 1.3.27
- Operating system hosting tomcat and apache
it's suse linux 7.3 with kernel 2.4.20 with sun jdk 1.4.1_01
This messa
Sven Köhler wrote:
void processConnection(MsgContext ep) {
try {
MsgAjp recv=new MsgAjp();
while( running ) {
int status= this.receive( recv, ep );
i looked into these sources, and i am shocked!!!
this.receive() uses this.read(), and this method
void processConnection(MsgContext ep) {
try {
MsgAjp recv=new MsgAjp();
while( running ) {
int status= this.receive( recv, ep );
i looked into these sources, and i am shocked!!!
this.receive() uses this.read(), and this method finally calls the
I
Could you give us more information :
- jk version you're using (jk or jk2)
mod_jk (not mod_jk 2) version 1.2.2
- Apache webserver (1.3/2.0)
apache 1.3.27
- Operating system hosting tomcat and apache
it's suse linux 7.3 with kernel 2.4.20 with sun jdk 1.4.1_01
This message appears in tomcat in w
Is this mod_jk 2?
no, i'm not using mod_jk 2 because i read, that it isn't that well
testet yet.
I am very familiar with mod_jk 1.2/AJP13 and could answer your questions
for it, but your log message imply you are using mod_jk 2 which I am not
familiar with enough to answer your question. Costin?
Sven Köhler wrote:
hi,
i didn't get any useful response in the tomcat-user-mailinglist.
many users have messages in their catalina.out, saying that a socket
times out, or a connection had been closed.
these messages look like this:
25.02.2003 20:22:48 org.apache.jk.common.ChannelSocket processCo
E: socket errors in catalina.out and mod_jk.log
I am getting the exact same messages as of upgrading from 3.2.3 to 4.1.18 yesterday.
Travis
Original Message
From: =?UTF-8?B?U3ZlbiBLw7ZobGVy?= <[EMAIL PROTECTED]>
Sent: 2003-02-25
To: [EMAIL PROTECTED]
Subject: socket erro
Is this mod_jk 2?
I am very familiar with mod_jk 1.2/AJP13 and could answer your questions
for it, but your log message imply you are using mod_jk 2 which I am not
familiar with enough to answer your question. Costin?
Glenn
Sven Köhler wrote:
hi,
i didn't get any useful response in the tomcat-u
I am getting the exact same messages as of upgrading from 3.2.3 to 4.1.18 yesterday.
i think everbody gets these messages, but nobody has ever states, if
they are normal, should be fixed, can be fixed or where the hell they
came from!
when will finally somebody of the tomcat-team comment the s
I am getting the exact same messages as of upgrading from 3.2.3 to 4.1.18 yesterday.
Travis
Original Message
From: =?UTF-8?B?U3ZlbiBLw7ZobGVy?= <[EMAIL PROTECTED]>
Sent: 2003-02-25
To: [EMAIL PROTECTED]
Subject: socket errors in catalina.out and mod_jk.log
hi,
i didn
hi,
i didn't get any useful response in the tomcat-user-mailinglist.
many users have messages in their catalina.out, saying that a socket
times out, or a connection had been closed.
these messages look like this:
25.02.2003 20:22:48 org.apache.jk.common.ChannelSocket processConnection
INFO: conn
35 matches
Mail list logo
