mina-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Guy Itzhaki" <gitzh...@nextnine.com>
Subject RE: Possible synchronization issue
Date Tue, 21 Sep 2010 11:07:28 GMT
Thank you very much for the fast and elaborated response.

I've tested the client back and forth, I even sniffed the data that sent from the server and
I clearly saw the server start processing a message before it finished processing the message
before. I even looked into the NIOProcessor logs and I saw that a message was processed before
the previous one was finished.
I want to emphasis that it doesn't happen when I am using encoders.
Maybe my FileWithHeaderWriteFilter is causing this problem (although it is a very simple one)
I just don't know how...

Per your input about ordered execution please note that I care less about the order, all I
care is that messages will arrive to their destination. 

If you need me to provide you with more details please let me know.
Thanks in advance,

-----Original Message-----
From: Emmanuel L├ęcharny [mailto:elecharny@apache.org] 
Sent: Monday, September 20, 2010 3:34 PM
To: users@mina.apache.org
Subject: Re: Possible synchronization issue

  On 9/20/10 11:35 AM, Guy Itzhaki wrote:

Ok, I have tested the code, but sadly the client blows chuncks at some 
point, as it does not assume the response can be split in pieces. I get 
an OOM because the read size is a huge integer just because what has 
been read is in fact text.

Anyway, I see that in the server sessionOpened() method you are creating 
a thread to send all the responses to the client. Don't expect this 
thread to be fully executed before another call to the server for the 
very same client to be processed, as as soon as the thread on which your 
client session is being procesded will be released as soon as the thread 
has been launched (or a few ms after).

By creating a thread in one of the Handler methods, you are breaking the 
ordered execution of client requests.

Remove this thread, and may be rethink the way your server is processing 
client requests. I would suggest something like :

     public void sessionOpened( final IoSession session )
         log.info( "Session Opened ignore incoming messages unless 
'Start' command" );

                     File[] files = new File( "/Users/elecharny/test" 
                     System.out.println( "there are " + files.length + " 
to send" );

                     for ( File file : files )
                         FileWithHeader fileWithHeader = new 
FileWithHeader( file );
                         System.out.println( "send " + file.getName() + 
" len " + file.length() );
                         session.write( fileWithHeader );
                 catch ( IOException e )

The simple fact to call session.write inside the loop will already keep 
the session busy and this session will have to wait until the loop is 
processed to process another request for this session.

Obvioulsy, it has some drawback, like the client won't be able to stop 
the execution in the middle. You have ways to deal with this : first, 
don't use an OrderedThreadPool executor, otherwise you won't be able to 
process any other request while the previous one has been totally 
processed. Second, you'll have to manage the application's states : when 
a SEND request is being processed, another SEND request will have to 
wait. But this is something you have to deal with in the server, as MINA 
is not smart enough to do that (remember that MINA is *just* a NIO 

Adding an executor in the chain can help, but again, it's all about how 
your protocol should handle parallel requests. And then as you have to 
use a UnorderedThreadPool executor( *if* of course you want to be able 
to stop some processing on the server on the client request), then you 
still have to manage the application's states the same way.

Does it make sense ?

Emmanuel L├ęcharny

Click here to report this message as SPAM: http://vsp.ateranetworks.com/ReportSpam.php?sid=cdbd0d4e3172e6df2c2a945f36a12534_f2b5b05bcccc50c92ce2398af1c8380c
-- Powered by ATERA Networks --

View raw message