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 <eogl...@gmail.com> 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
> java.io.{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 <bimargul...@gmail.com>:
> > 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.
> >
>
