Hmm... Interesting. I'm not sure if this is a bug in HTTPConduit or a bug in the MimeBodyPartInputStream. From the HTTPConduit standpoint, the data written in the buffer is irrelevant and is discardable. Thus, if multiple threads access it and write data into it, who cares? Thus, I'm inclined to say it's a bug in the MimeBodyPartInputStream which is storing state in the passed in buffer while processing.
> I removed the 'static' from the field > definition and didn't see any problems anymore Well, you would if multiple threads used the same client. Thus, that's not really a fix either. The only "real" fix in HTTPConduit would be to allocate a new byte[] each close which is probably the safest thing to do. Other streams could possibly be used (like a gzip or similar) that may also be using the byte[] for temporary state. Can you log a JIRA? Dan On Tue August 4 2009 9:59:39 am _Jens wrote: > Hi, > > I ran into a multi-threading problem with a web service that returned > multiple attachments. After playing around with this for some time I found > that data that is read from the PushbackInputStream often gets unread > shortly afterwards. When my proe. I'm still not so sure about > all the details that occur and why this buffer causes problems with > attachments. Could someone confirm that this is a bug or could it be that > my setup is wrong?blem occurred this did not happen, causing > the AttachmentDeserializer to "think" that there are fewer attachments. > After more diffing, I found this member in HTTPConduit: > > private static final byte BUFFER[] = new byte[1024]; > > This is only used in the HTTPConduit.close(). However, it is shared between > all instances of HTTPConduit and it seems to be possible that close() gets > called by multiple threads. I removed the 'static' from the field > definition and didn't see any problems anymore > > Thanks, > Jens -- Daniel Kulp [email protected] http://www.dankulp.com/blog
