Eric,
Isn't the ajp13 specified in the workers2.properties simply a designation of
protocol and not telling the client (Apache mod_jk2) which connector to use on the
tomcat side. It should only know host, port, protocol (ajp13 vs ajp12).
Again, although I see the sytax differences in our two workers2.properties
configurations I don't see the logical differences. The mod_jk2 assumes a lot from
the naming convention of the workers and it is possible to create a configuration
using a very minimal amount of text in a workers2.properties but I went with the more
explicit approach which should be logically equivalent. Can you site any specific
instances where your configuration is logically different from mine?
Is using the 2.0.2 build of the connectors preferable to using the build
distributed with Tomcat 4.1.24 which I used? What kind of a user load does your
mod_jk2 configuration handle on a daily basis? How many concurrent sessions do you
run per application server, etc?
Thanks again for your help!
Jamey
-----Original Message-----
From: Eric J. Pinnell [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 01, 2003 6:09 PM
To: Tomcat Users List
Subject: RE: PLEASE HELP - Apache mod_jk2 loses communication with
Tomcat
Hi,
On Tue, 1 Jul 2003, James Courtney wrote:
> Thanks Eric.
> I'm still puzzled though. I don't really see any difference in
> what you're doing vs. what I'm doing. I explicitly specify host and
> port for the channel sockets and I explicitly define the workers but
> that's shouldn't make any difference should it? Is there anything in
> particular in my workers2.properties which is actually not correct?
I'd look closer. There are quite a bit of differences.
>
> Please recall that my cluster works for a time and then
> communication falters between the servers. This doesn't seem like a
> config problem as a config problem would probably preclude things
> working correctly in the first place.
I'm not so sure about that. But I would start with the low hanging fruit
first. My JK2 has worked fine for dayzzzz. In fact in another thread we
were talking about how mixing Ajp13 and Coyote causes unexpected errors
and general "freaky-out-ness" with no explanation what so ever. I notice
you declare ajp13 in your workers2.properties file as part of the channel.
>
> Is the general opinion that mod_jk2 is ready for production use or
> is it likely still a little rough? I'm having a lot of trouble getting
> mod_jk to work though as an alternative. I'm using the release of
> mod_jk(2) from the Tomcat 4.1.24 release which can be found at:
I think so. It's just a refactoring of mod_jk with some twists. But it
will never get there if people don't try to use it! :)
>
> http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.1.24/src/
I use:
http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk2/release/v2.0.2/src/jakarta-tomcat-connectors-jk2-2.0.2-src.tar.gz
-e
>
> Thanks!
>
> Jamey
>
>
> -----Original Message-----
> From: Eric J. Pinnell [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, July 01, 2003 2:34 PM
> To: Tomcat Users List
> Subject: Re: PLEASE HELP - Apache mod_jk2 loses communication with
> Tomcat
>
>
> Your workers2.properties looks a little off. I don't know if this is the
> root of your problem but it should look more like:
>
> [shm]
> file=${serverRoot}/logs/shm.file
> size=1048576
>
> [lb:lb_01]
> info=Default load balancer.
> debug=0
>
> # Example socket channel, override port and host.
> [channel.socket:localhost:8109]
> info=Ajp13 forwarding over a TCP socket
> tomcatId=worker1:8109
> lb_factor=100
> group=lb_01
>
> # define the worker
> [channel.socket:localhost:8209]
> info=A second tomcat instance on a different port.
> tomcatId=worker2:8209
> lb_factor=100
> group=lb_01
>
> # Uri mapping
> [uri:/*]
> group=lb_01
> debug=0
>
> You have to adjust it to your own needs. You can change 'localhost' to
> another IP or servername.
>
> -e
>
> On Tue, 1 Jul 2003, James Courtney wrote:
>
> > I'm trying again as no one responded to my first email. We REALLY need to resolve
> > this issue. Thanks!
> >
> >
> > We recently upgraded our production systems to Tomcat 4.1.24 and Apache 2.0.45
> > from 3.2.2 and 1.3.19 respectively and have noticed a VERY pleasing increase in
> > performance and over an 80% reduction in system load. We also decided to deploy
> > with mod_jk2 and the whole system behaved itself quite well during QA and some
> > load testing (admittedly not overly thorough). We pushed to production and things
> > ran fine for a couple of days but now, every day or two, our Apache partially
> > loses communication with one of the two Tomcats it's load balancing accross (not
> > always the same one). The result is that requests block on Apache and the load
> > goes up as users click away trying to get their page(s) to load. Restarting the
> > Tomcat seems to rectify the problem until the next time...
> >
> > Any thoughts on this problem and the overall maturity of mod_jk2 vs. mod_jk would
> > be very helpful. Many thanks to all!
> >
> >
> > Jamey
> >
> >
> > James Courtney
> > InPhonic, Inc.
> > Hayward, CA
> >
> >
> > *******************
> > ** Apache Errors **
> > *******************
> > inunison.com:8081 145 Connection timed out [Wed Jun 25 15:08:10 2003] [error]
> > ajp13.connect() failed ajp13:portal4.somedomain.com:8081 [Wed Jun 25 15:08:10
> > 2003] [error] ajp13.service() failed to connect endpoint errno=145 Connection
> > timed out [Wed Jun 25 15:08:10 2003] [error] ajp13.service() Error forwarding
> > ajp13:portal4.somedomain.com:8081 1 1 [Wed Jun 25 15:08:10 2003] [error]
> > lb.service() worker failed 120000 for ajp13:portal4.somedomain.com:8081 [Wed Jun
> > 25 15:08:13 2003] [error] channelSocket.open() connect failed
> > portal4.somedomain.com:8081 145 Connection timed out [Wed Jun 25 15:08:13 2003]
> > [error] ajp13.connect() failed ajp13:portal4.somedomain.com:8081 [Wed Jun 25
> > 15:08:13 2003] [error] ajp13.service() failed to connect endpoint errno=145
> > Connection timed out [Wed Jun 25 15:08:13 2003] [error] ajp13.service() Error
> > forwarding ajp13:portal4.somedomain.com:8081 1 1 [Wed Jun 25 15:08:13 2003]
> > [error] lb.service() worker failed 120000 for ajp13:portal4.somedomain.com:8081
> > [Wed Jun 25 15:08:22 2003] [error] channelSocket.open() connect failed
> > portal4.somedomain.com:8081 145 Connection timed out [Wed Jun 25 15:08:22 2003]
> > [error] ajp13.connect() failed ajp13:portal4.somedomain.com:8081 [Wed Jun 25
> > 15:08:22 2003] [error] ajp13.service() failed to connect endpoint errno=145
> > Connection timed out [Wed Jun 25 15:08:22 2003] [error] ajp13.service() Error
> > forwarding ajp13:portal4.somedomain.com:8081 1 1 [Wed Jun 25 15:08:22 2003]
> > [error] lb.service() worker failed 120000 for ajp13:portal4.somedomain.com:8081
> >
> > ****************************
> > ** WORKERS2 CONFIGURATION **
> > ****************************
> > # only at beginning. In production uncomment it out
> > [logger.apache2]
> > level=ERROR
> >
> > [shm]
> > file=/tmp/workers2shmDONOTDELETE.file
> > size=1048576
> >
> > # portal3 socket
> > [channel.socket:portal3.somedomain.com:8081]
> > host=portal3.somedomain.com
> > port=8081
> > tomcatId=portal3
> > group=lb:balanced
> > graceful=1
> >
> > # portal3 worker
> > [ajp13:portal3.somedomain.com:8081]
> > channel=channel.socket:portal3.somedomain.com:8081
> > lb_factor=12
> >
> > # portal4 socket
> > [channel.socket:portal4.somedomain.com:8081]
> > host=portal4.somedomain.com
> > port=8081
> > tomcatId=portal4
> > group=lb:balanced
> >
> > # portal4 worker
> > [ajp13:portal4.somedomain.com:8081]
> > channel=channel.socket:portal4.somedomain.com:8081
> > lb_factor=12
> >
> >
> > # Load balanced worker
> > [lb:balanced]
> > worker=ajp13:portal3.somedomain.com:8081
> > worker=ajp13:portal4.somedomain.com:8081
> > # sticky is on by default but setting it adds a harmless error to the log
> > #stickySession=1
> >
> >
> > # Define a status worker
> > [status:status]
> >
> >
> > # URI mapping
> > [uri:/*]
> > group=lb:balanced
> >
> >
> > # Status URI mapping (should not be publicly accessible!!!)
> > [uri:/jkstatus]
> > group=status:status
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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]
>
>
>
---------------------------------------------------------------------
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]
