Re: Mod_jk error

2014-01-13 Thread Alex Lucard
Thank you so much i have it working now i had to change the httpd.com from
JkMount /Hello/*loadbalancer1
To
JkMount /Hello*workspace1
On Jan 12, 2014 9:31 PM, 侯树成 chain...@gmail.com wrote:

 Hi, Alex
 What is your mod_jk.conf file that used for mod_jk configuration.

 You can config it as blow:
 LoadModule jk_module modules/mod_jk.so
 JkWorkersFile  conf/workers.properties
 JkLogFile logs/mod_jk.log
 JkLogLevel error
 JkLogStampFormat [%a %b %d %H:%M:%S %Y]
 JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories
 JkMount /test_status mystatus
 JkMount /hello*loadbalancer1

 or Just as your configuration now, but add the JkMount to http.conf. The
 JkMount /hello* loadbalancer1 will send all request start with hello  to
 loadbalancer1

 Hope to help you.


 2014/1/11 Mark Eggers its_toas...@yahoo.com

  On 1/10/2014 2:53 PM, Alex Lucard wrote:
 
  .
  On Jan 10, 2014 5:00 PM, Alex Lucard priest.luc...@gmail.com wrote:
 
   I am running CentOS 6.5 and tomcat 7
  I cannot get the mod_jk to work
  I have a JSP page on this server and if you go to localhost:8080/Hello
 it
  will work but if I just go to localhost/Hello The requested URL /Hello
  was
  not found on this server.
 
  I have apache2 and tomcat 7 install both work.
  Here is the part I added to the httpd.conf file
 
  # Load the mod_jk module.
  LoadModule jk_module /usr/lib64/httpd/modules/mod_jk.so
  JkWorkersFile /etc/httpd/conf/workers.properties
  jkLogFile /var/log/mod_jk.log
  JkLogLevellevel
  JkLogStampFormat [%a %b %d %H:%M:%S %Y] 
 
  My workers.properties file at /etc/httpd/conf/workers.properties
  worker.list=worker1
  worker.worker1.type=ajp13
  worker.worker1.port=8009
  worker.worker1.host=localhost
  #worker.worker1.lbfactor=1
 
 
  My error log file /var/log/mod_jk.log
  [Fri Jan 10 15:19:22 2014] [1854:140509786134496] [info]
  init_jk::mod_jk.c
  (3365): mod_jk/1.2.37 initialized
  [Fri Jan 10 15:19:23 2014] [1855:140509786134496] [error]
  ajp_validate::jk_ajp_common.c (2696): worker worker1 can't resolve
 tomcat
  address localhost
  [Fri Jan 10 15:19:23 2014] [1855:140509786134496] [info]
  init_jk::mod_jk.c
  (3365): mod_jk/1.2.37 initialized
 
 
 
  What happens when you type the following from the command line:
 
  dig localhost
 
  As a workaround, replace localhost with 127.0.0.1.
 
  . . . . just my two cents
  /mde/
 
  -
  To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
  For additional commands, e-mail: users-h...@tomcat.apache.org
 
 



Re: Mod_jk error

2014-01-12 Thread 侯树成
Hi, Alex
What is your mod_jk.conf file that used for mod_jk configuration.

You can config it as blow:
LoadModule jk_module modules/mod_jk.so
JkWorkersFile  conf/workers.properties
JkLogFile logs/mod_jk.log
JkLogLevel error
JkLogStampFormat [%a %b %d %H:%M:%S %Y]
JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories
JkMount /test_status mystatus
JkMount /hello*loadbalancer1

or Just as your configuration now, but add the JkMount to http.conf. The
JkMount /hello* loadbalancer1 will send all request start with hello  to
loadbalancer1

Hope to help you.


2014/1/11 Mark Eggers its_toas...@yahoo.com

 On 1/10/2014 2:53 PM, Alex Lucard wrote:

 .
 On Jan 10, 2014 5:00 PM, Alex Lucard priest.luc...@gmail.com wrote:

  I am running CentOS 6.5 and tomcat 7
 I cannot get the mod_jk to work
 I have a JSP page on this server and if you go to localhost:8080/Hello it
 will work but if I just go to localhost/Hello The requested URL /Hello
 was
 not found on this server.

 I have apache2 and tomcat 7 install both work.
 Here is the part I added to the httpd.conf file

 # Load the mod_jk module.
 LoadModule jk_module /usr/lib64/httpd/modules/mod_jk.so
 JkWorkersFile /etc/httpd/conf/workers.properties
 jkLogFile /var/log/mod_jk.log
 JkLogLevellevel
 JkLogStampFormat [%a %b %d %H:%M:%S %Y] 

 My workers.properties file at /etc/httpd/conf/workers.properties
 worker.list=worker1
 worker.worker1.type=ajp13
 worker.worker1.port=8009
 worker.worker1.host=localhost
 #worker.worker1.lbfactor=1


 My error log file /var/log/mod_jk.log
 [Fri Jan 10 15:19:22 2014] [1854:140509786134496] [info]
 init_jk::mod_jk.c
 (3365): mod_jk/1.2.37 initialized
 [Fri Jan 10 15:19:23 2014] [1855:140509786134496] [error]
 ajp_validate::jk_ajp_common.c (2696): worker worker1 can't resolve tomcat
 address localhost
 [Fri Jan 10 15:19:23 2014] [1855:140509786134496] [info]
 init_jk::mod_jk.c
 (3365): mod_jk/1.2.37 initialized



 What happens when you type the following from the command line:

 dig localhost

 As a workaround, replace localhost with 127.0.0.1.

 . . . . just my two cents
 /mde/

 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org




Mod_jk error

2014-01-10 Thread Alex Lucard
.
On Jan 10, 2014 5:00 PM, Alex Lucard priest.luc...@gmail.com wrote:

 I am running CentOS 6.5 and tomcat 7
 I cannot get the mod_jk to work
 I have a JSP page on this server and if you go to localhost:8080/Hello it
 will work but if I just go to localhost/Hello The requested URL /Hello was
 not found on this server.

 I have apache2 and tomcat 7 install both work.
 Here is the part I added to the httpd.conf file

 # Load the mod_jk module.
 LoadModule jk_module /usr/lib64/httpd/modules/mod_jk.so
 JkWorkersFile /etc/httpd/conf/workers.properties
 jkLogFile /var/log/mod_jk.log
 JkLogLevellevel
 JkLogStampFormat [%a %b %d %H:%M:%S %Y] 

 My workers.properties file at /etc/httpd/conf/workers.properties
 worker.list=worker1
 worker.worker1.type=ajp13
 worker.worker1.port=8009
 worker.worker1.host=localhost
 #worker.worker1.lbfactor=1


 My error log file /var/log/mod_jk.log
 [Fri Jan 10 15:19:22 2014] [1854:140509786134496] [info] init_jk::mod_jk.c
 (3365): mod_jk/1.2.37 initialized
 [Fri Jan 10 15:19:23 2014] [1855:140509786134496] [error]
 ajp_validate::jk_ajp_common.c (2696): worker worker1 can't resolve tomcat
 address localhost
 [Fri Jan 10 15:19:23 2014] [1855:140509786134496] [info] init_jk::mod_jk.c
 (3365): mod_jk/1.2.37 initialized



Re: Mod_jk error

2014-01-10 Thread Mark Eggers

On 1/10/2014 2:53 PM, Alex Lucard wrote:

.
On Jan 10, 2014 5:00 PM, Alex Lucard priest.luc...@gmail.com wrote:


I am running CentOS 6.5 and tomcat 7
I cannot get the mod_jk to work
I have a JSP page on this server and if you go to localhost:8080/Hello it
will work but if I just go to localhost/Hello The requested URL /Hello was
not found on this server.

I have apache2 and tomcat 7 install both work.
Here is the part I added to the httpd.conf file

# Load the mod_jk module.
LoadModule jk_module /usr/lib64/httpd/modules/mod_jk.so
JkWorkersFile /etc/httpd/conf/workers.properties
jkLogFile /var/log/mod_jk.log
JkLogLevellevel
JkLogStampFormat [%a %b %d %H:%M:%S %Y] 

My workers.properties file at /etc/httpd/conf/workers.properties
worker.list=worker1
worker.worker1.type=ajp13
worker.worker1.port=8009
worker.worker1.host=localhost
#worker.worker1.lbfactor=1


My error log file /var/log/mod_jk.log
[Fri Jan 10 15:19:22 2014] [1854:140509786134496] [info] init_jk::mod_jk.c
(3365): mod_jk/1.2.37 initialized
[Fri Jan 10 15:19:23 2014] [1855:140509786134496] [error]
ajp_validate::jk_ajp_common.c (2696): worker worker1 can't resolve tomcat
address localhost
[Fri Jan 10 15:19:23 2014] [1855:140509786134496] [info] init_jk::mod_jk.c
(3365): mod_jk/1.2.37 initialized





What happens when you type the following from the command line:

dig localhost

As a workaround, replace localhost with 127.0.0.1.

. . . . just my two cents
/mde/

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Explanation mod_jk error messages

2009-10-01 Thread Bocalinda
Thanks a lot Rainer.

If the error messages are in some way OK, then my question got answered.
Thanks again.

2009/9/30 Rainer Jung rainer.j...@kippdata.de

 On 30.09.2009 17:19, Bocalinda wrote:
  Hi André.
 
  I actually stopped one server on purpose, to test the mod_jk's behavior.
  So the errors are not generated due to an overload or something.
 
  I would love to send you the whole workers.properties file and
 server.xml,
  but unfurtunately at this moment I can't.
  In advance I can tell you that both Tomncat's are running on diffferent
  servers 10.189.x.x, on port 8009 and 8010 respectively.
 
  I stopped the server on port 8009, which coincides with the logs.
 Although,
  it seems strange to me that it keeps trying to send request to that
 server.
 
  Hope this helps...

 Yes, if a backend node is gone and you don't inform mod_jk it will
 detect it, but it will also log it.

 Currently there is no separate probing of failed backends. If a backend
 has been detected as failed, mod_jk will use one of the requests which
 are eligible for this backend every now and then to see, if it works
 again. Depending on the load this should happen about once a minute.
 Usually mod_jk can detect very quickly, that the backend is still
 broken, log the fact and send the request to some other backend.

 If you to a backend out of service for some time, then it is nicer to
 set its attribute activation to stopped, Then mod_jk knows, that it
 shouldn't try to send anything there (and will not log any errors).

 Regards,

 Rainer

 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org




Explanation mod_jk error messages

2009-09-30 Thread Bocalinda
Hi List,

I have configured Apache 2.2.11 (worker mpm) with mod_jk 1.2.27 and two
nodes of Tomcat 6.0.20

My mod_jk configuration only has the following settings (apart from the port
and IP address settings ofcourse):

worker.tcnodo-11.socket_keepalive=true
worker.tcnodo-11.connection_pool_timeout=600

worker.tcnodo-12.socket_keepalive=true
worker.tcnodo-12.connection_pool_timeout=600

Inside the AJP connector tag of both Tomcats I have configure
connectionTimeout to 60.

Now, my application works fine and seems to handle correctly failover of
failed nodes.
However, there are a series of errors and warnings printed in the mod_jk.log
which worry me.

I was wondering if somebody could explain what they actually mean and what
is happening.
I noticed that although connection failed to a node, it keeps trying sending
requests to that node over and over.
Although, my web application never returns an error (thus it seems its
balancing correctly to the working node), I'm worried about this behavior as
it might introduce latency.

[Wed Sep 30 11:31:21.339 2009] [4681:1183201600] [info]
ajp_service::jk_ajp_common.c (2407): (tcnodo11-6eka) sending request to
tomcat failed (recoverable), because of error during request sending
(attempt=2)
[Wed Sep 30 11:31:21.339 2009] [4681:1183201600] [error]
ajp_service::jk_ajp_common.c (2426): (tcnodo11-6eka) connecting to
tomcat failed.
[Wed Sep 30 11:31:21.339 2009] [4681:1183201600] [info]
service::jk_lb_worker.c (1347): service failed, worker tcnodo11-6eka is
in error state
[Wed Sep 30 11:31:57.244 2009] [4680:1357449536] [info]
ajp_send_request::jk_ajp_common.c (1456): (tcnodo12-6eka) all endpoints
are disconnected, detected by connect check (1), cping (0), send (0)
[Wed Sep 30 11:33:21.572 2009] [4769:1297041728] [info]
jk_open_socket::jk_connect.c (593): connect to 10.189.x.x:8009 failed
(errno=111)
[Wed Sep 30 11:33:21.572 2009] [4769:1297041728] [info]
ajp_connect_to_endpoint::jk_ajp_common.c (922): Failed opening socket to
(10.189.x.x:8009) (errno=111)
[Wed Sep 30 11:33:21.572 2009] [4769:1297041728] [error]
ajp_send_request::jk_ajp_common.c (1467): (tcnodo11-6eka) connecting to
backend failed. Tomcat is probably not started or is listening on the
wrong port (errno=111)
[Wed Sep 30 11:33:21.572 2009] [4769:1297041728] [info]
ajp_service::jk_ajp_common.c (2407): (tcnodo11-6eka) sending request to
tomcat failed (recoverable), because of error during request sending
(attempt=1)
[Wed Sep 30 11:33:21.673 2009] [4769:1297041728] [info]
jk_open_socket::jk_connect.c (593): connect to 10.189.x.x:8009 failed
(errno=111)
[Wed Sep 30 11:33:21.673 2009] [4769:1297041728] [info]
ajp_connect_to_endpoint::jk_ajp_common.c (922): Failed opening socket to
(10.189.x.x:8009) (errno=111)
[Wed Sep 30 11:33:21.673 2009] [4769:1297041728] [error]
ajp_send_request::jk_ajp_common.c (1467): (tcnodo11-6eka) connecting to
backend failed. Tomcat is probably not started or is listening on the
wrong port (errno=111)
[Wed Sep 30 11:33:21.673 2009] [4769:1297041728] [info]
ajp_service::jk_ajp_common.c (2407): (tcnodo11-6eka) sending request to
tomcat failed (recoverable), because of error during request sending
(attempt=2)
[Wed Sep 30 11:33:21.673 2009] [4769:1297041728] [error]
ajp_service::jk_ajp_common.c (2426): (tcnodo11-6eka) connecting to
tomcat failed.
[Wed Sep 30 11:33:21.673 2009] [4769:1297041728] [info]
service::jk_lb_worker.c (1347): service failed, worker tcnodo11-6eka is
in error state
[Wed Sep 30 11:35:24.556 2009] [4769:1255082304] [info]
jk_open_socket::jk_connect.c (593): connect to 10.189.x.x:8009 failed
(errno=111)
[Wed Sep 30 11:35:24.556 2009] [4769:1255082304] [info]
ajp_connect_to_endpoint::jk_ajp_common.c (922): Failed opening socket to
(10.189.x.x:8009) (errno=111)
[Wed Sep 30 11:35:24.556 2009] [4769:1255082304] [error]
ajp_send_request::jk_ajp_common.c (1467): (tcnodo11-6eka) connecting to
backend failed. Tomcat is probably not started or is listening on the
wrong port (errno=111)
[Wed Sep 30 11:35:24.556 2009] [4769:1255082304] [info]
ajp_service::jk_ajp_common.c (2407): (tcnodo11-6eka) sending request to
tomcat failed (recoverable), because of error during request sending
(attempt=1)
[Wed Sep 30 11:35:24.657 2009] [4769:1255082304] [info]
jk_open_socket::jk_connect.c (593): connect to 10.189.x.x:8009 failed
(errno=111)
[Wed Sep 30 11:35:24.657 2009] [4769:1255082304] [info]
ajp_connect_to_endpoint::jk_ajp_common.c (922): Failed opening socket to
(10.189.x.x:8009) (errno=111)
[Wed Sep 30 11:35:24.657 2009] [4769:1255082304] [error]
ajp_send_request::jk_ajp_common.c (1467): (tcnodo11-6eka) connecting to
backend failed. Tomcat is probably not started or is listening on the
wrong port (errno=111)
[Wed Sep 30 11:35:24.657 2009] [4769:1255082304] [info]
ajp_service::jk_ajp_common.c (2407): (tcnodo11-6eka) sending request to
tomcat failed (recoverable), because of error during request sending
(attempt=2)
[Wed Sep 30 11:35:24.657 2009] [4769:1255082304] [error]

Re: Explanation mod_jk error messages

2009-09-30 Thread André Warnier

Bocalinda wrote:
...



My mod_jk configuration only has the following settings (apart from the port
and IP address settings ofcourse):


That is exactly what it would have been interesting to see, along with 
the Connector tags in your Tomcat's server.xml files.


What is strange with the error messages you show, is that you never see 
an error in your applications.  Maybe your back-end Tomcats are just 
overloaded from time to time, and have so many connection requests piled 
up that they start refusing new ones ?


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Explanation mod_jk error messages

2009-09-30 Thread Bocalinda
Hi André.

I actually stopped one server on purpose, to test the mod_jk's behavior.
So the errors are not generated due to an overload or something.

I would love to send you the whole workers.properties file and server.xml,
but unfurtunately at this moment I can't.
In advance I can tell you that both Tomncat's are running on diffferent
servers 10.189.x.x, on port 8009 and 8010 respectively.

I stopped the server on port 8009, which coincides with the logs. Although,
it seems strange to me that it keeps trying to send request to that server.

Hope this helps...

2009/9/30 André Warnier a...@ice-sa.com

 Bocalinda wrote:
 ...


 My mod_jk configuration only has the following settings (apart from the
 port
 and IP address settings ofcourse):


 That is exactly what it would have been interesting to see, along with the
 Connector tags in your Tomcat's server.xml files.

 What is strange with the error messages you show, is that you never see an
 error in your applications.  Maybe your back-end Tomcats are just overloaded
 from time to time, and have so many connection requests piled up that they
 start refusing new ones ?

 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org




Re: Explanation mod_jk error messages

2009-09-30 Thread Rainer Jung
On 30.09.2009 17:19, Bocalinda wrote:
 Hi André.
 
 I actually stopped one server on purpose, to test the mod_jk's behavior.
 So the errors are not generated due to an overload or something.
 
 I would love to send you the whole workers.properties file and server.xml,
 but unfurtunately at this moment I can't.
 In advance I can tell you that both Tomncat's are running on diffferent
 servers 10.189.x.x, on port 8009 and 8010 respectively.
 
 I stopped the server on port 8009, which coincides with the logs. Although,
 it seems strange to me that it keeps trying to send request to that server.
 
 Hope this helps...

Yes, if a backend node is gone and you don't inform mod_jk it will
detect it, but it will also log it.

Currently there is no separate probing of failed backends. If a backend
has been detected as failed, mod_jk will use one of the requests which
are eligible for this backend every now and then to see, if it works
again. Depending on the load this should happen about once a minute.
Usually mod_jk can detect very quickly, that the backend is still
broken, log the fact and send the request to some other backend.

If you to a backend out of service for some time, then it is nicer to
set its attribute activation to stopped, Then mod_jk knows, that it
shouldn't try to send anything there (and will not log any errors).

Regards,

Rainer

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: /context not working -- mod_jk error: no match for /server-status

2009-09-08 Thread Dennis Christopher

Rainer,

I've disabled mod_status in the httpd.conf and now the error no longer  
appears in mod_jk.log.


I try http://localhost/sample/ on the server, as you request, and I am  
back to file not found.


I can reach the server from outside - the default web page shows  up  
okay and references of the form mysite.com:8080/sample have always  
worked.


It may be helpful to see if mod_jk is the problem. Is there any way to  
exercise it apart from what we have been trying?


Dennis
On Sep 7, 2009, at 5:46 AM, Rainer Jung wrote:


On 04.09.2009 16:01, Dennis Christopher wrote:

Rainer,

Apparently apache is calling /server-status - I see that mod_status  
is


No, apache itself isn't calling anything.


enabled in httpd.conf and exercises that context.

One of the frustrations, and I dont know Apache well, is that the  
access

log seldom updates.
The error log in the same folder does update, but contains little
information--apache restarts is about it.

I don't know if this helps, but I just tried to access the sample web
app from the server machine's own browser

httpd://localhost/sample

and I get Bad Gateway! The proxy server received an invalid response
from an upstream server
Error 502
locahost


So that indicates, that Apache is answering via mod_jk (or mod_proxy).
You should try the correct URL

http://localhost/sample/

though.


and this does update the access log.


So you have a problem reaching your web server from outside. Firewall,
DNS, routing or similar stuff.


Dennis Christopher
On Sep 4, 2009, at 12:49 AM, Rainer Jung wrote:


On 03.09.2009 20:24, Dennis Christopher wrote:

Rainer,

Trying your /sample/ I get the same result.

The log appears to respond to that try but the lines are similar to
those I originally posted from mod_jk.log.

It's as though every context request is translated into
'/server-status'.


Not very likely. Are those entries also appearing in times you are  
not

testing? If so those are someone else, and your own request isn't
handled by the Apache you are looking at. Can you find your  
request in

the access log?

Go through all config files and find out, what is configured about
/server-status. That URL doesn't have anything to do with mod_jk.

Regards,

Rainer


the bracketed numbers are:

[221:268597152] [debug] attempting to map URI '/server-status'  
from 5

maps.
.
.
[221:268597152] [debug] attempting to map context URI
'/sample/*.=JBOSS1*' source JKMount
.
.

all the entries are marked [debug].

221 is process httpd with user _www.

Dennis

On Sep 3, 2009, at 1:26 PM, Rainer Jung wrote:


On 03.09.2009 19:15, Dennis Christopher wrote:
The problem is that I am trying to support simple references to  
my

context without the tomcat port explicitly included.

example: myexample.com/sample should invoke the web-app sample.


You don't have a JkMount for /sample, only one for /sample/*.
What happens, if you point your browser to

http://my.apache.name/sample/

If it doesn't work, extract the lines from your mod_jk log, that  
refer

to this request. Look for something like

... [A_NUMBER:ANOTHER_NUMBER] ... Attempting to map URI '/sample/'
from ...

Then note A_NUMBER:ANOTHER_NUMBER which are the process and  
thread id

used for the request, and get all lines form the log, which have a
timestamp close to your request and use the same IDs.

Check whether there are any non-debug lines in there. If you  
can't see

what goes wrong, post those lines.

Regards,

Rainer


what happens instead: the browser tells me: file not found.

looking at catalina.out it seems the request doesnt reach  
Tomcat at

all.

How I did it: he quick start guide at

http://tomcat.apache.org/connectors-doc/generic_howto/quick.html

gives a simple proof of concept for a context setup (/examples).

which I have followed implicitly. I believe you have already seen
what I
have done with the config files I posted.

Dennis

P.S as it may be important - if I try example.com:8080/sample  
the main
page of my web app loads but all of its subreferences, to gif  
images

etc, are broken.


On Sep 3, 2009, at 12:48 PM, Rainer Jung wrote:


On 03.09.2009 15:34, Dennis Christopher wrote:

Rainer,

I am not sending /server-status explicitly.

The mod_jk log which I excerpted earlier shows the processing  
of

server-status before any context is asked for, apparently when
Tomcat
starts up.

The log continues to repeat these entries - apparently mod_jk  
is

looping
trying to satisfy this context and never does.


No I'm pretty sure this is not the case. I expect someone has a
monitoring tool running or a browser windows with auto-refresh  
for

/server-status and that's what produces those debug log lines in
mod_jk.
No problem per se.

So back to the basic question: what is your problem? What are  
you

trying
to achieve, what did you do to make it work, how do you test  
it, what

result do you expect and what happens instead?

Regards,

Rainer


I added JkMountCopy All but this had no effect.

Dennis

Re: /context not working -- mod_jk error: no match for /server-status

2009-09-07 Thread Rainer Jung
On 04.09.2009 16:01, Dennis Christopher wrote:
 Rainer,
 
 Apparently apache is calling /server-status - I see that mod_status is

No, apache itself isn't calling anything.

 enabled in httpd.conf and exercises that context.
 
 One of the frustrations, and I dont know Apache well, is that the access
 log seldom updates.
 The error log in the same folder does update, but contains little
 information--apache restarts is about it.
 
 I don't know if this helps, but I just tried to access the sample web
 app from the server machine's own browser
 
 httpd://localhost/sample
 
 and I get Bad Gateway! The proxy server received an invalid response
 from an upstream server
 Error 502
 locahost

So that indicates, that Apache is answering via mod_jk (or mod_proxy).
You should try the correct URL

http://localhost/sample/

though.

 and this does update the access log.

So you have a problem reaching your web server from outside. Firewall,
DNS, routing or similar stuff.

 Dennis Christopher
 On Sep 4, 2009, at 12:49 AM, Rainer Jung wrote:
 
 On 03.09.2009 20:24, Dennis Christopher wrote:
 Rainer,

 Trying your /sample/ I get the same result.

 The log appears to respond to that try but the lines are similar to
 those I originally posted from mod_jk.log.

 It's as though every context request is translated into
 '/server-status'.

 Not very likely. Are those entries also appearing in times you are not
 testing? If so those are someone else, and your own request isn't
 handled by the Apache you are looking at. Can you find your request in
 the access log?

 Go through all config files and find out, what is configured about
 /server-status. That URL doesn't have anything to do with mod_jk.

 Regards,

 Rainer

 the bracketed numbers are:

 [221:268597152] [debug] attempting to map URI '/server-status' from 5
 maps.
 .
 .
 [221:268597152] [debug] attempting to map context URI
 '/sample/*.=JBOSS1*' source JKMount
 .
 .

 all the entries are marked [debug].

 221 is process httpd with user _www.

 Dennis

 On Sep 3, 2009, at 1:26 PM, Rainer Jung wrote:

 On 03.09.2009 19:15, Dennis Christopher wrote:
 The problem is that I am trying to support simple references to my
 context without the tomcat port explicitly included.

 example: myexample.com/sample should invoke the web-app sample.

 You don't have a JkMount for /sample, only one for /sample/*.
 What happens, if you point your browser to

 http://my.apache.name/sample/

 If it doesn't work, extract the lines from your mod_jk log, that refer
 to this request. Look for something like

 ... [A_NUMBER:ANOTHER_NUMBER] ... Attempting to map URI '/sample/'
 from ...

 Then note A_NUMBER:ANOTHER_NUMBER which are the process and thread id
 used for the request, and get all lines form the log, which have a
 timestamp close to your request and use the same IDs.

 Check whether there are any non-debug lines in there. If you can't see
 what goes wrong, post those lines.

 Regards,

 Rainer

 what happens instead: the browser tells me: file not found.

 looking at catalina.out it seems the request doesnt reach Tomcat at
 all.

 How I did it: he quick start guide at

 http://tomcat.apache.org/connectors-doc/generic_howto/quick.html

 gives a simple proof of concept for a context setup (/examples).

 which I have followed implicitly. I believe you have already seen
 what I
 have done with the config files I posted.

 Dennis

 P.S as it may be important - if I try example.com:8080/sample the main
 page of my web app loads but all of its subreferences, to gif images
 etc, are broken.


 On Sep 3, 2009, at 12:48 PM, Rainer Jung wrote:

 On 03.09.2009 15:34, Dennis Christopher wrote:
 Rainer,

 I am not sending /server-status explicitly.

 The mod_jk log which I excerpted earlier shows the processing of
 server-status before any context is asked for, apparently when
 Tomcat
 starts up.

 The log continues to repeat these entries - apparently mod_jk is
 looping
 trying to satisfy this context and never does.

 No I'm pretty sure this is not the case. I expect someone has a
 monitoring tool running or a browser windows with auto-refresh for
 /server-status and that's what produces those debug log lines in
 mod_jk.
 No problem per se.

 So back to the basic question: what is your problem? What are you
 trying
 to achieve, what did you do to make it work, how do you test it, what
 result do you expect and what happens instead?

 Regards,

 Rainer

 I added JkMountCopy All but this had no effect.

 Dennis
 On Sep 3, 2009, at 4:18 AM, Rainer Jung wrote:

 On 02.09.2009 21:45, Dennis Christopher wrote:
 Rainer,

 Thanks for the reply. I was confused in my orginal post: I am not
 using
 JBoss at all, only mod_jk.

 The file contents are as follows below.

 Apache has a hosts directory, but I'm not sure if the files
 matter.
 They
 are either the apache .default files or slight modifications of
 them,
 e.g. virtual_host_global.conf contains just:

 Listen *:80

 I don't understand, why you test 

Re: /context not working -- mod_jk error: no match for /server-status

2009-09-04 Thread Dennis Christopher

Rainer,

Apparently apache is calling /server-status - I see that mod_status is  
enabled in httpd.conf and exercises that context.


One of the frustrations, and I dont know Apache well, is that the  
access log seldom updates.
The error log in the same folder does update, but contains little  
information--apache restarts is about it.


I don't know if this helps, but I just tried to access the sample web  
app from the server machine's own browser


httpd://localhost/sample

and I get Bad Gateway! The proxy server received an invalid response  
from an upstream server

Error 502
locahost

and this does update the access log.

Dennis Christopher
On Sep 4, 2009, at 12:49 AM, Rainer Jung wrote:


On 03.09.2009 20:24, Dennis Christopher wrote:

Rainer,

Trying your /sample/ I get the same result.

The log appears to respond to that try but the lines are similar to
those I originally posted from mod_jk.log.

It's as though every context request is translated into '/server- 
status'.


Not very likely. Are those entries also appearing in times you are not
testing? If so those are someone else, and your own request isn't
handled by the Apache you are looking at. Can you find your request in
the access log?

Go through all config files and find out, what is configured about
/server-status. That URL doesn't have anything to do with mod_jk.

Regards,

Rainer


the bracketed numbers are:

[221:268597152] [debug] attempting to map URI '/server-status' from  
5 maps.

.
.
[221:268597152] [debug] attempting to map context URI
'/sample/*.=JBOSS1*' source JKMount
.
.

all the entries are marked [debug].

221 is process httpd with user _www.

Dennis

On Sep 3, 2009, at 1:26 PM, Rainer Jung wrote:


On 03.09.2009 19:15, Dennis Christopher wrote:

The problem is that I am trying to support simple references to my
context without the tomcat port explicitly included.

example: myexample.com/sample should invoke the web-app sample.


You don't have a JkMount for /sample, only one for /sample/*.
What happens, if you point your browser to

http://my.apache.name/sample/

If it doesn't work, extract the lines from your mod_jk log, that  
refer

to this request. Look for something like

... [A_NUMBER:ANOTHER_NUMBER] ... Attempting to map URI '/sample/'
from ...

Then note A_NUMBER:ANOTHER_NUMBER which are the process and thread  
id

used for the request, and get all lines form the log, which have a
timestamp close to your request and use the same IDs.

Check whether there are any non-debug lines in there. If you can't  
see

what goes wrong, post those lines.

Regards,

Rainer


what happens instead: the browser tells me: file not found.

looking at catalina.out it seems the request doesnt reach Tomcat  
at all.


How I did it: he quick start guide at

http://tomcat.apache.org/connectors-doc/generic_howto/quick.html

gives a simple proof of concept for a context setup (/examples).

which I have followed implicitly. I believe you have already seen  
what I

have done with the config files I posted.

Dennis

P.S as it may be important - if I try example.com:8080/sample the  
main
page of my web app loads but all of its subreferences, to gif  
images

etc, are broken.


On Sep 3, 2009, at 12:48 PM, Rainer Jung wrote:


On 03.09.2009 15:34, Dennis Christopher wrote:

Rainer,

I am not sending /server-status explicitly.

The mod_jk log which I excerpted earlier shows the processing of
server-status before any context is asked for, apparently when  
Tomcat

starts up.

The log continues to repeat these entries - apparently mod_jk is
looping
trying to satisfy this context and never does.


No I'm pretty sure this is not the case. I expect someone has a
monitoring tool running or a browser windows with auto-refresh for
/server-status and that's what produces those debug log lines in
mod_jk.
No problem per se.

So back to the basic question: what is your problem? What are you
trying
to achieve, what did you do to make it work, how do you test it,  
what

result do you expect and what happens instead?

Regards,

Rainer


I added JkMountCopy All but this had no effect.

Dennis
On Sep 3, 2009, at 4:18 AM, Rainer Jung wrote:


On 02.09.2009 21:45, Dennis Christopher wrote:

Rainer,

Thanks for the reply. I was confused in my orginal post: I am  
not

using
JBoss at all, only mod_jk.

The file contents are as follows below.

Apache has a hosts directory, but I'm not sure if the files  
matter.

They
are either the apache .default files or slight modifications of
them,
e.g. virtual_host_global.conf contains just:

Listen *:80


I don't understand, why you test this with a request /server- 
status.
That doesn't make sense, because you don't want /server-status  
to be

forwarded by mod_jk and in fact you didn't configure it.

So choose a better URL to test (one of the URLs you have a  
JkMount

for)
and add JkMountCopy All.

Regards,

Rainer


1. uriworkermap.properties -- not used

2. from apache2/httpd.conf:

LoadModule jk_module 

Re: /context not working -- mod_jk error: no match for /server-status

2009-09-03 Thread Rainer Jung
On 03.09.2009 20:24, Dennis Christopher wrote:
 Rainer,
 
 Trying your /sample/ I get the same result.
 
 The log appears to respond to that try but the lines are similar to
 those I originally posted from mod_jk.log.
 
 It's as though every context request is translated into '/server-status'.

Not very likely. Are those entries also appearing in times you are not
testing? If so those are someone else, and your own request isn't
handled by the Apache you are looking at. Can you find your request in
the access log?

Go through all config files and find out, what is configured about
/server-status. That URL doesn't have anything to do with mod_jk.

Regards,

Rainer

 the bracketed numbers are:
 
 [221:268597152] [debug] attempting to map URI '/server-status' from 5 maps.
 .
 .
 [221:268597152] [debug] attempting to map context URI
 '/sample/*.=JBOSS1*' source JKMount
 .
 .
 
 all the entries are marked [debug].
 
 221 is process httpd with user _www.
 
 Dennis
 
 On Sep 3, 2009, at 1:26 PM, Rainer Jung wrote:
 
 On 03.09.2009 19:15, Dennis Christopher wrote:
 The problem is that I am trying to support simple references to my
 context without the tomcat port explicitly included.

 example: myexample.com/sample should invoke the web-app sample.

 You don't have a JkMount for /sample, only one for /sample/*.
 What happens, if you point your browser to

 http://my.apache.name/sample/

 If it doesn't work, extract the lines from your mod_jk log, that refer
 to this request. Look for something like

 ... [A_NUMBER:ANOTHER_NUMBER] ... Attempting to map URI '/sample/'
 from ...

 Then note A_NUMBER:ANOTHER_NUMBER which are the process and thread id
 used for the request, and get all lines form the log, which have a
 timestamp close to your request and use the same IDs.

 Check whether there are any non-debug lines in there. If you can't see
 what goes wrong, post those lines.

 Regards,

 Rainer

 what happens instead: the browser tells me: file not found.

 looking at catalina.out it seems the request doesnt reach Tomcat at all.

 How I did it: he quick start guide at

 http://tomcat.apache.org/connectors-doc/generic_howto/quick.html

 gives a simple proof of concept for a context setup (/examples).

 which I have followed implicitly. I believe you have already seen what I
 have done with the config files I posted.

 Dennis

 P.S as it may be important - if I try example.com:8080/sample the main
 page of my web app loads but all of its subreferences, to gif images
 etc, are broken.


 On Sep 3, 2009, at 12:48 PM, Rainer Jung wrote:

 On 03.09.2009 15:34, Dennis Christopher wrote:
 Rainer,

 I am not sending /server-status explicitly.

 The mod_jk log which I excerpted earlier shows the processing of
 server-status before any context is asked for, apparently when Tomcat
 starts up.

 The log continues to repeat these entries - apparently mod_jk is
 looping
 trying to satisfy this context and never does.

 No I'm pretty sure this is not the case. I expect someone has a
 monitoring tool running or a browser windows with auto-refresh for
 /server-status and that's what produces those debug log lines in
 mod_jk.
 No problem per se.

 So back to the basic question: what is your problem? What are you
 trying
 to achieve, what did you do to make it work, how do you test it, what
 result do you expect and what happens instead?

 Regards,

 Rainer

 I added JkMountCopy All but this had no effect.

 Dennis
 On Sep 3, 2009, at 4:18 AM, Rainer Jung wrote:

 On 02.09.2009 21:45, Dennis Christopher wrote:
 Rainer,

 Thanks for the reply. I was confused in my orginal post: I am not
 using
 JBoss at all, only mod_jk.

 The file contents are as follows below.

 Apache has a hosts directory, but I'm not sure if the files matter.
 They
 are either the apache .default files or slight modifications of
 them,
 e.g. virtual_host_global.conf contains just:

 Listen *:80

 I don't understand, why you test this with a request /server-status.
 That doesn't make sense, because you don't want /server-status to be
 forwarded by mod_jk and in fact you didn't configure it.

 So choose a better URL to test (one of the URLs you have a JkMount
 for)
 and add JkMountCopy All.

 Regards,

 Rainer

 1. uriworkermap.properties -- not used

 2. from apache2/httpd.conf:

 LoadModule jk_module libexec/apache2/mod_jk.so
 .
 .
 IfModule mod_jk.c
  JKWorkersFile /etc/apache2/workers.properties
  JKLogFile /var/log/apache2/mod_jk.log
  JKLogLevel debug
  JKShmFile /var/log/apache2/mod_jk.shm
  JKMount /*.jsp JBoss1
  JKMount /servlet/* JBoss1
  JKMount /examples/* JBoss1
  JKMount /picturetalk/* JBoss1
  JKMount /sample/* JBoss1
 /IfModule
 .
 .

 3. from apache2/workers.properties:

 worker.list=JBoss1, JBoss2, loadbalancer, blojsomworker

 # 
 # First JBoss server
 # 
 worker.JBoss1.port=8009
 worker.JBoss1.host=127.0.0.1
 worker.JBoss1.type=ajp13

 # Specify the size of the 

Re: /context not working -- mod_jk error: no match for /server-status

2009-09-03 Thread Rainer Jung
On 02.09.2009 21:45, Dennis Christopher wrote:
 Rainer,
 
 Thanks for the reply. I was confused in my orginal post: I am not using
 JBoss at all, only mod_jk.
 
 The file contents are as follows below.
 
 Apache has a hosts directory, but I'm not sure if the files matter. They
 are either the apache .default files or slight modifications of them,
 e.g. virtual_host_global.conf contains just:
 
 Listen *:80

I don't understand, why you test this with a request /server-status.
That doesn't make sense, because you don't want /server-status to be
forwarded by mod_jk and in fact you didn't configure it.

So choose a better URL to test (one of the URLs you have a JkMount for)
and add JkMountCopy All.

Regards,

Rainer

 1. uriworkermap.properties -- not used
 
 2. from apache2/httpd.conf:
 
 LoadModule jk_module libexec/apache2/mod_jk.so
 .
 .
 IfModule mod_jk.c
 JKWorkersFile /etc/apache2/workers.properties
 JKLogFile /var/log/apache2/mod_jk.log
 JKLogLevel debug
 JKShmFile /var/log/apache2/mod_jk.shm
 JKMount /*.jsp JBoss1
 JKMount /servlet/* JBoss1
 JKMount /examples/* JBoss1
 JKMount /picturetalk/* JBoss1
 JKMount /sample/* JBoss1
 /IfModule
 .
 .
 
 3. from apache2/workers.properties:
 
 worker.list=JBoss1, JBoss2, loadbalancer, blojsomworker
 
 # 
 # First JBoss server
 # 
 worker.JBoss1.port=8009
 worker.JBoss1.host=127.0.0.1
 worker.JBoss1.type=ajp13
 
 # Specify the size of the open connection cache.
 #worker.JBoss1.cachesize
 
 #
 # Specifies the load balance factor when used with
 # a load balancing worker.
 # Note:
 #   lbfactor must be  0
 #   Low lbfactor means less work done by the worker.
 worker.JBoss1.lbfactor=100
 
 
 # 
 # Second JBoss server
 # 
 #worker.JBoss2.port=9008
 #worker.JBoss2.host=localhost
 worker.JBoss2.lbfactor=100
 
 
 # 
 # Load Balancer worker
 # 
 
 #
 # The loadbalancer (type lb) worker performs weighted round-robin
 # load balancing with sticky sessions.
 # Note:
 #   If a worker dies, the load balancer will check its state
 #once in a while. Until then all work is redirected to peer
 #worker.
 worker.loadbalancer.type=lb
 worker.loadbalancer.balanced_workers=JBoss1, JBoss2
 
 # 
 # Blojsom worker
 # 
 #
 # Worker created specifically for Blojsom.
 worker.blojsomworker.port=1279
 worker.blojsomworker.host=127.0.0.1
 worker.blojsomworker.type=ajp13
 worker.blojsomworker.lbfactor=100
 
 
 # END workers.properties
 #
 
 On Sep 2, 2009, at 2:05 PM, Rainer Jung wrote:
 
 On 27.08.2009 15:45, Dennis Christopher wrote:
 environment: Tomcat 6.0.18 under apache2 on Mac OS X Server 10.5
 (Leopard).

 I am using a mod_jk connector with JBoss.

 I am having trouble getting context urls of the form
 website.my.com/myapplication honoured (or even localhost/myapplication).
 (Safari:File not found).I have googled  the error messages below but
 can't find anything applicable to my setup.

 The quick start guide at

 http://tomcat.apache.org/connectors-doc/generic_howto/quick.html

 gives a simple proof of concept for a connector setup (/examples).
 However, this does not work,
 though I have followed the editing of the configuration files exactly
 (using JKMount in the httpd.conf etc)

 I get an error in mod_jk.log (set to debug level):

 [Tue Aug 25 12:41:11.783 2009] [211:2688784416] [debug]
 map_uri_to_worker_ext::jk_uri_worker_map.c (1036): (TEST) Attempting to
 map URI '/server-status' from 5 maps
 [Tue Aug 25 12:41:11.783 2009] [211:2688784416] [debug]
 map_uri_to_worker_ext::jk_uri_worker_map.c (1039): Initial match
 value:for URI '/server-status' is -1.
 [Tue Aug 25 12:41:11.783 2009] [211:2688784416] [debug]
 find_match::jk_uri_worker_map.c (850): Attempting to map context URI
 '/examples/*=JBoss1' source 'JkMount'
 [Tue Aug 25 12:41:11.783 2009] [211:2688784416] [debug]
 find_match::jk_uri_worker_map.c (850): Attempting to map context URI
 '/servlet/*=JBoss1' source 'JkMount'
 [Tue Aug 25 12:41:11.783 2009] [211:2688784416] [debug]
 find_match::jk_uri_worker_map.c (850): Attempting to map context URI
 '/sample/*=JBoss1' source 'JkMount'
 [Tue Aug 25 12:41:11.784 2009] [211:2688784416] [debug]
 find_match::jk_uri_worker_map.c (850): Attempting to map context URI
 '/*.jsp=JBoss1' source 'JkMount'
 [Tue Aug 25 12:41:11.784 2009] [211:2688784416] [debug]
 map_uri_to_worker_ext::jk_uri_worker_map.c (1047): Match value:for URI
 '/server-status' is -1.
 [Tue Aug 25 12:41:11.784 2009] [211:2688784416] [debug]
 jk_translate::mod_jk.c (3536): no match for /server-status found

 Any help on how to diagnose what the seeming error is pointing to would
 be much appreciated.

 This log snippet is not useful, because the request you used was for
 /server-status, which is most likely not a request you want 

Re: /context not working -- mod_jk error: no match for /server-status

2009-09-03 Thread Dennis Christopher

Rainer,

I am not sending /server-status explicitly.

The mod_jk log which I excerpted earlier shows the processing of  
server-status before any context is asked for, apparently when Tomcat  
starts up.


The log continues to repeat these entries - apparently mod_jk is  
looping trying to satisfy this context and never does.


I added JkMountCopy All but this had no effect.

Dennis
On Sep 3, 2009, at 4:18 AM, Rainer Jung wrote:


On 02.09.2009 21:45, Dennis Christopher wrote:

Rainer,

Thanks for the reply. I was confused in my orginal post: I am not  
using

JBoss at all, only mod_jk.

The file contents are as follows below.

Apache has a hosts directory, but I'm not sure if the files matter.  
They

are either the apache .default files or slight modifications of them,
e.g. virtual_host_global.conf contains just:

Listen *:80


I don't understand, why you test this with a request /server-status.
That doesn't make sense, because you don't want /server-status to be
forwarded by mod_jk and in fact you didn't configure it.

So choose a better URL to test (one of the URLs you have a JkMount  
for)

and add JkMountCopy All.

Regards,

Rainer


1. uriworkermap.properties -- not used

2. from apache2/httpd.conf:

LoadModule jk_module libexec/apache2/mod_jk.so
.
.
IfModule mod_jk.c
   JKWorkersFile /etc/apache2/workers.properties
   JKLogFile /var/log/apache2/mod_jk.log
   JKLogLevel debug
   JKShmFile /var/log/apache2/mod_jk.shm
   JKMount /*.jsp JBoss1
   JKMount /servlet/* JBoss1
   JKMount /examples/* JBoss1
   JKMount /picturetalk/* JBoss1
   JKMount /sample/* JBoss1
/IfModule
.
.

3. from apache2/workers.properties:

worker.list=JBoss1, JBoss2, loadbalancer, blojsomworker

# 
# First JBoss server
# 
worker.JBoss1.port=8009
worker.JBoss1.host=127.0.0.1
worker.JBoss1.type=ajp13

# Specify the size of the open connection cache.
#worker.JBoss1.cachesize

#
# Specifies the load balance factor when used with
# a load balancing worker.
# Note:
#   lbfactor must be  0
#   Low lbfactor means less work done by the worker.
worker.JBoss1.lbfactor=100


# 
# Second JBoss server
# 
#worker.JBoss2.port=9008
#worker.JBoss2.host=localhost
worker.JBoss2.lbfactor=100


# 
# Load Balancer worker
# 

#
# The loadbalancer (type lb) worker performs weighted round-robin
# load balancing with sticky sessions.
# Note:
#   If a worker dies, the load balancer will check its state
#once in a while. Until then all work is redirected to peer
#worker.
worker.loadbalancer.type=lb
worker.loadbalancer.balanced_workers=JBoss1, JBoss2

# 
# Blojsom worker
# 
#
# Worker created specifically for Blojsom.
worker.blojsomworker.port=1279
worker.blojsomworker.host=127.0.0.1
worker.blojsomworker.type=ajp13
worker.blojsomworker.lbfactor=100


# END workers.properties
#

On Sep 2, 2009, at 2:05 PM, Rainer Jung wrote:


On 27.08.2009 15:45, Dennis Christopher wrote:

environment: Tomcat 6.0.18 under apache2 on Mac OS X Server 10.5
(Leopard).

I am using a mod_jk connector with JBoss.

I am having trouble getting context urls of the form
website.my.com/myapplication honoured (or even localhost/ 
myapplication).
(Safari:File not found).I have googled  the error messages below  
but

can't find anything applicable to my setup.

The quick start guide at

http://tomcat.apache.org/connectors-doc/generic_howto/quick.html

gives a simple proof of concept for a connector setup (/examples).
However, this does not work,
though I have followed the editing of the configuration files  
exactly

(using JKMount in the httpd.conf etc)

I get an error in mod_jk.log (set to debug level):

[Tue Aug 25 12:41:11.783 2009] [211:2688784416] [debug]
map_uri_to_worker_ext::jk_uri_worker_map.c (1036): (TEST)  
Attempting to

map URI '/server-status' from 5 maps
[Tue Aug 25 12:41:11.783 2009] [211:2688784416] [debug]
map_uri_to_worker_ext::jk_uri_worker_map.c (1039): Initial match
value:for URI '/server-status' is -1.
[Tue Aug 25 12:41:11.783 2009] [211:2688784416] [debug]
find_match::jk_uri_worker_map.c (850): Attempting to map context  
URI

'/examples/*=JBoss1' source 'JkMount'
[Tue Aug 25 12:41:11.783 2009] [211:2688784416] [debug]
find_match::jk_uri_worker_map.c (850): Attempting to map context  
URI

'/servlet/*=JBoss1' source 'JkMount'
[Tue Aug 25 12:41:11.783 2009] [211:2688784416] [debug]
find_match::jk_uri_worker_map.c (850): Attempting to map context  
URI

'/sample/*=JBoss1' source 'JkMount'
[Tue Aug 25 12:41:11.784 2009] [211:2688784416] [debug]
find_match::jk_uri_worker_map.c (850): Attempting to map context  
URI

'/*.jsp=JBoss1' source 'JkMount'
[Tue Aug 25 12:41:11.784 2009] [211:2688784416] [debug]
map_uri_to_worker_ext::jk_uri_worker_map.c (1047): Match  
value:for URI

'/server-status' is -1.
[Tue Aug 25 

Re: /context not working -- mod_jk error: no match for /server-status

2009-09-03 Thread Rainer Jung
On 03.09.2009 15:34, Dennis Christopher wrote:
 Rainer,
 
 I am not sending /server-status explicitly.
 
 The mod_jk log which I excerpted earlier shows the processing of
 server-status before any context is asked for, apparently when Tomcat
 starts up.
 
 The log continues to repeat these entries - apparently mod_jk is looping
 trying to satisfy this context and never does.

No I'm pretty sure this is not the case. I expect someone has a
monitoring tool running or a browser windows with auto-refresh for
/server-status and that's what produces those debug log lines in mod_jk.
No problem per se.

So back to the basic question: what is your problem? What are you trying
to achieve, what did you do to make it work, how do you test it, what
result do you expect and what happens instead?

Regards,

Rainer

 I added JkMountCopy All but this had no effect.
 
 Dennis
 On Sep 3, 2009, at 4:18 AM, Rainer Jung wrote:
 
 On 02.09.2009 21:45, Dennis Christopher wrote:
 Rainer,

 Thanks for the reply. I was confused in my orginal post: I am not using
 JBoss at all, only mod_jk.

 The file contents are as follows below.

 Apache has a hosts directory, but I'm not sure if the files matter. They
 are either the apache .default files or slight modifications of them,
 e.g. virtual_host_global.conf contains just:

 Listen *:80

 I don't understand, why you test this with a request /server-status.
 That doesn't make sense, because you don't want /server-status to be
 forwarded by mod_jk and in fact you didn't configure it.

 So choose a better URL to test (one of the URLs you have a JkMount for)
 and add JkMountCopy All.

 Regards,

 Rainer

 1. uriworkermap.properties -- not used

 2. from apache2/httpd.conf:

 LoadModule jk_module libexec/apache2/mod_jk.so
 .
 .
 IfModule mod_jk.c
JKWorkersFile /etc/apache2/workers.properties
JKLogFile /var/log/apache2/mod_jk.log
JKLogLevel debug
JKShmFile /var/log/apache2/mod_jk.shm
JKMount /*.jsp JBoss1
JKMount /servlet/* JBoss1
JKMount /examples/* JBoss1
JKMount /picturetalk/* JBoss1
JKMount /sample/* JBoss1
 /IfModule
 .
 .

 3. from apache2/workers.properties:

 worker.list=JBoss1, JBoss2, loadbalancer, blojsomworker

 # 
 # First JBoss server
 # 
 worker.JBoss1.port=8009
 worker.JBoss1.host=127.0.0.1
 worker.JBoss1.type=ajp13

 # Specify the size of the open connection cache.
 #worker.JBoss1.cachesize

 #
 # Specifies the load balance factor when used with
 # a load balancing worker.
 # Note:
 #   lbfactor must be  0
 #   Low lbfactor means less work done by the worker.
 worker.JBoss1.lbfactor=100


 # 
 # Second JBoss server
 # 
 #worker.JBoss2.port=9008
 #worker.JBoss2.host=localhost
 worker.JBoss2.lbfactor=100


 # 
 # Load Balancer worker
 # 

 #
 # The loadbalancer (type lb) worker performs weighted round-robin
 # load balancing with sticky sessions.
 # Note:
 #   If a worker dies, the load balancer will check its state
 #once in a while. Until then all work is redirected to peer
 #worker.
 worker.loadbalancer.type=lb
 worker.loadbalancer.balanced_workers=JBoss1, JBoss2

 # 
 # Blojsom worker
 # 
 #
 # Worker created specifically for Blojsom.
 worker.blojsomworker.port=1279
 worker.blojsomworker.host=127.0.0.1
 worker.blojsomworker.type=ajp13
 worker.blojsomworker.lbfactor=100


 # END workers.properties
 #

 On Sep 2, 2009, at 2:05 PM, Rainer Jung wrote:

 On 27.08.2009 15:45, Dennis Christopher wrote:
 environment: Tomcat 6.0.18 under apache2 on Mac OS X Server 10.5
 (Leopard).

 I am using a mod_jk connector with JBoss.

 I am having trouble getting context urls of the form
 website.my.com/myapplication honoured (or even
 localhost/myapplication).
 (Safari:File not found).I have googled  the error messages below but
 can't find anything applicable to my setup.

 The quick start guide at

 http://tomcat.apache.org/connectors-doc/generic_howto/quick.html

 gives a simple proof of concept for a connector setup (/examples).
 However, this does not work,
 though I have followed the editing of the configuration files exactly
 (using JKMount in the httpd.conf etc)

 I get an error in mod_jk.log (set to debug level):

 [Tue Aug 25 12:41:11.783 2009] [211:2688784416] [debug]
 map_uri_to_worker_ext::jk_uri_worker_map.c (1036): (TEST)
 Attempting to
 map URI '/server-status' from 5 maps
 [Tue Aug 25 12:41:11.783 2009] [211:2688784416] [debug]
 map_uri_to_worker_ext::jk_uri_worker_map.c (1039): Initial match
 value:for URI '/server-status' is -1.
 [Tue Aug 25 12:41:11.783 2009] [211:2688784416] [debug]
 find_match::jk_uri_worker_map.c (850): Attempting to map context URI
 '/examples/*=JBoss1' source 'JkMount'
 [Tue Aug 25 12:41:11.783 2009] [211:2688784416] [debug]
 find_match::jk_uri_worker_map.c 

Re: /context not working -- mod_jk error: no match for /server-status

2009-09-03 Thread Dennis Christopher

Rainer,

The problem is that I am trying to support simple references to my  
context without the tomcat port explicitly included.


example: myexample.com/sample should invoke the web-app sample.

what happens instead: the browser tells me: file not found.

looking at catalina.out it seems the request doesnt reach Tomcat at all.

How I did it: he quick start guide at

http://tomcat.apache.org/connectors-doc/generic_howto/quick.html

gives a simple proof of concept for a context setup (/examples).

which I have followed implicitly. I believe you have already seen what  
I have done with the config files I posted.


Dennis

P.S as it may be important - if I try example.com:8080/sample the main  
page of my web app loads but all of its subreferences, to gif images  
etc, are broken.



On Sep 3, 2009, at 12:48 PM, Rainer Jung wrote:


On 03.09.2009 15:34, Dennis Christopher wrote:

Rainer,

I am not sending /server-status explicitly.

The mod_jk log which I excerpted earlier shows the processing of
server-status before any context is asked for, apparently when Tomcat
starts up.

The log continues to repeat these entries - apparently mod_jk is  
looping

trying to satisfy this context and never does.


No I'm pretty sure this is not the case. I expect someone has a
monitoring tool running or a browser windows with auto-refresh for
/server-status and that's what produces those debug log lines in  
mod_jk.

No problem per se.

So back to the basic question: what is your problem? What are you  
trying

to achieve, what did you do to make it work, how do you test it, what
result do you expect and what happens instead?

Regards,

Rainer


I added JkMountCopy All but this had no effect.

Dennis
On Sep 3, 2009, at 4:18 AM, Rainer Jung wrote:


On 02.09.2009 21:45, Dennis Christopher wrote:

Rainer,

Thanks for the reply. I was confused in my orginal post: I am not  
using

JBoss at all, only mod_jk.

The file contents are as follows below.

Apache has a hosts directory, but I'm not sure if the files  
matter. They
are either the apache .default files or slight modifications of  
them,

e.g. virtual_host_global.conf contains just:

Listen *:80


I don't understand, why you test this with a request /server-status.
That doesn't make sense, because you don't want /server-status to be
forwarded by mod_jk and in fact you didn't configure it.

So choose a better URL to test (one of the URLs you have a JkMount  
for)

and add JkMountCopy All.

Regards,

Rainer


1. uriworkermap.properties -- not used

2. from apache2/httpd.conf:

LoadModule jk_module libexec/apache2/mod_jk.so
.
.
IfModule mod_jk.c
  JKWorkersFile /etc/apache2/workers.properties
  JKLogFile /var/log/apache2/mod_jk.log
  JKLogLevel debug
  JKShmFile /var/log/apache2/mod_jk.shm
  JKMount /*.jsp JBoss1
  JKMount /servlet/* JBoss1
  JKMount /examples/* JBoss1
  JKMount /picturetalk/* JBoss1
  JKMount /sample/* JBoss1
/IfModule
.
.

3. from apache2/workers.properties:

worker.list=JBoss1, JBoss2, loadbalancer, blojsomworker

# 
# First JBoss server
# 
worker.JBoss1.port=8009
worker.JBoss1.host=127.0.0.1
worker.JBoss1.type=ajp13

# Specify the size of the open connection cache.
#worker.JBoss1.cachesize

#
# Specifies the load balance factor when used with
# a load balancing worker.
# Note:
#   lbfactor must be  0
#   Low lbfactor means less work done by the worker.
worker.JBoss1.lbfactor=100


# 
# Second JBoss server
# 
#worker.JBoss2.port=9008
#worker.JBoss2.host=localhost
worker.JBoss2.lbfactor=100


# 
# Load Balancer worker
# 

#
# The loadbalancer (type lb) worker performs weighted round-robin
# load balancing with sticky sessions.
# Note:
#   If a worker dies, the load balancer will check its state
#once in a while. Until then all work is redirected to peer
#worker.
worker.loadbalancer.type=lb
worker.loadbalancer.balanced_workers=JBoss1, JBoss2

# 
# Blojsom worker
# 
#
# Worker created specifically for Blojsom.
worker.blojsomworker.port=1279
worker.blojsomworker.host=127.0.0.1
worker.blojsomworker.type=ajp13
worker.blojsomworker.lbfactor=100


# END workers.properties
#

On Sep 2, 2009, at 2:05 PM, Rainer Jung wrote:


On 27.08.2009 15:45, Dennis Christopher wrote:

environment: Tomcat 6.0.18 under apache2 on Mac OS X Server 10.5
(Leopard).

I am using a mod_jk connector with JBoss.

I am having trouble getting context urls of the form
website.my.com/myapplication honoured (or even
localhost/myapplication).
(Safari:File not found).I have googled  the error messages  
below but

can't find anything applicable to my setup.

The quick start guide at

http://tomcat.apache.org/connectors-doc/generic_howto/quick.html

gives a simple proof of concept for a connector setup (/ 
examples).

However, this does not 

Re: /context not working -- mod_jk error: no match for /server-status

2009-09-03 Thread Rainer Jung
On 03.09.2009 19:15, Dennis Christopher wrote:
 The problem is that I am trying to support simple references to my
 context without the tomcat port explicitly included.
 
 example: myexample.com/sample should invoke the web-app sample.

You don't have a JkMount for /sample, only one for /sample/*.
What happens, if you point your browser to

http://my.apache.name/sample/

If it doesn't work, extract the lines from your mod_jk log, that refer
to this request. Look for something like

... [A_NUMBER:ANOTHER_NUMBER] ... Attempting to map URI '/sample/' from ...

Then note A_NUMBER:ANOTHER_NUMBER which are the process and thread id
used for the request, and get all lines form the log, which have a
timestamp close to your request and use the same IDs.

Check whether there are any non-debug lines in there. If you can't see
what goes wrong, post those lines.

Regards,

Rainer

 what happens instead: the browser tells me: file not found.
 
 looking at catalina.out it seems the request doesnt reach Tomcat at all.
 
 How I did it: he quick start guide at
 
 http://tomcat.apache.org/connectors-doc/generic_howto/quick.html
 
 gives a simple proof of concept for a context setup (/examples).
 
 which I have followed implicitly. I believe you have already seen what I
 have done with the config files I posted.
 
 Dennis
 
 P.S as it may be important - if I try example.com:8080/sample the main
 page of my web app loads but all of its subreferences, to gif images
 etc, are broken.
 
 
 On Sep 3, 2009, at 12:48 PM, Rainer Jung wrote:
 
 On 03.09.2009 15:34, Dennis Christopher wrote:
 Rainer,

 I am not sending /server-status explicitly.

 The mod_jk log which I excerpted earlier shows the processing of
 server-status before any context is asked for, apparently when Tomcat
 starts up.

 The log continues to repeat these entries - apparently mod_jk is looping
 trying to satisfy this context and never does.

 No I'm pretty sure this is not the case. I expect someone has a
 monitoring tool running or a browser windows with auto-refresh for
 /server-status and that's what produces those debug log lines in mod_jk.
 No problem per se.

 So back to the basic question: what is your problem? What are you trying
 to achieve, what did you do to make it work, how do you test it, what
 result do you expect and what happens instead?

 Regards,

 Rainer

 I added JkMountCopy All but this had no effect.

 Dennis
 On Sep 3, 2009, at 4:18 AM, Rainer Jung wrote:

 On 02.09.2009 21:45, Dennis Christopher wrote:
 Rainer,

 Thanks for the reply. I was confused in my orginal post: I am not using
 JBoss at all, only mod_jk.

 The file contents are as follows below.

 Apache has a hosts directory, but I'm not sure if the files matter.
 They
 are either the apache .default files or slight modifications of them,
 e.g. virtual_host_global.conf contains just:

 Listen *:80

 I don't understand, why you test this with a request /server-status.
 That doesn't make sense, because you don't want /server-status to be
 forwarded by mod_jk and in fact you didn't configure it.

 So choose a better URL to test (one of the URLs you have a JkMount for)
 and add JkMountCopy All.

 Regards,

 Rainer

 1. uriworkermap.properties -- not used

 2. from apache2/httpd.conf:

 LoadModule jk_module libexec/apache2/mod_jk.so
 .
 .
 IfModule mod_jk.c
   JKWorkersFile /etc/apache2/workers.properties
   JKLogFile /var/log/apache2/mod_jk.log
   JKLogLevel debug
   JKShmFile /var/log/apache2/mod_jk.shm
   JKMount /*.jsp JBoss1
   JKMount /servlet/* JBoss1
   JKMount /examples/* JBoss1
   JKMount /picturetalk/* JBoss1
   JKMount /sample/* JBoss1
 /IfModule
 .
 .

 3. from apache2/workers.properties:

 worker.list=JBoss1, JBoss2, loadbalancer, blojsomworker

 # 
 # First JBoss server
 # 
 worker.JBoss1.port=8009
 worker.JBoss1.host=127.0.0.1
 worker.JBoss1.type=ajp13

 # Specify the size of the open connection cache.
 #worker.JBoss1.cachesize

 #
 # Specifies the load balance factor when used with
 # a load balancing worker.
 # Note:
 #   lbfactor must be  0
 #   Low lbfactor means less work done by the worker.
 worker.JBoss1.lbfactor=100


 # 
 # Second JBoss server
 # 
 #worker.JBoss2.port=9008
 #worker.JBoss2.host=localhost
 worker.JBoss2.lbfactor=100


 # 
 # Load Balancer worker
 # 

 #
 # The loadbalancer (type lb) worker performs weighted round-robin
 # load balancing with sticky sessions.
 # Note:
 #   If a worker dies, the load balancer will check its state
 #once in a while. Until then all work is redirected to peer
 #worker.
 worker.loadbalancer.type=lb
 worker.loadbalancer.balanced_workers=JBoss1, JBoss2

 # 
 # Blojsom worker
 # 
 #
 # Worker created specifically for Blojsom.
 worker.blojsomworker.port=1279
 

Re: /context not working -- mod_jk error: no match for /server-status

2009-09-03 Thread Dennis Christopher

Rainer,

Trying your /sample/ I get the same result.

The log appears to respond to that try but the lines are similar to  
those I originally posted from mod_jk.log.


It's as though every context request is translated into '/server- 
status'.


the bracketed numbers are:

[221:268597152] [debug] attempting to map URI '/server-status' from 5  
maps.

.
.
[221:268597152] [debug] attempting to map context URI '/sample/ 
*.=JBOSS1*' source JKMount

.
.

all the entries are marked [debug].

221 is process httpd with user _www.

Dennis

On Sep 3, 2009, at 1:26 PM, Rainer Jung wrote:


On 03.09.2009 19:15, Dennis Christopher wrote:

The problem is that I am trying to support simple references to my
context without the tomcat port explicitly included.

example: myexample.com/sample should invoke the web-app sample.


You don't have a JkMount for /sample, only one for /sample/*.
What happens, if you point your browser to

http://my.apache.name/sample/

If it doesn't work, extract the lines from your mod_jk log, that refer
to this request. Look for something like

... [A_NUMBER:ANOTHER_NUMBER] ... Attempting to map URI '/sample/'  
from ...


Then note A_NUMBER:ANOTHER_NUMBER which are the process and thread id
used for the request, and get all lines form the log, which have a
timestamp close to your request and use the same IDs.

Check whether there are any non-debug lines in there. If you can't see
what goes wrong, post those lines.

Regards,

Rainer


what happens instead: the browser tells me: file not found.

looking at catalina.out it seems the request doesnt reach Tomcat at  
all.


How I did it: he quick start guide at

http://tomcat.apache.org/connectors-doc/generic_howto/quick.html

gives a simple proof of concept for a context setup (/examples).

which I have followed implicitly. I believe you have already seen  
what I

have done with the config files I posted.

Dennis

P.S as it may be important - if I try example.com:8080/sample the  
main

page of my web app loads but all of its subreferences, to gif images
etc, are broken.


On Sep 3, 2009, at 12:48 PM, Rainer Jung wrote:


On 03.09.2009 15:34, Dennis Christopher wrote:

Rainer,

I am not sending /server-status explicitly.

The mod_jk log which I excerpted earlier shows the processing of
server-status before any context is asked for, apparently when  
Tomcat

starts up.

The log continues to repeat these entries - apparently mod_jk is  
looping

trying to satisfy this context and never does.


No I'm pretty sure this is not the case. I expect someone has a
monitoring tool running or a browser windows with auto-refresh for
/server-status and that's what produces those debug log lines in  
mod_jk.

No problem per se.

So back to the basic question: what is your problem? What are you  
trying
to achieve, what did you do to make it work, how do you test it,  
what

result do you expect and what happens instead?

Regards,

Rainer


I added JkMountCopy All but this had no effect.

Dennis
On Sep 3, 2009, at 4:18 AM, Rainer Jung wrote:


On 02.09.2009 21:45, Dennis Christopher wrote:

Rainer,

Thanks for the reply. I was confused in my orginal post: I am  
not using

JBoss at all, only mod_jk.

The file contents are as follows below.

Apache has a hosts directory, but I'm not sure if the files  
matter.

They
are either the apache .default files or slight modifications of  
them,

e.g. virtual_host_global.conf contains just:

Listen *:80


I don't understand, why you test this with a request /server- 
status.
That doesn't make sense, because you don't want /server-status  
to be

forwarded by mod_jk and in fact you didn't configure it.

So choose a better URL to test (one of the URLs you have a  
JkMount for)

and add JkMountCopy All.

Regards,

Rainer


1. uriworkermap.properties -- not used

2. from apache2/httpd.conf:

LoadModule jk_module libexec/apache2/mod_jk.so
.
.
IfModule mod_jk.c
 JKWorkersFile /etc/apache2/workers.properties
 JKLogFile /var/log/apache2/mod_jk.log
 JKLogLevel debug
 JKShmFile /var/log/apache2/mod_jk.shm
 JKMount /*.jsp JBoss1
 JKMount /servlet/* JBoss1
 JKMount /examples/* JBoss1
 JKMount /picturetalk/* JBoss1
 JKMount /sample/* JBoss1
/IfModule
.
.

3. from apache2/workers.properties:

worker.list=JBoss1, JBoss2, loadbalancer, blojsomworker

# 
# First JBoss server
# 
worker.JBoss1.port=8009
worker.JBoss1.host=127.0.0.1
worker.JBoss1.type=ajp13

# Specify the size of the open connection cache.
#worker.JBoss1.cachesize

#
# Specifies the load balance factor when used with
# a load balancing worker.
# Note:
#   lbfactor must be  0
#   Low lbfactor means less work done by the worker.
worker.JBoss1.lbfactor=100


# 
# Second JBoss server
# 
#worker.JBoss2.port=9008
#worker.JBoss2.host=localhost
worker.JBoss2.lbfactor=100


# 
# Load Balancer worker
# 

Re: /context not working -- mod_jk error: no match for /server-status

2009-09-02 Thread Rainer Jung
On 27.08.2009 15:45, Dennis Christopher wrote:
 environment: Tomcat 6.0.18 under apache2 on Mac OS X Server 10.5 (Leopard).
 
 I am using a mod_jk connector with JBoss.
 
 I am having trouble getting context urls of the form
 website.my.com/myapplication honoured (or even localhost/myapplication).
 (Safari:File not found).I have googled  the error messages below but
 can't find anything applicable to my setup.
 
 The quick start guide at
 
 http://tomcat.apache.org/connectors-doc/generic_howto/quick.html
 
 gives a simple proof of concept for a connector setup (/examples).
 However, this does not work,
 though I have followed the editing of the configuration files exactly
 (using JKMount in the httpd.conf etc)
 
 I get an error in mod_jk.log (set to debug level):
 
 [Tue Aug 25 12:41:11.783 2009] [211:2688784416] [debug]
 map_uri_to_worker_ext::jk_uri_worker_map.c (1036): (TEST) Attempting to
 map URI '/server-status' from 5 maps
 [Tue Aug 25 12:41:11.783 2009] [211:2688784416] [debug]
 map_uri_to_worker_ext::jk_uri_worker_map.c (1039): Initial match
 value:for URI '/server-status' is -1.
 [Tue Aug 25 12:41:11.783 2009] [211:2688784416] [debug]
 find_match::jk_uri_worker_map.c (850): Attempting to map context URI
 '/examples/*=JBoss1' source 'JkMount'
 [Tue Aug 25 12:41:11.783 2009] [211:2688784416] [debug]
 find_match::jk_uri_worker_map.c (850): Attempting to map context URI
 '/servlet/*=JBoss1' source 'JkMount'
 [Tue Aug 25 12:41:11.783 2009] [211:2688784416] [debug]
 find_match::jk_uri_worker_map.c (850): Attempting to map context URI
 '/sample/*=JBoss1' source 'JkMount'
 [Tue Aug 25 12:41:11.784 2009] [211:2688784416] [debug]
 find_match::jk_uri_worker_map.c (850): Attempting to map context URI
 '/*.jsp=JBoss1' source 'JkMount'
 [Tue Aug 25 12:41:11.784 2009] [211:2688784416] [debug]
 map_uri_to_worker_ext::jk_uri_worker_map.c (1047): Match value:for URI
 '/server-status' is -1.
 [Tue Aug 25 12:41:11.784 2009] [211:2688784416] [debug]
 jk_translate::mod_jk.c (3536): no match for /server-status found
 
 Any help on how to diagnose what the seeming error is pointing to would
 be much appreciated.

This log snippet is not useful, because the request you used was for
/server-status, which is most likely not a request you want mod_jk to
send to JBoss.

Please post all your JK directives from your httpd.conf and the files
included in that. Also post your workers.properties, and if you use it
the uriworkermap.properties file.

The most common cause why simple setups do not work is the use of
virtual hosts in the Apache configuration. If you have virtual hosts,
you have to put JkMount into the virtual hosts, or you set JkMountCopy
All in the global part of the configuration.

Regards,

Rainer

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: /context not working -- mod_jk error: no match for /server-status

2009-09-02 Thread Dennis Christopher

Rainer,

Thanks for the reply. I was confused in my orginal post: I am not  
using JBoss at all, only mod_jk.


The file contents are as follows below.

Apache has a hosts directory, but I'm not sure if the files matter.  
They are either the apache .default files or slight modifications of  
them,

e.g. virtual_host_global.conf contains just:

Listen *:80

Dennis


1. uriworkermap.properties -- not used

2. from apache2/httpd.conf:

LoadModule jk_module libexec/apache2/mod_jk.so
.
.
IfModule mod_jk.c
JKWorkersFile /etc/apache2/workers.properties
JKLogFile /var/log/apache2/mod_jk.log
JKLogLevel debug
JKShmFile /var/log/apache2/mod_jk.shm
JKMount /*.jsp JBoss1
JKMount /servlet/* JBoss1
JKMount /examples/* JBoss1
JKMount /picturetalk/* JBoss1
JKMount /sample/* JBoss1
/IfModule
.
.

3. from apache2/workers.properties:

worker.list=JBoss1, JBoss2, loadbalancer, blojsomworker

# 
# First JBoss server
# 
worker.JBoss1.port=8009
worker.JBoss1.host=127.0.0.1
worker.JBoss1.type=ajp13

# Specify the size of the open connection cache.
#worker.JBoss1.cachesize

#
# Specifies the load balance factor when used with
# a load balancing worker.
# Note:
#   lbfactor must be  0
#   Low lbfactor means less work done by the worker.
worker.JBoss1.lbfactor=100


# 
# Second JBoss server
# 
#worker.JBoss2.port=9008
#worker.JBoss2.host=localhost
worker.JBoss2.lbfactor=100


# 
# Load Balancer worker
# 

#
# The loadbalancer (type lb) worker performs weighted round-robin
# load balancing with sticky sessions.
# Note:
#   If a worker dies, the load balancer will check its state
#once in a while. Until then all work is redirected to peer
#worker.
worker.loadbalancer.type=lb
worker.loadbalancer.balanced_workers=JBoss1, JBoss2

# 
# Blojsom worker
# 
#
# Worker created specifically for Blojsom.
worker.blojsomworker.port=1279
worker.blojsomworker.host=127.0.0.1
worker.blojsomworker.type=ajp13
worker.blojsomworker.lbfactor=100


# END workers.properties
#

On Sep 2, 2009, at 2:05 PM, Rainer Jung wrote:


On 27.08.2009 15:45, Dennis Christopher wrote:
environment: Tomcat 6.0.18 under apache2 on Mac OS X Server 10.5  
(Leopard).


I am using a mod_jk connector with JBoss.

I am having trouble getting context urls of the form
website.my.com/myapplication honoured (or even localhost/ 
myapplication).

(Safari:File not found).I have googled  the error messages below but
can't find anything applicable to my setup.

The quick start guide at

http://tomcat.apache.org/connectors-doc/generic_howto/quick.html

gives a simple proof of concept for a connector setup (/examples).
However, this does not work,
though I have followed the editing of the configuration files exactly
(using JKMount in the httpd.conf etc)

I get an error in mod_jk.log (set to debug level):

[Tue Aug 25 12:41:11.783 2009] [211:2688784416] [debug]
map_uri_to_worker_ext::jk_uri_worker_map.c (1036): (TEST)  
Attempting to

map URI '/server-status' from 5 maps
[Tue Aug 25 12:41:11.783 2009] [211:2688784416] [debug]
map_uri_to_worker_ext::jk_uri_worker_map.c (1039): Initial match
value:for URI '/server-status' is -1.
[Tue Aug 25 12:41:11.783 2009] [211:2688784416] [debug]
find_match::jk_uri_worker_map.c (850): Attempting to map context URI
'/examples/*=JBoss1' source 'JkMount'
[Tue Aug 25 12:41:11.783 2009] [211:2688784416] [debug]
find_match::jk_uri_worker_map.c (850): Attempting to map context URI
'/servlet/*=JBoss1' source 'JkMount'
[Tue Aug 25 12:41:11.783 2009] [211:2688784416] [debug]
find_match::jk_uri_worker_map.c (850): Attempting to map context URI
'/sample/*=JBoss1' source 'JkMount'
[Tue Aug 25 12:41:11.784 2009] [211:2688784416] [debug]
find_match::jk_uri_worker_map.c (850): Attempting to map context URI
'/*.jsp=JBoss1' source 'JkMount'
[Tue Aug 25 12:41:11.784 2009] [211:2688784416] [debug]
map_uri_to_worker_ext::jk_uri_worker_map.c (1047): Match value:for  
URI

'/server-status' is -1.
[Tue Aug 25 12:41:11.784 2009] [211:2688784416] [debug]
jk_translate::mod_jk.c (3536): no match for /server-status found

Any help on how to diagnose what the seeming error is pointing to  
would

be much appreciated.


This log snippet is not useful, because the request you used was for
/server-status, which is most likely not a request you want mod_jk to
send to JBoss.

Please post all your JK directives from your httpd.conf and the files
included in that. Also post your workers.properties, and if you use it
the uriworkermap.properties file.

The most common cause why simple setups do not work is the use of
virtual hosts in the Apache configuration. If you have virtual hosts,
you have to put JkMount into the virtual hosts, or you set  
JkMountCopy

All in the global part of the configuration.


mod_jk error

2009-08-28 Thread Dennis Christopher
environment: Tomcat 6.0.18 under apache2 on Mac OS X Server 10.5  
(Leopard).


My mod_jk error log set to debug level tells me

Attempting to map URI /server-status

then

no match for server-status found

Anyone know if this error matters, and if so where the URI server- 
status is coming from?


Dennis Christopher

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



/context not working -- mod_jk error: no match for /server-status

2009-08-27 Thread Dennis Christopher
environment: Tomcat 6.0.18 under apache2 on Mac OS X Server 10.5  
(Leopard).


I am using a mod_jk connector with JBoss.

I am having trouble getting context urls of the form website.my.com/ 
myapplication honoured (or even localhost/myapplication).
(Safari:File not found).I have googled  the error messages below but  
can't find anything applicable to my setup.


The quick start guide at

http://tomcat.apache.org/connectors-doc/generic_howto/quick.html

gives a simple proof of concept for a connector setup (/examples).  
However, this does not work,
though I have followed the editing of the configuration files exactly  
(using JKMount in the httpd.conf etc)


I get an error in mod_jk.log (set to debug level):

[Tue Aug 25 12:41:11.783 2009] [211:2688784416] [debug]  
map_uri_to_worker_ext::jk_uri_worker_map.c (1036): (TEST) Attempting  
to map URI '/server-status' from 5 maps
[Tue Aug 25 12:41:11.783 2009] [211:2688784416] [debug]  
map_uri_to_worker_ext::jk_uri_worker_map.c (1039): Initial match  
value:for URI '/server-status' is -1.
[Tue Aug 25 12:41:11.783 2009] [211:2688784416] [debug]  
find_match::jk_uri_worker_map.c (850): Attempting to map context URI '/ 
examples/*=JBoss1' source 'JkMount'
[Tue Aug 25 12:41:11.783 2009] [211:2688784416] [debug]  
find_match::jk_uri_worker_map.c (850): Attempting to map context URI '/ 
servlet/*=JBoss1' source 'JkMount'
[Tue Aug 25 12:41:11.783 2009] [211:2688784416] [debug]  
find_match::jk_uri_worker_map.c (850): Attempting to map context URI '/ 
sample/*=JBoss1' source 'JkMount'
[Tue Aug 25 12:41:11.784 2009] [211:2688784416] [debug]  
find_match::jk_uri_worker_map.c (850): Attempting to map context URI '/ 
*.jsp=JBoss1' source 'JkMount'
[Tue Aug 25 12:41:11.784 2009] [211:2688784416] [debug]  
map_uri_to_worker_ext::jk_uri_worker_map.c (1047): Match value:for URI  
'/server-status' is -1.
[Tue Aug 25 12:41:11.784 2009] [211:2688784416] [debug]  
jk_translate::mod_jk.c (3536): no match for /server-status found


Any help on how to diagnose what the seeming error is pointing to  
would be much appreciated.


Dennis Christopher

RE: /context not working -- mod_jk error: no match for /server-status

2009-08-27 Thread Martin Gainty

JBOSS ajp connector  is org.mortbay.http.ajp.AJP13Listener

from jboss docs you will need to config jboss-service.xml
5.  In jboss_home/server/all/deploy/jbossweb.sar/META-INF/jboss-service.xml, 
edit the following:
-
Under the Configure the Request Listeners section, look for the add
listener call of org.mortbay.http.SocketListener and change the port
setting line to (8080 is the default):
Set name=PortSystemProperty name=jetty.port default=18080//Set
-
Under the Configure the Request Listeners section, look for the add
listener call of org.mortbay.http.ajp.AJP13Listener and change the
port setting line to (8009 is the default):
Set name=Port18009/Set
- Also the call org.mortbay.http.ajp.AJP13Listener, change the port setting 
line to (443 is the default):
Set name=confidentialPort1443/Set
For JBoss 3.2.0, do these steps (contributed by Anantha Krishnan V):
5.a In 
jboss_home/server/all/deploy/jbossweb-jetty.sar/META-INF/jboss-service.xml, 
edit the following:
- Do the same as above, since the .sar was renamed.
For JBoss 3.2.1 with Tomcat, do these steps:
5.b In 
jboss_home/server/all/deploy/jbossweb-tomcat.sar/META-INF/jboss-service.xml, 
edit the following:
-
Under the Configure the Request Listeners section, look for the add
listener call of org.apache.coyote.tomcat4.CoyoteConnector and change
the port setting line to (8080 is the default):
!--
A HTTP/1.1 Connector on port 18080 --Connector
className=org.apache.coyote.tomcat4.CoyoteConnector   
port=18080 minProcessors=3 maxProcessors=10   
enableLookups=true acceptCount=10 debug=0   
connectionTimeout=2 useURIValidationHack=false /
 - Also the AJP 1.3 Connector, change the port setting line to (8009 and 8443 
are the defaults):
!--
A AJP 1.3 Connector on port 18009 --Connector
className=org.apache.coyote.tomcat4.CoyoteConnector   
port=18009 minProcessors=5 maxProcessors=75
enableLookups=true redirectPort=18443   
acceptCount=10 debug=0 connectionTimeout=2   
useURIValidationHack=false   
protocolHandlerClassName=org.apache.jk.server.JkCoyoteHandler/
ajp13 configuration spec is located at
http://www.jboss.org/community/wiki/ConfigurePorts

Martin Gainty 
__ 
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
 
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger 
sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung 
oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem 
Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. 
Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung 
fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le 
destinataire prévu, nous te demandons avec bonté que pour satisfaire informez 
l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est 
interdite. Ce message sert à l'information seulement et n'aura pas n'importe 
quel effet légalement obligatoire. Étant donné que les email peuvent facilement 
être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité 
pour le contenu fourni.




 From: dchristop...@pixion.com
 To: users@tomcat.apache.org
 Subject: /context not working -- mod_jk error: no match for /server-status
 Date: Thu, 27 Aug 2009 09:45:26 -0400
 
 environment: Tomcat 6.0.18 under apache2 on Mac OS X Server 10.5  
 (Leopard).
 
 I am using a mod_jk connector with JBoss.
 
 I am having trouble getting context urls of the form website.my.com/ 
 myapplication honoured (or even localhost/myapplication).
 (Safari:File not found).I have googled  the error messages below but  
 can't find anything applicable to my setup.
 
 The quick start guide at
 
 http://tomcat.apache.org/connectors-doc/generic_howto/quick.html
 
 gives a simple proof of concept for a connector setup (/examples).  
 However, this does not work,
 though I have followed the editing of the configuration files exactly  
 (using JKMount in the httpd.conf etc)
 
 I get an error in mod_jk.log (set to debug level):
 
 [Tue Aug 25 12:41:11.783 2009] [211:2688784416] [debug]  
 map_uri_to_worker_ext::jk_uri_worker_map.c (1036): (TEST) Attempting  
 to map URI '/server-status' from 5 maps
 [Tue Aug 25 12:41:11.783 2009] [211:2688784416] [debug]  
 map_uri_to_worker_ext::jk_uri_worker_map.c (1039): Initial match  
 value:for URI '/server-status' is -1.
 [Tue Aug 25 12:41:11.783 2009] [211:2688784416] [debug]  
 find_match::jk_uri_worker_map.c (850): Attempting to map context URI '/ 
 examples/*=JBoss1' source 'JkMount'
 [Tue Aug 25 12:41:11.783 2009] [211:2688784416] [debug]  
 find_match::jk_uri_worker_map.c (850): Attempting to map context URI '/ 
 servlet/*=JBoss1' source 'JkMount'
 [Tue Aug 25 12:41:11.783 2009] [211:2688784416] [debug]  
 find_match

Re: /context not working -- mod_jk error: no match for /server-status

2009-08-27 Thread Dennis Christopher

Martin,

Thanks for the reply.

I can't be 100% sure, but I have another setup machine that used to  
work but the internet serving on it is broken.

The config files on it ought to be accurate.

However there is no boss-service.xml file on it.

In workers.properties, I have defined:

worker.list=JBoss1, JBoss2, loadbalancer, blojsomworker

# 
# First JBoss server
# 
worker.JBoss1.port=8009
worker.JBoss1.host=127.0.0.1
worker.JBoss1.type=ajp13
worker.JBoss1.lbfactor=100
.
.
.

is that not sufficient?

Dennis
On Aug 27, 2009, at 2:39 PM, Martin Gainty wrote:



JBOSS ajp connector  is org.mortbay.http.ajp.AJP13Listener

from jboss docs you will need to config jboss-service.xml
5.  In jboss_home/server/all/deploy/jbossweb.sar/META-INF/jboss- 
service.xml, edit the following:

-
Under the Configure the Request Listeners section, look for the add
listener call of org.mortbay.http.SocketListener and change the port
setting line to (8080 is the default):
Set name=PortSystemProperty name=jetty.port default=18080/ 
/Set

-
Under the Configure the Request Listeners section, look for the add
listener call of org.mortbay.http.ajp.AJP13Listener and change the
port setting line to (8009 is the default):
Set name=Port18009/Set
- Also the call org.mortbay.http.ajp.AJP13Listener, change the  
port setting line to (443 is the default):

Set name=confidentialPort1443/Set
For JBoss 3.2.0, do these steps (contributed by Anantha Krishnan V):
5.a In jboss_home/server/all/deploy/jbossweb-jetty.sar/META-INF/ 
jboss-service.xml, edit the following:

- Do the same as above, since the .sar was renamed.
For JBoss 3.2.1 with Tomcat, do these steps:
5.b In jboss_home/server/all/deploy/jbossweb-tomcat.sar/META-INF/ 
jboss-service.xml, edit the following:

-
Under the Configure the Request Listeners section, look for the add
listener call of org.apache.coyote.tomcat4.CoyoteConnector and  
change

the port setting line to (8080 is the default):
!--
A HTTP/1.1 Connector on port 18080 --Connector
className=org.apache.coyote.tomcat4.CoyoteConnector
port=18080 minProcessors=3 maxProcessors=10
enableLookups=true acceptCount=10 debug=0
connectionTimeout=2 useURIValidationHack=false /
- Also the AJP 1.3 Connector, change the port setting line to (8009  
and 8443 are the defaults):

!--
A AJP 1.3 Connector on port 18009 --Connector
className=org.apache.coyote.tomcat4.CoyoteConnector
port=18009 minProcessors=5 maxProcessors=75 
enableLookups=true redirectPort=18443

acceptCount=10 debug=0 connectionTimeout=2
useURIValidationHack=false
protocolHandlerClassName=org.apache.jk.server.JkCoyoteHandler/
ajp13 configuration spec is located at
http://www.jboss.org/community/wiki/ConfigurePorts

Martin Gainty
__
Verzicht und Vertraulichkeitanmerkung/Note de déni et de  
confidentialité


Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene  
Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede  
unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig.  
Diese Nachricht dient lediglich dem Austausch von Informationen und  
entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten  
Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den  
Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes  
pas le destinataire prévu, nous te demandons avec bonté que pour  
satisfaire informez l'expéditeur. N'importe quelle diffusion non  
autorisée ou la copie de ceci est interdite. Ce message sert à  
l'information seulement et n'aura pas n'importe quel effet  
légalement obligatoire. Étant donné que les email peuvent facilement  
être sujets à la manipulation, nous ne pouvons accepter aucune  
responsabilité pour le contenu fourni.






From: dchristop...@pixion.com
To: users@tomcat.apache.org
Subject: /context not working -- mod_jk error: no match for /server- 
status

Date: Thu, 27 Aug 2009 09:45:26 -0400

environment: Tomcat 6.0.18 under apache2 on Mac OS X Server 10.5
(Leopard).

I am using a mod_jk connector with JBoss.

I am having trouble getting context urls of the form website.my.com/
myapplication honoured (or even localhost/myapplication).
(Safari:File not found).I have googled  the error messages below but
can't find anything applicable to my setup.

The quick start guide at

http://tomcat.apache.org/connectors-doc/generic_howto/quick.html

gives a simple proof of concept for a connector setup (/examples).
However, this does not work,
though I have followed the editing of the configuration files exactly
(using JKMount in the httpd.conf etc)

I get an error in mod_jk.log (set to debug level):

[Tue Aug 25 12:41:11.783 2009] [211:2688784416] [debug]
map_uri_to_worker_ext::jk_uri_worker_map.c (1036): (TEST) Attempting
to map URI '/server-status' from 5 maps
[Tue Aug 25 12:41:11.783 2009] [211:2688784416] [debug]
map_uri_to_worker_ext

Re: tomcat mod_jk error log

2007-11-19 Thread Rainer Jung

Hi Martin,

lanes wrote:

Hi Rainer,

my os is Red Hat Linux v7.3 2.96-112.

this my workers.properties =


Delete the next 3 lines, they are useless.


workers.tomcat_home=/usr/local/tomcat
workers.java_home=/usr/java/j2sdk1.4.1_02
ps=/


I hope you are not really trying to do ajp12?
If you are only using ajp13, then delete ajp12 from the worker list and 
all lines of the form worker.ajp12=... from the workers.properties file.



worker.list=ajp12, ajp13
worker.ajp12.port=8007
worker.ajp12.host=localhost
worker.ajp12.type=ajp12
worker.ajp12.lbfactor=1
worker.ajp13.port=8009
worker.ajp13.host=localhost
worker.ajp13.type=ajp13
worker.ajp13.lbfactor=1


Read the docs about the more up-to-date names of the directives 
cachesize and cache_timeout (the page on workers.properties containes a 
list of deprecated attributes and their replacements).



worker.ajp13.cachesize=10
worker.ajp13.cache_timeout=600
worker.ajp13.socket_keepalive=1 
worker.ajp13.socket_timeout=300
worker.ajp13.reply_timeout=6 
worker.loadbalancer.type=lb


It doesn't really make sense to balance between an ajp12 and an ajp13 
worker (it should work, but I see no real reason for it).



worker.loadbalancer.balanced_workers=ajp12, ajp13


Delete all the worker.inprocess, I hope you are not really trying to use 
them.



worker.inprocess.type=jni
worker.inprocess.class_path=$(workers.tomcat_home)$(ps)lib$(ps)tomcat.jar
worker.inprocess.cmd_line=start
worker.inprocess.jvm_lib=$(workers.java_home)$(ps)jre$(ps)bin$(ps)classic$(ps)jvm.dll
worker.inprocess.stdout=$(workers.tomcat_home)$(ps)logs$(ps)inprocess.stdout
worker.inprocess.stderr=$(workers.tomcat_home)$(ps)logs$(ps)inprocess.stderr



Which version of mod_jk? Modern version will log an info message during 
startup, for older ones you can do


strings modules/mod_jk.so | fgrep 1.2.

Version 1.2.25 is the most recent (and recommended).


below is my apache conf file to load mod_jk =
LoadModulejk_module  modules/mod_jk.so
JkWorkersFile /usr/local/tomcat/conf/workers.properties
JkLogFile /etc/httpd/logs/mod_jk.log
JkLogLevelinfo


Better use the default JkLogStampFormat, then you will profit from 
improvements there (e.g. since version 1.2.25 we log milliseconds by 
default, unless you are using an old hard-coded JkLogStampFormat).



JkLogStampFormat [%a %b %d %H:%M:%S %Y] 
Alias /testPortal /usr/local/tomcat/webapps/testPortal
JkMount /*.jsp ajp13
JkMount /*/servlet/ ajp13


