cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glynn, Eoghan" <eoghan.gl...@iona.com>
Subject RE: Flush Problem with HTTPCondit
Date Thu, 21 Sep 2006 16:54:02 GMT
 

> -----Original Message-----
> From: Dan Diephouse [mailto:dan@envoisolutions.com] 
> Sent: 21 September 2006 16:03
> To: Li, Tao (Tom)
> Cc: cxf-dev@incubator.apache.org
> Subject: Re: Flush Problem with HTTPCondit
> 
> Li, Tao (Tom) wrote:
> 
> >Hi Dan,
> >
> >If there's transforming interceptor, it must use a stream 
> which can cache all the data generated by other interceptor 
> before it doing its transforming work, so our api providing a 
> AbstractCachedOutputStream to enable caching, and provide 
> some callback like doFlush & doClose for customization, and I 
> think the AbstractCachedOutputStream can serve as a base 
> class for output stream used by transforming interceptor. 
> >  
> >
> I don't think thats true. I could create a piped stream which 
> unzips the data as I pull it through. There is no requirement 
> that it be cached before I can unzip it as far as I know.

I think Tom was referring to the outbound dispatch as opposed to the inbound, i.e. the process
of zipping up rather than unzipping.

In my naïve understanding of how data compression works, it performs best on fairly decent
chunks of data (i.e. a large block size) as opposed to being drip-fed data in small increments
(e.g. individual XML elements). 

Hence the motivation for caching all (or at least reasonable chunks of) the payload before
applying the compression.

/Eoghan
 
> >That means even if there's do have transforming interceptor, 
> the assumption won't caused problem. And like Eoghan said, I 
> will try to modify the AttachmentOutInterceptor to act like a 
> transforming interceptor, and provide a customized 
> outputstream inherited from AbstractCachedOutputStream whose 
> doFlush() will only flush the underlying stream, the resetOut 
> will be left to doClose().
> >
> >Any comments are welcomed!
> >
> >Thanks,
> >Tom
> >
> >
> >
> >-----Original Message-----
> >From: Dan Diephouse [mailto:dan@envoisolutions.com]
> >Sent: Thursday, September 21, 2006 7:37 AM
> >To: cxf-dev@incubator.apache.org
> >Cc: Li, Tao (Tom)
> >Subject: Re: Flush Problem with HTTPCondit
> >
> >
> >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