A rather crazy idea for a feature

[Benson Margulies <bi...@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.

Re: A rather crazy idea for a feature

[Benson Margulies <bi...@gmail.com>]

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 <eo...@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 <bi...@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.
> >
>

Re: A rather crazy idea for a feature

[Eoghan Glynn <eo...@gmail.com>]

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 <bi...@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.
>