You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@xmlgraphics.apache.org by Carl Buxbaum <cb...@tradestonesoftware.com> on 2014/01/07 16:46:31 UTC
running out of filehandles
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.
Re: running out of filehandles
Posted by Luis Bernardo <lm...@gmail.com>.
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.
RE: running out of filehandles
Posted by Carl Buxbaum <cb...@tradestonesoftware.com>.
Ok, thanks, so there really should be no difference between a report where all the URLs resolve and a report where none of them resolve?
Carl
-----Original Message-----
From: Simon Steiner [mailto:simonsteiner1984@gmail.com]
Sent: Tuesday, January 07, 2014 11:10 AM
To: general@xmlgraphics.apache.org
Subject: RE: running out of filehandles
Hi,
I was told this can happen when you do many FO to IF without closing jvm, files are kept open for IF to output stage. Unless you set that property to avoid it.
File is opened to read to check file type and next stage is to read file, these 2 steps can be far apart so connection may need to redone.
Thanks
-----Original Message-----
From: Carl Buxbaum [mailto:cbuxbaum@tradestonesoftware.com]
Sent: 07 January 2014 15:47
To: general@xmlgraphics.apache.org
Subject: running out of filehandles
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-so
urce-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.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org
RE: running out of filehandles
Posted by Simon Steiner <si...@gmail.com>.
Hi,
I was told this can happen when you do many FO to IF without closing jvm,
files are kept open for IF to output stage. Unless you set that property to
avoid it.
File is opened to read to check file type and next stage is to read file,
these 2 steps can be far apart so connection may need to redone.
Thanks
-----Original Message-----
From: Carl Buxbaum [mailto:cbuxbaum@tradestonesoftware.com]
Sent: 07 January 2014 15:47
To: general@xmlgraphics.apache.org
Subject: running out of filehandles
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-so
urce-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.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org