Re: OutOfMemoryError: PermGen space

[Román Valoria]

Cris:

You are looking at the wrong memory object. You need to focus on the
PermGen memory tab, not the Heap one.

That is, of course, if your memory error is indeed mentioning PermGen as in
the subject of this mail.

Again the PermGen holds the classes metadata definitions, so it should not
be impacted by how many times you call the classes or how much memory they
consume or how much data you are loading into memory.

I have never ran it with anything later than Java 6 and Tomcat 7, so I
cannot comment you your other errors.

Regards,

Roman.

On Tue, Jul 19, 2016 at 10:08 PM, Berneburg, Cris J. - US <
cberneb...@caci.com> wrote:

> Román
>
> Thanks for taking the time to reply and educate me.  :-)  Please see my
> ramblings below.
>
> -Original Message-
> From: Román Valoria [mailto:romanvalo...@gmail.com]
> Sent: Thursday, July 14, 2016 11:28 PM
> To: Tomcat Users List
> Subject: Re: OutOfMemoryError: PermGen space
>
> > Cris:
> >
> > Couple of things here.
> >
> > First, you can use in any Java 6 Update 45 and above the Java Visual VM,
> > to monitor in real time the memory utilization done by the Java virtual
> > machine. This will show you both the Help and Perm Gen memory graphs.
> > You can find this tool in the bin directory of any JDK.
>
>
> Thanks for suggesting that.  I have never used the Java Visual VM before.
> Upon trying it, I can't seem to get the tool to find Tomcat running, even
> when starting the tool with administrative privileges.  The only local
> application it sees is itself, VisualVM.  Tomcat is not visible to the tool
> running either as a Windows service nor by starting using startup.bat.
>
> Having never used the tool before I suspect I have missed something very
> basic.  Hmm... Google says I need to enable JMX on Tomcat and then add the
> JMX connection to Visual VM.  No dice, still can't see Tomcat.  Java bug
> #7009828 (http://bugs.java.com/bugdatabase/view_bug.do?bug_id=7009828)
> prevents Visual VM from connecting but says I can launch the tool with
> Java's temp directory matching Tomcat's temp dir (or something like that).
> That did it!  Now Visual VM can see Tomcat.
>
> I took a snapshot and heap dump, restarted my app 5x, then took another
> snapshot and heap dump.  The first dump is 25MB, and the second after all
> the restarts is 46MB.  The top 3 classes in both are java.lang.String,
> char[], java.util.HashMap$Entry.  How do I pinpoint where a potential
> problem is?
>
> In Visual VM, under File, Compare Memory Snapshots, it does not see the
> snapshots I generated.  The snapshots appear to be extension *.apps, but
> the compare function looks for files with extension *.nps.  I don't know
> how to get the compare function to work.
>
> Not sure where to go from here.  Got any suggestions?
>
>
> > Second, you can issue some Java parameters to actually enlarge the
> > PermGen memory allocation upon startup. Please refer to your java
> > version documentation on Oracle and lookup for the -XX parameters.
> >
> > You can start by enlarging your PermGen space and the monitor on the
> > Visual VM the behavior, if you consistently run out of memory, then
> > you may have a leak.
> >
> > Of course that you would be constrained by the fact of running a
> > 32-bit or 64-bit Tomcat / Java environment.
> >
> >
> > On Fri, Jul 15, 2016 at 2:26 AM, Berneburg, Cris J. - US <
> cberneb...@caci.com> wrote:
> >
> > > Hi Folks
> > >
> > > I got this error from the Tomcat Web Application Manager after having
> > > stopped and started one of the applications multiple times.  (This was
> > > after repeatedly deploying the application manually to attempt to find
> > > a bug that I could not reproduce in my IDE.)  Once the error occurred,
> > > the server was extremely sluggish to respond even to remote desktop
> > > mouse and keyboard events.
> > >
> > > FYI, I deploy the app by stopping it on the Tomcat web manager,
> > > deleting almost everything out of the app folder using file manager,
> > > copying the new files and folders in, then starting the app from the
> Tomcat manager.
> > >
> > > Here's the error:
> > >
> > > FAIL - Application at context path /someapp could not be started FAIL
> > > - Encountered exception java.lang.OutOfMemoryError: PermGen space
> > >
> > > Is this likely due to a memory leak in my application?  Or does it
> > > have something to do with me doing so many repeated deployments?  Or
> > > perhaps simply from restarting the app so many times?  I might try an
> > > experiment to see how many times I can stop/start the app before the
> error next occurs.
> > >
> > > OS: Win Server 2012 R2
> > > Java: 1.6.0_24  (oops, need to upgrade that now)
> > > Tomcat: 6.0.37  (hmm... will need to upgrade soon-ish)
> > >
> > > --
> > > Cris Berneburg, Lead Software Engineer, CACI
> > >
>
> --
> Cris Berneburg, Lead Software Engineer, CACI
>
>