OK, so you are not usiung ajp12 and inprocess workers (good) and you can 
delete the respective config items in workers.properties.


Since you don't use the loadbalancer either, you can also delete those 
lines (or instead replace ajp13 in the JkMount by loadbalancer).





My tomcat version is 4.1.12


Oops, that's very outdated, and maybe here's the reason for the error 
messages. It could very well be, that Cping/Cpong were invented after 
4.1.12, so the Tomcat connector might not know about this protocol. If 
you need to stick to 4.1, that version is still well maintaoined. Please 
update to 4.1.36 and try again.




Thank you very much.

Regards,
Martin


Regards,

Rainer



Rainer Jung-3 wrote:

Hi,

we can't identify your problem without knowing your configuration.

Please give us

- your operating system
- your Tomcat connector configuration for the connector you talk to via
mod_jk
- your workers.properties
- your httpd JK-directives
- your Tomcat-version and mod_jk-version

You can furthermore improve the chance of finding your problem by
running your test case when having JkLogLevel debug and posting
the full jk log file in addition.

I would guess, the problem could have to do with a firewall dropping
idle connections between Apache and Tomcat? If so, look at the Timeouts
documentation page of mod_jk.

Regards,

Rainer


Marthen LT schrieb:

hi all,

i have a live production server running tomcat  apache under linux.
but recently my cpu usage is being consumed by the mod_jk log file.
it keep logging and saying below warning/error messages:

