directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Wallace <rwall...@thewallacepack.net>
Subject Re: OT: Psuedo Async File IO
Date Sat, 09 Apr 2005 06:06:40 GMT
Trustin Lee wrote:
> Hi Richard,
> 
> 
>>I'm getting to a point with my smtp protocol provider that I need to
>>start thinking about file IO.  Since there is no support for
>>non-blocking IO in Java yet I need something that fakes it.  I was
>>wondering if anyone had any experience with any existing components that
>>do this.  If there aren't any really good ones that anyone can recommend
>>I'll probably wind up writing something on my own.
> 
> 
> How about Coconut AIO or stuff from IBM developerWorks?  or,, you
> could implement your own one using Doug Lea's concurrent package
> easily.
> 

Never heard of Coconut before.  But it looks like its not being actively 
developed anymore.  I'll take a closer look and maybe email them.  The 
only thing I found at IBM is this: http://alphaworks.ibm.com/tech/aio4j. 
  That what you meant?  I saw that but wasn't sure of the licensing on 
it.    Using Doug Lea's concurrent package is definitely a good idea if 
I do go the custom route.

> 
>>I'm kind of thinking it should basically be a component that uses a
>>single thread to monitor a queue for IO requests and then uses something
>>like the IoHandler in MINA to let clients know when reads/writes have
>>started/stopped/failed.
> 
> 
> It would be nice if MINA can support file I/O, but I don't see any
> easy way to do it retaining current API.  Of course we could read one
> file sequentially as requests and write the other file sequentially as
> responses.  WDYT?
> 

Actually, I wasn't thinking too much of actually changing MINA as maybe 
taking some of the interfaces and modifying them to make them more 
appropriate for file IO.  I could probably use a good deal of the things 
in the o.a.mina.io package and the filter subpackage.  The filters could 
be handy for adding things like compression and encryption.  Then using 
something like the ProtocolHandler but without the 
session{Opened|Closed|Idle}() methods for notifying the caller that data 
has been written or read.  Sound reasonable?

Rich

Mime
View raw message