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