I recall there being some scenario when I was debugging where I the application message had already opened a connection on the wire while a CreateSequence was being sent. Looking back I can see that this might have been related to my refactoring at some point.
The big issue though was that things depended on having onFlush() called once and only once. - Dan On 6/13/07, Andrea Smyth <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] wrote: >Author: dandiep >Date: Tue Jun 12 15:49:08 2007 >New Revision: 546656 > >URL: http://svn.apache.org/viewvc?view=rev&rev=546656 >Log: > >Refactoring of the low level IO layer inside CXF. > >Remove the dependence on flush() being called ONCE and only once >inside CXF. There was the assumption in all the code that things would >be cached until we actually finished databinding, which is a bad assumption. >There are a couple problems with this: >1. The Soap envelope writer was writing the envelope twice if a fault was >thrown during databinding and the stream was already flushed. (i.e. during >validation) >2. The code didn't differentiate between the type of caching that was going >on. i.e. are we a) writing to the underlying stream AND caching the message >at the same time. Or b) are we caching the message and then writing on close() > >Ensure that the RM and Logging layers correctly do their work on close() >instead of flush(). > >Transports now pass in the underlying stream. The RM layer and logging >interceptors correct detect when a cached stream is not being used >and act accordingly. This is much more robust as I/O transformations >are a very valid use case an many people will want to switch the >underlying streams. We also shouldn't force transport writers to >use CachedOutputStream. > >Rename AbstractCachedOutputStream to CachedOutputStream and make >it a non-abstract class. This cuts down on the number of CachedOutputStream >classes laying around! There are now two extended implementations of >COS as well: >1. WriteOnCloseOutputStream. This caches the message until the outputstream >is closed. This is needed for the RM scenarios where we are caching the message >until the CreateSequence is done. We don't want to open the connection until >all of this is done. (I think we could probably reset this output stream >as soon as the createsequence is finished though > > Hi Dan, I am not sure what you mean with 'caching the message until the CreateSequence is done': In the RM case the original application message should not be written before a Sequence is available - the logical RM out interceptor (which triggers sequence creation) sits in the PRE_LOGICAL phase RM uses the RetransmissionCallback class to cache application messages for future resends - util they are acknowledged. Andrea. >2. CacheAndWriteOutputStream. This caches the message while it is written >to the underlying stream at the same time. Useful for logging. > >Update the DataBinding code to have JAXB write directly to the OutputStream >whenever possible. This gives a great performance improvement for some scenarios. > >Refactor the JAXB code so we don't have so many data readers/writers. > >TODO: Make RM and Logging work when the message is larger than memory or the >CachedOutputStream writes to disk. > > >TODO: Fix HTTPS 401 Redirect test > > > > ---------------------------- IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
-- Dan Diephouse Envoi Solutions http://envoisolutions.com | http://netzooid.com/blog
