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/
