You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@axis.apache.org by bl...@libero.it on 2008/08/23 01:29:56 UTC
MTOM cached file corrupted and threshold parameter: bug?
Hi, I'm using Axis2 (ADB binding). I enabled caching for MTOM
attachments (my service receives 80-100MB files) and I noticed
something that appears to be a bug.
When the threshold is under 1000 (byte) the cached file is corrupted:
it's missing a fragment whose size is (xbuffer-threshold) where
xbuffer has size values like 892 or 878 bytes.
In other words the cached file is composed like this: (threshold
bytes) + (remaining data starting after xbuffer bytes).
Is this perhaps a bug in PartFactory or related class?
<Snippet from PArtFactory.java>
...
// We need to read the input stream to determine whether
// the size is bigger or smaller than the threshold.
BAAOutputStream baaos = new BAAOutputStream();
int t1 =
BufferUtils.inputStream2OutputStream(dross, baaos, thresholdSize);
int t2
= BufferUtils.inputStream2OutputStream(in, baaos, thresholdSize - t1);
int total = t1 + t2;
if (total < thresholdSize) {
return new PartOnMemoryEnhanced(headers,
baaos.buffers(), baaos.length());
} else {
// A BAAInputStream is an input stream over
a list of non-contiguous 4K buffers.
BAAInputStream baais =
new BAAInputStream(baaos.buffers(),
baaos.length());
part = new PartOnFile(manager, headers,
baais,
in,
attachmentDir);
}
It's as if the second InputStream (in) we pass in the constructor is
not starting at byte threshold+1 but a bit later in the stream.
Anyway, has someone else noticed this behavior? The crucial point is:
am I safe in a production environment if I set threshold to 1000 (in
my tests this setting appears to work correctly)?
Thank you a lot for any help.
Alessandro Malatesta
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org