mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Trustin Lee" <trus...@gmail.com>
Subject Re: NIO and Fileaccess
Date Thu, 08 Jun 2006 01:50:13 GMT
Hi Michael,

On 6/5/06, Michael Bauroth <Michael.Bauroth@falcom.de> wrote:
> Hi,
> I'm interested in both directions.
> First of all the incoming direction: Assume that I have 10.000
> concurrent client connections sending data to the server. I've to make
> some plausibility checks for the data and afterwards I must store it in
> some way. MySQL and other DB's can't handle such amount of incoming data
> every second without a cluster behind the server I think. That's why I
> want to store (append) the data in separate CSV files and import it over
> the CSV engine from MySQL only when I need them.
> To reduce the overhead of separate file / data handling and
> transformation I thought that it would be a good idea to take the
> already existing ByteBuffers and a separate connector (Mina), which
> forwards the data directly to some FileChannels using NIO. In this way I
> have a consistent data flow chain without separate overhead.

If you have to do some check before writing the data into a file, then you
have to load the data into ByteBuffer, check the integrity, and write it
into the file.  So there's no much benefit of using MINA to write a file
IMHO.  In case you want to directly link SocketChannel into FileChannel, we
need some work related with this here.

The outgoing direction: In the same model sometimes it can happen, that
> a client needs some data stored in a file. Here I want to specify the
> file over a filechannel and redirect the ByteBuffer data over the chain
> directly to the clients (eventually using some of the filters to modify
> parts of the content).

This can be handled with Dave's solution.  Let's wait for Dave's patch!

what we call human nature is actually human habit
PGP key fingerprints:
* E167 E6AF E73A CBCE EE41  4A29 544D DE48 FE95 4E7E
* B693 628E 6047 4F8F CFA4  455E 1C62 A7DC 0255 ECA6

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message