xmlgraphics-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luis Bernardo <lmpmberna...@gmail.com>
Subject Re: running out of filehandles
Date Tue, 07 Jan 2014 23:30:23 GMT

Can you try trunk to see if the problem also happens then? There was a 
fix by Alexios Giotis regarding open files that may be relevant for your 
case, but I think it happened after the 1.1 release.

Possibly what is happening is that the files are being left open always. 
If the image exists, then it is cached by FOP, and the next time time 
requested FOP uses the cached image instead of opening a new connection. 
If the image does not exist, FOP keeps opening new connections (since no 
image was cached) until you run out of file handles.


On 1/7/14, 3:46 PM, Carl Buxbaum wrote:
> 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