Hi Rainer,

I just use mod_jk to connect apache to tomcat.  I don't do anything special
with the configurations:  i just have a few virtual hosts that contain a few
JkMounts and some apache rewrites.  Do you think switching to mod_proxy_ajp
would make the problem go away?

Thanks,
Dave


Rainer Jung-3 wrote:
> 
> dave.smith schrieb:
>> Yesterday, I upgraded our dev environment to mod_jk 1.2.26, which
>> couldn't
>> have been easier.  It will probably take me a couple of days before I can
>> get this done in production, though.
>> 
>> I terminate all HTTPS requests before they get to the web server, so from
>> what you have described, it is probably safe to disable the APR
>> connector. 
>> How do I disable it, though?  I will look into disabling this after I
>> have
>> updated mod_jk in production.
> 
> Locate the tcnative shared object file (tcnative.so or tcnative-1.so) 
> and renme it, so that the linker loader does not find it (e.g. add an 
> underscore at the end of the file name).
> 
> Then during the next startup, Tomcat should emit an info level log 
> message telling you, that it couldn't find the lib.
> 
>> Here's the full stack trace for that exception, displayed in my Tomcat
>> logs:
>> 
>> Jul 10, 2008 10:06:50 PM org.apache.catalina.connector.Request
>> parseParameters
>> WARNING: Exception thrown whilst processing POSTed parameters
>> java.io.IOException: Socket read failed
>>         at
>> org.apache.coyote.ajp.AjpAprProcessor.read(AjpAprProcessor.java:1037)
>>         at
>> org.apache.coyote.ajp.AjpAprProcessor.readMessage(AjpAprProcessor.java:1158)
>>         at
>> org.apache.coyote.ajp.AjpAprProcessor.receive(AjpAprProcessor.java:1090)
>>         at
>> org.apache.coyote.ajp.AjpAprProcessor$SocketInputBuffer.doRead(AjpAprProcessor.java:1228)
>>         at org.apache.coyote.Request.doRead(Request.java:419)
>>         at
>> org.apache.catalina.connector.InputBuffer.realReadBytes(InputBuffer.java:265)
>>         at
>> org.apache.tomcat.util.buf.ByteChunk.substract(ByteChunk.java:403)
>>         at
>> org.apache.catalina.connector.InputBuffer.read(InputBuffer.java:280)
>>         at
>> org.apache.catalina.connector.CoyoteInputStream.read(CoyoteInputStream.java:193)
>>         at
>> org.apache.catalina.connector.Request.readPostBody(Request.java:2400)
>>         at
>> org.apache.catalina.connector.Request.parseParameters(Request.java:2379)
>>         at
>> org.apache.catalina.connector.Request.getParameterNames(Request.java:1047)
>>         at
>> org.apache.catalina.connector.RequestFacade.getParameterNames(RequestFacade.java:369)
>>         at
>> org.apache.struts.util.RequestUtils.populate(RequestUtils.java:1225)
>>         at
>> org.apache.struts.action.RequestProcessor.processPopulate(RequestProcessor.java:821)
>>         at
>> org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:254)
>>         at
>> org.apache.struts.action.ActionServlet.process(ActionServlet.java:1482)
>>         at
>> org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:525)
>>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
>>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
>>         at
>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269)
>>         at
>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
>>         at
>> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
>>         at
>> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:174)
>>         at
>> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
>>         at
>> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
>>         at
>> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108)
>>         at
>> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:151)
>>         at
>> org.apache.coyote.ajp.AjpAprProcessor.process(AjpAprProcessor.java:444)
>>         at
>> org.apache.coyote.ajp.AjpAprProtocol$AjpConnectionHandler.process(AjpAprProtocol.java:472)
>>         at
>> org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1286)
>>         at java.lang.Thread.run(Thread.java:595)
> 
> OK, thanks. You are sure it is not 5.5.26?
> 
> Regards,
> 
> Rainer
> 
>> Rainer Jung-3 wrote:
>>> Hi David,
>>>
>>> dave.smith schrieb:
>>>> Hi Rainer,
>>>>
>>>> Thanks a lot for the reply.
>>>>
>>>> I am using Tomcat 5.5.25 (rpm from jpackage.org).  CentOS Linux 2.6.18.
>>>>
>>>> httpd was compiled in prefork mode. The prefork settings are:
>>>>
>>>> StartServers       8
>>>> MinSpareServers    5
>>>> MaxSpareServers   20
>>>> ServerLimit      256
>>>> MaxClients       256
>>>> MaxRequestsPerChild  4000
>>>>
>>>> I have setup JMeter to run against a test environment, but was unable
>>>> to
>>>> reproduce.  These random responses occur in production about once every
>>>> week
>>>> or so/more.  The problem will often (temporarily) correct itself, but
>>>> sometimes I will need to restart httpd if the problem persists --
>>>> restarting
>>>> tomcat also works to temporarily correct the problem.
>>>>
>>>> The only thing strange that I see in my logs are in the
>>>> test_client.log:
>>>>
>>>> WARNING: Exception thrown whilst processing POSTed parameters 
>>>> java.io.IOException: Socket read failed
>>>>         at
>>>> org.apache.coyote.ajp.AjpAprProcessor.read(AjpAprProcessor.java:1037)
>>>>         ...
>>> Thanks for the information. What is "test_client.log"? It looks like a 
>>> Tomcat log file? Could you also post a larger part of the stack, or do 
>>> you only get one line?
>>>
>>> Would you be able to do the following two things, maybe not both at the 
>>> same time:
>>>
>>> - disable the apr connector (tcnative.so)
>>> - upgrade jk to 1.2.26
>>>
>>> Concerning the apr connector: If you are using OpenSSL with apr and 
>>> Tomcat or you have some similar reason you really need it, then don't 
>>> switch. But if you use it without a very specific reason, disabling it 
>>> for a week or two would help us isolate the problem.
>>>
>>> Concerning mod_jk upgrade: That should be very easy, apart from the 
>>> following: if your httpd uses VirtualHost in the configuration, you have 
>>> to include your JkMount inside the VirtualHost, not in the global part, 
>>> or you add JkMountCopy On to the VirtualHost.
>>>
>>> Regards,
>>>
>>> Rainer
>>>
>>>> Rainer Jung-3 wrote:
>>>>> dave.smith schrieb:
>>>>>>> Wow. That's weird. Is Tomcat serving the file, or is httpd serving
>>>>>>> it?
>>>>>> Not too weird.  I am experiencing the same thing with Tomcat 5.5 and
>>>>>> mod_jk
>>>>>> 1.2.23.  I have Tomcat serving everything.
>>>>>>
>>>>>> I am also using a load balancer that sends an OPTION every 2 seconds
>>>>>> to
>>>>>> each
>>>>>> web server to make sure that the server is alive.
>>>>>>
>>>>>> This intermittent random response issue is really killing me.
>>>>> Could you please also add some info:
>>>>>
>>>>> Tomcat version?
>>>>>
>>>>> And from my previous mail:
>>>>>
>>>>> What's you platform and which httpd MPM (prefork orworker or something 
>>>>> else) do you use? For some platforms (e.g. AIX) the detection of 
>>>>> multi-threading in httpd during mpod_jk build-time was broken.
>>>>> Starting 
>>>>> with 1.2.24 we build always including multi-thread support unless 
>>>>> explicitely stated via a configure option. If you 1.2.23 build is not 
>>>>> thread safe, but your httpd uses threads (like with worker mpm), then 
>>>>> such trouble is possible, although more likely you would see crashes 
>>>>> etc. For most platforms like Linux and Solaris the threading detection 
>>>>> was OK already before 1.2.24.
>>>>>
>>>>> Another possible (but not very likely) cause could be bug 44494 of 
>>>>> Tomcat 6.0.16/5.5.26 which under certain circumstances could leave
>>>>> data 
>>>>> in the request object after request handling completed. You could try 
>>>>> either downgrading to 6.0.15/5.5.25 or upgrading to the soon to be 
>>>>> expected 6.0.17/5.5.27.
>>>>>
>>>>> I would also add the access log on the Tomcat side. If you find the
>>>>> same 
>>>>> phenomenon there, then it's unlikely, that httpd/mod_jk are
>>>>> responsible 
>>>>> and the reason should be inside Tomcat or the webapp.
>>>>>
>>>>> Can you reproduce the problem on a test system?
>>>>>
>>>>> 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]
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Apache-mod_jk-serves-random-files-from-tomcat-tp18385568p18515074.html
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]

Reply via email to