You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Benson Margulies <bi...@gmail.com> on 2010/10/28 01:27:33 UTC
Strange EOFs on streams from optimized MTOM
A return value from an operation of mine includes an MTOM-optimized
byte[], organized via Aegis binding a DataHandler. It's the only
attachment, so we get the full optimization treatment: a stream that
is directly reading the socket.
In one entirely repeatable case, I get an EOFException that I can't
yet explain.
The backtrace is below, trying to read just the first two bytes.
the actual stream is a DelegatingInputStream, boundaryFond true,
pbAmount 2048. The PushbackInputStream under it has pos=2048.
ObjectInputStream$PeekInputStream.readFully(byte[], int, int) line: 2280
ObjectInputStream$BlockDataInputStream.readShort() line: 2749
ObjectInputStream.readStreamHeader() line: 779
ObjectInputStream.<init>(InputStream) line: 279
CrossdocCorefBatch.readSomething(Class<T>, InputStream) line: 177
CrossdocCorefBatch.access$3(CrossdocCorefBatch, Class, InputStream) line: 175
CrossdocCorefBatch$JugCorefDocDb.readDoc(String) line: 62
Re: Strange EOFs on streams from optimized MTOM
Posted by Daniel Kulp <dk...@apache.org>.
Benson,
Can you try with the latest snapshot? I fixed some issues in this area last
week so it MAY be fixed.. If not, I'd love to see the test case, although I
may not be able to get to it till after ApacheCon. (in London right now)
Dan
On Wednesday 27 October 2010 7:27:33 pm Benson Margulies wrote:
> A return value from an operation of mine includes an MTOM-optimized
> byte[], organized via Aegis binding a DataHandler. It's the only
> attachment, so we get the full optimization treatment: a stream that
> is directly reading the socket.
>
> In one entirely repeatable case, I get an EOFException that I can't
> yet explain.
>
> The backtrace is below, trying to read just the first two bytes.
>
> the actual stream is a DelegatingInputStream, boundaryFond true,
> pbAmount 2048. The PushbackInputStream under it has pos=2048.
>
>
> ObjectInputStream$PeekInputStream.readFully(byte[], int, int) line: 2280
> ObjectInputStream$BlockDataInputStream.readShort() line: 2749
> ObjectInputStream.readStreamHeader() line: 779
> ObjectInputStream.<init>(InputStream) line: 279
> CrossdocCorefBatch.readSomething(Class<T>, InputStream) line: 177
> CrossdocCorefBatch.access$3(CrossdocCorefBatch, Class, InputStream) line:
> 175 CrossdocCorefBatch$JugCorefDocDb.readDoc(String) line: 62
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Re: Strange EOFs on streams from optimized MTOM
Posted by Benson Margulies <bi...@gmail.com>.
This was a self-inflicted wound. I reused the CachedOutputStream in my
own code and did not understand when I was not supposed to call close.
On Wed, Oct 27, 2010 at 7:27 PM, Benson Margulies <bi...@gmail.com> wrote:
> A return value from an operation of mine includes an MTOM-optimized
> byte[], organized via Aegis binding a DataHandler. It's the only
> attachment, so we get the full optimization treatment: a stream that
> is directly reading the socket.
>
> In one entirely repeatable case, I get an EOFException that I can't
> yet explain.
>
> The backtrace is below, trying to read just the first two bytes.
>
> the actual stream is a DelegatingInputStream, boundaryFond true,
> pbAmount 2048. The PushbackInputStream under it has pos=2048.
>
>
> ObjectInputStream$PeekInputStream.readFully(byte[], int, int) line: 2280
> ObjectInputStream$BlockDataInputStream.readShort() line: 2749
> ObjectInputStream.readStreamHeader() line: 779
> ObjectInputStream.<init>(InputStream) line: 279
> CrossdocCorefBatch.readSomething(Class<T>, InputStream) line: 177
> CrossdocCorefBatch.access$3(CrossdocCorefBatch, Class, InputStream) line: 175
> CrossdocCorefBatch$JugCorefDocDb.readDoc(String) line: 62
>