directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Trustin Lee <>
Subject Re: [mina] Looking for advice...
Date Mon, 28 Nov 2005 04:52:46 GMT
Hi Olivier,

I'm sorry for a late response.

2005/11/25, Olivier Ceulemans <>:
> I'm converting a blocking io server to mina (using 0.9 snapshot). My
> server handles big requests (large xml requests and large binary
> attachments) using a simple and proprietary protocol. I actually managed
> to perform a dumb port to mina without encountering major difficulties
> in just a few hours of work (thanks to your great tutorial!).

That's good!

However, I'm not sure I have made the right choices, the following
> points are causing me some trouble:
> - In my decoder, I parse xml data to convert it to pojo containing
> business data. To do that, I must copy everything to a
> ByteArrayOutputStream and then convert to a ByteArrayInputStream that
> can be handled by traditional xml parsers. I see two problems with that:

You can implement a ByteBufferInputStream instead of this redundancy.

       - My xml data is sometimes large, so it takes a lot of memory. It
> could be nice id my pojo could be constructed progressively but xml
> parsers can't be fed with bytebufers...

You're right.  Traditional XML parsers don't fit with asynchronous I/O.
What do you think about XML Pull Parsers which provides the better model for
asynchronous I/O?

       - I'm not sure this processing should be done at this level (in
> the decoder) from a mina point of view.

It's a good idea. :)

- In my decoder, I copy binary data to temporary files and pass file
> object to the protocol handler. Again it seems like decoders should not
> perform these kind of 'heavy' operations ?

If the binary data is big enough, you have to do so.  If it is small, you
don't need to do so.  You can choose one of them dynamically.

- In my encoder, I sometimes create very large bytebuffers to return data.
>        - Should i create smaller bytebuffers, write them, join their
> WriteFuture before sending the next one ?

That will decrease the throughput, but I think it is a reasonable approach.

After searching, I saw a solution in the StreamIOHandler. But, I don't
> see clearly what this brings (in term of performance) compared to a
> blocking IO solution. I insepcted the code, and it looks like it create
> one thread per session like a standard blocking IO solution.

You're right.  It is semi-asynchronous.  It will run slightly faster than
plain blocking I/O though.  I recommend you avoid StreamIoHandler.

After much thinking, I think that what could be the best for me is a
> StreamIOHandler that only spans the time of a request/response cycle of
> my server and that could be reused in a threadpool. Is it possible to do
> that with mina ?

Yes, it's possible. But I always recomment to use ProtocolEncoder/Decoder
for maximum performance. :)

==>Don't hesitate to point me to background information: I'm aware I
> might not have comletely understood the underlying phylosophy of mina.

I think you already have great knowledge on MINA! :)

what we call human nature is actually human habit

View raw message