May I ask to see the stacktrace of the original error? I want to correlate a strange jetty error from non-felix code against this one because they seem eerily similar. (long shot)
- Ray On Thu, Sep 18, 2014 at 8:35 AM, Richard S. Hall <[email protected]> wrote: > I guess the question to ask is what behavior is the correct behavior if > there really is an exception on close? This patch will ignore every > exception, not just ones that occurs because of a double close (although it > seems to me a double close should be a no-op, not sure why it throws, but > that is another issue). > > Does it make sense that every close exception is ignored and the user is > never alerted? Granted, there isn't much we can do, but often such errors > are better breaking things than just being ignored. > > -> richard > > > On 9/18/14 03:43 , Rob Walker wrote: > >> Just wanted to check this one before I raise a JIRA, in case it's known >> and/or already been fixed or being worked on. >> >> In one of our models we provision our application over WebStart, which >> causes bundles to be loaded over HTTP. Occasionally we get a Stream Closed >> exception being thrown from the Jetty HTTP server (the server serving up >> the code is also running under Felix). >> >> What seems to happen is a double close of the input stream - which throws >> an error. I've include the notes below from our developer who found this. >> >> It's a pretty simple mod to ignore the exception on second close >> (highlighted red below) - assuming everyone is happy this is an ok approach. >> >> -- Rob >> >> === >> >> /It turns out the problem was arising when caching the VersaTest jar >> files. Whilst they are coming across via WebStart ok, an error was being >> thrown because the stream used to read them was being closed multiple times >> and at some point the close operation causes an exception that isn't caught >> so stops the load. This error occurs in Felix in the JarRevision class, in >> the initialize() method. I put a simple fix in that ignored the error on >> close. So in the code below, a close on the input stream was being called >> in the //BundleCache.copyStreamToFile(is, m_bundleFile) and in the >> bottom finally block (you can see below where I put in that disregarding >> catch. (Note, I suspect that also the input stream could be closed in the >> //((HttpURLConnection) conn).disconnect() //as well. But it is explicitly >> closed in the copyStreamToFile.)//// >> /// >> >> if (!byReference) >> { >> URLConnection conn = null; >> try >> { >> if (is == null) >> { >> // Do it the manual way to have a chance to >> // set request properties such as proxy auth. >> URL url = BundleCache.getSecureAction(). >> createURL( >> null, getLocation(), null); >> conn = url.openConnection(); >> >> // Support for http proxy authentication. >> String auth = BundleCache.getSecureAction() >> .getSystemProperty("http.proxyAuth", null); >> if ((auth != null) && (auth.length() > 0)) >> { >> if ("http".equals(url.getProtocol()) || >> "https".equals(url.getProtocol())) >> { >> String base64 = >> Util.base64Encode(auth); >> conn.setRequestProperty( >> "Proxy-Authorization", "Basic " + base64); >> } >> } >> is = BundleCache.getSecureAction() >> .getURLConnectionInputStream(conn); >> } >> >> // Save the bundle jar file. >> BundleCache.copyStreamToFile(is, m_bundleFile); >> } >> finally >> { >> // This is a hack to fix an issue on Android, >> where >> // HttpURLConnections are not properly closed. >> (FELIX-2728) >> if ((conn != null) && (conn instanceof >> HttpURLConnection)) >> { >> ((HttpURLConnection) conn).disconnect(); >> } >> } >> } >> } >> } >> finally >> { >> if (is != null) >> { >> try >> { >> is.close(); >> } catch (IOException ioe) >> { >> /* Catch and disregard exception on close as could >> already have been closed, >> either in the disconnect or in the >> copyStreamToProfile >> */ >> >> } >> >> } >> } >> >> >> >> >> >> >> >> >> >> >> >> > -- *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000) Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> (@Liferay)
