I guess, by "Strange" you don't mean your status 500. That's something I
didn't go into. I only checked the headers and where they come from.
In your case it seems the correct headers get received after the flush.
even without the Tomcat fix. Without the mod_jk fix, any flush before
You need to build those yourself. The build works exactly like for an
official release. There might be some bugs inside this snapshot
> Hi rainer,
>
> I've attached 2 logfiles. The first one is the mod_jk.log in debug mode,
> the other on is the output on my screen (dosbox) when I tried to access
> the webserver via a testtool and sending some data to the appserver.
>
> Strange things happened when i crosscheck the output data (check the
> timestamps) on mod_jk.log and my screen. Maybe you can explain what is
> going on :-/
>
> Thx and greetz, david
>
>> -----Original Message-----
>> From: Rainer Jung [mailto:
rainer.jung@...]
>> 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/dev@.../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