[Fri Nov 16 15:02:13 2007]  [jk_ajp_common.c (819)]: ERROR: can't
receive the response message from tomcat, network problems or tomcat
is down. err=-1
[Fri Nov 16 15:02:13 2007]  [jk_ajp_common.c (717)]: Error
ajp13:cping: awaited reply cpong, not received
[Fri Nov 16 15:02:13 2007]  [jk_ajp_common.c (1026)]: Error sending
request try another pooled connection

what is happening?
i try to restart my tomcat also didn't give me a solution.

any help will be appreciated.
thank you.


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: tomcat mod_jk error log

2007-11-19 Thread lanes
, e-mail: [EMAIL PROTECTED]
 
 
 

-- 
View this message in context: 
http://www.nabble.com/tomcat-mod_jk-error-log-tf4825734.html#a13833423
Sent from the Tomcat - User mailing list archive at Nabble.com.


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: tomcat mod_jk error log

2007-11-18 Thread Rainer Jung
Hi,

we can't identify your problem without knowing your configuration.

Please give us

- your operating system
- your Tomcat connector configuration for the connector you talk to via
mod_jk
- your workers.properties
- your httpd JK-directives
- your Tomcat-version and mod_jk-version

You can furthermore improve the chance of finding your problem by
running your test case when having JkLogLevel debug and posting
the full jk log file in addition.