Re: NullPointerExceptions from Coyote over SSL

[Peter Robbins]

Without JCE or BC? Both are pretty critical for core functionality and didn't 
cause any issues until 8.5.3 entered the mix. Any known issues there I should 
be aware of?

Peter

On Jul 19, 2016 6:24 PM, R?my Maucherat  wrote:
2016-07-19 23:51 GMT+02:00 Peter Robbins :

> Hi there,
>
> JCE, Bouncy Castle 1.48
>
> Maybe try without that first.

R?my

Re: NullPointerExceptions from Coyote over SSL

[Rémy Maucherat]

2016-07-19 23:51 GMT+02:00 Peter Robbins :

> Hi there,
>
> JCE, Bouncy Castle 1.48
>
> Maybe try without that first.

Rémy

NullPointerExceptions from Coyote over SSL

[Peter Robbins]

Hi there,

Versions: Tomcat 8.5.3, JDK 1.8 + JCE, Bouncy Castle 1.48, Ubuntu 14.04 & 
16.04,Windows 2012 R2

I’m running into an issue where we are getting NullPointerExceptions from the 
Coyote connector in a Tomcat web application.

This is an existing, stable web application that was recently upgraded to 
Tomcat 8.5.3. When we repeatedly send requests over HTTPS eventually (after 30 
or so rapid requests) the web app becomes largely unresponsive and the catalina 
log fills up with errors like this:

 BEGIN LOG 

18-Jul-2016 10:47:30.066 WARNING [Tomcat-7] 
org.apache.tomcat.util.net.AbstractEndpoint.countDownConnection Incorrect 
connection count, multiple socket.close called on the same socket.

18-Jul-2016 10:47:36.707 INFO [Tomcat-6] 
org.apache.coyote.http11.Http11Processor.service Error parsing HTTP request 
header
 Note: further occurrences of HTTP header parsing errors will be logged at 
DEBUG level.
 java.lang.IllegalStateException: Unexpected state: headers already parsed. 
Buffer not recycled?
at 
org.apache.coyote.http11.Http11InputBuffer.parseHeaders(Http11InputBuffer.java:587)
at 
org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:1010)
at 
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
at 
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:785)
at 
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1425)
at 
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:52)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at 
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:745)

18-Jul-2016 10:47:36.815 SEVERE [Tomcat-12] 
org.apache.coyote.http11.Http11Processor.service Error processing request
 java.lang.NullPointerException
at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:389)
at 
org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:1110)
at 
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
at 
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:785)
at 
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1425)
at 
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:52)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at 
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:745)

18-Jul-2016 10:47:36.816 SEVERE [Tomcat-12] 
org.apache.coyote.http11.Http11Processor.endRequest Error finishing response
 java.lang.NullPointerException
at 
org.apache.coyote.http11.Http11OutputBuffer.flushBuffer(Http11OutputBuffer.java:533)
at 
org.apache.coyote.http11.Http11OutputBuffer.endRequest(Http11OutputBuffer.java:318)
at 
org.apache.coyote.http11.Http11Processor.endRequest(Http11Processor.java:1794)
at 
org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:1149)
at 
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
at 
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:785)
at 
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1425)
at 
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:52)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at 
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:745)

18-Jul-2016 10:56:54.739 INFO [https-jsse-nio-8443-ClientPoller-1] 
org.apache.catalina.connector.CoyoteAdapter.checkRecycled Encountered a 
non-recycled request and recycled it forcedly.
 org.apache.catalina.connector.CoyoteAdapter$RecycleRequiredException
