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: ActiveIO (was: Donation of a CORBA Orb)
Date Mon, 11 Jul 2005 09:59:14 GMT
Hiram,

I browsed through the ActiveIO code, and it is pretty close to what I  
am looking for for the basic IO stuff.   Very nice!

Here's a couple of things that come off my mind...

- the NIOAsyncChannel class should use the selector mechanism to wait  
for the ability to write data, rather than Object.wait'ing.

- it would be benefitial to be able to buffer output enabling  
invocations in the main logic threads to finish fast, and then do the  
I/O in a separate thread (for example directly inside the selector  
thread).   This is valuable for "slow clients" that may access the  
server over a modem for example.  But this is just nice to have.

Maybe the above two could be combined into an "OutputAsyncChannel"  
interface?  Perhaps this could work by means of a special FlushPacket  
that invokes a callback handler when all previous packets has been sent.

- It looks like all writes are synchronous and blocking.  We need to  
have a timeout mechanism for both read- and write-operations -- this  
is critical for large-scale operations.  When there are many clients,  
several of them will typically be inactive for longer periods of  
time, and so there is a lot to be saved by closing down connections.   
Also, some of them will simply hang, become disconnected from the  
network without TCP-level notification, or otherwise be ineffective.   
example: In one of our installations we have hundreds of CORBA  
clients sitting at "work stations" around the facility, and most of  
these are idle most of the time.  Corba/iiop has a mechanism to  
reestablish such connections as needed  (at least the Trifork ORB  
does that).

- It would also be good to have the half-close functionality.  In the  
Trifork ORB, if ORB receives a shut down, all active connection  
sockets are half-closed until active requests are done and responses  
sent.

One of the difficult problems with TCP sockets is that one does not  
necessarily know if the other end closed the connection (or if he is  
gone).   This can result in some pretty annoying hangs higher up the  
stack, and it's a pain to handle those cases all over the place in I/ 
O code.  The only "generic solution" to this as far as I can see is  
to use reasonable timeouts everywhere.

I'll come back later with some thoughts on SSL stuff...



Kresten Krab Thorup
krab@trifork.com

"We do not inherit the Earth from our parents, we borrow it from our  
children." Saint Exupery



On Jul 8, 2005, at 5:35 PM, Hiram Chirino wrote:

> Hi David,
>
> You are absolutely correct.  The ActiveIO stuff was a  
> generalization and abstraction of the IO code in ActiveMQ.  Thanks  
> for clarifying a potentially sensitive situation!
>
> Regards,
> Hiram
>
> On Jul 7, 2005, at 10:51 PM, David Blevins wrote:
>
>
>> On Thu, Jul 07, 2005 at 12:16:19PM -0400, 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.
>>>
>>>
>>
>> There's the "f" word again :)
>>
>> Hiram, you can correct me if I'm wrong, but thought the ActiveIO code
>> was created from the ActiveMQ transport system?
>>
>> We had several conversations over a period of months on just using  
>> the
>> ActiveMQ transports in OpenEJB and Geronimo so there would be
>> something common to cut-down on duplicating efforts.  We didn't use
>> any Geronimo IO code cause it, well... sucked :)
>>
>> Even then, I think you pretty much rewrote everything.
>>
>> Is my memory of history accurate or have I demented myself?
>>
>> -David
>>
>>
>
>


Mime
View raw message