Alexander Knöller wrote:
>
> Hello mailing list.
>
> We use a single tomcat instance (soon switching from 5.5.23 to 7.x) with
> 24 webapps. Each webapp is based on spring and hibernate doing a lot of
> I/O during initialization.
> Tomcat is often restarted which causes long downtimes. As far a
Pid * wrote:
>
>
> Exactly which version of Tomcat are you running?
>
>
Latest, 7.0.21.
--
View this message in context:
http://old.nabble.com/Request-params-randomly-null-in-servlet%28s%29-tp32461421p32474158.html
Sent from the Tomcat - User mailing list archive at Nabble.com.
--
Pid * wrote:
>
>
> What is your server.xml config? (please remove comments, passwords etc
> & post it inline, in the response)
>
>
Here it is, nothing special ( except usage of RemoteIpValve ). Thanks for
looking into this problem.
Pid * wrote:
>
> On 14/09/2011 11:55, Darius D. wrote:
>
> They are in *that* thread.
>
> It is possible to expose either request or response object outside of
> the scope of the thread, so a second request sees a modified version of
> the same object.
>
> E.g.
Pid * wrote:
>
> doProcess(req, res) is not a Servlet API method. What other method(s)
> call it?
>
> Usually this type of thing occurs because the request (or response) is
> being held as an instance field somewhere in a thread-unsafe way.
>
>
It is called from:
public void doGet(H
Hi,
we have a problem of request params beeing null in servlets where it
shouldn't be ( post or get, in get we can even see that
request.getQueryString() is fine, but params are null).
It is more pronounced when using dedicated thread executor, moving to
threads provided by connector itself (wit
ss(Http11Processor.java:845)
> at
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
> at
> org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:354)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886
rakesh k-3 wrote:
>
> Hi Christopher
>
> thanks for viewing m configuration ..as mentioned we are using http
> connectors in my configuration not AJP.
>
> and here are my configuration details.
>
> Apache tomcat configuration (server.xml)
>
> maxThreads="150" minSpareThreads="4"/>
Jeff Sturm wrote:
>
>
> The Linux JVM has a nice option -XX:+UseLargePages to help avoid TLB
> misses on heap accesses. It's good for modest gains, and has the side
> effect of locking the heap into memory. I tend to use it on systems with
> large heaps.
>
> Not much you can do about cache
David Kerber wrote:
>
> On 9/3/2011 1:15 PM, Darius D. wrote:
>>
>>
>> n828cl wrote:
>>>> From: Darius D. [mailto:darius@gmail.com]
>>>> Subject: Re: Performance for many small requests
>>>> in my opinion using 64bit JVM with
n828cl wrote:
>
>> From: Darius D. [mailto:darius@gmail.com]
>> Subject: Re: Performance for many small requests
>
>> in my opinion using 64bit JVM with such a small
>> heap is only needed if performance testing shows
>> gains versus 32bit JVM.
>
Some good advice in this thread already, but given the power of server there
should be no problem serving even more requests ( as long as they are small,
not bound by CPU or I/O).
I'd start looking at JVM GC properties.
Turn on gc logging with
-Xloggc:/someplace/gclog_tomcat.txt -XX:+PrintGCDe
ould be no harm by setting it to 100 microseconds, as NIO
connectors are using 1000ms as default selectorTimeout ( same epoll inside )
and working just fine.
Christopher Schultz-2 wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Darius,
>
> On 7/1
Darius D. wrote:
>
>
> Does Tomcat APR really needs pollTime set so low by default? I thought
> timeout is meant for some sort of book keeping, where is all connections
> in FD set are "idle", no events come for timeout period - you force
> timeout and do bookke
>From documentation:
TC6:
Duration of a poll call. Lowering this value will slightly decrease latency
of connections being kept alive in some cases, but will use more CPU as more
poll calls are being made. The default value is 2000 (5ms).
TC7:
Duration of a poll call in microseconds. Lowering
15 matches
Mail list logo