I would guess, the problem could have to do with a firewall dropping
idle connections between Apache and Tomcat? If so, look at the Timeouts
documentation page of mod_jk.

Regards,

Rainer


Marthen LT schrieb:
 hi all,
 
 i have a live production server running tomcat  apache under linux.
 but recently my cpu usage is being consumed by the mod_jk log file.
 it keep logging and saying below warning/error messages:
 
 [Fri Nov 16 15:02:13 2007]  [jk_ajp_common.c (819)]: ERROR: can't
 receive the response message from tomcat, network problems or tomcat
 is down. err=-1
 [Fri Nov 16 15:02:13 2007]  [jk_ajp_common.c (717)]: Error
 ajp13:cping: awaited reply cpong, not received
 [Fri Nov 16 15:02:13 2007]  [jk_ajp_common.c (1026)]: Error sending
 request try another pooled connection
 
 what is happening?
 i try to restart my tomcat also didn't give me a solution.
 
 any help will be appreciated.
 thank you.

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: tomcat mod_jk error log

2007-11-18 Thread lanes

Hi Rainer,

my os is Red Hat Linux v7.3 2.96-112.

this my workers.properties =
workers.tomcat_home=/usr/local/tomcat
workers.java_home=/usr/java/j2sdk1.4.1_02
ps=/
worker.list=ajp12, ajp13
worker.ajp12.port=8007
worker.ajp12.host=localhost
worker.ajp12.type=ajp12
worker.ajp12.lbfactor=1
worker.ajp13.port=8009
worker.ajp13.host=localhost
worker.ajp13.type=ajp13
worker.ajp13.lbfactor=1
worker.ajp13.cachesize=10
worker.ajp13.cache_timeout=600
worker.ajp13.socket_keepalive=1 
worker.ajp13.socket_timeout=300
worker.ajp13.reply_timeout=6 
worker.loadbalancer.type=lb
worker.loadbalancer.balanced_workers=ajp12, ajp13
worker.inprocess.type=jni
worker.inprocess.class_path=$(workers.tomcat_home)$(ps)lib$(ps)tomcat.jar
worker.inprocess.cmd_line=start
worker.inprocess.jvm_lib=$(workers.java_home)$(ps)jre$(ps)bin$(ps)classic$(ps)jvm.dll
worker.inprocess.stdout=$(workers.tomcat_home)$(ps)logs$(ps)inprocess.stdout
worker.inprocess.stderr=$(workers.tomcat_home)$(ps)logs$(ps)inprocess.stderr


