I use MINA 0.9.4 in an open project where MINA is using as a TCP/IP layer Server/Client for my project. I found MINA very interesting as I want to get non blocking IO on the net and also in my under layer (physical which are files on several filesystems).
I implement quite quickly and easily with Mina a server/client approach. The main idea is the client ask for a file or put a file then the server is responding to the client the file or receiving the file. In the beginning I wanted to directly send the file, but I found on several mails there is an issue right now with the Stream, which could be a problem for me (if I remeber well, the current implementation is blocking). So I implement it in another way, that is using first the demuxing part for the server (as it is intend to serve several functionnality). Sceond, the server is responding by packet, which each of them is a section of the file to transmit, in order to allowed a maximum of asynchronous transfer without taking in memory the full file to transmit or receive. I use also the serialization filter so that I bring in one class a part of the message. I get started from the SumUp example. As far as I am now (just starting a few weeks ago), I am quite happy with MINA. I found several points, but I don't know if they could be considered as bugs or improvements. 1) The serialization filter : I found there is a limit in the code both for encode and decode, but the limits are different (2 GB for encoder while 1 Mb for decoder). I don't know if it is normal or not, so I made my own serialization filter which is almost the same except the limits are the same (2 Gb). What do you think of this ? Second, I was surprised to see that the decoder is a cumulative protocol. Why this ? I don't understand quite really the difference. I try with my own filter both situations (cumulative or not) and I didn't see so far any difference. But I don't go around 2 Gb, so perhaps here is the problem ? 2) ThreadPool : The documentation is quite different considering 0.8.x and 0.9.x and it was difficult for me to find the right way to assign my ThreadPool with the number of thread I want. I am quite confused with the model, as I didn't see clearly where to put this ThreadPool. I understand that in 0.8 it was possible to put a ThreadPool both at the socket part and at the filter part. But I am not sure what is the best and what is the correct usage considering that I will have more than 10 000 users concurrently connected and each of them could done a simple task that could be heavy (in short time but quite cpu consumming or many message to send or receive). Can someone explains the model and how to correctly set the TreadPool(s) in 0.9.x ? 3) Memory : When I run my test with a single client making around 1000 get and put connections (500 of each), both the server and the client are quite symmetric (get or put is quite the same except the way the file is going to). The memory of the server, after a while, is fixed around let say 40 Mb, whatever the number of clients I ran. The memory of each client, at the end of the 1000 get and put, is around 150 Mb and not decreasing except if I put a long sleep, but then decreasing about 1 Mb each 8 seconds (even if I put a delay of 1 second for the ByteBuffer policy). As the server and the client are quite symmetric (except the server has open port for connection and not the client), I don't understand the real difference between them. Are the memory policies differents on server and client side ? How can I resolved this at it seems the client is going up and up in memory every time it sends or receives a message ? 4) Close feature : I was a bit surprise when I found the following situation. Consider the server is making a loop to send about 20 messages (each of them being a part of a file). At the end of the sends (session.write()), I put a session.close() and then a join() on the CloseFuture. I make a trace of all messageSent, sessionClosed, ... and I observed the following : - 10 messageSent (message really sent), - 1 sessionClosed appears - and of course the 10 last messages to sent are never sent (since the session is closed). Of course, session.write didn't say that when it returns, the message is realy sent. It is ok for me. But I believed that when I call session.close(), this function will wait that all sending messages in queue for this session will be sent before to closed the connection (or at least with the join()). It wasn't. To bypass this problem, I add a business logic in my program as follow : I put a lock in my session information that I unlock when the last message is really sent (in the messageSent() function). Then, before calling the session.close(), I wait on the lock until it is released. Coud it be possible that the normal call to session.close().join() would wait that all pending sends are really sent ? However, I found MINA quite useful and interesting. I was not forced to write it from scratch ! Thank you again for this great job ! Frederic
