it slower (
once disk heads start moving... ). Good and safe default would be 1 init
thread and max bound by cpus available in the system ?
Regards,
Darius.
--
View this message in context:
http://old.nabble.com/parallel-webapp-initialization-tp32619136p32620647.html
Sent from the Tomcat
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
rvices that throw NPEs and it seems that some
tomcat code is affected too with (1).
I'd grateful if some smart guys could look into this problem and willing to
provide any other info.
Only connector running is:
Also using
BR,
Darius.
--
est as shown in
access logs (and even request.getQueryString() is valid :) ) , processed
request from same user 5s ago, will process one more 5s later, but somehow
request is NULL??? Now we handle it by retrying, but such random NULL is
fatal for other servlets and services that throw NPEs and it seems
d.conf.
>
> ProxyPass / http://localhost:8080 route=msf1
>
> Regards
> Rakesh
>
>
>
Hi,
can you check your catalina.out to see if there is something like:
org.apache.coyote.http11.AbstractHttp11Processor endRequest
SEVERE: Error finishing response
java.lang.NullPointerExcepti
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
Hello,
I have test environment with tomcat 5.0.30 on Debian testing. Test
application is configured as such:
Evrything is working fine, except when trying to deploy new application.
Which is done by simply deleting old content and puting new jsp pages,
libs and compiled classes. After that, tomc
16 matches
Mail list logo
