geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kresten Krab Thorup <k...@trifork.com>
Subject Re: Donation of a CORBA Orb
Date Thu, 07 Jul 2005 20:28:04 GMT
Thanks for the pointer, Hiram.  I will definitively make sure to look  
into that project.

Kresten


On Jul 7, 2005, at 6:00 PM, Hiram Chirino 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
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>
>


Mime
View raw message