geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <ammul...@alumni.princeton.edu>
Subject Re: Donation of a CORBA Orb
Date Thu, 07 Jul 2005 17:17:54 GMT
	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.

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

Mime
View raw message