Return-Path: X-Original-To: apmail-xmlgraphics-general-archive@www.apache.org Delivered-To: apmail-xmlgraphics-general-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id BD1EE10432 for ; Tue, 7 Jan 2014 16:12:49 +0000 (UTC) Received: (qmail 93696 invoked by uid 500); 7 Jan 2014 16:10:50 -0000 Mailing-List: contact general-help@xmlgraphics.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: general@xmlgraphics.apache.org Delivered-To: mailing list general@xmlgraphics.apache.org Received: (qmail 93476 invoked by uid 99); 7 Jan 2014 16:10:23 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 07 Jan 2014 16:10:23 +0000 X-ASF-Spam-Status: No, hits=-0.5 required=5.0 tests=FREEMAIL_ENVFROM_END_DIGIT,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of simonsteiner1984@gmail.com designates 74.125.83.43 as permitted sender) Received: from [74.125.83.43] (HELO mail-ee0-f43.google.com) (74.125.83.43) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 07 Jan 2014 16:10:17 +0000 Received: by mail-ee0-f43.google.com with SMTP id c13so167546eek.16 for ; Tue, 07 Jan 2014 08:09:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:thread-index :content-language; bh=Uc6pjK6lqa65OeiMyuvryKyiYAG20JgRCmcsTFNP/6g=; b=hQjgyoPul6Eboz1GCztP0NzaAS/Jg5ok7q3WO7bboE9SQlixqb6Ae76DC6Jch1vITa JBSYoXmSkAabEBFODwvLcgVs7Vg9ixMH0Z7YVFeHqdJWa/1N/wmIL4+agUY/HjuMPTKK Lxyec9alTfdcmwY21rE/IVgP+g6rBo045lW5lCGn7S6bu4Xe81jTpxiXLLCh/3VJo77x oY39yodOOg5dvZaRbMTayU1NMH+CrC47q9VETwYt+BFB26+lqocyWgXz/2bk/iqr4+Tx h3i36a5hQJ4wAA7czxCz/0TS4M3jE8XJHXu4AjKR7kMHErok4PDBRg3cOUEK9I5ynORD JXHw== X-Received: by 10.14.53.14 with SMTP id f14mr8534375eec.105.1389110997029; Tue, 07 Jan 2014 08:09:57 -0800 (PST) Received: from WINM3GKAL0IMFB (spc3-bagu2-0-0-cust872.bagu.broadband.ntl.com. [81.104.63.105]) by mx.google.com with ESMTPSA id p45sm181219181eeg.1.2014.01.07.08.09.55 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 07 Jan 2014 08:09:56 -0800 (PST) From: "Simon Steiner" To: References: In-Reply-To: Subject: RE: running out of filehandles Date: Tue, 7 Jan 2014 16:09:54 -0000 Message-ID: <005301cf0bc2$e868ffb0$b93aff10$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQNDudaMyJmveHqV25O2eebHyTKm15eQEKOA Content-Language: en-gb X-Virus-Checked: Checked by ClamAV on apache.org 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 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