Jim,
How are you doing mail?
If you are not shelling out to do email, you can probably disregard this
email, though it may be of use later....
If you are shelling out from java to execute something locally, there's
something you should be aware of:
In this code snippet, I shell out to execute a program with arguments:
Process p = null;
try{
Runtime runtime = Runtime.getRuntime();
p = runtime.exec(arr_sCommands);
int nStatus = p.waitFor();
} catch (Exception ex) {
System.err.println("Caught this exception>" + ex.getMessage());
}
That will execute the command/arguments in arr_sCommands and wait for it to
return.
When running standalone, this is fine, but in a tomcat environment, there
is a pretty big problem. Process opens up 3 file handles and DOES NOT
close them. So that means every time you shell out to execute something,
you have 3 dangling file handles that could be eating up resources.
Before long, you run into too many files open and all kinds of seemingly
unrelated errors.
to fix this, you should add this code:
try {
...
} catch (Exception ex) {
...
} finally {
if ( p != null) {
p.getErrorStream().close();
p.getInputStream().close();
p.getOutputStream().close();
p.destroy();
p = null;
}
}
This is a bug in jdk's as recent as 1.4.2 (bugs # 4191034, 4637504)and has
no signs of being fixed soon, so beware of it!
Good Luck!
- Dan Obregon -
> I'm in a little over my head with a task I've got brewing in production
> land. I'm a junior developer that was hired to be an entire team.
>
> Roughly ten times as many people are registered to use the project than
> I was told, so I purchased more RAM. That makes the machine stats these.
>
> Pentium IV 2.4Ghz
> 2GB DDR ECC RAM
> Debian Linux 2 stable
> Tomcat 4.1.30
>
> A segment of the system is designed to send e-mail to everyone on a
> list. Each e-mail is sent by starting a thread that terminates when the
> sending is complete. The upper bound of emails in this list is about a
> thousand, but will rarely exceed five hundred. The system was running
> as expected (e.g. capable of sending multiple hundreds of messages)
> before at 512MB of RAM with the following options appended to JAVA_OPTS
> in catalina.sh
>
> -Xms 220M -Xmx 440M
>
> Now that the products have gotten the RAM upgrade, I changed these
> options to
>
> -Xms220m -Xmx1536m
>
> The result was a drop to about forty messages before I got an "Out of
> Memory- unable to start new native thread" error.
>
> As a result of looking around, particularly at the links like
> http://h21007.www2.hp.com/cmdspp/QuestionAnswer/1,1764,4AF428BF-32E1-4297-938A-0A1F93DE31B1,00.html
> and
> http://jboss.org/wiki/Wiki.jsp?page=OutOfMemoryExceptionWhenCannotCreateThread
>
> I changed the options to these
>
> -Xss1024K -Xms1536m -Xmx1536m
>
> but this only gets the boundary to about one hundred before thread
> creation fails. We're nowhere near the process limit for Linux, running
> at approximately 400 or so.
>
> Should I just keep tweaking the configuration settings hoping to find
> something that works? Give up a little bit more maximum heap size? The
> one similar post I've seen since March had the user going down to 16k
> stack size. Is that safe? I can't be blowing my stack on the
> production machine, that's worse than the problem I have now! I don't
> have any recursion going on, but I've seen some pretty deep stack traces.
>
> Is there something programmatically I could do, like having the call
> that starts the thread wait for awhile then try again if it fails?
>
> I've tried to do my homework, but I think I actually passed my limits on
> this project some time ago. :-) Thanks and good karma in advance for
> any and all help.
>
>
> Cheers,
>
> Jim
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
