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" );
try
{
File[] files = new File( "/Users/elecharny/test"
).listFiles();
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 )
{
e.printStackTrace();
}
}
}
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
framework).
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 ?
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