below is my apache conf file to load mod_jk =
LoadModulejk_module  modules/mod_jk.so
JkWorkersFile /usr/local/tomcat/conf/workers.properties
JkLogFile /etc/httpd/logs/mod_jk.log
JkLogLevelinfo
JkLogStampFormat [%a %b %d %H:%M:%S %Y] 
Alias /testPortal /usr/local/tomcat/webapps/testPortal
JkMount /*.jsp ajp13
JkMount /*/servlet/ ajp13


My tomcat version is 4.1.12

Thank you very much.

Regards,
Martin




Rainer Jung-3 wrote:
 
 Hi,
 
 we can't identify your problem without knowing your configuration.
 
 Please give us
 
 - your operating system
 - your Tomcat connector configuration for the connector you talk to via
 mod_jk
 - your workers.properties
 - your httpd JK-directives
 - your Tomcat-version and mod_jk-version
 
 You can furthermore improve the chance of finding your problem by
 running your test case when having JkLogLevel debug and posting
 the full jk log file in addition.
 
 I would guess, the problem could have to do with a firewall dropping
 idle connections between Apache and Tomcat? If so, look at the Timeouts
 documentation page of mod_jk.
 
 Regards,
 
 Rainer
 
 
 Marthen LT schrieb:
 hi all,
 
 i have a live production server running tomcat  apache under linux.
 but recently my cpu usage is being consumed by the mod_jk log file.
 it keep logging and saying below warning/error messages:
 
 [Fri Nov 16 15:02:13 2007]  [jk_ajp_common.c (819)]: ERROR: can't
 receive the response message from tomcat, network problems or tomcat
 is down. err=-1
 [Fri Nov 16 15:02:13 2007]  [jk_ajp_common.c (717)]: Error
 ajp13:cping: awaited reply cpong, not received
 [Fri Nov 16 15:02:13 2007]  [jk_ajp_common.c (1026)]: Error sending
 request try another pooled connection
 
 what is happening?
 i try to restart my tomcat also didn't give me a solution.
 
 any help will be appreciated.
 thank you.
 
 -
 To start a new topic, e-mail: users@tomcat.apache.org
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 

-- 
View this message in context: 
http://www.nabble.com/tomcat-mod_jk-error-log-tf4825734.html#a13829109
Sent from the Tomcat - User mailing list archive at Nabble.com.


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



tomcat mod_jk error log

2007-11-17 Thread Marthen LT
hi all,

i have a live production server running tomcat  apache under linux.
but recently my cpu usage is being consumed by the mod_jk log file.
it keep logging and saying below warning/error messages:

[Fri Nov 16 15:02:13 2007]  [jk_ajp_common.c (819)]: ERROR: can't
receive the response message from tomcat, network problems or tomcat
is down. err=-1
[Fri Nov 16 15:02:13 2007]  [jk_ajp_common.c (717)]: Error
ajp13:cping: awaited reply cpong, not received
[Fri Nov 16 15:02:13 2007]  [jk_ajp_common.c (1026)]: Error sending
request try another pooled connection

what is happening?
i try to restart my tomcat also didn't give me a solution.

any help will be appreciated.
thank you.

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



mod_jk error log

2007-11-16 Thread Marthen LT
hi all,

i have a live production server running tomcat  apache under linux.
but recently my cpu usage is being consumed by the mod_jk log file.
it keep logging and saying below warning/error messages:

[Fri Nov 16 15:02:13 2007]  [jk_ajp_common.c (819)]: ERROR: can't
receive the response message from tomcat, network problems or tomcat
is down. err=-1
[Fri Nov 16 15:02:13 2007]  [jk_ajp_common.c (717)]: Error
ajp13:cping: awaited reply cpong, not received
[Fri Nov 16 15:02:13 2007]  [jk_ajp_common.c (1026)]: Error sending
request try another pooled connection

what is happening?
i try to restart my tomcat also didn't give me a solution.

any help will be appreciated.
thank you.

rgds,
marthen

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Mod_jk error

2007-07-26 Thread Filip Hanik - Dev Lists

also solves your problem

+JkDisableReuse

in httpd.conf

Filip


Rainer Jung wrote:

André Vila Cova wrote:

Red Hat Enterprise Linux AS release 4 (Nahant Update 5)

Release :  Jakarta-Tomcat 5.5.20

Modulo nativo APR:  tomcat-connectors-1.2.20

JVM versão. : Sun JVM1.5.0_11

I think that apache web server don't receive response from tomcat and 
don't
send final ack to tomcat and tomcat don't free threads.I see every 
logs from

oracle executions and duration of TOP SQL is very low.
I made test using the same architecture without firewall and everything
works fine. Tomcat free threads and send complete response to web 
server.


If your analysis is correct, it's a known problem, that firewalls 
often drop idle connections, so mod_jk and Tomcat should both be 
configured to shut down idle connections. On the Tomcat side you 
should use the attribute connectionTimeout in the configuration of 
your AJP Connector in server.xml. The units are in milliseconds, so 10 
Minutes would be 60. On the mod_jk side you should use 
connection_pool_timeout, units are seconds, so 10 minutes are 600.


We have a new docs page about these things, which will go live next 
week with our 1.2.24 release. There is a preview for the page under


http://people.apache.org/~rjung/mod_jk-dev/docs/generic_howto/timeouts.html 



The next release 1.2.24 will some improvements for this situation, but 
you would still need the timeouts on bith ends.


For a plausibility check, if this really is your problem, you could 
compare netstat -an (only the lines corresponding to your Tomcat AJP 
port) on the Apache and on the Tomcat side, and also check with the 
JVM Thread Dump (kill -QUIT to Tomcat; it will not die, but write a 
list of all threads with a stack for each of them to catalina.out). If 
the firewall dropped the connections, most likely the two netstat 
outputs will show an inconsistent state for the connections. Tomcat 
threads, which sit listening on an idle connection will be shown in 
the thread dump as reading from the socket.


Regards,

Rainer


Thanks.



On 7/26/07, Rainer Jung [EMAIL PROTECTED] wrote:


Hi,

you didn't give us your versions, you platform or any configuration 
info.


André Vila Cova wrote:
 Hello!

 Apache mod_jk returns following error (frequently...):

 [Thu Jul 26 11:07:52 2007] [2703:1120] [error]
 ajp_connection_tcp_get_message::jk_ajp_common.c (948): (app02_aol) 
can't
 receive the response message from tomcat, network problems or 
tomcat is

 down
 (192.168.40.11:8007), err=-104
 [Thu Jul 26 11:07:52 2007] [2703:1120] [error]
 ajp_get_reply::jk_ajp_common.c (1566): (app02_aol) Tomcat is down or
 refused
 connection. No response has been sent to the client (yet)


The 104 is the errno of your local platform. For Linux 104 is
Connection reset by peer.

 We have two firewalls between Apache Web Server and Tomcat Web , 
but we

 didn't see nothing wrong in firewalls logs.

 Response appear on browser, but seems that no ack flag arrives to
webserver
 to finish request. Tomcat crashs with error All threads (400) are
currently
 *busy*, waiting. Increase *maxThreads* (400) or check the servlet
status.

The above log entry is for only a single request. You write that the
response actually goes back to the browser, but I guess you mean most
of the requests, or are you sure that this single request produced a
response?

No idea, what you mean by crash? If this message appears, it means,
that all the threads you have configured in you thread pool of the
tomcat connector are busy by running a request. Since you configured 
400
threads max, this might actually mean, that something is to slow in 
your

app or in some backend your app is using, so the requests take to long
and the system becomes congested. In this situation take a java thread
dump to check, what those 400 threads are actually doing.

 Is it a configuration problem? May I setup some parameter to resolve
 problem?

If only we knew your configuration ...

Regards,

Rainer


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]






-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Mod_jk error

2007-07-26 Thread Rainer Jung

André Vila Cova wrote:

Red Hat Enterprise Linux AS release 4 (Nahant Update 5)

Release :  Jakarta-Tomcat 5.5.20

Modulo nativo APR:  tomcat-connectors-1.2.20

JVM versão. : Sun JVM1.5.0_11

I think that apache web server don't receive response from tomcat and don't
send final ack to tomcat and tomcat don't free threads.I see every logs 
from

oracle executions and duration of TOP SQL is very low.
I made test using the same architecture without firewall and everything
works fine. Tomcat free threads and send complete response to web server.


If your analysis is correct, it's a known problem, that firewalls often 
drop idle connections, so mod_jk and Tomcat should both be configured to 
shut down idle connections. On the Tomcat side you should use the 
attribute connectionTimeout in the configuration of your AJP Connector 
in server.xml. The units are in milliseconds, so 10 Minutes would be 
60. On the mod_jk side you should use connection_pool_timeout, units 
are seconds, so 10 minutes are 600.


We have a new docs page about these things, which will go live next week 
with our 1.2.24 release. There is a preview for the page under


http://people.apache.org/~rjung/mod_jk-dev/docs/generic_howto/timeouts.html

The next release 1.2.24 will some improvements for this situation, but 
you would still need the timeouts on bith ends.


For a plausibility check, if this really is your problem, you could 
compare netstat -an (only the lines corresponding to your Tomcat AJP 
port) on the Apache and on the Tomcat side, and also check with the JVM 
Thread Dump (kill -QUIT to Tomcat; it will not die, but write a list of 
all threads with a stack for each of them to catalina.out). If the 
firewall dropped the connections, most likely the two netstat outputs 
will show an inconsistent state for the connections. Tomcat threads, 
which sit listening on an idle connection will be shown in the thread 
dump as reading from the socket.


Regards,

Rainer


Thanks.



On 7/26/07, Rainer Jung [EMAIL PROTECTED] wrote:


Hi,

you didn't give us your versions, you platform or any configuration info.

André Vila Cova wrote:
 Hello!

 Apache mod_jk returns following error (frequently...):

 [Thu Jul 26 11:07:52 2007] [2703:1120] [error]
 ajp_connection_tcp_get_message::jk_ajp_common.c (948): (app02_aol) 
can't

 receive the response message from tomcat, network problems or tomcat is
 down
 (192.168.40.11:8007), err=-104
 [Thu Jul 26 11:07:52 2007] [2703:1120] [error]
 ajp_get_reply::jk_ajp_common.c (1566): (app02_aol) Tomcat is down or
 refused
 connection. No response has been sent to the client (yet)


The 104 is the errno of your local platform. For Linux 104 is
Connection reset by peer.

 We have two firewalls between Apache Web Server and Tomcat Web , but we
 didn't see nothing wrong in firewalls logs.

 Response appear on browser, but seems that no ack flag arrives to
webserver
 to finish request. Tomcat crashs with error All threads (400) are
currently
 *busy*, waiting. Increase *maxThreads* (400) or check the servlet
status.

The above log entry is for only a single request. You write that the
response actually goes back to the browser, but I guess you mean most
of the requests, or are you sure that this single request produced a
response?

No idea, what you mean by crash? If this message appears, it means,
that all the threads you have configured in you thread pool of the
tomcat connector are busy by running a request. Since you configured 400
threads max, this might actually mean, that something is to slow in your
app or in some backend your app is using, so the requests take to long
and the system becomes congested. In this situation take a java thread
dump to check, what those 400 threads are actually doing.

 Is it a configuration problem? May I setup some parameter to resolve
 problem?

If only we knew your configuration ...

Regards,

Rainer


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Mod_jk error

2007-07-26 Thread André Vila Cova

Red Hat Enterprise Linux AS release 4 (Nahant Update 5)

Release :  Jakarta-Tomcat 5.5.20

Modulo nativo APR:  tomcat-connectors-1.2.20

JVM versão. : Sun JVM1.5.0_11

I think that apache web server don't receive response from tomcat and don't
send final ack to tomcat and tomcat don't free threads.I see every logs from
oracle executions and duration of TOP SQL is very low.
I made test using the same architecture without firewall and everything
works fine. Tomcat free threads and send complete response to web server.

Thanks.



On 7/26/07, Rainer Jung [EMAIL PROTECTED] wrote:


Hi,

you didn't give us your versions, you platform or any configuration info.

André Vila Cova wrote:
 Hello!

 Apache mod_jk returns following error (frequently...):

 [Thu Jul 26 11:07:52 2007] [2703:1120] [error]
 ajp_connection_tcp_get_message::jk_ajp_common.c (948): (app02_aol) can't
 receive the response message from tomcat, network problems or tomcat is
 down
 (192.168.40.11:8007), err=-104
 [Thu Jul 26 11:07:52 2007] [2703:1120] [error]
 ajp_get_reply::jk_ajp_common.c (1566): (app02_aol) Tomcat is down or
 refused
 connection. No response has been sent to the client (yet)


