Static buffer field in HTTPConduit

[_Jens <je...@icw.de>]

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 problem 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. 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?

Thanks,
Jens
-- 
View this message in context: http://www.nabble.com/Static-buffer-field-in-HTTPConduit-tp24809185p24809185.html
Sent from the cxf-user mailing list archive at Nabble.com.

Re: Static buffer field in HTTPConduit

[_Jens <je...@icw.de>]

Hi Dan,

thanks for the quick reply. Yes, you are right, it is probably better to
allocate the buffer in close() or fix it in MimeBodyPartInputStream. My
"fix" was only a way for me to see that this was indeed the problem I was
having. I submitted a bug for this: 

https://issues.apache.org/jira/browse/CXF-2381

Jens
-- 
View this message in context: http://www.nabble.com/Static-buffer-field-in-HTTPConduit-tp24809185p24822083.html
Sent from the cxf-user mailing list archive at Nabble.com.

Re: Static buffer field in HTTPConduit

[Daniel Kulp <dk...@apache.org>]

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
dkulp@apache.org
http://www.dankulp.com/blog