[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Tomcat can't create threads with THREDDS

my best guess at the moment is that the file caching is causing out-of-memory 
errors. try reducing the number of maximum files allowed.

see THREDDS File Handle Caching (not Java disk cache) in


Roy Mendelssohn wrote:
> Hi John:
> Might take awhile to set up a test.  part of it may be that we are
> serving a lot of data, so the TDS creates a lot of threads, and we are
> linking to a lot of remote datasets, which appears to give THREDDS some
> heartburn.
> All we get are the to errors you saw- the connection times out and
> produces an error, and then over time we get the message that a "new
> thread can not be created" and that holds for all the catalogs past our
> initial first page catalog.  The tomcat keeps running, it just can't
> produce new threads to do anything.
> Is there some other setting we can do that would help -  believe we
> already have verbose mode turned on.  We have monkeyed with the java
> settings repeatedly, and still are unclear the best ones.  Some internet
> sites say for productions servers, the min and max should be the same,
> so that garbage collection works right, we have tried setting the
> garbage collection to diferent things - most made it more unstable not
> less.
> Thanks,
> -Roy
> On Sep 23, 2008, at 9:18 AM, John Caron wrote:
>> Hi Roy: I got both, thanks.
>> I tried to reproduce with no luck so far. One can call a broken catref
>> a million times and it wont consume memory. I have eliminated the
>> stack trace and just put out a warning now, so the logs are a bit more
>> readable.
>> however, there may be a way that the threads get lost, or something
>> else in your use case that im not duplicating.
>> how exactly does the catref get broken? does it return a 404 or just
>> hang or ???
>> can you can reproduce the problem reliably on a test server?
>> Roy Mendelssohn wrote:
>>> We have had to do several restarts the last couple of days.  To keep the
>>> file size manageable  (one may or may not got through) I have edited
>>> them to the last couple of days.  Let me know if you get both files.
>>> -roy
>>> The original MIME headers for this attachment are:
>>> Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
>>> Content-transfer-encoding: 7BIT
> **********************
> "The contents of this message do not reflect any position of the U.S.
> Government or NOAA."
> **********************
> Roy Mendelssohn
> Supervisory Operations Research Analyst
> Environmental Research Division
> Southwest Fisheries Science Center
> 1352 Lighthouse Avenue
> Pacific Grove, CA 93950-2097
> e-mail: address@hidden (Note new e-mail address)
> voice: (831)-648-9029
> fax: (831)-648-8440
> www: http://www.pfeg.noaa.gov/
> "Old age and treachery will overcome youth and skill."
> "From those who have been given much, much will be expected"

NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.