Experience of a recent user of Mina and some bug/improvement/question for Mina

[Frédéric Brégier <fr...@free.fr>]

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 

Re: Experience of a recent user of Mina and some bug/improvement/question for Mina

[Niklas Therning <ni...@trillian.se>]

fred.bregier@free.fr wrote:
> I agree with you. I didn't notice this way.
> Thank you !
>
> But anyway, don't you think, all of the Mina team
> and other people, that when one call the close().join()
> function on a session, one could assume that
> it will wait (with the join() feature) until
> all pending sending messages are really sent ?
>
> For me, my logic is that if I call close().join(),
> it should wait for all messages to be gone.
> As the usual meaning of close (filechannel, stream, ...).
>
>   
I agree with you that calling session.close() should wait until all
pending writes have been written before closing the connection. That
would be more in line with how it works with streams (close() flushes
out everything written before closing the stream) and I think that is
what most users would expect.

However, the way session.close() works currently also has it's uses.
Sometimes you may want to close a session forcefully without flushing
anything. But it might be better to introduce a new method for that like
session.destroy().

WDYT?

-- 
Niklas Therning
Software Architect
www.spamdrain.net

Re: Experience of a recent user of Mina and some bug/improvement/question for Mina

[fr...@free.fr]

I agree with you. I didn't notice this way.
Thank you !

But anyway, don't you think, all of the Mina team
and other people, that when one call the close().join()
function on a session, one could assume that
it will wait (with the join() feature) until
all pending sending messages are really sent ?

For me, my logic is that if I call close().join(),
it should wait for all messages to be gone.
As the usual meaning of close (filechannel, stream, ...).

If not, every users need to check if their message
are really gone, whatever the process, by hand,
before closing the session in a secure way.
Of course, we can all put write(...).join()
for the last write operation, but sometime
it can be not so easy. For example, I saw in
the mailing list a recent bug with IoStream if
I recall well.

However, I found a way to make it correct
at least for me (waiting on getScheduledWriteRequests()
to be 0 before calling close()).
Perhaps it could be a good idea to change a bit
the standard close function in MINA ?
There is probably better ways than mine inside MINA.

Frederic

Selon peter royal <pr...@apache.org>:

> On Jul 27, 2006, at 3:49 PM, Frédéric Brégier wrote:
> > 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).
>
> Put a callback on the last WriteFuture you get from writing, and in
> that, perform your close. That way it will close after sending the
> last message.
>
> -pete
>
>
> --
> proyal@apache.org - http://fotap.org/~osi
>
>
>
>

Re: Experience of a recent user of Mina and some bug/improvement/question for Mina

[peter royal <pr...@apache.org>]

On Jul 27, 2006, at 3:49 PM, Frédéric Brégier wrote:
> 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).

Put a callback on the last WriteFuture you get from writing, and in  
that, perform your close. That way it will close after sending the  
last message.

-pete


-- 
proyal@apache.org - http://fotap.org/~osi

Re: Experience of a recent user of Mina and some bug/improvement/question for Mina

[fr...@free.fr]

Hi all, (sorry for some bad english, but I try)
To continue on this thread :

On 2) ThreadPool. I am also in the same context than Raj.
That is I have two kinds of clients:
a) one shot client : many of them (10 000) may run but with
 one connexion/exchange of one file (many messages)/deconnexion
b) long term client : few of them (less than 100) may run but
 with lon term connexion (many exchange of files or orders)

So I have both problem, also from the client point of vue.
So one more question : is there a specific aspect for threadpool
according to the client aspect ? Or do we just need to take
this problem outside MINA for the client point of vue ?

The question is still open for the server part of course.

On 3) Memory :
I try a long term session with client, and it appears that memory
is better handled in this case for the client (about the same
memory both in client and server part).
But if I used short term client, but with many connexion in one
running java program, then the memory of the client is really
growing in proportion very different than the server.
The difference is only the number of new sessions for the client.

Is there a way to be sure that this memory is released when the session
is closed for the client ?
At the time writting, the memory isn't released correctly for the client
with many sessions (sequentially created and closed).

On 4) Close feature :
I implement the following spirit in my business logic :
- when I start a session, I set up a lock (java.concurrent).
- when I send the last message (or received the last message),
I unlock this lock and then waiting for all pending
messages to be send in this session (using the
IoSession.getScheduledWriteRequest to return 0).

I am feeling that the IoSession.close() should at least
waiting that IoSession.getScheduledWriteRequest should return 0
in order to close correctly the session.
At least, the join() on the closefuture should wait on this,
but it depends on the meaning of the join() feature.
What do you think ?

At the time speaking, I am able to send/receive (client and server
on the same laptop) about 21K of file in 20 ms (using 1K buffer).
I know the buffer is small, but is just for testing, and the speed
is already here, so I am quite happy.

On 1) (serialization) My questions are still open of course.

Frederic

Re: Experience of a recent user of Mina and some bug/improvement/question for Mina

[Raj Kunjithapadam <kr...@silverspringnet.com>]

Hi All,
Like Frederic here I am new to MINA and have similar questions. More  
specifically it would help if someone could answer the
thread pool question.
Per this link http://wiki.apache.org/directory/MinaTutorial it is  
rather clear from looking at the java docs that this document is old.

I am trying to use MINA on the client side but this client lives  
within a long running App server and will be sending and receiving  
messages
from a proprietary message bus(server).
So it is a long lived client/sessions

The sending and receiving itself should be quick as it is assumed the  
client and server are on a high speed LAN(fast or Gig E)
But the client after parsing the message could be taking some time to  
process the business logic and insert some info to DB.

Now one way to reach parallelism from my understanding is to use  
multiple IoSession(s) (sockets) for sending and receiving
meaning adding a thread pool in the socket layer through the MINA  
ThreadPoolFilter being added to the DefaultIoFilterChain.

Is this the recommended and correct way for a long lived client and  
can I have multiple IoSessions for my client application?

Is there an example or document to add a ThreadPoolFilter higher up  
in the protocol stack where I am going to be handling my business  
logic over and above the ThreadPool in the socket layer.

In that tutorial it talks about
> ProtocolHandler is a counterpart of the I/O layer IoHandler.

I could not find exactly the equivalent of ProtocolHandler in 0.9.x.  
Is this the ProtoclDecoderAdapter?

Help appreciated.
--KRaj




>
> 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 ?
>