|
[
Permlink
| « Hide
]
Peter lynch added a comment - 18/Nov/05 06:17 AM
One workaround as stated in the original post is to wrap the BufferedReader in the request with a "NonClosingBufferedReader". Override the close() method to do a noop and in the servlet finally block call a 'forceClose()' to clean things up in the servlet ( which calls the real BufferedReader.close() method ).
Exactly the same issue here with JAXP 1.3, Tomcat 5.5.12.
I'm not sure about the work around. It sounds to me as if that results in memory leaks ... I'm running into this same issue. I have code that assumes the InputStream is not retained and ensures it is closed once parsing has finished, ultimately leading to an exception the next time something is parsed.
I think this one is better left for the Piccolo guys to deal with. I guess though, that I can't see how wrapping it into an "unclosable" stream would lead to more memory leaks than you would have should Piccolo not close the stream.
Also, it feels to me that, in some sense, Tomcat could take care that a "close" does the right thing, so that the fact that the streams are in reality shared is transparent to programmers. Would you feel better if XmlBeans had an option to wrap any streams that it uses in "unclosable" streams? I don't know much about Piccolo, but according to what I'm seeing (especially the call stack), it does appear to be their problem to fix. I should note that in my case I'm not reusing streams, but simply ensuring they are closed before returning to the user. I happen to be using a custom InputStream (connected to our back end document repository) that, once close() has been called, any further invocations to any method throw an IOException. My code does something similar to this:
<code><pre> try { XmlObject xo = factoryclass.parse(inputStream); ... } finally { inputStream.close(); } </pre></code> The first time through, everything works fine. However, the second time through (which could be any amount of time later depending on user activity, in a completely separate transaction for another user altogether), Piccolo will attempt to call close() on the previous InputStream! Somewhere it is maintaining a static reference to it and then calling close() <i>way</i> after the fact. Since I didn't have time to dig through Piccolo or XMLBeans source code, I just hacked together a quick and dirty workaround: <code><pre> public static class XmlBeansWorkaroundInputStream extends InputStream { private final WeakReference<InputStream> in; public XmlBeansWorkaroundInputStream(final InputStream in) { this.in = new WeakReference<InputStream>(in); } protected InputStream getIn() { return this.in.get(); } @Override public int read() throws IOException { final InputStream in = getIn(); if(in != null) { return in.read(); } else { return -1; } } @Override public int read(byte b[]) throws IOException { final InputStream in = getIn(); if(in != null) { return in.read(b); } else { return -1; } } @Override public int read(byte b[], int off, int len) throws IOException { final InputStream in = getIn(); if(in != null) { return in.read(b, off, len); } else { return -1; } } @Override public long skip(long n) throws IOException { final InputStream in = getIn(); if(in != null) { return in.skip(n); } else { return 0; } } @Override public int available() throws IOException { final InputStream in = getIn(); if(in != null) { return in.available(); } else { return 0; } } /** * Part of the fix for this issue is to completely ignore the close() * call - thus, this implementation of close() does not call close() on * 'in'. * @throws IOException */ @Override public void close() throws IOException { final InputStream in = getIn(); if(in != null) { this.in.clear(); } } @Override public synchronized void mark(int readlimit) { final InputStream in = getIn(); if(in != null) { in.mark(readlimit); } } @Override public synchronized void reset() throws IOException { final InputStream in = getIn(); if(in != null) { in.reset(); } } @Override public boolean markSupported() { final InputStream in = getIn(); if(in != null) { return in.markSupported(); } else { return false; } } } </pre></code> Since I'm keeping a strong reference to the source input stream for as long as I'm actually using it, I decided to use a WeakReference in the class above to avoid memory leaks (since Piccolo will hold on to the reference for an indeterminate amount of time). If the source InputStream is garbage collected then the decorating InputStream gracefully pretends that it has reached the end of stream. This has solved our issue, with regression and integration tests passing. Hi everyone ---
I found an elegant solution to this issue of InputStream cleanup. Apache Commons IO released v1.4 which includes an AutoCloseInputStream wrapper which cleans up InputStreams once they have been read. http://commons.apache.org/io/api-release/org/apache/commons/io/input/AutoCloseInputStream.html We are using this IBM WAS 6.1 and this appears to resolve this bug. Does anyone see any issue with using this fix? Thanks. Rich |
||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Open
Major
Exception "Unexpected end of file after null"
