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 13:22:40 GMT

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).

The GzipOutInterceptor could be implemented to preceed the
StaxOutInterceptor in the outgoing chain, and wrap the (single-flush)
CachedOutputStream (provided by the transport layer) with its own
wrapper output stream that discards calls to flush(). Since Gzip
presumably can't write anything to the real output stream until the all
the data is available, the call to resetOut() etc. would be pushed from
the flush() method to the close().

Can you explain the issue that occurs in the SOAP attachment case? Why
would streaming the SOAP body directly onto the wire cause a problem in
this case?

Cheers,
Eoghan

> _____________________________________________ 
> From: 	Li, Tao (Tom)  
> Sent:	21 September 2006 13:34
> To:	Glynn, Eoghan
> Cc:	cxf-dev@incubator.apache.org
> Subject:	Flush Problem with HTTPCondit
> 
> Hi Eoghan,
> 
> I has a question about the behaviour of flush of HTTPCondit.
> Currently, when we call *.flush (inlcude outputstream get from message
> and XML stream writer build on it), it will call the doFlush() which
> will resetOut the output stream and send out the content by socket to
> its real destination. 
> But in some case, we need only flush the content of XML stream writer
> to its based output stream (normally a ByteArrayStream), and do not
> allow the content been sent to destination. 
> For example, in GzipStreamHandler case, after the SoapOutInterceptor,
> the XMLStreamWriter.flush() in this interceptor has already flush the
> data to server, that will make it impossible to do Gzip transform. 
> And in attachment case, it also prevent us to make a wrapped soap
> message with attachments based on the soap envelop inforset.
> 
> Could we add a method like flushToOutSide() which will do resetOut &
> flushHeader, and make the flush only do currentStream.flush().
> And in a suitable place, cast the OutputStream to
> AbstractWrappedOutputStream and call the flushToOutSide() to solve
> above problem.
> 
> Thanks 
> Tom
> 
> 
> Regards
> Tom Li
> Software Engineer
> 
> IONA Asia Pacific Software Development Center
> 2/F, Unit A, Information Center
> Zhongguancun Software Park Haidian District,
> Beijing, P.R.China (100094)
> 
> Tel: +86-10-82825151 - 519
> Fax: +86-10-82825210
> Email: tom.li@iona.com
> 

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message