at 
org.apache.catalina.connector.CoyoteAdapter.checkRecycled(CoyoteAdapter.java:494)
at 
org.apache.coyote.http11.Http11Processor.recycle(Http11Processor.java:1840)
at 
org.apache.coyote.AbstractProtocol$ConnectionHandler.release(AbstractProtocol.java:955)
at 
org.apache.coyote.AbstractProtocol$ConnectionHandler.release(AbstractProtocol.java:976)
at 
org.apache.tomcat.util.net.NioEndpoint$Poller.cancelledKey(NioEndpoint.java:730)
at 

Tomcat Log file setting.

[Boyle, James A]

Hello,
   I have a web app running on my workstation using Tomcat 7 and 
have the following entries in my console output. Any help would be appreciated. 
Thanks.

INFO: Initializing log4j from 
[file:///c://lbxdw_ido_obm//conf//LOCALlog4j_JAB.xml] This is the log4j config 
file and is a good file.
log4j:ERROR setFile(null,true) call failed. Not sure why this is being 
generated. I specify the Error appender in the config file appropriately
java.io.FileNotFoundException: D:\Apps\Tomcat 7.2\logs\IDOMailLOCAL1.log (The 
device is not ready) This is the issue. My D drive is the DVD drive, but the 
kicker is that I cant find anywhere in my app or within Tomcat where this 
setting is being made. Nothing residual in the registry. Is there some sort of 
.ini file that I am missing?

Log4j config file

http://jakarta.apache.org/log4j/; 
debug="true">
   
  
  
 
  
   
   
  
  
  
 
  
   
   
  
  
  
 
  
   
   
  
  
   

Jim Boyle
Wholesale Lockbox Technology
Bank of America
(617) 533-4532
james.a.bo...@baml.com

--
This message, and any attachments, is for the intended recipient(s) only, may 
contain information that is privileged, confidential and/or proprietary and 
subject to important terms and conditions available at 
http://www.bankofamerica.com/emaildisclaimer.   If you are not the intended 
recipient, please delete this message.

Re: OutOfMemoryError: PermGen space

[Mark Thomas]

On 19/07/2016 17:19, Berneburg, Cris J. - US wrote:



>> This is probably a useful read:
>> http://people.apache.org/~markt/presentations/2010-11-04-Memory-Leaks-60mins.pdf
>>
>> Despite the age, it is still very relevant today.
> 
> 
> Thanks for reminding me about that document.  It does sound relevant.  The 
> document says,
> 
>> How memory leaks occur: Reference chains
>> [...]
>> Retaining a reference to a single object from a web application
>> pins every class loaded by the web application in the Permanent
>> Generation
> 
> Practically speaking, how is a reference retained?
> 1. Is a module-level (member) variable in a Servlet an example?

No. Assuming the class that defines the Servlet is packaged with the web
application (i.e. in a JAR in WEB-INF/lib or in WEB-INF/classes

> 2. How about using ServletContext.setAttribute without an accompanying 
> removeAttribute?

No.

> 3. I see in one of my listeners some member (module-level) variables: a 
> private static for the logger and also a protected final String.  Is that a 
> problem?

No.

> If you could provide a little more guidance about the details, I would 
> appreciate it.

Sure.

There are two categories of objects we are concerned about. Objects
defined by classes that are provided by your web application (in
WEB-INF/lib or WEB-INF/classes) and objects defined by classes that are
provided by the container (Tomcat) or the JVM.

References from web application objects to web application objects are fine.

References from web application objects to container objects are fine.

References from container objects to web application objects are
potentially a problem.

Additionally, references from container objects to the web application
class loader are potentially a problem.

For example:

When you start a thread in a web application, the thread context class
loader will be the web application class loader and the thread holds a
reference to this. If the thread is not stopped when the web application
is stopped there will be a reference held to the web application class
loader which will cause a leak.

If you add a logging framework to Tomcat's lib directory and then
package a custom log formatter with your web application, the formatter
will be registered with the logging framework and unless you unregister
it when the application stops there will be reference from logging
framework to custom formatter object to custom formatter class to web
application class loader which will cause a leak.

HTH,

Mark

P.S. I'll be talking about this (hopefully - if my talk gets accepted)
at ApacheCon EU later this year.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: OutOfMemoryError: PermGen space

[Berneburg, Cris J. - US]

Mark

Thanks for taking the time to answer my questions.  Please see my response and 
questions below.

-Original Message-
From: Mark Thomas [mailto:ma...@apache.org] 
Sent: Thursday, July 14, 2016 2:58 PM
To: Tomcat Users List
Subject: Re: OutOfMemoryError: PermGen space

> On 14/07/2016 20:26, Berneburg, Cris wrote:
> 
> > Hi Folks
> > 
> > I got this error from the Tomcat Web Application Manager after having
> > stopped and started one of the applications multiple times.  (This was
> > after repeatedly deploying the application manually to attempt to find
> > a bug that I could not reproduce in my IDE.)  Once the error occurred,
> > the server was extremely sluggish to respond even to remote desktop
> > mouse and keyboard events.
> > 
> > [SNIP]
> > 
> > Here's the error:
> > 
> > FAIL - Application at context path /someapp could not be started FAIL 
> > - Encountered exception java.lang.OutOfMemoryError: PermGen space
> > 
> > Is this likely due to a memory leak in my application?
> 
> Yes.
> 
> >  Or does it have something to do with me doing so many repeated deployments?
> 
> Also yes.
> 
> >  Or perhaps simply from restarting the app so many times?
> 
> Stop/start has the same effect as redeploy in this case.
> 
> >  I might try an experiment to see how many times I can stop/start the
> > app before the error next occurs.
> > 
> > OS: Win Server 2012 R2
> > Java: 1.6.0_24  (oops, need to upgrade that now)
> > Tomcat: 6.0.37  (hmm... will need to upgrade soon-ish)
> 
> Indeed. Some upgrades are certainly in order. Not least because some of
> the potential sources of memory leaks are JVM bugs that are fixed in
> the lastest Java 8 releases.
> 
> This is probably a useful read:
> http://people.apache.org/~markt/presentations/2010-11-04-Memory-Leaks-60mins.pdf
> 
> Despite the age, it is still very relevant today.


Thanks for reminding me about that document.  It does sound relevant.  The 
document says,

> How memory leaks occur: Reference chains
> [...]
> Retaining a reference to a single object from a web application
> pins every class loaded by the web application in the Permanent
> Generation

Practically speaking, how is a reference retained?
1. Is a module-level (member) variable in a Servlet an example?
2. How about using ServletContext.setAttribute without an accompanying 
removeAttribute?
3. I see in one of my listeners some member (module-level) variables: a private 
static for the logger and also a protected final String.  Is that a problem?

If you could provide a little more guidance about the details, I would 
appreciate it.

> Mark

--
Cris Berneburg, Lead Software Engineer, CACI


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: OutOfMemoryError: PermGen space

[Jäkel , Guido]

>In Visual VM, under File, Compare Memory Snapshots, it does not see the 
>snapshots I generated.  The snapshots appear to
>be extension *.apps, but the compare function looks for files with extension 
>*.nps.  I don't know how to get the compare
>function to work.
>
>Not sure where to go from here.  Got any suggestions?

You may pull heap dumps and use the Eclipse Memory Analyzer Toolkit (aka MAT)  
(http://www.eclipse.org/mat/) to discover stale objects danging on the webapps 
classloader. The tool may be used stand-alone (via an included  Eclipse RCP) or 
as an Eclipse Plugin.


Greetings

Guido

RE: OutOfMemoryError: PermGen space

[Berneburg, Cris J. - US]

Román

Thanks for taking the time to reply and educate me.  :-)  Please see my 
ramblings below.

-Original Message-
From: Román Valoria [mailto:romanvalo...@gmail.com] 
Sent: Thursday, July 14, 2016 11:28 PM
To: Tomcat Users List
Subject: Re: OutOfMemoryError: PermGen space

> Cris:
> 
> Couple of things here.
> 
> First, you can use in any Java 6 Update 45 and above the Java Visual VM,
> to monitor in real time the memory utilization done by the Java virtual
> machine. This will show you both the Help and Perm Gen memory graphs.
> You can find this tool in the bin directory of any JDK.


Thanks for suggesting that.  I have never used the Java Visual VM before.  Upon 
trying it, I can't seem to get the tool to find Tomcat running, even when 
starting the tool with administrative privileges.  The only local application 
it sees is itself, VisualVM.  Tomcat is not visible to the tool running either 
as a Windows service nor by starting using startup.bat.

Having never used the tool before I suspect I have missed something very basic. 
 Hmm... Google says I need to enable JMX on Tomcat and then add the JMX 
connection to Visual VM.  No dice, still can't see Tomcat.  Java bug #7009828 
(http://bugs.java.com/bugdatabase/view_bug.do?bug_id=7009828) prevents Visual 
VM from connecting but says I can launch the tool with Java's temp directory 
matching Tomcat's temp dir (or something like that).  That did it!  Now Visual 
VM can see Tomcat.

I took a snapshot and heap dump, restarted my app 5x, then took another 
snapshot and heap dump.  The first dump is 25MB, and the second after all the 
restarts is 46MB.  The top 3 classes in both are java.lang.String, char[], 
java.util.HashMap$Entry.  How do I pinpoint where a potential problem is?

In Visual VM, under File, Compare Memory Snapshots, it does not see the 
snapshots I generated.  The snapshots appear to be extension *.apps, but the 
compare function looks for files with extension *.nps.  I don't know how to get 
the compare function to work.

Not sure where to go from here.  Got any suggestions?


> Second, you can issue some Java parameters to actually enlarge the
> PermGen memory allocation upon startup. Please refer to your java
> version documentation on Oracle and lookup for the -XX parameters.
> 
> You can start by enlarging your PermGen space and the monitor on the
> Visual VM the behavior, if you consistently run out of memory, then
> you may have a leak.
>
> Of course that you would be constrained by the fact of running a
> 32-bit or 64-bit Tomcat / Java environment.
> 
> 
> On Fri, Jul 15, 2016 at 2:26 AM, Berneburg, Cris J. - US < 
> cberneb...@caci.com> wrote:
> 
> > Hi Folks
> >
> > I got this error from the Tomcat Web Application Manager after having 
> > stopped and started one of the applications multiple times.  (This was 
> > after repeatedly deploying the application manually to attempt to find 
> > a bug that I could not reproduce in my IDE.)  Once the error occurred, 
> > the server was extremely sluggish to respond even to remote desktop 
> > mouse and keyboard events.
> >
> > FYI, I deploy the app by stopping it on the Tomcat web manager, 
> > deleting almost everything out of the app folder using file manager, 
> > copying the new files and folders in, then starting the app from the Tomcat 
> > manager.
> >
> > Here's the error:
> >
> > FAIL - Application at context path /someapp could not be started FAIL 
> > - Encountered exception java.lang.OutOfMemoryError: PermGen space
> >
> > Is this likely due to a memory leak in my application?  Or does it 
> > have something to do with me doing so many repeated deployments?  Or 
> > perhaps simply from restarting the app so many times?  I might try an 
> > experiment to see how many times I can stop/start the app before the error 
> > next occurs.
> >
> > OS: Win Server 2012 R2
> > Java: 1.6.0_24  (oops, need to upgrade that now)
> > Tomcat: 6.0.37  (hmm... will need to upgrade soon-ish)
> >
> > --
> > Cris Berneburg, Lead Software Engineer, CACI
> >

--
Cris Berneburg, Lead Software Engineer, CACI

Re: mod-jk (1.2.37) crashes Apache 2 (2.4.7) occasionally with a buffer overflow on Ubuntu 14.04 x64

[Michael Diener]

Chris,

thanks a lot for explaining what could be overflowing the FD_SETSIZE of
1024.

Just for reference, I use mpm_event mostly with SSL connections, so it
should behave like mpm_worker. This is my configuration:

StartServers 2
ServerLimit  16

MinSpareThreads  256
MaxSpareThreads  1280

ThreadLimit  1024
ThreadsPerChild  1024

MaxRequestWorkers 16384
MaxConnectionsPerChild   0


One more thing, poll() seems to be used in jk_connect.c in other places
already, just not at the spot that matters in my case.

Anyhow, I will submit a bug report later this week with all the information
and will post a link over here as well.

Thank you,
Michael




On 18 July 2016 at 16:56, Christopher Schultz 
wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Michael,
>
> On 7/18/16 10:10 AM, Christopher Schultz wrote:
> > Michael,
> >
> > On 7/18/16 8:53 AM, Michael Diener wrote:
> >> On 6 July 2016 at 00:09, Christopher Schultz
> >>  wrote:
> >
>  From what I understand a buffer overflow would only happen
>  for FD_SET if the fd_set gets over 1024 descriptors. I made
>  sure that my ulimit for open files is set and applied large
>  enough, so that's not it.
> >>>
> >>> There's nothing magic about the ulimit. An fd_set should size
> >>> appropriately for your OS. On my Linux system, FD_SETSIZE
> >>> happens to be set to 1024. Reading through the byzantine
> >>> labyrinth of includes, it appears that FD_SET has zero
> >>> boundary-checking, so it's therefore possible that overflow
> >>> will occur.
> >
> >
> >> Regarding the FD_SETSIZE, it is also set for me to 1024 although
> >> the ulimit is set higher.
> >
> > Well, the FD_SETSIZE is just the maximum size of the fd set that
> > can be passed-into select() specifically. That doesn't limit the
> > number of file descriptors your processes can open. The ulimit
> > settings are the limits on those.
> >
> >> I'm a bit lost now on what I should do now. What makes me wonder
> >> is, that nobody else seems to hit this limitation of FD_SET and
> >> this makes me think something on my Linux machine is not right.
> >
> > Well, not everyone is using the same setup. For example, using NIO
> > through Java is likely to get you the poll() call under the hood,
> > so supporting more than e.g. 1024 file descriptors is not an issue
> > there. That's just a guess, but I think it's a reasonable guess.
> >
> > I think tcnative+APR is not widely deployed. I have no numbers to
> > back that up, but we don't get a huge volume of questions in the
> > list about it.
>
> Of course, the above statement makes no sense whatsoever. This is
> about mod_jk and not tcnative. Sorry for the confusion.
>
> But I was thinking, the case above would require a single httpd thread
> to accumulate more than 1024 connections, and that would require some
> very specific circumstances.
>
> First, you'd have to be using an MPM that allowed more than one
> connection per process/thread, so that means no pre-fork, leaving
> basically event or worker available.
>
> Then, you'd have to have enough traffic to cause one thread to grow to
> more than 1024 connections. The default for httpd's worker MPM has 64
> threads per child and 16 server processes.
>
> For one process to exceed the 1024 fd limit, you'd have to be handling
> roughly 16 simultaneous connections per thread PER PROCESS. I'm not
> sure how httpd auto-scales-out its child processes, so you could
> conceivably get 1024 simultaneous connections in a burst of requests
> to a single child process, but it seems likely that load would be
> roughly-split between 16 child processes, keeping those 1024
> connections down to a mild 64-jk-connections per-process.
>
> Assuming you have 16 child processes and a perfectly uniform
> load-distribution between them, you'd have to get a burst of 16k
> simultaneous requests in order to max-out that fd array on a single
> server. That's probably why it's quite rare.
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJXjO4tAAoJEBzwKT+lPKRYb9wP/j2i6FW7gOGf/G4/CTundEMY
> WcKKPfNXAOU270KyiBkuSLw06Cjw8mk3vsjpg5i5JkPC4TUNy1jyhaI5cs0RvisV
> pzqFgZCuyz4gPtg4TRCXw5RrmLwe7unBldTETjK54P9/Nd6Vuj34mUV8OLcnYZh6
> UMCe0ULbBV5IoGhLmGQ5yy7MfHGdq1vwmxR41i4A4rc4J9fOC1UI4pIOvJRM1cnT
> 5cfLEavT3tbqxaxLCs5V/pQkkuwQMKITSW+JGdDPxN3oXL7b1QCw8RGBqhpDgjE/
> FIIIBGfbMGHDXstmSBRXGlxkASKKdYlK9qoYU3f7G0PK053zx5TD+2vOfb0u0Vi/
> lwIkk3lhL7Azw9hYKFr1R+PW3ewUqXI7Nh05HldNWlJ48I91cTGLF2mC7uRo6uQ2
> M9pUCuyCtL1ajgG6eUmBlo2soIAaHPkorCmCdUAiv/zWfHKSSEGTwr3l81DtSapE
> iORRoCyLVIhxKQprvBlTHp2uDIa7lzXOI83RcMb6ZqdxiNe3LscTRsVl/Ll8cVHj
> Fw7klJgbPrRPmMn02hANdalDE96CvagPlEmgCGhp9h3TPD7fV28a3vY154IYxLBW
>