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 17:34:36 GMT
yep. +1


On 7/7/05, Geir Magnusson Jr. <geirm@apache.org> wrote:
> 
> On Jul 7, 2005, at 1:17 PM, Aaron Mulder wrote:
> 
> >     I dunno, if it's going to take 4 months for TriFork to finish
> > releasing the code, I'm all in favor of picking a home ASAP so it
> > doesn't
> > slip further.
> >
> >     I think the incubator is the best, as everyone who needs to can
> > get access to it there, I think some incubation steps are required
> > for any
> > pre-existing donated code anyway (for legal/IP reasons), and we can
> > delay
> > the decision of whether it goes into a Geronimo subproject or a
> > project
> > of its own until it actually is ready to leave the incubator.
> 
> To be clear, the incubation steps can happen in parallel - it doesn't
> require a "quarantine visit" or such in incubator SVN repo.  It can
> come directly here if we choose, and do the documentation at the same
> time.
> 
> geir
> 
> 
> >
> >     I'm not sure the ActiveIO question is all that relevant, since I'm
> > assuming IO is a small part of the ORB.  That is, if they want to
> > enhance
> > and use ActiveIO, that can become a library dependency for the
> > incubator
> > ORB module.  If they choose to start with their own IO code, they
> > can put
> > it in the incubator, adn then decide when/whether/how to replace it
> > with
> > ActiveIO or something else going forward.
> >
> > Aaron
> >
> > On Thu, 7 Jul 2005, Hiram Chirino wrote:
> >
> >
> >> That's a possibility.  I would not mind bringing the project into
> >> apache if it will help grow the community.
> >> But I think the first step is to see if activeio is the kind of think
> >> that new Trifork orb is interested in.
> >>
> >> Regards,
> >> Hiram
> >>
> >> On Jul 7, 2005, at 12:16 PM, Davanum Srinivas wrote:
> >>
> >>
> >>> 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/
> >>>
> >>>
> >>
> >>
> >>
> >
> >
> 
> --
> Geir Magnusson Jr                                  +1-203-665-6437
> geirm@apache.org
> 
> 
> 


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

Mime
View raw message