cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Diephouse <...@envoisolutions.com>
Subject Re: Flush Problem with HTTPCondit
Date Thu, 21 Sep 2006 14:36:33 GMT
Dan Diephouse wrote:

> Glynn, Eoghan wrote:
>
>> Hi Tom,
>>
>> Well the current Conduit/CachedOutputStream model assumes that when the
>> first flush() call is made during the outgoing interceptor chain
>> traversal, the message content is effectively "frozen" in the sense that
>> it can written onto the "real" output stream provided by the transport
>> layer.
>>
>> Currently, as you say, this first flush() normally occurs in the
>> SoapOutInterceptor after it has written the message body. However, I was
>> thinking that in the normal case (i.e. in the absence of
>> payload-transforming interceptors like Gzip) that we should change this
>> so that the initial flush() occurs before the envelope is written (so
>> that the SOAP envelope is streamed directly onto the wire, to avoid the
>> overhead of caching and copying).
>>
>>  
>>
> +1 - although, why not have the tranforming interceptors add the 
> cached stream themselves if they need it as opposed to adding it at 
> the transport level?

One other thing - I've seen some places in the code where people just 
assume that its a cached outputstream (like the attachments code). This 
is BAD, as there could be a transforming interceptor in between and it 
could set its own outputstream. So it seems like we shouldn't make this 
assumption at all anyway - in which case I'm not sure there is a reason 
for it to be at the transport level. What do you think?

- Dan

-- 
Dan Diephouse
(616) 971-2053
Envoi Solutions LLC
http://netzooid.com


Mime
View raw message