The 104 is the errno of your local platform. For Linux 104 is
Connection reset by peer.

 We have two firewalls between Apache Web Server and Tomcat Web , but we
 didn't see nothing wrong in firewalls logs.

 Response appear on browser, but seems that no ack flag arrives to
webserver
 to finish request. Tomcat crashs with error All threads (400) are
currently
 *busy*, waiting. Increase *maxThreads* (400) or check the servlet
status.

The above log entry is for only a single request. You write that the
response actually goes back to the browser, but I guess you mean most
of the requests, or are you sure that this single request produced a
response?

No idea, what you mean by crash? If this message appears, it means,
that all the threads you have configured in you thread pool of the
tomcat connector are busy by running a request. Since you configured 400
threads max, this might actually mean, that something is to slow in your
app or in some backend your app is using, so the requests take to long
and the system becomes congested. In this situation take a java thread
dump to check, what those 400 threads are actually doing.

 Is it a configuration problem? May I setup some parameter to resolve
 problem?

If only we knew your configuration ...

Regards,

Rainer

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: Mod_jk error

2007-07-26 Thread Rainer Jung

Hi,

you didn't give us your versions, you platform or any configuration info.

André Vila Cova wrote:
 Hello!

 Apache mod_jk returns following error (frequently...):

 [Thu Jul 26 11:07:52 2007] [2703:1120] [error]
 ajp_connection_tcp_get_message::jk_ajp_common.c (948): (app02_aol) can't
 receive the response message from tomcat, network problems or tomcat is
 down
 (192.168.40.11:8007), err=-104
 [Thu Jul 26 11:07:52 2007] [2703:1120] [error]
 ajp_get_reply::jk_ajp_common.c (1566): (app02_aol) Tomcat is down or
 refused
 connection. No response has been sent to the client (yet)


The 104 is the errno of your local platform. For Linux 104 is 
Connection reset by peer.



We have two firewalls between Apache Web Server and Tomcat Web , but we
didn't see nothing wrong in firewalls logs.



Response appear on browser, but seems that no ack flag arrives to webserver
to finish request. Tomcat crashs with error All threads (400) are currently
*busy*, waiting. Increase *maxThreads* (400) or check the servlet status.


The above log entry is for only a single request. You write that the 
response actually goes back to the browser, but I guess you mean most 
of the requests, or are you sure that this single request produced a 
response?


No idea, what you mean by crash? If this message appears, it means, 
that all the threads you have configured in you thread pool of the 
tomcat connector are busy by running a request. Since you configured 400 
threads max, this might actually mean, that something is to slow in your 
app or in some backend your app is using, so the requests take to long 
and the system becomes congested. In this situation take a java thread 
dump to check, what those 400 threads are actually doing.



Is it a configuration problem? May I setup some parameter to resolve
problem?


If only we knew your configuration ...

Regards,

Rainer

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Mod_jk error

2007-07-26 Thread André Vila Cova

Hello!

Apache mod_jk returns following error (frequently...):

[Thu Jul 26 11:07:52 2007] [2703:1120] [error]
ajp_connection_tcp_get_message::jk_ajp_common.c (948): (app02_aol) can't
receive the response message from tomcat, network problems or tomcat is down
(192.168.40.11:8007), err=-104
[Thu Jul 26 11:07:52 2007] [2703:1120] [error]
ajp_get_reply::jk_ajp_common.c (1566): (app02_aol) Tomcat is down or refused
connection. No response has been sent to the client (yet)

We have two firewalls between Apache Web Server and Tomcat Web , but we
didn't see nothing wrong in firewalls logs.

Response appear on browser, but seems that no ack flag arrives to webserver
to finish request. Tomcat crashs with error All threads (400) are currently
*busy*, waiting. Increase *maxThreads* (400) or check the servlet status.

Is it a configuration problem? May I setup some parameter to resolve
problem?

Could you help me?

Thanks a lot.


mod_jk error detection

2007-07-25 Thread Scott McClanahan
I am installing mod_jk 1.2.23 in a load balancing configuration between
apache 2.0.52 and tomcat 5.0.28.  I am trying to understand how the
mod_jk error detection actually works.  In the documentation
socket_timeout directive defaults to zero (infinite waiting) but the
retries directive defaults to two.

With these settings how could I expect the connector to behave if:

1.  Tomcat dies and the port is no longer listening resulting in an
immediate icmp response.

2.  The box hosting tomcat dies or the tcp stack for whatever reason
tanks resulting in no immediate icmp response.

3.  The connector does make a successful connection to the backend
tomcat worker only to have that worker become slow and almost
unresponsive.

Are there more directives I should be concerned with?  Currently, I have
no intentions on monitoring the http response status codes to detect
errors.


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: mod_jk error detection

2007-07-25 Thread Rainer Jung

Hi,

good questions. First of all: I just today wrote a new docs page about 
timeouts. We are soon releasing 1.2.24 which contains this page. You can 
already look at it under


http://people.apache.org/~rjung/mod_jk-dev/docs/

(The new page is named Timeouts and part of the group Generic Howtos.

Also the new docs contain a better explanation, what retries means, 
especially the huge difference between retries for an lb worker and a 
usual worker. This info is on the updated workers.properties page in the 
reference guide.



With these settings how could I expect the connector to behave if:

1.  Tomcat dies and the port is no longer listening resulting in an
immediate icmp response.


I would expect, that any attempt to use an existing connection or to 
open a new one immediately returns with an error, because the remote 
machine rejects the communication. Further JK behaviour is now depending 
if you are using a load balancer or not. Se retries etc. in the updated 
docs.



2.  The box hosting tomcat dies or the tcp stack for whatever reason
tanks resulting in no immediate icmp response.


As long as your local system or the last router still has an arp entry 
for the died machine, you will run into very long TCP timeouts. We 
recommend CPing/CPong, see the new Timeouts page.



3.  The connector does make a successful connection to the backend
tomcat worker only to have that worker become slow and almost
unresponsive.


You should use CPing/CPong and reply timeouts. See again the new 
Timeouts page. If you don't use an lb, the best you can do is throwing 
an error early, such that the rest of the infrastructure doesnt get 
congested.



Are there more directives I should be concerned with?  Currently, I have
no intentions on monitoring the http response status codes to detect
errors.


Look at the new page and look at the workers.properties page of the 
reference guide. Use a load balancing worker, set recovery_options etc.


HTH.

Regards,

Rainer

P.S.: If you have suggestions how to improve the new page: it's not 
public yet. If you are fast enough, we can include those changes.


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: mod_jk error detection

2007-07-25 Thread Scott McClanahan
On Wed, 2007-07-25 at 17:00 +0200, Rainer Jung wrote:
 Hi,
 
 good questions. First of all: I just today wrote a new docs page about 
 timeouts. We are soon releasing 1.2.24 which contains this page. You can 
 already look at it under
 
 http://people.apache.org/~rjung/mod_jk-dev/docs/
 
 (The new page is named Timeouts and part of the group Generic Howtos.
 
 Also the new docs contain a better explanation, what retries means, 
 especially the huge difference between retries for an lb worker and a 
 usual worker. This info is on the updated workers.properties page in the 
 reference guide.
 
  With these settings how could I expect the connector to behave if:
  
  1.  Tomcat dies and the port is no longer listening resulting in an
  immediate icmp response.
 
 I would expect, that any attempt to use an existing connection or to 
 open a new one immediately returns with an error, because the remote 
 machine rejects the communication. Further JK behaviour is now depending 
 if you are using a load balancer or not. Se retries etc. in the updated 
 docs.
 
  2.  The box hosting tomcat dies or the tcp stack for whatever reason
  tanks resulting in no immediate icmp response.
 
 As long as your local system or the last router still has an arp entry 
 for the died machine, you will run into very long TCP timeouts. We 
 recommend CPing/CPong, see the new Timeouts page.
 
  3.  The connector does make a successful connection to the backend
  tomcat worker only to have that worker become slow and almost
  unresponsive.
 
 You should use CPing/CPong and reply timeouts. See again the new 
 Timeouts page. If you don't use an lb, the best you can do is throwing 
 an error early, such that the rest of the infrastructure doesnt get 
 congested.
 
  Are there more directives I should be concerned with?  Currently, I have
  no intentions on monitoring the http response status codes to detect
  errors.
 
 Look at the new page and look at the workers.properties page of the 
 reference guide. Use a load balancing worker, set recovery_options etc.
 
 HTH.
 
 Regards,
 
 Rainer
 
 P.S.: If you have suggestions how to improve the new page: it's not 
 public yet. If you are fast enough, we can include those changes.
 
 -
 To start a new topic, e-mail: users@tomcat.apache.org
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 

Thanks I'll be reading up this afternoon and posting comments.


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: mod_jk error detection

2007-07-25 Thread Rainer Jung

Hi Scott,


I thoroughly enjoyed the updated docs.  It is just what I needed.  I
just want to mention a few inferences I have now from reading it.


Thanks.


In a load balanced setup using connect_timeout and prepost_timeout, this
will protect me from sending either newly established connections (rare
event due to persistence) as well as each and every individual request
from being sent to a failed tomcat node based on CPING/CPONG messages.
These messages only detect whether or not the container (I'm using
tomcat) is healthy enough to respond to such a message but not
necessarily anything more, correct?  Basically, its ajp listener is
responsive.  Plus, if I need more high speed error detection I can use


That's correct.


reply_timeout.  Sound correct?


That one, reply_timeout, is not really meant for high speed detection. 
Usually you've got an ap, that every now and then needs 10 or 20 seconds 
for an answer and you don't like to disable a worker automatically 
because of those rare events. So normally one sets reply_timeout to 1, 2 
or 3 minutes.


Now with the new max_reply_timeouts one can experiment with lower 
values. It's new, so not enough experience for good suggestions.



I get confused on the recovery_options section.  How does it work in a
load balanced environment?  If tomcat receives a request and processes
some of it followed by a catastrophic failure before completing the
response, what exactly does a repeated request from the client do?
Assuming recovery_options is set to 0.


Value 0 means, if you don't get any part of the answer and an error 
occurs (network, reply_timeout, ...) then send the same request again to 
another member of the load balancer (if a working member is remaining).


That's why you usualy really want to not use value 0 in case your app 
has data changing use cases. Most apps have.


If you use REST principles and HEAD and GET is always idempotent for 
your app, the new (version 1.2.24) bits 8 and 16 are your friend!



Also, I get confused with the section describing the retries directive.
In a load balanced environment, would the connector retry no matter the
state (tcp state here) of the connection whether it be established
already?  Would it retry against the same backend tomcat server?  The
reason I ask is because the docs say If the load balancer can not get a
free connection for a member worker from the pool, it will try again a
number of times given by retries. I highlighted the words that confuse
me.


We have to strongly make a difference between retries of a non-lb worker 
and of a load balancer worker. A normal worker has a simple retry 
procedure, independant of the fact, if it is used directly or as part of 
an lb. If it detects an error it uses another pool connection and by 
default tries once more.


An lb has another idea of retries. It uses retries if all connections to 
a backend are busy. For Apache with default config, this should never 
happen, because we allow as many connections as threads per process. So 
any request should be able to get a connection without waiting (maybe it 
needs to start a new one). For the other web servers we don't have a 
good way to detect the correct pool size. In some cases even for 
Apache it might be interesting to use a smaler pool size, in case the 
backend is only used occasionally and/or you want to prevent it from 
getting flodded in case of congestion. Then you might run out of 
available connections and requests will have to wait. LB retries 
configure this waiting.



Every 60 seconds would we expect the connector to attempt to send a
valid request to a backend tomcat and fail or once a worker goes into
error state do we only check with CPING/CPONG requests during the
maintenance cycle?


The maintenance uses a real request and handles it as if the backend 
wouldn't have failed. If you enabled CPing/CPong this means, that it 
would detect a still broken backend early and transparently send the 
request to another member. Because no part of the request (the CPing 
doesn't count) already has been send, the failover to another member 
happens independently of recovery_options (i.e. even with 
recovery_options 3).


If you like to improve the page about load balancing or the timeouts 
page, or you want to add some parts about retries and recovery: 
contributions are welcome.


Regards,

Rainer

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: mod_jk error detection

2007-07-25 Thread Scott McClanahan
Thanks, so much! I'd like to continue this thread a bit more because of
helpful I think it will be for everyone using mod_jk.

On Wed, 2007-07-25 at 22:00 +0200, Rainer Jung wrote:
 Hi Scott,
 
  I thoroughly enjoyed the updated docs.  It is just what I needed.  I
  just want to mention a few inferences I have now from reading it.
 
 Thanks.
 
  In a load balanced setup using connect_timeout and prepost_timeout, this
  will protect me from sending either newly established connections (rare
  event due to persistence) as well as each and every individual request
  from being sent to a failed tomcat node based on CPING/CPONG messages.
  These messages only detect whether or not the container (I'm using
  tomcat) is healthy enough to respond to such a message but not
  necessarily anything more, correct?  Basically, its ajp listener is
  responsive.  Plus, if I need more high speed error detection I can use
 
 That's correct.
 
  reply_timeout.  Sound correct?
 
 That one, reply_timeout, is not really meant for high speed detection. 
 Usually you've got an ap, that every now and then needs 10 or 20 seconds 
 for an answer and you don't like to disable a worker automatically 
 because of those rare events. So normally one sets reply_timeout to 1, 2 
 or 3 minutes.

I don't understand what besides a timed out CPING/CPONG message would
render a backend tomcat disabled, especially in a default config since
reply_timeout is 0.

 
 Now with the new max_reply_timeouts one can experiment with lower 
 values. It's new, so not enough experience for good suggestions.
 
  I get confused on the recovery_options section.  How does it work in a
  load balanced environment?  If tomcat receives a request and processes
  some of it followed by a catastrophic failure before completing the
  response, what exactly does a repeated request from the client do?
  Assuming recovery_options is set to 0.
 
 Value 0 means, if you don't get any part of the answer and an error 
 occurs (network, reply_timeout, ...) then send the same request again to 
 another member of the load balancer (if a working member is remaining).
 
 That's why you usualy really want to not use value 0 in case your app 
 has data changing use cases. Most apps have.
 
 If you use REST principles and HEAD and GET is always idempotent for 
 your app, the new (version 1.2.24) bits 8 and 16 are your friend!
 
  Also, I get confused with the section describing the retries directive.
  In a load balanced environment, would the connector retry no matter the
  state (tcp state here) of the connection whether it be established
  already?  Would it retry against the same backend tomcat server?  The
  reason I ask is because the docs say If the load balancer can not get a
  free connection for a member worker from the pool, it will try again a
  number of times given by retries. I highlighted the words that confuse
  me.
 
 We have to strongly make a difference between retries of a non-lb worker 
 and of a load balancer worker. A normal worker has a simple retry 
 procedure, independant of the fact, if it is used directly or as part of 
 an lb. If it detects an error it uses another pool connection and by 
 default tries once more.

If that happens does the real worker officially change to an error state
which would subsequently kick off the retry logic of the load balancer
worker?

 
 An lb has another idea of retries. It uses retries if all connections to 
 a backend are busy. For Apache with default config, this should never 
 happen, because we allow as many connections as threads per process. So 
 any request should be able to get a connection without waiting (maybe it 
 needs to start a new one). For the other web servers we don't have a 
 good way to detect the correct pool size. In some cases even for 
 Apache it might be interesting to use a smaler pool size, in case the 
 backend is only used occasionally and/or you want to prevent it from 
 getting flodded in case of congestion. Then you might run out of 
 available connections and requests will have to wait. LB retries 
 configure this waiting.
 
  Every 60 seconds would we expect the connector to attempt to send a
  valid request to a backend tomcat and fail or once a worker goes into
  error state do we only check with CPING/CPONG requests during the
  maintenance cycle?
 
 The maintenance uses a real request and handles it as if the backend 
 wouldn't have failed. If you enabled CPing/CPong this means, that it 
 would detect a still broken backend early and transparently send the 
 request to another member. Because no part of the request (the CPing 
 doesn't count) already has been send, the failover to another member 
 happens independently of recovery_options (i.e. even with 
 recovery_options 3).

Is the request used to test the health of the backend tomcat whichever
one comes first after a global maintenance run even if it has been
previously serviced by another healthy tomcat?  Is this request attempt

Re: mod_jk error detection

2007-07-25 Thread Scott McClanahan
On Wed, 2007-07-25 at 22:40 +0200, Rainer Jung wrote:
 Scott McClanahan wrote:
  Thanks, so much! I'd like to continue this thread a bit more because of
  helpful I think it will be for everyone using mod_jk.
  
  That one, reply_timeout, is not really meant for high speed detection. 
  Usually you've got an ap, that every now and then needs 10 or 20 seconds 
  for an answer and you don't like to disable a worker automatically 
  because of those rare events. So normally one sets reply_timeout to 1, 2 
  or 3 minutes.
  
  I don't understand what besides a timed out CPING/CPONG message would
  render a backend tomcat disabled, especially in a default config since
  reply_timeout is 0.
 
 Default config: no CPing/CPong. But: after some time the TCP stack will 
 give up, when there is a network problem, or the backend is no longer 
 listening. So this case will even be handled in a default config, but 
 depending on the exact network situation, the error detection might take 
 a long time.
 
 n case your backend simply eats your requests, but doesn't produce 
 answers, you will very fast eat up all connections and threads and the 
 whole system will hang - without configured timeouts.

I see your point.  I was thinking only within the context of mod_jk.
Meaning what in mod_jk other than CPING/CPONG message failures would
cause a worker to go into error state.  You answered that.

 
 BTW: there is also a non-default config to make a worker fail on several 
 received HTTP status codes, fail_on_status.
 
  We have to strongly make a difference between retries of a non-lb worker 
  and of a load balancer worker. A normal worker has a simple retry 
  procedure, independant of the fact, if it is used directly or as part of 
  an lb. If it detects an error it uses another pool connection and by 
  default tries once more.
  
  If that happens does the real worker officially change to an error state
  which would subsequently kick off the retry logic of the load balancer
  worker?
 
 Without an lb a worker does not have an error state. It will be 
 continuously reused. Only an lb uses error states and temporarily 
 disables a failed worker. Even an lb will continuously reuse a worker, 
 if there is no other worker to failover.

I understand this bit now finally too.  It was a really good idea to
have the CPING/CPONG message timeout checks before individual requests
get forwarded to avoid several different problem scenarios here.  Good
thinking.

 
  The maintenance uses a real request and handles it as if the backend 
  wouldn't have failed. If you enabled CPing/CPong this means, that it 
  would detect a still broken backend early and transparently send the 
  request to another member. Because no part of the request (the CPing 
  doesn't count) already has been send, the failover to another member 
  happens independently of recovery_options (i.e. even with 
  recovery_options 3).
  
  Is the request used to test the health of the backend tomcat whichever
  one comes first after a global maintenance run even if it has been
  previously serviced by another healthy tomcat?  Is this request attempt
  to a once errant worker only to test its healthiness and not to actually
  have it fulfill the request?  I would hope it is only to test the health
  of the backend tomcat and even if it is now willing to accept
  connections, the request goes to whatever tomcat has been previously and
  successfully responding to the session.
 
 No, the first new request accepted by the web server and mapped to the 
 lb will be used (at least if it is free to be routed to any worker. If 
 the request belongs to a session located on another backend and the 
 default config with sticky sessions is active, it will of course be send 
 to its correct backend). It is a real user request. If the backend 
 works, OK. If it doesn't accept the request, we can still send it to 
 some other worker. If the backend accepts the requests, but processing 
 fails, depending on recovery_options the user gets an error.

Sounds great too.

 
  If you like to improve the page about load balancing or the timeouts 
  page, or you want to add some parts about retries and recovery: 
  contributions are welcome.
  
  After, we are done discussing I might have some recommendations.  Again,
  you've been great.
 
 Thanks. At least we improve the knowledge inside the mailing list archive.

One obvious thing that confuses me and could be changed is the Advanced
worker directives table.  It includes directives that are applicable to
both load balancer workers and real workers and only distinguishes which
directives are used for which worker when it is to be used for a load
balancer worker.  Does that mean the others are usable directives for
both real workers and load balancer workers or just real workers or in
some cases both.

I believe I know the answer to that but it somewhat misleading.

 
 Regards,
 
 Rainer
 
 

Re: mod_jk error detection

2007-07-25 Thread Rainer Jung

One obvious thing that confuses me and could be changed is the Advanced
worker directives table.  It includes directives that are applicable to
both load balancer workers and real workers and only distinguishes which
directives are used for which worker when it is to be used for a load
balancer worker.  Does that mean the others are usable directives for
both real workers and load balancer workers or just real workers or in
some cases both.

I believe I know the answer to that but it somewhat misleading.


You are right, this needs a little forward before the table. At the 
moment we note Only used for load balancer workers., Only used for a 
member worker of a load balancer. or This attribute can be used for 
normal workers and for load balancer workers.. In fact we would need to 
mark, if an attribute is useful


LB) for an lb worker
N) for a non lb worker (normal worker, mostly synonymous with ajp13)
M) for an lb member worker

X) for a worker in the worker list (worker.list)

An attribute might apply to some or combinations of LB) to M) and an 
optional and with X.


I also think, that our advanced category is more historically 
motivated, so we should check, if some attributes should change their group.


Have fun using mod_jk!

Regards,

Rainer

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: mod_jk error detection

2007-07-25 Thread Rainer Jung

Scott McClanahan wrote:

Thanks, so much! I'd like to continue this thread a bit more because of
helpful I think it will be for everyone using mod_jk.

That one, reply_timeout, is not really meant for high speed detection. 
Usually you've got an ap, that every now and then needs 10 or 20 seconds 
for an answer and you don't like to disable a worker automatically 
because of those rare events. So normally one sets reply_timeout to 1, 2 
or 3 minutes.


I don't understand what besides a timed out CPING/CPONG message would
render a backend tomcat disabled, especially in a default config since
reply_timeout is 0.


