You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Henri Gomez <hg...@apache.org> on 2002/10/01 12:56:31 UTC
JK 1.2.1-beta
I started the JK 1.2.1 beta since I discovered many problems
in iSeries build which will make necessary a JK 1.2.1 release to
support iSeries.
BTW, while working on JNI support in iSeries i saw many suspects
area, in making pointer -> int -> jlong which make me think that
JNI is jk 1.2.1 need a serious review.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JK 1.2.1-beta
Posted by Henri Gomez <hg...@apache.org>.
Glenn Nielsen wrote:
> You are currently working on mod_jk 1.2 and have done alot of
> work on the docs. Would you like to do it?
We could add in the faq the common error messages and give an
explanation. Idea, even put an url to the online documentation on
jakarta ;-)
> I can do it if you can't, but I don't know when I would have the time.
I'm pretty busy these days, and I was thinking releasing jk 1.2.1 since
there was many fixes for iSeries, so jk 1.2.1 = jk 1.2.0 iSeries compatible.
Adding better error messages informations could be planned for jk 1.2.2
even if I think we should concentrate on jk2 now ;-)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JK 1.2.1-beta
Posted by Glenn Nielsen <gl...@mail.more.net>.
You are currently working on mod_jk 1.2 and have done alot of
work on the docs. Would you like to do it?
I can do it if you can't, but I don't know when I would have the time.
Regards,
Glenn
Henri Gomez wrote:
> Glenn Nielsen wrote:
>
>> Hi Henri,
>>
>> I would like to propose one change before the JK 1.2.1 release.
>>
>> I have noticed that on tomcat-user there are questions like:
>>
>> What do these mod_jk.log entries mean?
>>
>> There are some common problems which can happen using mod_jk in
>> production
>> which generate error messages which are great for those debugging C code
>> but are difficult for those using mod_jk in production to understand.
>>
>> Here are some examples of common errors reported on a production system.
>>
>> [Mon May 13 04:08:46 2002] [jk_ajp_common.c (933)]: Error
>> ajp_process_callback - write failed
>>
>> This really means that the remote browser client aborted the HTTP
>> request. This can happen
>> when Tomcat is overloaded and request latency increases significantly.
>>
>>
>> [Mon May 13 07:44:41 2002] [jk_uri_worker_map.c (595)]: In
>> jk_uri_worker_map_t::map_uri_to_worker, wrong parameters
>>
>> Not sure what this means, I would have to go back and review the code
>> again.
>>
>>
>> [Mon May 13 11:38:27 2002] [jk_ajp_common.c (652)]:
>> ajp_connection_tcp_get_message: Error - jk_tcp_socket_recvfull failed
>> [Mon May 13 11:38:27 2002] [jk_ajp_common.c (1013)]: Error reading reply
>> [Mon May 13 11:38:27 2002] [jk_ajp_common.c (1150)]: In
>> jk_endpoint_t::service, ajp_get_reply failed in send loop 0
>>
>> This means that all of Tomcats AjpProcessor's are in use and Tomcat
>> rejected the connection.
>> i.e. Tomcat is overloaded or the Connector maxProcessors needs to be
>> increased. But you get a
>> series of three errors rather than one human readable error.
>>
>>
>> [Mon May 13 11:38:33 2002] [jk_connect.c (151)]: jk_open_socket,
>> connect() failed errno = 146
>> [Mon May 13 11:38:33 2002] [jk_ajp_common.c (599)]: In
>> jk_endpoint_t::ajp_connect_to_endpoint, failed errno = 146
>> [Mon May 13 11:38:33 2002] [jk_ajp_common.c (844)]: Error connecting
>> to the Tomcat process.
>>
>> This means that the Tomcat AjpConnector socket isn't open. This at
>> least ends up with an error
>> that may help someone diagnose the problem. But you do end up with
>> three error messages rather
>> than just one.
>>
>> Trying to interpret these error messages is a common question on
>> tomcat-user.
>>
>> My proposal:
>>
>> 1. Change these errors messages so that they accurately identify what
>> happened.
>> 2. For these common errors only report one error rather than a series
>> of three.
>> 3. Add documentation to the mod_jk docs about what these errors mean.
>
>
> Good idea, who's candidate ?
>
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
--
----------------------------------------------------------------------
Glenn Nielsen glenn@more.net | /* Spelin donut madder |
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
----------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JK 1.2.1-beta
Posted by Henri Gomez <hg...@apache.org>.
Glenn Nielsen wrote:
> Hi Henri,
>
> I would like to propose one change before the JK 1.2.1 release.
>
> I have noticed that on tomcat-user there are questions like:
>
> What do these mod_jk.log entries mean?
>
> There are some common problems which can happen using mod_jk in production
> which generate error messages which are great for those debugging C code
> but are difficult for those using mod_jk in production to understand.
>
> Here are some examples of common errors reported on a production system.
>
> [Mon May 13 04:08:46 2002] [jk_ajp_common.c (933)]: Error
> ajp_process_callback - write failed
>
> This really means that the remote browser client aborted the HTTP
> request. This can happen
> when Tomcat is overloaded and request latency increases significantly.
>
>
> [Mon May 13 07:44:41 2002] [jk_uri_worker_map.c (595)]: In
> jk_uri_worker_map_t::map_uri_to_worker, wrong parameters
>
> Not sure what this means, I would have to go back and review the code
> again.
>
>
> [Mon May 13 11:38:27 2002] [jk_ajp_common.c (652)]:
> ajp_connection_tcp_get_message: Error - jk_tcp_socket_recvfull failed
> [Mon May 13 11:38:27 2002] [jk_ajp_common.c (1013)]: Error reading reply
> [Mon May 13 11:38:27 2002] [jk_ajp_common.c (1150)]: In
> jk_endpoint_t::service, ajp_get_reply failed in send loop 0
>
> This means that all of Tomcats AjpProcessor's are in use and Tomcat
> rejected the connection.
> i.e. Tomcat is overloaded or the Connector maxProcessors needs to be
> increased. But you get a
> series of three errors rather than one human readable error.
>
>
> [Mon May 13 11:38:33 2002] [jk_connect.c (151)]: jk_open_socket,
> connect() failed errno = 146
> [Mon May 13 11:38:33 2002] [jk_ajp_common.c (599)]: In
> jk_endpoint_t::ajp_connect_to_endpoint, failed errno = 146
> [Mon May 13 11:38:33 2002] [jk_ajp_common.c (844)]: Error connecting to
> the Tomcat process.
>
> This means that the Tomcat AjpConnector socket isn't open. This at least
> ends up with an error
> that may help someone diagnose the problem. But you do end up with
> three error messages rather
> than just one.
>
> Trying to interpret these error messages is a common question on
> tomcat-user.
>
> My proposal:
>
> 1. Change these errors messages so that they accurately identify what
> happened.
> 2. For these common errors only report one error rather than a series
> of three.
> 3. Add documentation to the mod_jk docs about what these errors mean.
Good idea, who's candidate ?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JK 1.2.1-beta
Posted by Henri Gomez <hg...@apache.org>.
Bojan Smojver wrote:
> On Tue, 2002-10-01 at 23:41, Glenn Nielsen wrote:
>
>
>>Trying to interpret these error messages is a common question on tomcat-user.
>>
>>My proposal:
>>
>>1. Change these errors messages so that they accurately identify what happened.
>>2. For these common errors only report one error rather than a series of three.
>>3. Add documentation to the mod_jk docs about what these errors mean.
>
>
> 2 sounds like quite a bit of work.
yes, it's too much works
> 3 I think is a must (your e-mail is a great start for it - maybe you can
> whack it in FAQ).
Yes, extend faq.xml/faq.html with error message.
> 1 would be nice, but people should be able to live with 3 if you don't
> have time for 1.
Why not put an URL to faq.html, for the common error messages, ie :
http://jakarta.apache.org/builds/jk/docs/faq.html#canconnect ?
Up to date documentation could be provided like this ?
What about same behaviour for jk2 ?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JK 1.2.1-beta
Posted by Bojan Smojver <bo...@rexursive.com>.
On Tue, 2002-10-01 at 23:41, Glenn Nielsen wrote:
> Trying to interpret these error messages is a common question on tomcat-user.
>
> My proposal:
>
> 1. Change these errors messages so that they accurately identify what happened.
> 2. For these common errors only report one error rather than a series of three.
> 3. Add documentation to the mod_jk docs about what these errors mean.
2 sounds like quite a bit of work.
3 I think is a must (your e-mail is a great start for it - maybe you can
whack it in FAQ).
1 would be nice, but people should be able to live with 3 if you don't
have time for 1.
Bojan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JK 1.2.1-beta
Posted by Glenn Nielsen <gl...@mail.more.net>.
Hi Henri,
I would like to propose one change before the JK 1.2.1 release.
I have noticed that on tomcat-user there are questions like:
What do these mod_jk.log entries mean?
There are some common problems which can happen using mod_jk in production
which generate error messages which are great for those debugging C code
but are difficult for those using mod_jk in production to understand.
Here are some examples of common errors reported on a production system.
[Mon May 13 04:08:46 2002] [jk_ajp_common.c (933)]: Error ajp_process_callback - write failed
This really means that the remote browser client aborted the HTTP request. This can happen
when Tomcat is overloaded and request latency increases significantly.
[Mon May 13 07:44:41 2002] [jk_uri_worker_map.c (595)]: In jk_uri_worker_map_t::map_uri_to_worker, wrong parameters
Not sure what this means, I would have to go back and review the code again.
[Mon May 13 11:38:27 2002] [jk_ajp_common.c (652)]: ajp_connection_tcp_get_message: Error - jk_tcp_socket_recvfull failed
[Mon May 13 11:38:27 2002] [jk_ajp_common.c (1013)]: Error reading reply
[Mon May 13 11:38:27 2002] [jk_ajp_common.c (1150)]: In jk_endpoint_t::service, ajp_get_reply failed in send loop 0
This means that all of Tomcats AjpProcessor's are in use and Tomcat rejected the connection.
i.e. Tomcat is overloaded or the Connector maxProcessors needs to be increased. But you get a
series of three errors rather than one human readable error.
[Mon May 13 11:38:33 2002] [jk_connect.c (151)]: jk_open_socket, connect() failed errno = 146
[Mon May 13 11:38:33 2002] [jk_ajp_common.c (599)]: In jk_endpoint_t::ajp_connect_to_endpoint, failed errno = 146
[Mon May 13 11:38:33 2002] [jk_ajp_common.c (844)]: Error connecting to the Tomcat process.
This means that the Tomcat AjpConnector socket isn't open. This at least ends up with an error
that may help someone diagnose the problem. But you do end up with three error messages rather
than just one.
Trying to interpret these error messages is a common question on tomcat-user.
My proposal:
1. Change these errors messages so that they accurately identify what happened.
2. For these common errors only report one error rather than a series of three.
3. Add documentation to the mod_jk docs about what these errors mean.
Regards,
Glenn
Henri Gomez wrote:
> I started the JK 1.2.1 beta since I discovered many problems
> in iSeries build which will make necessary a JK 1.2.1 release to
> support iSeries.
>
> BTW, while working on JNI support in iSeries i saw many suspects
> area, in making pointer -> int -> jlong which make me think that
> JNI is jk 1.2.1 need a serious review.
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>