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 <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED]
--
Davanum Srinivas -http://blogs.cocoondev.org/dims/
