cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <>
Subject Re: A rather crazy idea for a feature
Date Tue, 28 Apr 2009 11:45:12 GMT
Yes, that's precisely my idea. For the immediate case at hand, just mtom
would be useful. I see your point about the whole (oink) hog. Perhaps I can
get Tatu excited about the Woodstox end of this.

On Tue, Apr 28, 2009 at 6:53 AM, Eoghan Glynn <> wrote:

> Hi Benson,
> Do you mean using an NIO MappedByteBuffer?
> That would be an interesting thing to look at doing.
> Obviously limiting it to MTOM attachments sortta simplifies things,
> but of course there's also the possibility to go the whole hog and
> write a full-blown transport based on shared memory. Now in a previous
> life, I had great fun adding NIO support to a commercial CORBA ORB.
> One lesson learned from the experience was that to fully leverage the
> potential efficiency gains from NIO, one must marshall *directly* into
> an NIO buffer as opposed to some intermediate representation. So for a
> full-blown transport option, we would probably need to layer a
>{In|Out}Stream implementation over the NIO buffer to
> facilitate efficient StAX-based (parse|write} of the XML. Also some
> carefull thought would need to be put into the impact of asynchrony on
> the read side, dealing with the partial availability of data for
> incoming events etc. In the CORBA case there was lots of complexity
> around alignment and boundaries in the encoding and non-atomic reads
> of primitives, but I guess all that would be avoided in this case as
> it sort of fell out from the binary nature of the GIOP protocol.
> Cheers,
> Eoghan
> 2009/4/28 Benson Margulies <>:
> > Imagine a CXF extension to MTOM that used shared memory to move the
> > attachment. The bytes from the DataSource or whatever would be pushed
> into a
> > mapped file, and the client would map the same file. Maybe this is just
> the
> > file: URL as the MTOM identifier, and the mapping of the file is just an
> > opimization on top of that.
> >

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