|
Home > Archive > Apache Directory Project > November 2005 > [mina] Looking for advice...
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
[mina] Looking for advice...
|
|
| Olivier Ceulemans 2005-11-24, 5:47 pm |
| Hi,
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!).
I started from the 'Reverser' sample (High-level message
encoders/decoders & protocol handler)
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:
- 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...
- I'm not sure this processing should be done at this level (in
the decoder) from a mina point of view.
- 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 ?
- 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 ?
At this point, I must admit I'm a bit confused and not happy with my
solution that eats a lot of memory compared to the old blocking IO
solution (however I understand that it can admit a larger number of
connections without killing the jvm in context switching operations).
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.
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 ?
==>Don't hesitate to point me to background information: I'm aware I
might not have comletely understood the underlying phylosophy of mina.
Thanks in advance,
Olivier.
| |
| Trustin Lee 2005-11-28, 2:45 am |
| Hi Olivier,
I'm sorry for a late response.
2005/11/25, Olivier Ceulemans <olivier.ceulemans-AgBVmzD5pcezQB+pC5nmwQ@public.gmane.org>:
>
> 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!
HTH,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
|
|
|
|
|