-----Original Message-----
From: Rainer Jung [mailto:[EMAIL PROTECTED]
Sent: Friday, November 02, 2007 12:38 PM
To: Tomcat Users List
Subject: Re: mod_jk - answers from appsrv often changes
'content-type' from text/xml to text/plain
Hi,
there is a known problem in the AJP connector related to
flush actions done by the webapp before the response headers
were sent. The problem was fixed by patches on both sides.
Fpr mod_jk we ignore flushes if they come too early. This
code is already in our subversion code repository and will be
released as part of version 1.2.26.
On the Tomcat side there is a fix for the AJP connector to
not send out the flush, until the headers got sent. The fix is
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/java/o
rg/apache/jk/core/MsgContext.java?view=diff&r1=580814&r2=58081
5&pathrev=580815
and was done on October 1rst. The upcoming TC 6.0.15 will
include the fix, and any new TC 5.5 we release. For 5.5 there
is no release in sight yet. You can apply the patch yourself
though (and build) or build directly ffrom a subversion HEAD.
Can you reproduce the problem easily, also on a test system?
If so, I would be interested in a JK logfile made with
"JkLogLevel trace".
Using that I could check, if your problem really is the same,
as the above described.
Regards,
Rainer
MUDA(David Murko) wrote:
Dear all,
We have a strange problem with mod_jk on my linux box (centos45 -
64bit).
We use mod_jk 1.2.25 with apache 2.0.52 (default config) and on my
clients I got an error msg like this:
System.InvalidOperationException:
Client found response content type of 'text/plain; charset=UTF-8',
but
expected 'text/xml'
Our configuration is like this (all systems running
Centos45 x86_64):
Webserver with mod_jk -> Appserver with jboss 4.2 -> DB server
Our clients are posting data to a soap service (axis)
running on jboss
and expect an answer in text/xml like this:
####
Response: [
HTTP/1.1 200 OK
Date: Tue, 30 Oct 2007 10:54:59 GMT
Server: Apache/2.0.52 (CentOS)
X-Powered-By: Servlet 2.4; JBoss-4.2.0.CR1 (build:
SVNTag=JBoss_4_2_0_CR1 date=200703051212)/Tomcat-5.5
Connection: close
Content-Type: text/xml;charset=UTF-8
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><soap:Body
/></soap:Envelope> ] ####
but we very often got back this (sometimes the first 3 times the
answer is text/xml and ok but then switches to text/plain ... so it
switches always and the only workaround with this config is
to restart
the webserver and do it again)
####
Response: [
HTTP/1.1 200 OK
Date: Tue, 30 Oct 2007 16:44:55 GMT
Server: Apache/2.0.52 (CentOS)
Vary: Accept-Encoding,User-Agent
Connection: close
Content-Type: text/plain; charset=UTF-8
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><soap:Body
/></soap:Envelope> ] #####
We tried also to test it on a windows box (and mod_jk
1.2.22) with the
same results:
#####
Response: [
HTTP/1.1 200 OK
Date: Tue, 30 Oct 2007 10:54:59 GMT
Server: Apache/2.2.4 (Win32) mod_jk/1.2.22
X-Powered-By: Servlet 2.4; JBoss-4.2.0.CR1 (build:
SVNTag=JBoss_4_2_0_CR1 date=200703051212)/Tomcat-5.5
Connection: close
Content-Type: text/xml;charset=UTF-8
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><soap:Body
/></soap:Envelope> ] ####
and switches to this response:
####
Response: [
HTTP/1.1 200 OK
Date: Tue, 30 Oct 2007 10:55:32 GMT
Server: Apache/2.2.4 (Win32) mod_jk/1.2.22
Connection: close
Content-Type: text/plain
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><soap:Body
/></soap:Envelope> ] ####
Our client systems can only proper work with a response as
'content-type text/xml'
The only solution we found to do is use mod_jk 1.2.19 - It
also works
always when we go directly to jboss-tomcat port 8080 - We
found also
this case description in the archive
http://www.mail-archive.com/[EMAIL PROTECTED]/msg20475.html .
Do anyone have a solution to use it with mod_jk 1.2.25 ?
Thx and greetz, david
A sample config from mod_jk is below:
mod-jk.conf
#####
# Jakarta Tomcat Connector #
# Load mod_jk module
# Specify the filename of the mod_jk lib
LoadModule jk_module modules/mod_jk.so
# Where to find workers.properties
JkWorkersFile conf/workers.properties
# Where to put jk logs
JkLogFile logs/mod_jk.log
# Set the jk log level [debug/error/info]
JkLogLevel info
# Select the log format
JkLogStampFormat "[%a %b %d %H:%M:%S %Y]"
# JkOptions indicates to send SSK KEY SIZE
JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories
# JkRequestLogFormat
JkRequestLogFormat "%w %V %T"
# Mount your applications
# JkMount /application/* loadbalancer
# You can use external file for mount points.
# It will be checked for updates each 60 seconds.
# The format of the file is: /url=worker # /examples/*=loadbalancer
JkMountFile conf/uriworkermap.properties
# Add shared memory.
# This directive is present with 1.2.10 and # later versions of
mod_jk, and is needed for # for load balancing to work properly
JkShmFile /var/cache/httpd/jk.shm
# Add jkstatus for managing runtime data
<Location /jkstatus/>
JkMount status
Order deny,allow
Deny from all
Allow from 127.0.0.1
</Location>
uriworkermap.properties
####
# Simple worker configuration file
# Mount the Servlet context to the ajp13 worker
/jmx-console=node1
/jmx-console/*=node1
/web-console=node1
/web-console/*=node1
/MCWeb=node1
/MCWeb/*=node1
/MC=node1
/MC/*=node1
workers.properties
####
# Define list of workers that will be used # for mapping requests
worker.list=node1,status
# Define Node1
# modify the host as your host IP or DNS name.
worker.node1.port=8009 ## used for jboss ##
worker.node1.host=10.16.45.12
worker.node1.type=ajp13
worker.node1.socket_timeout=10
worker.node1.socket_keepalive=False
# Status worker for managing load balancer
worker.status.type=status