Default config: no CPing/CPong. But: after some time the TCP stack will 
give up, when there is a network problem, or the backend is no longer 
listening. So this case will even be handled in a default config, but 
depending on the exact network situation, the error detection might take 
a long time.


n case your backend simply eats your requests, but doesn't produce 
answers, you will very fast eat up all connections and threads and the 
whole system will hang - without configured timeouts.


BTW: there is also a non-default config to make a worker fail on several 
received HTTP status codes, fail_on_status.


We have to strongly make a difference between retries of a non-lb worker 
and of a load balancer worker. A normal worker has a simple retry 
procedure, independant of the fact, if it is used directly or as part of 
an lb. If it detects an error it uses another pool connection and by 
default tries once more.


If that happens does the real worker officially change to an error state
which would subsequently kick off the retry logic of the load balancer
worker?


Without an lb a worker does not have an error state. It will be 
continuously reused. Only an lb uses error states and temporarily 
disables a failed worker. Even an lb will continuously reuse a worker, 
if there is no other worker to failover.


The maintenance uses a real request and handles it as if the backend 
wouldn't have failed. If you enabled CPing/CPong this means, that it 
would detect a still broken backend early and transparently send the 
request to another member. Because no part of the request (the CPing 
doesn't count) already has been send, the failover to another member 
happens independently of recovery_options (i.e. even with 
recovery_options 3).


Is the request used to test the health of the backend tomcat whichever
one comes first after a global maintenance run even if it has been
previously serviced by another healthy tomcat?  Is this request attempt
to a once errant worker only to test its healthiness and not to actually
have it fulfill the request?  I would hope it is only to test the health
of the backend tomcat and even if it is now willing to accept
connections, the request goes to whatever tomcat has been previously and
successfully responding to the session.


No, the first new request accepted by the web server and mapped to the 
lb will be used (at least if it is free to be routed to any worker. If 
the request belongs to a session located on another backend and the 
default config with sticky sessions is active, it will of course be send 
to its correct backend). It is a real user request. If the backend 
works, OK. If it doesn't accept the request, we can still send it to 
some other worker. If the backend accepts the requests, but processing 
fails, depending on recovery_options the user gets an error.


If you like to improve the page about load balancing or the timeouts 
page, or you want to add some parts about retries and recovery: 
contributions are welcome.


After, we are done discussing I might have some recommendations.  Again,
you've been great.


Thanks. At least we improve the knowledge inside the mailing list archive.

Regards,

Rainer

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: mod_jk error detection

2007-07-25 Thread Scott McClanahan
On Wed, 2007-07-25 at 17:00 +0200, Rainer Jung wrote:

 Hi,
 
 good questions. First of all: I just today wrote a new docs page about 
 timeouts. We are soon releasing 1.2.24 which contains this page. You can 
 already look at it under
 
 http://people.apache.org/~rjung/mod_jk-dev/docs/
 
 (The new page is named Timeouts and part of the group Generic Howtos.
 
 Also the new docs contain a better explanation, what retries means, 
 especially the huge difference between retries for an lb worker and a 
 usual worker. This info is on the updated workers.properties page in the 
 reference guide.
 
  With these settings how could I expect the connector to behave if:
  
  1.  Tomcat dies and the port is no longer listening resulting in an
  immediate icmp response.
 
 I would expect, that any attempt to use an existing connection or to 
 open a new one immediately returns with an error, because the remote 
 machine rejects the communication. Further JK behaviour is now depending 
 if you are using a load balancer or not. Se retries etc. in the updated 
 docs.
 
  2.  The box hosting tomcat dies or the tcp stack for whatever reason
  tanks resulting in no immediate icmp response.
 
 As long as your local system or the last router still has an arp entry 
 for the died machine, you will run into very long TCP timeouts. We 
 recommend CPing/CPong, see the new Timeouts page.
 
  3.  The connector does make a successful connection to the backend
  tomcat worker only to have that worker become slow and almost
  unresponsive.
 
 You should use CPing/CPong and reply timeouts. See again the new 
 Timeouts page. If you don't use an lb, the best you can do is throwing 
 an error early, such that the rest of the infrastructure doesnt get 
 congested.
 
  Are there more directives I should be concerned with?  Currently, I have
  no intentions on monitoring the http response status codes to detect
  errors.
 
 Look at the new page and look at the workers.properties page of the 
 reference guide. Use a load balancing worker, set recovery_options etc.
 
 HTH.
 
 Regards,
 
 Rainer
 
 P.S.: If you have suggestions how to improve the new page: it's not 
 public yet. If you are fast enough, we can include those changes.
 
 -
 To start a new topic, e-mail: users@tomcat.apache.org
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 


I thoroughly enjoyed the updated docs.  It is just what I needed.  I
just want to mention a few inferences I have now from reading it.

In a load balanced setup using connect_timeout and prepost_timeout, this
will protect me from sending either newly established connections (rare
event due to persistence) as well as each and every individual request
from being sent to a failed tomcat node based on CPING/CPONG messages.
These messages only detect whether or not the container (I'm using
tomcat) is healthy enough to respond to such a message but not
necessarily anything more, correct?  Basically, its ajp listener is
responsive.  Plus, if I need more high speed error detection I can use
reply_timeout.  Sound correct?

I get confused on the recovery_options section.  How does it work in a
load balanced environment?  If tomcat receives a request and processes
some of it followed by a catastrophic failure before completing the
response, what exactly does a repeated request from the client do?
Assuming recovery_options is set to 0.

Also, I get confused with the section describing the retries directive.
In a load balanced environment, would the connector retry no matter the
state (tcp state here) of the connection whether it be established
already?  Would it retry against the same backend tomcat server?  The
reason I ask is because the docs say If the load balancer can not get a
free connection for a member worker from the pool, it will try again a
number of times given by retries. I highlighted the words that confuse
me.

Every 60 seconds would we expect the connector to attempt to send a
valid request to a backend tomcat and fail or once a worker goes into
error state do we only check with CPING/CPONG requests during the
maintenance cycle?


Re: mod_jk : error sending request. Will try another pooled connection

2007-01-24 Thread heind heind

Hi.

Thanks for answering me.


On 1/23/07, Rainer Jung [EMAIL PROTECTED] wrote:


Hi,

heind heind schrieb:
 Hi,

 I have a web application deployed in tomcat embedded in jonas 4.7.4
 Application Server, and  in frontend  there are apache 2.0.55 and mod_jk
 12.20.

 My issue is that the message below is generated systematically after
every
 jsp call although the jsp are well served and the application works
fine.



...

 My question is what is the meaning of this message and how to avoid a
 second
 attempt ?

 PS :
 - my Apache is 2.0.55 prefork so I can't increase the
 connectio_pool_minsize
 (cf. http://tomcat.apache.org/connectors-doc/reference/workers.html )
 - the workers.properties is in standard configuration.

There is no standard configuration. Please post your
workers.properties, the Jk* directives and the config of the prefork MPM
from your apache config and the tomcat AJP/1.3 connector config from
server.xml.



workers.properties
worker.list=w,jkstatus
# workers vers v440r-01
worker.w_worker1.port=8407
worker.w_worker1.host=v440r-01
worker.w_worker1.type=ajp13
worker.w_worker1.lbfactor=1
worker.w_worker1.distance=1
worker.w_worker1.connection_pool_minsize=1
worker.w_worker1.connection_pool_size=2

# workers vers v440r-02

worker.w_worker2.port=8407
worker.w_worker2.host=10.198.45.5
worker.w_worker2.type=ajp13
worker.w_worker2.lbfactor=1
worker.w_worker2.distance=0
worker.w_worker2.connection_pool_minsize=1
worker.w_worker2.connection_pool_size=2
# LB worker
worker.w.type=lb
worker.w.balance_workers=w_worker2
#worker.w.balance_workers=w_worker1,w_worker2
worker.jkstatus.type=status


jk directives

JkWorkersFile /jonasintra/logiciel/apache_mgf/conf/workers.properties
JkLogFile |/jonasintra/logiciel/apache_mgf/bin/rotatelogs -l
/jonasintra/logiciel/apache_mgf/logs/mod_jk_%Y-%m-%d-%Hh%M.log 86400
JkLogLevel INFO
#JkLogStampFormat [%a %b %d %H:%M:%S %Y]
JkLogStampFormat [%Y-%m-%d %T (%a %d %b %Y)] 
JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories
#JkRequestLogFormat %w %V %T
JkRequestLogFormat URL : %U - Query : %q - Duration : %Ts
JkMount /mgf/clamweb.applications.gip.f1.ImageServlet mgf
JkMount /mgf/RefreshData mgf
JkMount /mgf/*.do mgf
JkMount /mgf/*.jsp mgf
JkMount /mgf_mrtg/*.jsp mgf
JkMount /jkmanager/* jkstatus
JkMount /mgfJonasAdmin/* mgf
JkMount /essais/* mgf

prefork mpm

IfModule prefork.c
ServerLimit 500
StartServers20
MinSpareServers 10
MaxSpareServers 20
MaxClients  500
MaxRequestsPerChild 1
/IfModule

AJP/1.3 connector
 Connector port=8407
  maxThreads=500
enableLookups=false redirectPort=9043 protocol=AJP/1.3
connectionTimeout=60/

I set the connectionTimeout to the value above to avoide the broken pipe
messages in the backend.


As long as there are no messages of higher level, those info messages do
not indicate a serious functional problem. Normally they should not show
up for each request. Are you sure that you get those for every request?



Yes, I am sure that this message shows up for evry request  when the time
between each call is about 5 min as you see below within the exemple from
mod_jk logs.

[2007-01-24 01:53:07 (Wed 24 Jan 2007)] [12965:0001] [info]
ajp_send_request::jk_ajp_common.c (1201): (mgf_worker2) error sending
request. Will try another pooled connection
[2007-01-24 01:53:07 (Wed 24 Jan 2007)] [12965:0001] [info]
ajp_send_request::jk_ajp_common.c (1227): (mgf_worker2) all endpoints are
disconnected
[2007-01-24 01:53:07 (Wed 24 Jan 2007)] [12965:0001] [info]
ajp_send_request::jk_ajp_common.c (1230): (mgf_worker2) increase the backend
idle connection timeout or the connection_pool_minsize
[2007-01-24 01:53:07 (Wed 24 Jan 2007)] [12965:0001] [info]
ajp_service::jk_ajp_common.c (1916): (mgf_worker2) sending request to tomcat
failed,  recoverable operation attempt=1
[2007-01-24 01:53:07 (Wed 24 Jan 2007)] URL : /mgf_mrtg/memory.jsp - Query
:  - Duration : 0.006798s

[2007-01-24 01:58:08 (Wed 24 Jan 2007)] [12841:0001] [info]
ajp_send_request::jk_ajp_common.c (1201): (mgf_worker2) error sending
request. Will try another pooled connection
[2007-01-24 01:58:08 (Wed 24 Jan 2007)] [12841:0001] [info]
ajp_send_request::jk_ajp_common.c (1227): (mgf_worker2) all endpoints are
disconnected
[2007-01-24 01:58:08 (Wed 24 Jan 2007)] [12841:0001] [info]
ajp_send_request::jk_ajp_common.c (1230): (mgf_worker2) increase the backend
idle connection timeout or the connection_pool_minsize
[2007-01-24 01:58:08 (Wed 24 Jan 2007)] [12841:0001] [info]
ajp_service::jk_ajp_common.c (1916): (mgf_worker2) sending request to tomcat
failed,  recoverable operation attempt=1
[2007-01-24 01:58:08 (Wed 24 Jan 2007)] URL : /mgf_mrtg/memory.jsp - Query
:  - Duration : 0.006775s

[2007-01-24 02:03:07 (Wed 24 Jan 2007)] [12792:0001] [info]
ajp_send_request::jk_ajp_common.c (1201): (mgf_worker2) error sending
request. Will try another pooled connection
[2007-01-24 02:03:07 (Wed 24 Jan 2007)] [12792:0001] [info]

mod_jk : error sending request

2007-01-23 Thread heind heind

Hi,

I have a web application deployed in tomcat embedded in jonas 4.7.4
Application Server, and  in frontend  there are apache 2.0.55 and mod_jk
12.20.

My issue is that the message below is generated systematically after every
jsp call  although the jsp are well served and the application works fine.


[2007-01-18 14:51:48 (Thu 18 Jan 2007)] [19047:0001] [info]
ajp_send_request::jk_ajp_common.c (1201): (mgf_worker2) error sending
request. Will try another p
ooled connection
[2007-01-18 14:51:48 (Thu 18 Jan 2007)] [19047:0001] [info]
ajp_send_request::jk_ajp_common.c (1227): (mgf_worker2) all endpoints are
disconnected
[2007-01-18 14:51:48 (Thu 18 Jan 2007)] [19047:0001] [info]
ajp_send_request::jk_ajp_common.c (1230): (mgf_worker2) increase the backend
idle connection time
out or the connection_pool_minsize
[2007-01-18 14:51:48 (Thu 18 Jan 2007)] [19047:0001] [info]
ajp_service::jk_ajp_common.c (1916): (mgf_worker2) sending request to tomcat
failed,  recoverable
operation attempt=1
[2007-01-18 14:53:09 (Thu 18 Jan 2007)] [19053:0001] [info]
ajp_send_request::jk_ajp_common.c (1201): (mgf_worker2) error sending
request. Will try another p
ooled connection
[2007-01-18 14:53:09 (Thu 18 Jan 2007)] [19053:0001] [info]
ajp_send_request::jk_ajp_common.c (1227): (mgf_worker2) all endpoints are
disconnected
[2007-01-18 14:53:09 (Thu 18 Jan 2007)] [19053:0001] [info]
ajp_send_request::jk_ajp_common.c (1230): (mgf_worker2) increase the backend
idle connection time
out or the connection_pool_minsize
[2007-01-18 14:53:09 (Thu 18 Jan 2007)] [19053:0001] [info]
ajp_service::jk_ajp_common.c (1916): (mgf_worker2) sending request to tomcat
failed,  recoverable
operation attempt=1

My question is what is the meaning of this message and how to avoid a second
attempt ?

PS :
- my Apache is 2.0.55 prefork so I can't increase the connectio_pool_minsize
(cf. http://tomcat.apache.org/connectors-doc/reference/workers.html)
- the workers.properties is in standard configuration.


Thanks,

Hind


mod_jk : error sending request. Will try another pooled connection

2007-01-23 Thread heind heind

Hi,

I have a web application deployed in tomcat embedded in jonas 4.7.4
Application Server, and  in frontend  there are apache 2.0.55 and mod_jk
12.20.

My issue is that the message below is generated systematically after every
jsp call although the jsp are well served and the application works fine.


[2007-01-18 14:51:48 (Thu 18 Jan 2007)] [19047:0001] [info]
ajp_send_request::jk_ajp_common.c (1201): (mgf_worker2) error sending
request. Will try another p
ooled connection
[2007-01-18 14:51:48 (Thu 18 Jan 2007)] [19047:0001] [info]
ajp_send_request::jk_ajp_common.c (1227): (mgf_worker2) all endpoints are
disconnected
[2007-01-18 14:51:48 (Thu 18 Jan 2007)] [19047:0001] [info]
ajp_send_request::jk_ajp_common.c (1230): (mgf_worker2) increase the backend
idle connection time
out or the connection_pool_minsize
[2007-01-18 14:51:48 (Thu 18 Jan 2007)] [19047:0001] [info]
ajp_service::jk_ajp_common.c (1916): (mgf_worker2) sending request to tomcat
failed,  recoverable
operation attempt=1
[2007-01-18 14:53:09 (Thu 18 Jan 2007)] [19053:0001] [info]
ajp_send_request::jk_ajp_common.c (1201): (mgf_worker2) error sending
request. Will try another p
ooled connection
[2007-01-18 14:53:09 (Thu 18 Jan 2007)] [19053:0001] [info]
ajp_send_request::jk_ajp_common.c (1227): (mgf_worker2) all endpoints are
disconnected
[2007-01-18 14:53:09 (Thu 18 Jan 2007)] [19053:0001] [info]
ajp_send_request::jk_ajp_common.c (1230): (mgf_worker2) increase the backend
idle connection time
out or the connection_pool_minsize
[2007-01-18 14:53:09 (Thu 18 Jan 2007)] [19053:0001] [info]
ajp_service::jk_ajp_common.c (1916): (mgf_worker2) sending request to tomcat
failed,  recoverable
operation attempt=1

My question is what is the meaning of this message and how to avoid a second
attempt ?

PS :
- my Apache is 2.0.55 prefork so I can't increase the connectio_pool_minsize
(cf. http://tomcat.apache.org/connectors-doc/reference/workers.html )
- the workers.properties is in standard configuration.


Thanks,

Hind


Re: FW: question regarding 'mod_jk: error flushing'

2006-11-02 Thread Durk Strooisma
Alright, thanks for your explanation!

Are the mod_jk: error flushing messages more or less harmless? If so, I
prefer sticking to 1.2.6 for the moment.

Durk

 Hi Durk,

 the flushing has been changed in May 2005 around the time of version
 1.2.13 or 1.2.14. Previously there were a lot of calls to ap_rflush()
 during the writing of responses. Because that produced many problems
 (not only log messages) concerning performance and memory requirements,
 these calls have been made optional.

 So updating to 1.2.19 really changes the flushing behaviour (and the
 log statement is not there any longer). The old behaviour (lots of
 flushing, but without the annoying log messages) can be configured with
 newer mod_jk with JkOptions +FlushPackets. That should only be
 necessary, if your application has complex timing requirements. Per
 default the switch is off.

 Regards,

 Rainer

 Durk Strooisma schrieb:
 Hi Durk,

 are you really talking about mod_jk?

 Yep, the package apache2-jakarta-tomcat-connectors contains (from
 the included README file):
 1. mod_jk + Ajp13Connector
 2. mod_jk2 + CoyoteConnector + JkCoyoteHandler
 3. mod_webapp + WarpConnector

 2 is experimental, 3 is deprected, we're using option 1; mod_jk.

 If yes: which version of nod_jk
 are  you using? It would be nice, if you could check version 1.2.19.

 It was kinda hard to figure out the version... I've grepped in
 /usr/lib/apache2/mod_jk.so for '1.2', and it came up with 1.2.6-dev.

 Source for the apache2-jakarta-tomcat-connectors package was a
 tarball called jakarta-tomcat-connectors-4.1.30-src.tar.gz. 4.1.30
 seems to be the version of connector bundle. I found the jk-version in
 jakarta-tomcat-connectors-4.1.30-src/jk/native/common/jk_version.h,
 which shows: 1.2.6, just as expected.

 Replacing this version with 1.2.9 isn't quite easy considering
 maintenance. The version that came with the SUSE-distribution ensures
 stability/compatibility (at least I may hope so considering it's an
 enterprise grade distro) and is easier maintainable (security updates
 just come with the update tool).

 Well, I COULD do some tests with other versions of mod_jk on the
 testing system, but as long as the issue doesn't harm the
 functionality of the web applications, I'm hesitating a little in
 investing my time and downtime of the system.

 But then again, IF a new version of mod_jk would eliminate the error
 messages, we still don't know why or what it actually was.

 Durk

 Regards,

 Rainer

 Durk Strooisma wrote:
 Hi all!

 I'm wondering the same.

 I've got four servers (two production machines and their testing
 counter parts) running SUSE Linux Enterprise Server 9 with Apache 2,
 Tomcat 5, and ModJK. Below the relevant packages are shown:

 apache2   2.0.49-27.59
 apache2-prefork   2.0.49-27.59
 apache2-jakarta-tomcat-connectors 5.0.19-29.1
 jakarta-tomcat5.0.19-29.1

 Since June 2006 I'm getting lots of mod_jk: Error flushing \n on
 one production system (and its testing system as well), but
 everything seems to work fine... The other production system isn't
 affected.

 It's kind of annoying that there's no timestamp shown in the error
 message. Debugging is really tough this way. I'm wondering what it
 means and whether it's harmless or not. Like Kevin states, nowhere
 on the internet this question seems to answered.

 Thanks in advance!

 Durk


 Hello there,

 Does anyone know what is this 'mod_jk: error flushing' about? I am
 using Tomcat 5.0, Apache and Mod_JK in production environment and
 keep getting this error in error log. I do google search and find
 lots of persons asking this question but no answer. Can anybody
 having experience with this shed a light on what it might be and
 how to resolve it?

 Thanks a lot,

 Kevin Song



 -
 To start a new topic, e-mail: users@tomcat.apache.org
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]


 --
 kippdata informationstechnologie GmbH
 Bornheimer Str. 33a
 53111 Bonn

 Tel. 0228/98549-0
 Fax  0228/98549-50
 www.kippdata.de
 ===
 kippdata informationstechnologie GmbH
 Bornheimer Str. 33a
 D-53111 Bonn
 Germany

 Tel. +49/228/98549-0
 Fax  +49/228/98549-50
 www.kippdata.de

 -
 To start a new topic, e-mail: users@tomcat.apache.org
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




 -
 To start a new topic, e-mail: users@tomcat.apache.org
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]


 -
 To start a new topic, e-mail: users@tomcat.apache.org
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail

Re: FW: question regarding 'mod_jk: error flushing'

2006-11-02 Thread Durk Strooisma
Thanks for looking into the source code.

Well as long as no functional or performance problems arise in our web
applications it seems to be okay. But, of course, the error messages are not
really satifying.

Anyway, I'll keep in mind that versions of mod_jk from 1.2.14 and above will
not be able to produce these error messages anymore.

Thanks again,

Durk



 I'm afraid I can't tell for sure. I browsed a little through the apache
  code but not deep enough. The call has been removed after a discussion
  more or less based on no other module calls flush like mod_jk, just
 remove it. I didn't find a reliable source of information, when
 ap_rflush() is needed and under which circumstances it does not return
 with success.

 But frankly I limited the search in case of time when I noticed, that
 the whole construction is gone in mod_jk since more than a year.

 Regards,

 Rainer

 Durk Strooisma wrote:
 Alright, thanks for your explanation!

 Are the mod_jk: error flushing messages more or less harmless? If
 so, I prefer sticking to 1.2.6 for the moment.

 Durk


Hi Durk,

the flushing has been changed in May 2005 around the time of version
1.2.13 or 1.2.14. Previously there were a lot of calls to ap_rflush()
during the writing of responses. Because that produced many problems
(not only log messages) concerning performance and memory
requirements, these calls have been made optional.

So updating to 1.2.19 really changes the flushing behaviour (and the
log statement is not there any longer). The old behaviour (lots of
flushing, but without the annoying log messages) can be configured
with newer mod_jk with JkOptions +FlushPackets. That should only be
necessary, if your application has complex timing requirements. Per
default the switch is off.

Regards,

Rainer

Durk Strooisma schrieb:

Hi Durk,

are you really talking about mod_jk?

Yep, the package apache2-jakarta-tomcat-connectors contains (from
the included README file):
1. mod_jk + Ajp13Connector
2. mod_jk2 + CoyoteConnector + JkCoyoteHandler
3. mod_webapp + WarpConnector

2 is experimental, 3 is deprected, we're using option 1; mod_jk.


If yes: which version of nod_jk
are  you using? It would be nice, if you could check version 1.2.19.

It was kinda hard to figure out the version... I've grepped in
/usr/lib/apache2/mod_jk.so for '1.2', and it came up with
1.2.6-dev.

Source for the apache2-jakarta-tomcat-connectors package was a
tarball called jakarta-tomcat-connectors-4.1.30-src.tar.gz. 4.1.30
seems to be the version of connector bundle. I found the jk-version
in
jakarta-tomcat-connectors-4.1.30-src/jk/native/common/jk_version.h,
which shows: 1.2.6, just as expected.

Replacing this version with 1.2.9 isn't quite easy considering
maintenance. The version that came with the SUSE-distribution ensures
stability/compatibility (at least I may hope so considering it's an
enterprise grade distro) and is easier maintainable (security updates
just come with the update tool).

Well, I COULD do some tests with other versions of mod_jk on the
testing system, but as long as the issue doesn't harm the
functionality of the web applications, I'm hesitating a little in
investing my time and downtime of the system.

But then again, IF a new version of mod_jk would eliminate the error
messages, we still don't know why or what it actually was.

Durk


Regards,

Rainer

Durk Strooisma wrote:

Hi all!

I'm wondering the same.

I've got four servers (two production machines and their testing
counter parts) running SUSE Linux Enterprise Server 9 with Apache
2, Tomcat 5, and ModJK. Below the relevant packages are shown:

apache2   2.0.49-27.59
apache2-prefork   2.0.49-27.59
apache2-jakarta-tomcat-connectors 5.0.19-29.1
jakarta-tomcat5.0.19-29.1

Since June 2006 I'm getting lots of mod_jk: Error flushing \n on
one production system (and its testing system as well), but
everything seems to work fine... The other production system isn't
affected.

It's kind of annoying that there's no timestamp shown in the error
message. Debugging is really tough this way. I'm wondering what it
means and whether it's harmless or not. Like Kevin states, nowhere
on the internet this question seems to answered.

Thanks in advance!

Durk



Hello there,

Does anyone know what is this 'mod_jk: error flushing' about? I am
using Tomcat 5.0, Apache and Mod_JK in production environment and
keep getting this error in error log. I do google search and find
lots of persons asking this question but no answer. Can anybody
having experience with this shed a light on what it might be and
how to resolve it?

Thanks a lot,

Kevin Song



-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


 -
 To start a new topic, e-mail

Re: FW: question regarding 'mod_jk: error flushing'

2006-11-01 Thread Durk Strooisma
 Hi Durk,

 are you really talking about mod_jk?

Yep, the package apache2-jakarta-tomcat-connectors contains (from the
included README file):
1. mod_jk + Ajp13Connector
2. mod_jk2 + CoyoteConnector + JkCoyoteHandler
3. mod_webapp + WarpConnector

2 is experimental, 3 is deprected, we're using option 1; mod_jk.

 If yes: which version of nod_jk
 are  you using? It would be nice, if you could check version 1.2.19.

It was kinda hard to figure out the version... I've grepped in
/usr/lib/apache2/mod_jk.so for '1.2', and it came up with 1.2.6-dev.

Source for the apache2-jakarta-tomcat-connectors package was a tarball
called jakarta-tomcat-connectors-4.1.30-src.tar.gz. 4.1.30 seems to be the
version of connector bundle. I found the jk-version in
jakarta-tomcat-connectors-4.1.30-src/jk/native/common/jk_version.h, which
shows: 1.2.6, just as expected.

Replacing this version with 1.2.9 isn't quite easy considering maintenance.
The version that came with the SUSE-distribution ensures
stability/compatibility (at least I may hope so considering it's an
enterprise grade distro) and is easier maintainable (security updates just
come with the update tool).

Well, I COULD do some tests with other versions of mod_jk on the testing
system, but as long as the issue doesn't harm the functionality of the web
applications, I'm hesitating a little in investing my time and downtime of
the system.

But then again, IF a new version of mod_jk would eliminate the error
messages, we still don't know why or what it actually was.

Durk


 Regards,

 Rainer

 Durk Strooisma wrote:
 Hi all!

 I'm wondering the same.

 I've got four servers (two production machines and their testing
 counter parts) running SUSE Linux Enterprise Server 9 with Apache 2,
 Tomcat 5, and ModJK. Below the relevant packages are shown:

 apache2   2.0.49-27.59
 apache2-prefork   2.0.49-27.59
 apache2-jakarta-tomcat-connectors 5.0.19-29.1
 jakarta-tomcat5.0.19-29.1

 Since June 2006 I'm getting lots of mod_jk: Error flushing \n on one
 production system (and its testing system as well), but everything
 seems to work fine... The other production system isn't affected.

 It's kind of annoying that there's no timestamp shown in the error
 message. Debugging is really tough this way. I'm wondering what it
 means and whether it's harmless or not. Like Kevin states, nowhere on
 the internet this question seems to answered.

 Thanks in advance!

 Durk


Hello there,

Does anyone know what is this 'mod_jk: error flushing' about? I am
using Tomcat 5.0, Apache and Mod_JK in production environment and keep
getting this error in error log. I do google search and find lots of
persons asking this question but no answer. Can anybody having
experience with this shed a light on what it might be and how to
resolve it?

Thanks a lot,

Kevin Song




 -
 To start a new topic, e-mail: users@tomcat.apache.org
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



 --
 kippdata informationstechnologie GmbH
 Bornheimer Str. 33a
 53111 Bonn

 Tel. 0228/98549-0
 Fax  0228/98549-50
 www.kippdata.de
 ===
 kippdata informationstechnologie GmbH
 Bornheimer Str. 33a
 D-53111 Bonn
 Germany

 Tel. +49/228/98549-0
 Fax  +49/228/98549-50
 www.kippdata.de

 -
 To start a new topic, e-mail: users@tomcat.apache.org
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: FW: question regarding 'mod_jk: error flushing'

2006-11-01 Thread Rainer Jung
Hi Durk,

the flushing has been changed in May 2005 around the time of version
1.2.13 or 1.2.14. Previously there were a lot of calls to ap_rflush()
during the writing of responses. Because that produced many problems
(not only log messages) concerning performance and memory requirements,
these calls have been made optional.

So updating to 1.2.19 really changes the flushing behaviour (and the log
statement is not there any longer). The old behaviour (lots of flushing,
but without the annoying log messages) can be configured with newer
mod_jk with JkOptions +FlushPackets. That should only be necessary, if
your application has complex timing requirements. Per default the switch
is off.

Regards,

Rainer

Durk Strooisma schrieb:
 Hi Durk,

 are you really talking about mod_jk?
 
 Yep, the package apache2-jakarta-tomcat-connectors contains (from the
 included README file):
 1. mod_jk + Ajp13Connector
 2. mod_jk2 + CoyoteConnector + JkCoyoteHandler
 3. mod_webapp + WarpConnector
 
 2 is experimental, 3 is deprected, we're using option 1; mod_jk.
 
 If yes: which version of nod_jk
 are  you using? It would be nice, if you could check version 1.2.19.
 
 It was kinda hard to figure out the version... I've grepped in
 /usr/lib/apache2/mod_jk.so for '1.2', and it came up with 1.2.6-dev.
 
 Source for the apache2-jakarta-tomcat-connectors package was a tarball
 called jakarta-tomcat-connectors-4.1.30-src.tar.gz. 4.1.30 seems to be the
 version of connector bundle. I found the jk-version in
 jakarta-tomcat-connectors-4.1.30-src/jk/native/common/jk_version.h, which
 shows: 1.2.6, just as expected.
 
 Replacing this version with 1.2.9 isn't quite easy considering maintenance.
 The version that came with the SUSE-distribution ensures
 stability/compatibility (at least I may hope so considering it's an
 enterprise grade distro) and is easier maintainable (security updates just
 come with the update tool).
 
 Well, I COULD do some tests with other versions of mod_jk on the testing
 system, but as long as the issue doesn't harm the functionality of the web
 applications, I'm hesitating a little in investing my time and downtime of
 the system.
 
 But then again, IF a new version of mod_jk would eliminate the error
 messages, we still don't know why or what it actually was.
 
 Durk
 
 Regards,

 Rainer

 Durk Strooisma wrote:
 Hi all!

 I'm wondering the same.

 I've got four servers (two production machines and their testing
 counter parts) running SUSE Linux Enterprise Server 9 with Apache 2,
 Tomcat 5, and ModJK. Below the relevant packages are shown:

 apache2   2.0.49-27.59
 apache2-prefork   2.0.49-27.59
 apache2-jakarta-tomcat-connectors 5.0.19-29.1
 jakarta-tomcat5.0.19-29.1

 Since June 2006 I'm getting lots of mod_jk: Error flushing \n on one
 production system (and its testing system as well), but everything
 seems to work fine... The other production system isn't affected.

 It's kind of annoying that there's no timestamp shown in the error
 message. Debugging is really tough this way. I'm wondering what it
 means and whether it's harmless or not. Like Kevin states, nowhere on
 the internet this question seems to answered.

 Thanks in advance!

 Durk


 Hello there,

 Does anyone know what is this 'mod_jk: error flushing' about? I am
 using Tomcat 5.0, Apache and Mod_JK in production environment and keep
 getting this error in error log. I do google search and find lots of
 persons asking this question but no answer. Can anybody having
 experience with this shed a light on what it might be and how to
 resolve it?

 Thanks a lot,

 Kevin Song



 -
 To start a new topic, e-mail: users@tomcat.apache.org
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]


 --
 kippdata informationstechnologie GmbH
 Bornheimer Str. 33a
 53111 Bonn

 Tel. 0228/98549-0
 Fax  0228/98549-50
 www.kippdata.de
 ===
 kippdata informationstechnologie GmbH
 Bornheimer Str. 33a
 D-53111 Bonn
 Germany

 Tel. +49/228/98549-0
 Fax  +49/228/98549-50
 www.kippdata.de

 -
 To start a new topic, e-mail: users@tomcat.apache.org
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 
 
 -
 To start a new topic, e-mail: users@tomcat.apache.org
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: FW: question regarding 'mod_jk: error flushing'

2006-10-31 Thread Durk Strooisma
Hi all!

I'm wondering the same.

I've got four servers (two production machines and their testing counter
parts) running SUSE Linux Enterprise Server 9 with Apache 2, Tomcat 5, and
ModJK. Below the relevant packages are shown:

apache2   2.0.49-27.59
apache2-prefork   2.0.49-27.59
apache2-jakarta-tomcat-connectors 5.0.19-29.1
jakarta-tomcat5.0.19-29.1

Since June 2006 I'm getting lots of mod_jk: Error flushing \n on one
production system (and its testing system as well), but everything seems to
work fine... The other production system isn't affected.

It's kind of annoying that there's no timestamp shown in the error message.
Debugging is really tough this way. I'm wondering what it means and whether
it's harmless or not. Like Kevin states, nowhere on the internet this
question seems to answered.

Thanks in advance!

Durk

 Hello there,

 Does anyone know what is this 'mod_jk: error flushing' about? I am using
 Tomcat 5.0, Apache and Mod_JK in production environment and keep getting
 this error in error log. I do google search and find lots of persons
 asking this question but no answer. Can anybody having experience with
 this shed a light on what it might be and how to resolve it?

 Thanks a lot,

 Kevin Song



-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



mod_jk error

2006-05-24 Thread Raman, Jay
Environment: 

Apache 2.0.54 running on Solaris

modJK 1.2.14 running on Solaris 

Tomcat 5.0.28 running on RedHat Linux AS 3

Workers.properties file:

 

worker.list=router

worker.router.host=lxdnp636.acme.com

worker.router.port=8009

worker.router.type=ajp13

worker.router.lbfactor=1

worker.router.cache_timeout=120

worker.router.socket_keepalive=1

worker.router.socket_timeout=60

worker.router.disabled=True

 

Every 4 or 5 hours we see the following error in mod_jk log.

 

[Wed May 24 21:10:00 2006] [error]
ajp_connection_tcp_get_message::jk_ajp_common.c (961): Can't receive the
response message from tomcat, network problems or tomcat is down
(151.116.4.77:8009), err=-131

 

When this happens, no response comes back when hitting the web server
URL

However if you hit the Tomcat URL results come back instantaneously.

 

This is not related to load since it happens even at 2 am when there is
no load.

 

Any help will be greatly appreciated!

 

Things become alright after 5 or 10 minutes!

 

Broadcom Ethernet NIC with tg3 driver

Solution slightly improved with the older unsupported bcm5700 driver.

 

 

 

Jay

 



mod_jk error log

2006-04-27 Thread Todd Huss
On all of our webservers from development (doing 1 page view every  
few minutes) to production (doing 500 page views per minute) we're  
seeing these error messages in the mod_jk log:


[Thu Apr 20 17:57:45 2006] [jk_ajp_common.c (783)]: ERROR: can't  
receive the response message from tomcat, network problems or tomcat  
is down (127.0.0.1:8009), err=-54
[Thu Apr 20 17:57:45 2006] [jk_ajp_common.c (1250)]: Tomcat is down  
or network problems. No response has been sent to the client (yet)
[Thu Apr 20 17:57:45 2006] [jk_ajp_common.c (1449)]: ERROR: Receiving  
from tomcat failed, recoverable operation. err=0
[Thu Apr 20 17:57:45 2006] [jk_ajp_common.c (1468)]: sending request  
to tomcat failed in send loop. err=0


The site appears to be working fine and I haven't noticed any  
problems but it's a little disconcerting to these messages going by  
every 5 minutes. We're running Apache 1.3.33 and Mod_jk 1.2.13 on  
FreeBSD. Any idea what configuration setting might be causing this  
and how we might fix it?


Thanks,
Todd

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: mod_jk error log

2006-04-27 Thread Mladen Turk

Todd Huss wrote:
On all of our webservers from development (doing 1 page view every few 
minutes) to production (doing 500 page views per minute) we're seeing 
these error messages in the mod_jk log:


[Thu Apr 20 17:57:45 2006] [jk_ajp_common.c (783)]: ERROR: can't receive 
the response message from tomcat, network problems or tomcat is down 
(127.0.0.1:8009), err=-54


You have connectionTimeout set in server.xml for
AJP/1.3 connector, correct?

We're running Apache 1.3.33 and Mod_jk 1.2.13 on FreeBSD. Any 
idea what configuration setting might be causing this and how we might 
fix it?




Use mod_jk 1.2.15 (latest stable). 1.2.13 is a mess.
Look at:
http://tomcat.apache.org/connectors-doc/changelog.html

Regards,
Mladen.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: mod_jk error log

2006-04-27 Thread thuss2

Hi Mladen,

I'll upgrade to the latest mod_jk. I do have a timeout set as follows:

Connector port=8009 connectionTimeout=2
   maxThreads=500 minSpareThreads=5 maxSpareThreads=75
   enableLookups=false redirectPort=8443 debug=0
   protocol=AJP/1.3 /

Then in my workers.properties we have:

worker.tomcat.socket_timeout=60

Does that look OK?
--
View this message in context: 
http://www.nabble.com/mod_jk-error-log-t1519311.html#a4126407
Sent from the Tomcat - User forum at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



FW: question regarding 'mod_jk: error flushing'

2006-04-10 Thread Kevin Song
Hello there,

 

Does anyone know what is this 'mod_jk: error flushing' about? I am using
Tomcat 5.0, Apache and Mod_JK in production environment and keep getting
this error in error log. I do google search and find lots of persons
asking this question but no answer. Can anybody having experience with
this shed a light on what it might be and how to resolve it?

 

 

Thanks a lot,

 

Kevin Song

 



mod_jk error -60

2006-03-29 Thread Earnie Dyke
Can anyone tell me what a -60 error is?

[Wed Mar 29 13:56:11 2006] [error] jk_ajp_common.c (961): Can't receive the 
response message from tomcat, network problems or tomcat is down 
(10.1.1.80:8009), err=-60

Earnie!

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: mod_jk error -60

2006-03-29 Thread Rainer Jung

In case of an error this line will print errno as a negative number.

More precisely:

#if defined(WIN32) || (defined(NETWARE)  defined(__NOVELL_LIBC__))
...
errno = WSAGetLastError() - WSABASEERR;
...
#endif
...
do some read from network
...
return (errno  0) ? -errno : errno;

On Solaris errno 60 is ENOSTR. You need to check, what errno 60 is on 
your platform.


Rainer

Earnie Dyke wrote:

Can anyone tell me what a -60 error is?

[Wed Mar 29 13:56:11 2006] [error] jk_ajp_common.c (961): Can't receive the 
response message from tomcat, network problems or tomcat is down 
(10.1.1.80:8009), err=-60

Earnie!

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: mod_jk error -60

2006-03-29 Thread Rainer Jung

I don't know, how correct it is, but the following table looks helpful:

http://www.ioplex.com/~miallen/errcmp.html

It says, that 60 is a time out (ETIMEDOUT) on FreeBSD 5.2.1, OSX 10.3.8 
and OSF1.


Rainer Jung wrote:

In case of an error this line will print errno as a negative number.

More precisely:

#if defined(WIN32) || (defined(NETWARE)  defined(__NOVELL_LIBC__))
...
errno = WSAGetLastError() - WSABASEERR;
...
#endif
...
do some read from network
...
return (errno  0) ? -errno : errno;

On Solaris errno 60 is ENOSTR. You need to check, what errno 60 is on 
your platform.


Rainer

Earnie Dyke wrote:

Can anyone tell me what a -60 error is?

[Wed Mar 29 13:56:11 2006] [error] jk_ajp_common.c (961): Can't 
receive the response message from tomcat, network problems or tomcat 
is down (10.1.1.80:8009), err=-60


Earnie!

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: mod_jk error numbers

2006-02-16 Thread Mladen Turk

Filip Hanik - Dev Lists wrote:
1. What does the 449 and 461 numbers mean? A: My guess would be line 
numbers




Sure those are line numbers, but for [debug] those
are not errors :)
As well as for [info] and [warn].

Anyhow the format is:
[DATE] [PID:ThreadID] [LEVEL] sourcefile (line number): log message ...



2. Is there a security hole in our server?


No. mod_jk will try to map any request from the wire,
and if no match is found (JkMount) it will return 404.


A: What is your setup like, do you have an apache in front of an apache?



I must say that I don't follow this one.
What could mod_jk do in front of another apache?

Regards,
Mladen.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



mod_jk error numbers

2006-02-14 Thread Peters Jan
Hi all,
 
I would like to ask the list if someone can give me a hint, what might
have gone wrong with our mod_jk. I just installed the connector and
switched logging to debug mode. When I open  the log file I see the
following:
 
[Tue Feb 14 18:00:23 2006] [27276:50880] [debug]
map_uri_to_worker::jk_uri_worker_map.c (449): Attempting to map URI
'/proxycheck.php' from 4 maps
[Tue Feb 14 18:00:23 2006] [27276:50880] [debug]
map_uri_to_worker::jk_uri_worker_map.c (461): Attempting to map context
URI '/servlets-examples/*'
[Tue Feb 14 18:00:23 2006] [27276:50880] [debug]
map_uri_to_worker::jk_uri_worker_map.c (461): Attempting to map context
URI '/jsp-examples/*.jsp'
[Tue Feb 14 18:00:23 2006] [27276:50880] [debug]
map_uri_to_worker::jk_uri_worker_map.c (461): Attempting to map context
URI '/esriadmin/*'
[Tue Feb 14 18:00:23 2006] [27276:50880] [debug]
map_uri_to_worker::jk_uri_worker_map.c (461): Attempting to map context
URI '/servlet/*'
[Tue Feb 14 18:00:23 2006] [27275:50880] [debug]
map_uri_to_worker::jk_uri_worker_map.c (449): Attempting to map URI
'/cgi-bin/iframe/autovol' from 4 maps
[Tue Feb 14 18:00:23 2006] [27275:50880] [debug]
map_uri_to_worker::jk_uri_worker_map.c (461): Attempting to map context
URI '/servlets-examples/*'
[Tue Feb 14 18:00:23 2006] [27275:50880] [debug]
map_uri_to_worker::jk_uri_worker_map.c (461): Attempting to map context
URI '/jsp-examples/*.jsp'
[Tue Feb 14 18:00:23 2006] [27275:50880] [debug]
map_uri_to_worker::jk_uri_worker_map.c (461): Attempting to map context
URI '/esriadmin/*'
[Tue Feb 14 18:00:23 2006] [27275:50880] [debug]
map_uri_to_worker::jk_uri_worker_map.c (461): Attempting to map context
URI '/servlet/*'
[Tue Feb 14 18:00:35 2006] [27272:50880] [debug]
map_uri_to_worker::jk_uri_worker_map.c (449): Attempting to map URI
'/ip.cgi' from 4 maps

over and over. What bothers me is the existence of the '/proxycheck.php'
, '/cgi-bin/iframe/autovol' and '/ip.cgi'  entries, since these are the
same requests at our apache firewall in mod_secure. These should have
been blocked, but seem to get through to the connector. So my questions
are:
 
1. What does the 449 and 461 numbers mean? 
2. Is there a security hole in our server?
 
Thanks for any reply and best regards
 
Jan Peters-Anders