xmlgraphics-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carl Buxbaum <cbuxb...@tradestonesoftware.com>
Subject running out of filehandles
Date Tue, 07 Jan 2014 15:46:31 GMT
Hi all, this is directed toward the developers:

We have a customer who recently encountered an issue when running a FOP 1.0 report in an environment
where none of the images referenced in the report existed.  All of the references were URLs
to images served by our application through a servlet.  Our servlet writes the image bytes
to the ServletOutputStream.  I verified that I close all resources in a finally  block (I
do not, of course, close the Output Stream). If the file does not exist, I return a 404 not
found in the response.

When the images do not exist on the server, the platform runs out of file handles.  They get
this error:

java.net.SocketException: Too many open files

After researching a workaround, I had the customer add this to their Java startup

-Dorg.apache.xmlgraphics.image.loader.impl.AbstractImageSessionContext.no-source-reuse=true

This fixed it, but we are unclear on why the customer would see a difference between a server
where all the images are available, and where the images are not available.  In their production
environment they never had this problem.  Is it possible that the URL resource (and/or the
ServletOutputStream) is not being closed when the response is 404 not found?

Thanks,

Carl  Buxbaum
Software Architect
TradeStone Software
17 Rogers St. Suite 2; Gloucester, MA 01930
P: 978-515-5128 F : 978-281-0673
www.tradestonesoftware.com<http://www.tradestonesoftware.com>


DISCLAIMER: 
E-mails and attachments from TradeStone Software, Inc. are confidential.
If you are not the intended recipient, please notify the sender immediately by
replying to the e-mail, and then delete it without making copies or using it
in any way. No representation is made that this email or any attachments are
free of viruses. Virus scanning is recommended and is the responsibility of
the recipient.
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message