Re: parallel webapp initialization

2011-10-09 Thread Darius D.
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

Re: Request params randomly null in servlet(s)

2011-09-15 Thread Darius D.
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. --

Re: Request params randomly null in servlet(s)

2011-09-15 Thread Darius D.
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.

Re: Request params randomly null in servlet(s)

2011-09-14 Thread Darius D.
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.

Re: Request params randomly null in servlet(s)

2011-09-14 Thread Darius D.
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

Request params randomly null in servlet(s)

2011-09-14 Thread Darius D.
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

Re: Apache Tomcat unable to send the request. tomcat throwing 502 Gate Way error

2011-09-13 Thread Darius D.
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

Re: Apache Tomcat unable to send the request. tomcat throwing 502 Gate Way error

2011-09-12 Thread Darius D.
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"/>

RE: Performance for many small requests

2011-09-03 Thread Darius D.
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

Re: Performance for many small requests

2011-09-03 Thread Darius D.
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

RE: Performance for many small requests

2011-09-03 Thread Darius D.
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. >

Re: Performance for many small requests

2011-09-03 Thread Darius D.
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

Re: APR connector pollTime defaults are strange in tomcat6/7

2011-08-01 Thread Darius D.
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

Re: APR connector pollTime defaults are strange in tomcat6/7

2011-07-22 Thread Darius D.
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

APR connector pollTime defaults are strange in tomcat6/7

2011-07-18 Thread Darius D.
>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