FYI, I've answered my own problem... First, the cause of this problem:
When using AJP, this problem is caused by a request coming from the httpd (apache) server to tomcat, but the apache server is stopped from listening for the response from the tomcat server. Usually this is caused by a user clicking on a new link before tomcat has a chance to respond (fully), so apache has moved on - but tomcat doesn't know about it. It can be safely ignored. Second, how do you fix it? For my case, I added the following 2 lines to the bottom of the 'logging.properties' (we use the default JULI logging package): org.apache.jk.common.ChannelSocket.level = SEVERE org.apache.jk.common.ChannelSocket.handlers = 2localhost.org.apache.juli.FileHandler The first line tells JULI to only log 'SEVERE' errors from this class. The second line ties this logging class to the standard FileHandler in JULI. (You may have a different setup on this second line - I just copied it from another line in the file for the "FileHandler" setup, and then changed the class to match the ChannelSocket class I needed to adjust. I figured this out by figuring out which line mapped the handler to the 'catalina.out' file, and then duplicated that setup...) The reason I'm bothering to note this here is because in all the research I've done on this - I found not one single "answer" to how to make it stop. -- Robin D. Wilson Director of Web Development KingsIsle Entertainment, Inc. WORK: 512-623-5913 CELL: 512-426-3929 www.KingsIsle.com -----Original Message----- From: Robin Wilson [mailto:rwil...@kingsisle.com] Sent: Friday, April 24, 2009 3:56 PM To: users@tomcat.apache.org Subject: org.apache.jk.common.ChannelSocket processConnection WARNING: processCallbacks status 2 I'm trying to figure out what this means, and how to stop it... We're getting following error repeated in our catalina.out logs: Apr 24, 2009 8:42:24 AM org.apache.jk.common.ChannelSocket processConnection WARNING: processCallbacks status 2 Apr 24, 2009 8:44:00 AM org.apache.jk.common.ChannelSocket processConnection WARNING: processCallbacks status 2 Apr 24, 2009 8:46:36 AM org.apache.jk.common.ChannelSocket processConnection WARNING: processCallbacks status 2 Apr 24, 2009 8:46:38 AM org.apache.jk.common.ChannelSocket processConnection WARNING: processCallbacks status 2 Apr 24, 2009 8:46:39 AM org.apache.jk.common.ChannelSocket processConnection WARNING: processCallbacks status 2 Apr 24, 2009 8:46:40 AM org.apache.jk.common.ChannelSocket processConnection WARNING: processCallbacks status 2 Apr 24, 2009 9:44:17 AM org.apache.jk.common.ChannelSocket processConnection WARNING: processCallbacks status 2 Apr 24, 2009 9:45:03 AM org.apache.jk.common.ChannelSocket processConnection WARNING: processCallbacks status 2 Apr 24, 2009 10:10:42 AM org.apache.jk.common.ChannelSocket processConnection WARNING: processCallbacks status 2 Apr 24, 2009 10:10:43 AM org.apache.jk.common.ChannelSocket processConnection WARNING: processCallbacks status 2 Apr 24, 2009 10:10:45 AM org.apache.jk.common.ChannelSocket processConnection WARNING: processCallbacks status 2 Apr 24, 2009 10:10:45 AM org.apache.jk.common.ChannelSocket processConnection WARNING: processCallbacks status 2 Apr 24, 2009 10:16:05 AM org.apache.jk.common.ChannelSocket processConnection WARNING: processCallbacks status 2 ... It goes on like this all day long - every few minutes we get another error. We'd like to know what's causing it - and whether there is any way to prevent it (or even filter it if it isn't worth worrying about). Our production team is a stickler for not logging things that don't require action (in production), so they are really queasy about this repeated error. FYI, our configuration is: 4 Apache 2.2.11 servers (running on Red Hat Linux boxes) each Apache is currently running in a 1:1 AJP Proxy connection to 1 of: 4 tomcat 6.0.18 servers (running on Red Hat Linux boxes) So "apache 1" connects only to "tomcat 1", and "apache 2" connects only to "tomcat 2", etc. (We're working on getting our tomcat clustering stable enough to deploy.) One of the things that is preventing our roll out of full clustering is understanding the nature of this error in the catalina.out logs. Also, all 4 tomcat servers are identically configured with the same webapps, and the apache servers are load-balanced, but setup with "sticky sessions" so a browser will stay with the same apache once they connect. We do have <distributable /> setup in our web.xml for one of our web apps, and we have a clustering "basic" (the defaults from one of the docs on clustering) setup in the 'server.xml' file. This seems to work - but we throw a lot of errors when we actually try to use clustered sessions - so we're working through those as quickly as we can. -- Robin D. Wilson Director of Web Development KingsIsle Entertainment, Inc. www.KingsIsle.com --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
