geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Davanum Srinivas <dava...@gmail.com>
Subject Re: Donation of a CORBA Orb
Date Thu, 07 Jul 2005 16:16:19 GMT
Hiram,

Could you please make sure that the project gets worked on here at
Apache? Am a bit concerned about code getting forked out and then
becoming geronimo becoming a dependency on an external project. If
activeio folks want to come here and join forces with trifork folks,
that would be ideal IMHO.

thanks,
dims

On 7/7/05, Hiram Chirino <chirino@apache.org> wrote:
> Hi Kresten,
> 
> On Jul 4, 2005, at 11:53 AM, Kresten Krab Thorup wrote:
> >
> > == first project ==
> >
> > Right now the Trifork ORB is using NIO for the server-side of IIOP,
> > but "classic" IO for the client side.  The NIO part is great
> > because it lets us run all corba handling in a single selector
> > thread backed by the appserver's thread pool.  However, With the
> > experience from working with this for the last 5 years, I would
> > like to redo the core I/O subsystem, and so I have started to do
> > the first steps towards this rework.
> >
> > The benefits of this, apart from cleaning up code that has grown
> > over time, would be:
> >
> > - Reduce copying data through the stack.
> > - Reduce thread usage further to support even more clients.
> > - Off-load reading&writing - e.g. response writing to the framework
> > so as to better handle slow clients.
> >
> > There are many reasons why I would like to do this, here is one:
> > One optimization that we did at one point was to pool byte arrays,
> > because the allocation of byte arrays (read: zeroing out memory)
> > took way too much time. [I know - generally pooling in JVM's is a
> > bad idea, but in this case it made a lot of sense]  With this
> > rewrite we would gain the same optimization one more time.  CORBA
> > Input/OutputStreams should be backed by java.nio.ByteBuffers
> > directly, which will then be passed straight down to the NIO
> > interface.
> >
> > The effort as I see it falls in two parts:
> >
> > - Asynchroneous I/O API (AIO).  Based on the abstractions we have
> > internally in the ORB, I'm doing a generalized version of something
> > very similar to IBM's aio4j; future-based socket I/O. Unline aio4j
> > however, the API runs straight on top of a Java SE 1.4 [no native
> > code], and hooks into an external thread pool to provide the same
> > API based on both NIO and "classic" IO technology.
> >
> 
> This area of work is absolutely fascinating for me.  It seems that in
> ActiveMQ we have very similar requirements to your ORB.  A standalone
> project was started to deal with exactly those issues at http://
> activeio.org.  We built a flexible IO abstractions so that a client
> application can choose the API and implementation technology that
> best suites it's needs.  Clients can choose to use a synchronous
> packet, asynchronous packet, or a synchronous stream interface.  The
> And the client can choose what underlying IO technology will
> implement the chosen interface, it could choose to use standard
> blocking IO, or use NIO in blocking mode, or NIO in non-blocking
> mode, or IBM AIO, or JXTA sockets, or jvm pipes, etc. etc.
> All of this has already been implemented and is ASL 2.0 licensed and
> being used by Geronimo and ActiveMQ.  Since you've been thinking
> this, it would be good to chat to see if it would suite your needs or
> if needs enhancing.
> 
> Regards,
> Hiram
> 
> 
> > - IIOP Streams on AIO. Based on the above, write InputStream/
> > OutputStream implementations, as  well as connection management,
> > backed by the AIO infrastructure and NIO direct buffers such that
> > the underlying OS can stream data straight into the high-level
> > structures.
> >
> > Kresten
> >
> >
> > On Jul 4, 2005, at 2:37 PM, Geir Magnusson Jr. wrote:
> >
> >
> >> Joern,
> >>
> >> Thanks for the note.  This is the right place to discuss.
> >>
> >> There are two separate threads of discussion that I can think of :
> >>
> >> 1) Technical - if the donation fits technically into what we are
> >> doing (I'm sure it does...)
> >>
> >> 2) Administrative - how, where and when
> >>
> >> As for #2 my questions to you are :
> >>
> >> a) What is the timing for this donation?  How soon?
> >>
> >> b) Do you see this as coming straight to Geronimo to be part of
> >> Geronimo initially, or to the Apache Incubator where we could work
> >> on it with you and then make the decision of coming to the
> >> Geronimo project or being something else, like a stand-alone top-
> >> level project.
> >>
> >> c) I assume that you'd be offering committers to help us with the
> >> codebase and to continue working and expanding.  Do you have an
> >> idea of how many?
> >>
> >> Thanks for doing this, and we look forward to discussion on both
> >> subjects above.
> >>
> >> geir
> >> --
> >> Geir Magnusson Jr                                  +1-203-665-6437
> >> geirm@apache.org
> >>
> >>
> >>
> >>
> >
> >
> 
> 


-- 
Davanum Srinivas -http://blogs.cocoondev.org/dims/

Mime
View raw message