geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <ge...@apache.org>
Subject Re: Donation of a CORBA Orb
Date Thu, 07 Jul 2005 17:33:06 GMT

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



Mime
View raw message