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