You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by "Trustin Lee (JIRA)" <ji...@apache.org> on 2007/11/14 08:08:43 UTC
[jira] Created: (DIRMINA-477) Update page about differences between
1.x and 2.x
Update page about differences between 1.x and 2.x
-------------------------------------------------
Key: DIRMINA-477
URL: https://issues.apache.org/jira/browse/DIRMINA-477
Project: MINA
Issue Type: Task
Components: Web Site / Documentation
Reporter: Trustin Lee
Fix For: 2.0.0-M1
Our current web site doesn't describe what have been changed in 2.x comparing to 1.x. We need to carefully put all changes together there so people can migrate more easily.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Created: (DIRMINA-477) Update page about differences between1.x and 2.x
Posted by Trustin Lee <tr...@gmail.com>.
On Nov 22, 2007 3:45 AM, Frédéric Brégier <fr...@free.fr> wrote:
> Now the client code... As previously, any comment and correction ...
>
> NioSocketConnector connector = new NioSocketConnector(myNumberOfCpuPlusOne);
> // Set connect timeout.
> connector.setConnectTimeout(myTIMEOUTCON);
>
> SocketSessionConfig config = (SocketSessionConfig) connector.getSessionConfig();
> config.setReuseAddress(true); // XXX was false but is true better for client ?
> //XXX VISTA BUG ? => setSoLinger and KeepAlive(true)
> config.setSoLinger(1);
> config.setKeepAlive(false); // true?
> // No delay
> config.setTcpNoDelay(true);
> // set idle timeout
> config.setIdleTime(IdleStatus.BOTH_IDLE, myTIMEOUT);
> config.setReceiveBufferSize(myTCPBLOCKSIZE);
> config.setSendBufferSize(myTCPBLOCKSIZE);
>
> DefaultIoFilterChainBuilder chain = connector.getFilterChain();
> CompressionFilter compression =
> new CompressionFilter(serverCompressed,
> clientCompressed,
> CompressionFilter.COMPRESSION_MAX);
> chain.addFirst("Compression",compression);
> ExecutorService executorChainService = new OrderedThreadPoolExecutor(myNbClient_THREAD);
> // was Executors.newCachedThreadPool();
> ExecutorFilter executorChainFilter = new ExecutorFilter(executorChainService);
> chain.addLast("SerializePool", executorChainFilter);
> ProtocolCodecFactory codec = new ObjectSerializationCodecFactory();
> chain.addLast("Serialize", new ProtocolCodecFilter(codec));
> connector.setHandler(new MyIoHandlerAdapter());
>
> // IoBuffer
> IoBuffer.setUseDirectBuffer(false);
> ioBufferAllocator = new SimpleBufferAllocator();
> IoBuffer.setAllocator(ioBufferAllocator);
>
> // Connection
> IoSession ioSession = null;
> try {
> ConnectFuture future = connector.connect(inetSocketAddress);
> if (future != null) {
> future.awaitUninterruptibly();
> IoSession ioSession = future.getSession();
> if (ioSession == null) {
> // Problem of connection !
> }
> }
> } catch( RuntimeIoException e ) {// Connector is ko=>retry later on
> ioSession = null;
> }
> if (ioSession != null) {
> // set idle timeout
> // Change from Trunk 6 month ago : it seems to be now in SocketSessionConfig directly
> /*ioSession.setIdleTime(IdleStatus.BOTH_IDLE,
> LSDConstants.TIMEOUT);*/
> }
>
>
> And shutting down :
> if (ioBufferAllocator != null)
> ioBufferAllocator.dispose();
> ioBufferAllocator = null;
> if (executorChainFilter != null) {
> executorChainFilter.shutdownNow();
> executorChainFilter = null;
> }
Again, you need to call connector.dispose() to release all resources
such as Selector and Thread. Except that, it looks perfect!
You could also use SocketAcceptor and SocketConnector interface
instead of NioSocketAcceptor and NioSocketConnector concrete class
because you might want to switch to AprSocketAcceptor and
AprSocketConnector in the future.
HTH,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
Re: [jira] Created: (DIRMINA-477) Update page about differences between1.x and 2.x
Posted by Frédéric Brégier <fr...@free.fr>.
Now the client code... As previously, any comment and correction ...
NioSocketConnector connector = new NioSocketConnector(myNumberOfCpuPlusOne);
// Set connect timeout.
connector.setConnectTimeout(myTIMEOUTCON);
SocketSessionConfig config = (SocketSessionConfig) connector.getSessionConfig();
config.setReuseAddress(true); // XXX was false but is true better for client ?
//XXX VISTA BUG ? => setSoLinger and KeepAlive(true)
config.setSoLinger(1);
config.setKeepAlive(false); // true?
// No delay
config.setTcpNoDelay(true);
// set idle timeout
config.setIdleTime(IdleStatus.BOTH_IDLE, myTIMEOUT);
config.setReceiveBufferSize(myTCPBLOCKSIZE);
config.setSendBufferSize(myTCPBLOCKSIZE);
DefaultIoFilterChainBuilder chain = connector.getFilterChain();
CompressionFilter compression =
new CompressionFilter(serverCompressed,
clientCompressed,
CompressionFilter.COMPRESSION_MAX);
chain.addFirst("Compression",compression);
ExecutorService executorChainService = new OrderedThreadPoolExecutor(myNbClient_THREAD);
// was Executors.newCachedThreadPool();
ExecutorFilter executorChainFilter = new ExecutorFilter(executorChainService);
chain.addLast("SerializePool", executorChainFilter);
ProtocolCodecFactory codec = new ObjectSerializationCodecFactory();
chain.addLast("Serialize", new ProtocolCodecFilter(codec));
connector.setHandler(new MyIoHandlerAdapter());
// IoBuffer
IoBuffer.setUseDirectBuffer(false);
ioBufferAllocator = new SimpleBufferAllocator();
IoBuffer.setAllocator(ioBufferAllocator);
// Connection
IoSession ioSession = null;
try {
ConnectFuture future = connector.connect(inetSocketAddress);
if (future != null) {
future.awaitUninterruptibly();
IoSession ioSession = future.getSession();
if (ioSession == null) {
// Problem of connection !
}
}
} catch( RuntimeIoException e ) {// Connector is ko=>retry later on
ioSession = null;
}
if (ioSession != null) {
// set idle timeout
// Change from Trunk 6 month ago : it seems to be now in SocketSessionConfig directly
/*ioSession.setIdleTime(IdleStatus.BOTH_IDLE,
LSDConstants.TIMEOUT);*/
}
And shutting down :
if (ioBufferAllocator != null)
ioBufferAllocator.dispose();
ioBufferAllocator = null;
if (executorChainFilter != null) {
executorChainFilter.shutdownNow();
executorChainFilter = null;
}
Frederic
Re: [jira] Created: (DIRMINA-477) Update page about differences between1.x and 2.x
Posted by Frédéric Brégier <fr...@free.fr>.
Hi all,
Another point I discovered last few days and that woul be
useful to point in the web page from 1.x to 2.x :
- setDefaultLocalAddress
- setCloseOnDeactivation
change from two weeks Mina 2 for the acceptor
so should be also changed in the web page
(and correct the page since it is written setLocalAddress).
As far as my benchmark are now, the performance
are almost the same (even a little bit better but how to
know if it comes from Mina alone or from my correction
on other parts).
Frederic
Re: [jira] Created: (DIRMINA-477) Update page about differences between1.x and 2.x
Posted by fr...@free.fr.
Hi Trustin,
Thank you and it is my pleasure if I can help... ;-)
I am on the way to migrate so I will let you know,
especially after new benchmarks...
Frederic
Selon Trustin Lee <tr...@gmail.com>:
> Hi Frédéric,
>
> On Nov 21, 2007 3:55 AM, Frédéric Brégier <fr...@free.fr> wrote:
> > Hi Trustin and all of you !
> > I come back to MINA since I feel that MINA 2 is on the way to get out.
> > And I start to look what could be my effort to switch from beta 2 (trunk)
> > from 6 months ago to the current status of trunk.
> > I found some points that might be good to add on the page you started to
> > write.
>
> Thanks for the feed back! Your suggestion will hopefully be applied
> before the first release candidate of 2.0 is released. :)
>
> > Just a question I've just thinking about : Am I correct if I say
> > Executors.newCachedThreadPool()
> > will no more allows order as it is point in this page of transition in
> > filter ?
> > Of course, page in "configuring thread model" is no more correct for V2
> > (as far as I understand).
>
> Right. We need to update it.
>
> > As always, Mina is going better and better... Just I feel like almost a new
> > user to Mina
> > after 6 months without coding Mina stuff, even If I read all the mailing
> > list (great one !).
>
> I hope the changes were not too much to follow. How was your experience?
>
> Cheers,
> Trustin
> --
> what we call human nature is actually human habit
> --
> http://gleamynode.net/
> --
> PGP Key ID: 0x0255ECA6
>
Re: [jira] Created: (DIRMINA-477) Update page about differences between1.x and 2.x
Posted by Trustin Lee <tr...@gmail.com>.
Hi Frédéric,
On Nov 21, 2007 3:55 AM, Frédéric Brégier <fr...@free.fr> wrote:
> Hi Trustin and all of you !
> I come back to MINA since I feel that MINA 2 is on the way to get out.
> And I start to look what could be my effort to switch from beta 2 (trunk)
> from 6 months ago to the current status of trunk.
> I found some points that might be good to add on the page you started to
> write.
Thanks for the feed back! Your suggestion will hopefully be applied
before the first release candidate of 2.0 is released. :)
> Just a question I've just thinking about : Am I correct if I say
> Executors.newCachedThreadPool()
> will no more allows order as it is point in this page of transition in
> filter ?
> Of course, page in "configuring thread model" is no more correct for V2
> (as far as I understand).
Right. We need to update it.
> As always, Mina is going better and better... Just I feel like almost a new
> user to Mina
> after 6 months without coding Mina stuff, even If I read all the mailing
> list (great one !).
I hope the changes were not too much to follow. How was your experience?
Cheers,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
Re: messageSent on DemuxingIoHandler
Posted by Frédéric Brégier <fr...@free.fr>.
Hi Trustin,
I am still not sure on the answear. For the moment,
I do like both methods are called when message is
send (both from the specific MessageHandler and from
DemuxingIoHandler).
Frederic
----- Original Message -----
Hi Trustin,
Well, I am sometime (always ?) quite long in my email
and obviously not necesseraly more clear than others.. ;-)
The problem I found (is this a problem, I don't know) is :
1) In the past, only DemuxingIoHandler has messageSent() function
to overload but not mandatory (you can if you want not define
anything). In my code, I had some codes to do some stuff
after the message is really sent.
2) Now, in trunk, MessageHandler has a mandatory messageSent()
function.
As when you use DemuxingIoHandler, you should use also object
that extends MessageHandler, I feel like a bit loose.
Contrary to what I wrote before, I would not suggest to remove
the messageSent() from DemuxingIoHandler since a message can be
sent, even if no MessageHandler is registered for it.
I try in my code, and I saw "DemuxingIoHandler.messageSent()" called
for such message not registered.
Now the question :
If one messageHandler is registered and such a message is sent, which function will be called ?
DemuxingIoHandler.messageSent() on all messages ? or only on not registered messages ?
MessageHandler.messageSent() on all messages that are registered ?
Or only one (for registered message) ?
As I need to do some stuff after message is sent, I don't know if I need to
writye the same code (or so) in each messageSent() of MessageHandler.
I hope I am more clear, this time.
And for JMX, I was starting to think about it since I feel like I really should improve
this part in my app. So thank you for this ! I start probably this week some benchmark
(I hope almost all my port to "new" trunk is done). After that, I could spend some useful
time on JMX approach...
Frederic
----- Original Message -----
From: "Trustin Lee"
On Nov 22, 2007 5:40 PM, fred.bregier wrote:
> I suppose the one from MessageHandler is the one that would be executed, right ?
>
> Since we must defined messageSent function in MessageHandler
> (mandatory), second it is not mandatory to get it in DemuxingIoHandler,
> third as you said only one will be called (the one from
> MessageHandler ?), I would say that probably this function in
> DemuxingIoHandler is no more necessary and probably confusing with the
> one from MessageHandler.
> Except if one can use DemuxingIoHandler with something totally different
> from MessageHandler (?), I would suggest to remove this function (or mark
> it as deprecated and pointing to the one in MessageHandler). WDYT ?
I didn't get the question actually. Could explain again?
Thanks in advance,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
Re: messageSent on DemuxingIoHandler
Posted by Trustin Lee <tr...@gmail.com>.
Hi Frédéric,
I am so glad that you like my change. Let me mark the two methods final then.
Cheers,
Trustin
On Dec 13, 2007 3:37 AM, Frédéric Brégier <fr...@free.fr> wrote:
> Hi Trustin,
> I have made all the changes (about an half hour so quite quickly),
> and it is really perfect and more clear now.
> So I think your original idea from the first mail (splitting MessageHandler by
> adding addSentMessageHandler and addReceivedMessageHandler)
> and the given implementation were the good one (as always) !!!
> I really thank you and it gives me the opportunity to correct the logic
> of my program !
>
> I feel like the idea to make final those functions (messageSent and
> messageReceived) in DemuxingIoHandler should be done in order
> to prevent some users (like me) to override them and so breaking
> the Mina's logic.
>
> Again, a very big thank you !
>
> Frederic
>
>
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
Re: messageSent on DemuxingIoHandler
Posted by Frédéric Brégier <fr...@free.fr>.
Hi Trustin,
I have made all the changes (about an half hour so quite quickly),
and it is really perfect and more clear now.
So I think your original idea from the first mail (splitting MessageHandler by
adding addSentMessageHandler and addReceivedMessageHandler)
and the given implementation were the good one (as always) !!!
I really thank you and it gives me the opportunity to correct the logic
of my program !
I feel like the idea to make final those functions (messageSent and
messageReceived) in DemuxingIoHandler should be done in order
to prevent some users (like me) to override them and so breaking
the Mina's logic.
Again, a very big thank you !
Frederic
Re: messageSent on DemuxingIoHandler
Posted by Frédéric Brégier <fr...@free.fr>.
Hi Trustin,
>I've made more change to MessageHandler and DemuxingIoHandler to fix
>the API design issue you raised. Please take a look at the following
>change log. The code will explain everything:
>
> http://svn.apache.org/viewvc?view=rev&revision=603158
I understand again more clearly after your words what I should do.
I suppose I was confusing with the "standard way" of IoHandler.
I didn't make the necessary change in my code as I should do.
So I will make the change ASAP, taking the last revision of trunk to test it.
I quickly read your change, and I feel like it could do the trick.
I will come back to you with my final impression.
>You could simply register MessageHandler.NOOP to that type of message,
>no? If you want to ignore all messageSent events, then you can even
>do the following:
>
> handler.addSentMessageHandler(MessageHandler.NOOP);
>
>Especially with the change I've just made, I think all the concerns
>you raised have been resolved. Please let me know if there's any case
>that I missed out.
Let me come back after I made the change.
> > If I am correct, in my case, it is therefore necessary to keep both ways
> > as possible in MINA.
> > Except perhaps I break the logic of Min by doing this ?
>
>The possibility of overriding
>DemuxingIoHandler.messageReceived/messageSent/exceptionCaught/findReceivedMessageHandler/findSentMessageHandler/findExceptionHandler
>means that anyone who extends DemuxingIoHandler can break the existing
>logic of DemuxingIoHandler. We could make all these methods final and
>provide a kind of hook methods whose access modifier is 'protected'.
>Assuming my recent change has resolved all the issues you raised, we
>could do that. WDYT?
Yes, I think if one should not overriding such methods, you probably
have to make them final, espcially considering it is quite different than
standard way (standard IoHandler, where you have to override them
in the IoHandler) and so should be point both in documentation API
and with the "final" word.
>> Should I register those written only MessageHandler even if I never received one of them ?
>> Perhaps it is related more to your question on splitting MessageHandler ?
>> I don't like to make the API growing more and more, but you probably know better
>> than me what it is better ot not in this case.
>
>Yes, you have to register MessageHandler.NOOP at least to avoid an
>exception. I think it's mandatory to prevent any mistake that a user
>might forget to register a required handler.
OK, I will make the change and come back to you.
I suppose it should not take too long... (I hope)
Thank you again for your help !
Frederic
Re: messageSent on DemuxingIoHandler
Posted by Trustin Lee <tr...@gmail.com>.
Hi Frédéric Brégier,
On Dec 11, 2007 12:09 AM, Frédéric Brégier <fr...@free.fr> wrote:
> Hi Trustin,
> Don't be sorry ! I completely understand the time this mailing
> list takes for you, and I really appreciate all the advices you give !!!
> I hope that you still have some night for you and your family...
Thanks for your understanding. I really appreciate it. :)
> Now back on the question :
> I understand better now the way it does with your answear.
> In my case, I probably can continue with only DemuxingIoHandler
> implements the global stuff since it is the same on every message
> (or almost, since I free some data specific to each message).
>
> I am not sure (I'm not such an expert) that splitting MessageHandler
> or making catch-all handler is better than now.
> For now, it was just a matter to know how to do it correctly,
> and your answear is just fine. Perhaps a short note in the API
> would be enough to be clear between those two ways.
I've made more change to MessageHandler and DemuxingIoHandler to fix
the API design issue you raised. Please take a look at the following
change log. The code will explain everything:
http://svn.apache.org/viewvc?view=rev&revision=603158
> Now next question (one answear sometimes brings another question)
> is that are you sure DemuxingIoHandler should throw an exception
> on messageSent when there is no messageHandler for it ?
> I look at the code in MINA, and it seems so.
> In my code, I have one particular message that the server will never
> receive but always anwear (written), so there is no messageHandler for it.
> As I overload the messageSent() function in my deumxingIoHandler,
> it never raised the exception since, if I am understanding clearly,
> mine overloading will never try to find the appropriate messageHandler
> (no call to handler.messageSent()).
You could simply register MessageHandler.NOOP to that type of message,
no? If you want to ignore all messageSent events, then you can even
do the following:
handler.addSentMessageHandler(MessageHandler.NOOP);
Especially with the change I've just made, I think all the concerns
you raised have been resolved. Please let me know if there's any case
that I missed out.
> If I am correct, in my case, it is therefore necessary to keep both ways
> as possible in MINA.
> Except perhaps I break the logic of Min by doing this ?
The possibility of overriding
DemuxingIoHandler.messageReceived/messageSent/exceptionCaught/findReceivedMessageHandler/findSentMessageHandler/findExceptionHandler
means that anyone who extends DemuxingIoHandler can break the existing
logic of DemuxingIoHandler. We could make all these methods final and
provide a kind of hook methods whose access modifier is 'protected'.
Assuming my recent change has resolved all the issues you raised, we
could do that. WDYT?
> Should I register those written only MessageHandler even if I never received one of them ?
> Perhaps it is related more to your question on splitting MessageHandler ?
> I don't like to make the API growing more and more, but you probably know better
> than me what it is better ot not in this case.
Yes, you have to register MessageHandler.NOOP at least to avoid an
exception. I think it's mandatory to prevent any mistake that a user
might forget to register a required handler.
> Perhaps my way (overloading DemuxingIoHandler, just an hypothesis)
> could be related to the other problem of 0 value for messages in statistics ?
No. It's not related. Let me respond in the other thread.
Cheers,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
Re: messageSent on DemuxingIoHandler
Posted by Frédéric Brégier <fr...@free.fr>.
Hi Trustin,
Don't be sorry ! I completely understand the time this mailing
list takes for you, and I really appreciate all the advices you give !!!
I hope that you still have some night for you and your family...
Now back on the question :
I understand better now the way it does with your answear.
In my case, I probably can continue with only DemuxingIoHandler
implements the global stuff since it is the same on every message
(or almost, since I free some data specific to each message).
I am not sure (I'm not such an expert) that splitting MessageHandler
or making catch-all handler is better than now.
For now, it was just a matter to know how to do it correctly,
and your answear is just fine. Perhaps a short note in the API
would be enough to be clear between those two ways.
Now next question (one answear sometimes brings another question)
is that are you sure DemuxingIoHandler should throw an exception
on messageSent when there is no messageHandler for it ?
I look at the code in MINA, and it seems so.
In my code, I have one particular message that the server will never
receive but always anwear (written), so there is no messageHandler for it.
As I overload the messageSent() function in my deumxingIoHandler,
it never raised the exception since, if I am understanding clearly,
mine overloading will never try to find the appropriate messageHandler
(no call to handler.messageSent()).
If I am correct, in my case, it is therefore necessary to keep both ways
as possible in MINA.
Except perhaps I break the logic of Min by doing this ?
Should I register those written only MessageHandler even if I never received one of them ?
Perhaps it is related more to your question on splitting MessageHandler ?
I don't like to make the API growing more and more, but you probably know better
than me what it is better ot not in this case.
Perhaps my way (overloading DemuxingIoHandler, just an hypothesis)
could be related to the other problem of 0 value for messages in statistics ?
Frederic
----- Original Message -----
From: "Trustin Lee"
Hi Frédéric,
I am sorry for the late answer first of all. :)
On Nov 27, 2007 3:15 AM, Frédéric Brégier wrote:
> Hi Trustin,
>
> Well, I am sometime (always ?) quite long in my email
> and obviously not necesseraly more clear than others.. ;-)
>
> The problem I found (is this a problem, I don't know) is :
> 1) In the past, only DemuxingIoHandler has messageSent() function
> to overload but not mandatory (you can if you want not define
> anything). In my code, I had some codes to do some stuff
> after the message is really sent.
> 2) Now, in trunk, MessageHandler has a mandatory messageSent()
> function.
> As when you use DemuxingIoHandler, you should use also object
> that extends MessageHandler, I feel like a bit loose.
>
> Contrary to what I wrote before, I would not suggest to remove
> the messageSent() from DemuxingIoHandler since a message can be
> sent, even if no MessageHandler is registered for it.
> I try in my code, and I saw "DemuxingIoHandler.messageSent()" called
> for such message not registered.
You can still do what you want with DemuxingIoHandler by overriding
messageSent():
public class MyDemuxingIoHandler extends DemuxingIoHandler {
@Override
public void messageSent(...) {
if (...) {
// Implement some common logic
} else {
super.messageSent(...);
}
}
}
It might be better to 1) split MessageHandler into 2 or 2) add a
catch-all handler (e.g.
DemuxingIoHandler.setCatchAllHandler(MessageHandler)) though. WDYT?
> Now the question :
> If one messageHandler is registered and such a message is sent, which function will be called ?
> DemuxingIoHandler.messageSent() on all messages ? or only on not registered messages ?
> MessageHandler.messageSent() on all messages that are registered ?
> Or only one (for registered message) ?
> As I need to do some stuff after message is sent, I don't know if I need to
> writye the same code (or so) in each messageSent() of MessageHandler.
DemuxingIoHandler.messageSent() is implemented to look for a proper
MessageHandler and call it. Therefore,
DemuxingIoHandler.messageSent() is always called. It will throw an
exception if there's no registered handler for a sent message. Of
course, you can override this behavior like I suggested above.
Thank you so much for your feed back,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
Re: messageSent on DemuxingIoHandler
Posted by Trustin Lee <tr...@gmail.com>.
Hi Frédéric,
I am sorry for the late answer first of all. :)
On Nov 27, 2007 3:15 AM, Frédéric Brégier <fr...@free.fr> wrote:
> Hi Trustin,
>
> Well, I am sometime (always ?) quite long in my email
> and obviously not necesseraly more clear than others.. ;-)
>
> The problem I found (is this a problem, I don't know) is :
> 1) In the past, only DemuxingIoHandler has messageSent() function
> to overload but not mandatory (you can if you want not define
> anything). In my code, I had some codes to do some stuff
> after the message is really sent.
> 2) Now, in trunk, MessageHandler has a mandatory messageSent()
> function.
> As when you use DemuxingIoHandler, you should use also object
> that extends MessageHandler, I feel like a bit loose.
>
> Contrary to what I wrote before, I would not suggest to remove
> the messageSent() from DemuxingIoHandler since a message can be
> sent, even if no MessageHandler is registered for it.
> I try in my code, and I saw "DemuxingIoHandler.messageSent()" called
> for such message not registered.
You can still do what you want with DemuxingIoHandler by overriding
messageSent():
public class MyDemuxingIoHandler extends DemuxingIoHandler {
@Override
public void messageSent(...) {
if (...) {
// Implement some common logic
} else {
super.messageSent(...);
}
}
}
It might be better to 1) split MessageHandler into 2 or 2) add a
catch-all handler (e.g.
DemuxingIoHandler.setCatchAllHandler(MessageHandler)) though. WDYT?
> Now the question :
> If one messageHandler is registered and such a message is sent, which function will be called ?
> DemuxingIoHandler.messageSent() on all messages ? or only on not registered messages ?
> MessageHandler.messageSent() on all messages that are registered ?
> Or only one (for registered message) ?
> As I need to do some stuff after message is sent, I don't know if I need to
> writye the same code (or so) in each messageSent() of MessageHandler.
DemuxingIoHandler.messageSent() is implemented to look for a proper
MessageHandler and call it. Therefore,
DemuxingIoHandler.messageSent() is always called. It will throw an
exception if there's no registered handler for a sent message. Of
course, you can override this behavior like I suggested above.
Thank you so much for your feed back,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
Re: messageSent on DemuxingIoHandler
Posted by Frédéric Brégier <fr...@free.fr>.
Hi Trustin,
Well, I am sometime (always ?) quite long in my email
and obviously not necesseraly more clear than others.. ;-)
The problem I found (is this a problem, I don't know) is :
1) In the past, only DemuxingIoHandler has messageSent() function
to overload but not mandatory (you can if you want not define
anything). In my code, I had some codes to do some stuff
after the message is really sent.
2) Now, in trunk, MessageHandler has a mandatory messageSent()
function.
As when you use DemuxingIoHandler, you should use also object
that extends MessageHandler, I feel like a bit loose.
Contrary to what I wrote before, I would not suggest to remove
the messageSent() from DemuxingIoHandler since a message can be
sent, even if no MessageHandler is registered for it.
I try in my code, and I saw "DemuxingIoHandler.messageSent()" called
for such message not registered.
Now the question :
If one messageHandler is registered and such a message is sent, which function will be called ?
DemuxingIoHandler.messageSent() on all messages ? or only on not registered messages ?
MessageHandler.messageSent() on all messages that are registered ?
Or only one (for registered message) ?
As I need to do some stuff after message is sent, I don't know if I need to
writye the same code (or so) in each messageSent() of MessageHandler.
I hope I am more clear, this time.
And for JMX, I was starting to think about it since I feel like I really should improve
this part in my app. So thank you for this ! I start probably this week some benchmark
(I hope almost all my port to "new" trunk is done). After that, I could spend some useful
time on JMX approach...
Frederic
----- Original Message -----
From: "Trustin Lee"
On Nov 22, 2007 5:40 PM, fred.bregier wrote:
> I suppose the one from MessageHandler is the one that would be executed, right ?
>
> Since we must defined messageSent function in MessageHandler
> (mandatory), second it is not mandatory to get it in DemuxingIoHandler,
> third as you said only one will be called (the one from
> MessageHandler ?), I would say that probably this function in
> DemuxingIoHandler is no more necessary and probably confusing with the
> one from MessageHandler.
> Except if one can use DemuxingIoHandler with something totally different
> from MessageHandler (?), I would suggest to remove this function (or mark
> it as deprecated and pointing to the one in MessageHandler). WDYT ?
I didn't get the question actually. Could explain again?
Thanks in advance,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
Re: messageSent on DemuxingIoHandler
Posted by Trustin Lee <tr...@gmail.com>.
On Nov 22, 2007 5:40 PM, <fr...@free.fr> wrote:
> I suppose the one from MessageHandler is the one that would be executed, right ?
>
> Since we must defined messageSent function in MessageHandler
> (mandatory), second it is not mandatory to get it in DemuxingIoHandler,
> third as you said only one will be called (the one from
> MessageHandler ?), I would say that probably this function in
> DemuxingIoHandler is no more necessary and probably confusing with the
> one from MessageHandler.
> Except if one can use DemuxingIoHandler with something totally different
> from MessageHandler (?), I would suggest to remove this function (or mark
> it as deprecated and pointing to the one in MessageHandler). WDYT ?
I didn't get the question actually. Could explain again?
Thanks in advance,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
Re: messageSent on DemuxingIoHandler
Posted by fr...@free.fr.
Hi Trustin,
I don't think splitting MessageHandler into the two interfaces makes more sense
since, at least for me, it is simpler to write both sides in one class
as some codes could be duplicated if I split them.
So my question is (I could read the code but I feel like asking could be
faster ;-)
I suppose the one from MessageHandler is the one that would be executed, right ?
Since we must defined messageSent function in MessageHandler
(mandatory), second it is not mandatory to get it in DemuxingIoHandler,
third as you said only one will be called (the one from
MessageHandler ?), I would say that probably this function in
DemuxingIoHandler is no more necessary and probably confusing with the
one from MessageHandler.
Except if one can use DemuxingIoHandler with something totally different
from MessageHandler (?), I would suggest to remove this function (or mark
it as deprecated and pointing to the one in MessageHandler). WDYT ?
Frederic
Selon Trustin Lee <tr...@gmail.com>:
> Hi Frédéric,
>
> On Nov 22, 2007 3:23 AM, Frédéric Brégier <fr...@free.fr> wrote:
> > Hy all, I am on the way to upgrade to last version of trunk...
> >
> > I have one question on DemuxingIoHandler in trunk version.
> > I used DemuxingIoHandler which enables messageSent function to
> > be overload ("Invoked when a message written by IoSession.write(Object) is
> sent out.")
> >
> > I extend MessageHandler for my own message but now it implies the
> messageSent function (mandatory) too.
> > ("Invoked when the specific type of message is received from the specified
> session."
> > Of course here the manual from API has en error since it is obviously "is
> sent out" and not "is received")
>
> Thanks for pointing out the JavaDoc error. I've just fixed it.
>
> > But why those two functions ? Is one call after the other or just one only
> (and if so, which one) ?
>
> It depends on situation but only one will be used and the other will
> be left as blank method for most cases. Thinking of why... well, I
> was somewhat crazy about creating more interfaces (i.e. replacing
> MessageHandler with ReceivedMessageHandler and SentMessageHandler).
> I'm not actually sure if it was a right decision. Please let me know
> if splitting MessageHandler into the two interfaces makes more sense.
>
> Thanks,
> Trustin
> --
> what we call human nature is actually human habit
> --
> http://gleamynode.net/
> --
> PGP Key ID: 0x0255ECA6
>
Re: messageSent on DemuxingIoHandler
Posted by Trustin Lee <tr...@gmail.com>.
Hi Frédéric,
On Nov 22, 2007 3:23 AM, Frédéric Brégier <fr...@free.fr> wrote:
> Hy all, I am on the way to upgrade to last version of trunk...
>
> I have one question on DemuxingIoHandler in trunk version.
> I used DemuxingIoHandler which enables messageSent function to
> be overload ("Invoked when a message written by IoSession.write(Object) is sent out.")
>
> I extend MessageHandler for my own message but now it implies the messageSent function (mandatory) too.
> ("Invoked when the specific type of message is received from the specified session."
> Of course here the manual from API has en error since it is obviously "is sent out" and not "is received")
Thanks for pointing out the JavaDoc error. I've just fixed it.
> But why those two functions ? Is one call after the other or just one only (and if so, which one) ?
It depends on situation but only one will be used and the other will
be left as blank method for most cases. Thinking of why... well, I
was somewhat crazy about creating more interfaces (i.e. replacing
MessageHandler with ReceivedMessageHandler and SentMessageHandler).
I'm not actually sure if it was a right decision. Please let me know
if splitting MessageHandler into the two interfaces makes more sense.
Thanks,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
messageSent on DemuxingIoHandler
Posted by Frédéric Brégier <fr...@free.fr>.
Hy all, I am on the way to upgrade to last version of trunk...
I have one question on DemuxingIoHandler in trunk version.
I used DemuxingIoHandler which enables messageSent function to
be overload ("Invoked when a message written by IoSession.write(Object) is sent out.")
I extend MessageHandler for my own message but now it implies the messageSent function (mandatory) too.
("Invoked when the specific type of message is received from the specified session."
Of course here the manual from API has en error since it is obviously "is sent out" and not "is received")
But why those two functions ? Is one call after the other or just one only (and if so, which one) ?
Continue your great job !
Frederic
Re: [jira] Created: (DIRMINA-477) Update page about differences between1.x and 2.x
Posted by Trustin Lee <tr...@gmail.com>.
On Nov 22, 2007 3:24 AM, Frédéric Brégier <fr...@free.fr> wrote:
> Hello all !
>
> Well, after some rewriting (but no test up to now), I get the following
> bootstraping code.
> I know that it could be dizzy to help on this kind of "very long" code,
> but what I am thinking is that such a code in a manual web page of Mina
> could help, of course, once we correct it (since I'm sure it is not perfect).
>
> So here it is, beginning by the server part:
> // Create service
> NioSocketAcceptor acceptor = new NioSocketAcceptor(myNumberOfCpuPlusOne);
> // It implies "myNumberOfCpuPlusOne" IoAcceptor using an internal newCachedThreadPool
>
> SocketSessionConfig socketSessionConfig = (SocketSessionConfig) acceptor.getSessionConfig();
> socketSessionConfig.setReuseAddress(true);
> //XXX VISTA BUG ? => I need to remove setSoLinger(x) and KeepAlive(true)
> socketSessionConfig.setSoLinger(1);
> socketSessionConfig.setKeepAlive(false); //Not sure
> socketSessionConfig.setTcpNoDelay(true);
> socketSessionConfig.setReceiveBufferSize(myTCPBLOCKSIZE);
> socketSessionConfig.setSendBufferSize(myTCPBLOCKSIZE);
> socketSessionConfig.setIdleTime(IdleStatus.BOTH_IDLE, myTIMEOUT);
>
> // Create IoHandler (I am using an extension of DemuxingIoHandler)
> MyDemuxingIoHandler myDemuxingIoHandler = new MyDemuxingIoHandler();
> // Create for each class one message handler
> // MyMessage
> MyMessageHandler myMessageHandler = new MyMessageHandler();
> myDemuxingIoHandler.addMessageHandler(MyMessage.class, myMessageHandler);
> ...
>
> // Configuration of the filter chain
> DefaultIoFilterChainBuilder chain = acceptor.getFilterChain();
> // Compression
> CompressionFilter compression =
> new CompressionFilter(COMPRESSIONCLIENT,
> COMPRESSIONSERVER,
> CompressionFilter.COMPRESSION_MAX);
> chain.addLast("Compression",compression);
> // Serialization : I add a pool of Executor since serizalisation is not free of CPU and after that my protocol
> // implies some extra codes (like JDBC calls)
> ProtocolCodecFactory codec = new ObjectSerializationCodecFactory();
> // Was Executors.newCachedThreadPool();
> ExecutorService executorSerialize = new OrderedThreadPoolExecutor(LSDConstants.SERVER_THREAD);
> chain.addLast("SerializePool", new ExecutorFilter(executorSerialize));
> chain.addLast("Serialize", new ProtocolCodecFilter(codec));
>
> // Set port
> InetSocketAddress inetSocketAddress = new InetSocketAddress(mySERVER_PORT);
>
>
> // All together
> acceptor.setLocalAddress(inetSocketAddress);
> acceptor.setHandler(myDemuxingIoHandler);
>
> // When Unbind, do not disconnect already connected client
> acceptor.setDisconnectOnUnbind(false);
> try {
> acceptor.bind();
> } catch (IOException e) {
> myLogger.error("Cannot Bind Service "+myname, e);
> return false;
> }
>
> When shutting down:
> // I use a complicated way (which I do not include here since too long)
> // to wait that all sessions are really closed before exiting the acceptor
> // (looping on ioAcceptor.getManagedSessions() to see if requests are pending)
> // But if you know a good way to do that (clean shutdown), I will take it !
> // Then realy closed if any session are still opened
> acceptor.setDisconnectOnUnbind(true);
> acceptor.unbind();
> if (executorSerialize != null) {
> executorSerialize.shutdownNow();
> executorSerialize = null;
> }
> // Did I forgot something ?
You forgot to call acceptor.dispose(). Except that, it looks perfect!
Cheers,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
Re: transferring files with Mina
Posted by Mark <el...@gmail.com>.
I have used StreamIoHandler for just what you are looking to do before. It
has served me well
On Nov 21, 2007 1:51 PM, Frédéric Brégier <fr...@free.fr> wrote:
> Hi all,
> I feel that the question I post inside my long previous mail should
> be on a separate one, so here it is again. Sorry for the double post !
>
> Just a question perhaps stupid :
> I have the idea to perhaps use StreamWriteFilter or StreamIoHandler to
> transfer some files
> but with a protocol exchange before and after the file transfer (to verify
> the access, the rules,
> to make some pre or post operations, probably making an MD5 check of the
> transfered file...).
> I have look at the mailing list but I didn't find a good example of what
> could be the best
> but also I didn't understand how to "get" the file on the other side.
> That is to say : I saw some code to send file (using StreamWF) but no on
> receiving this file?
> I'm surely missing something, obviously...
>
> Frederic
>
--
--------------------------------
The adjuration to be "normal" seems shockingly repellent to me; I see
neither hope nor comfort in sinking to that low level. I think it is
ignorance that makes people think of abnormality only with horror and allows
them to remain undismayed at the proximity of "normal" to average and
mediocre. For surely anyone who achieves anything is, essentially, abnormal.
Dr. Karl Menninger
Re: transferring files with Mina
Posted by fr...@free.fr.
Thank you to pointing this discussion, but as I said, no example
on client side ?
Now about the MD5, I agree with you on compute MD5 locally globally
on the file and comparing at the end.
However, if I send by packet as Trustin suggested, I come back to my previous
idea which was to compute MD5 on each packet, since it will bring some
extra functionnalities that could be interesting on large files.
For instance it allows to resend only the "corrupted" packet, restart a
transmission from a synchronisation point (like some FTP servers do), ...
As it takes some complexity to implement, I was looking at the new functionality
of Mina to see if I can use a simpler way...
I need to think about a clean way, perhaps something modular that can be reused
easily...
Frederic
Selon Eero Nevalainen <ee...@indagon.com>:
> This discussion brought to mind an earlier one about sending large files
>
http://www.nabble.com/Question-for-transfering-large-file-tf4222408s16868.html#a12011448
>
> What about the option of calculating the MD5 locally and then sending
> the file and the checksum after that?
>
> -Eero Nevalainen
>
> fred.bregier@free.fr wrote:
> > Hi Trustin,
> > (sorry for so much mails ;-)
> > Bloking IO could be problematic so I will probably work on the second
> > option (in fact my initial thoughts).
> > My initial work was based on serialization but I fell like it could
> > be no as efficient as needed, so I need to rethink about it and write
> > a protocol from scratch which will include a MD5 check on each packet
> > (security and check of file transport is the key of this project).
> > Thank a lot
> > Frederic
> >
> >
> > Selon Trustin Lee <tr...@gmail.com>:
> >
> >> On Nov 22, 2007 3:51 AM, Frédéric Brégier <fr...@free.fr> wrote:
> >>> Hi all,
> >>> I feel that the question I post inside my long previous mail should
> >>> be on a separate one, so here it is again. Sorry for the double post !
> >>>
> >>> Just a question perhaps stupid :
> >>> I have the idea to perhaps use StreamWriteFilter or StreamIoHandler to
> >> transfer some files
> >>> but with a protocol exchange before and after the file transfer (to
> verify
> >> the access, the rules,
> >>> to make some pre or post operations, probably making an MD5 check of the
> >> transfered file...).
> >>> I have look at the mailing list but I didn't find a good example of what
> >> could be the best
> >>> but also I didn't understand how to "get" the file on the other side.
> >>> That is to say : I saw some code to send file (using StreamWF) but no on
> >> receiving this file?
> >>> I'm surely missing something, obviously...
> >> For now.. you can:
> >>
> >> 1) Use StreamIoHandler, which is not recommended because it makes MINA
> >> work like a blocking I/O server. However, it's fine as long as you
> >> limit the usage of the StreamIoHandler.
> >> 2) Create a chunk message so your decoder generate multiple chunks
> >> with begin and end mark.
> >>
> >> Please let me know if you have any better idea to deal with big files. :)
> >>
> >> Trustin
> >> --
> >> what we call human nature is actually human habit
> >> --
> >> http://gleamynode.net/
> >> --
> >> PGP Key ID: 0x0255ECA6
> >>
> >
> >
>
>
Re: transferring files with Mina
Posted by Eero Nevalainen <ee...@indagon.com>.
This discussion brought to mind an earlier one about sending large files
http://www.nabble.com/Question-for-transfering-large-file-tf4222408s16868.html#a12011448
What about the option of calculating the MD5 locally and then sending
the file and the checksum after that?
-Eero Nevalainen
fred.bregier@free.fr wrote:
> Hi Trustin,
> (sorry for so much mails ;-)
> Bloking IO could be problematic so I will probably work on the second
> option (in fact my initial thoughts).
> My initial work was based on serialization but I fell like it could
> be no as efficient as needed, so I need to rethink about it and write
> a protocol from scratch which will include a MD5 check on each packet
> (security and check of file transport is the key of this project).
> Thank a lot
> Frederic
>
>
> Selon Trustin Lee <tr...@gmail.com>:
>
>> On Nov 22, 2007 3:51 AM, Frédéric Brégier <fr...@free.fr> wrote:
>>> Hi all,
>>> I feel that the question I post inside my long previous mail should
>>> be on a separate one, so here it is again. Sorry for the double post !
>>>
>>> Just a question perhaps stupid :
>>> I have the idea to perhaps use StreamWriteFilter or StreamIoHandler to
>> transfer some files
>>> but with a protocol exchange before and after the file transfer (to verify
>> the access, the rules,
>>> to make some pre or post operations, probably making an MD5 check of the
>> transfered file...).
>>> I have look at the mailing list but I didn't find a good example of what
>> could be the best
>>> but also I didn't understand how to "get" the file on the other side.
>>> That is to say : I saw some code to send file (using StreamWF) but no on
>> receiving this file?
>>> I'm surely missing something, obviously...
>> For now.. you can:
>>
>> 1) Use StreamIoHandler, which is not recommended because it makes MINA
>> work like a blocking I/O server. However, it's fine as long as you
>> limit the usage of the StreamIoHandler.
>> 2) Create a chunk message so your decoder generate multiple chunks
>> with begin and end mark.
>>
>> Please let me know if you have any better idea to deal with big files. :)
>>
>> Trustin
>> --
>> what we call human nature is actually human habit
>> --
>> http://gleamynode.net/
>> --
>> PGP Key ID: 0x0255ECA6
>>
>
>
Re: transferring files with Mina
Posted by fr...@free.fr.
Hi Trustin,
(sorry for so much mails ;-)
Bloking IO could be problematic so I will probably work on the second
option (in fact my initial thoughts).
My initial work was based on serialization but I fell like it could
be no as efficient as needed, so I need to rethink about it and write
a protocol from scratch which will include a MD5 check on each packet
(security and check of file transport is the key of this project).
Thank a lot
Frederic
Selon Trustin Lee <tr...@gmail.com>:
> On Nov 22, 2007 3:51 AM, Frédéric Brégier <fr...@free.fr> wrote:
> > Hi all,
> > I feel that the question I post inside my long previous mail should
> > be on a separate one, so here it is again. Sorry for the double post !
> >
> > Just a question perhaps stupid :
> > I have the idea to perhaps use StreamWriteFilter or StreamIoHandler to
> transfer some files
> > but with a protocol exchange before and after the file transfer (to verify
> the access, the rules,
> > to make some pre or post operations, probably making an MD5 check of the
> transfered file...).
> > I have look at the mailing list but I didn't find a good example of what
> could be the best
> > but also I didn't understand how to "get" the file on the other side.
> > That is to say : I saw some code to send file (using StreamWF) but no on
> receiving this file?
> > I'm surely missing something, obviously...
>
> For now.. you can:
>
> 1) Use StreamIoHandler, which is not recommended because it makes MINA
> work like a blocking I/O server. However, it's fine as long as you
> limit the usage of the StreamIoHandler.
> 2) Create a chunk message so your decoder generate multiple chunks
> with begin and end mark.
>
> Please let me know if you have any better idea to deal with big files. :)
>
> Trustin
> --
> what we call human nature is actually human habit
> --
> http://gleamynode.net/
> --
> PGP Key ID: 0x0255ECA6
>
Re: transferring files with Mina
Posted by Trustin Lee <tr...@gmail.com>.
On Nov 22, 2007 3:51 AM, Frédéric Brégier <fr...@free.fr> wrote:
> Hi all,
> I feel that the question I post inside my long previous mail should
> be on a separate one, so here it is again. Sorry for the double post !
>
> Just a question perhaps stupid :
> I have the idea to perhaps use StreamWriteFilter or StreamIoHandler to transfer some files
> but with a protocol exchange before and after the file transfer (to verify the access, the rules,
> to make some pre or post operations, probably making an MD5 check of the transfered file...).
> I have look at the mailing list but I didn't find a good example of what could be the best
> but also I didn't understand how to "get" the file on the other side.
> That is to say : I saw some code to send file (using StreamWF) but no on receiving this file?
> I'm surely missing something, obviously...
For now.. you can:
1) Use StreamIoHandler, which is not recommended because it makes MINA
work like a blocking I/O server. However, it's fine as long as you
limit the usage of the StreamIoHandler.
2) Create a chunk message so your decoder generate multiple chunks
with begin and end mark.
Please let me know if you have any better idea to deal with big files. :)
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
transferring files with Mina
Posted by Frédéric Brégier <fr...@free.fr>.
Hi all,
I feel that the question I post inside my long previous mail should
be on a separate one, so here it is again. Sorry for the double post !
Just a question perhaps stupid :
I have the idea to perhaps use StreamWriteFilter or StreamIoHandler to transfer some files
but with a protocol exchange before and after the file transfer (to verify the access, the rules,
to make some pre or post operations, probably making an MD5 check of the transfered file...).
I have look at the mailing list but I didn't find a good example of what could be the best
but also I didn't understand how to "get" the file on the other side.
That is to say : I saw some code to send file (using StreamWF) but no on receiving this file?
I'm surely missing something, obviously...
Frederic
Re: [jira] Created: (DIRMINA-477) Update page about differences between1.x and 2.x
Posted by Frédéric Brégier <fr...@free.fr>.
Hello all !
Well, after some rewriting (but no test up to now), I get the following
bootstraping code.
I know that it could be dizzy to help on this kind of "very long" code,
but what I am thinking is that such a code in a manual web page of Mina
could help, of course, once we correct it (since I'm sure it is not perfect).
So here it is, beginning by the server part:
// Create service
NioSocketAcceptor acceptor = new NioSocketAcceptor(myNumberOfCpuPlusOne);
// It implies "myNumberOfCpuPlusOne" IoAcceptor using an internal newCachedThreadPool
SocketSessionConfig socketSessionConfig = (SocketSessionConfig) acceptor.getSessionConfig();
socketSessionConfig.setReuseAddress(true);
//XXX VISTA BUG ? => I need to remove setSoLinger(x) and KeepAlive(true)
socketSessionConfig.setSoLinger(1);
socketSessionConfig.setKeepAlive(false); //Not sure
socketSessionConfig.setTcpNoDelay(true);
socketSessionConfig.setReceiveBufferSize(myTCPBLOCKSIZE);
socketSessionConfig.setSendBufferSize(myTCPBLOCKSIZE);
socketSessionConfig.setIdleTime(IdleStatus.BOTH_IDLE, myTIMEOUT);
// Create IoHandler (I am using an extension of DemuxingIoHandler)
MyDemuxingIoHandler myDemuxingIoHandler = new MyDemuxingIoHandler();
// Create for each class one message handler
// MyMessage
MyMessageHandler myMessageHandler = new MyMessageHandler();
myDemuxingIoHandler.addMessageHandler(MyMessage.class, myMessageHandler);
...
// Configuration of the filter chain
DefaultIoFilterChainBuilder chain = acceptor.getFilterChain();
// Compression
CompressionFilter compression =
new CompressionFilter(COMPRESSIONCLIENT,
COMPRESSIONSERVER,
CompressionFilter.COMPRESSION_MAX);
chain.addLast("Compression",compression);
// Serialization : I add a pool of Executor since serizalisation is not free of CPU and after that my protocol
// implies some extra codes (like JDBC calls)
ProtocolCodecFactory codec = new ObjectSerializationCodecFactory();
// Was Executors.newCachedThreadPool();
ExecutorService executorSerialize = new OrderedThreadPoolExecutor(LSDConstants.SERVER_THREAD);
chain.addLast("SerializePool", new ExecutorFilter(executorSerialize));
chain.addLast("Serialize", new ProtocolCodecFilter(codec));
// Set port
InetSocketAddress inetSocketAddress = new InetSocketAddress(mySERVER_PORT);
// All together
acceptor.setLocalAddress(inetSocketAddress);
acceptor.setHandler(myDemuxingIoHandler);
// When Unbind, do not disconnect already connected client
acceptor.setDisconnectOnUnbind(false);
try {
acceptor.bind();
} catch (IOException e) {
myLogger.error("Cannot Bind Service "+myname, e);
return false;
}
When shutting down:
// I use a complicated way (which I do not include here since too long)
// to wait that all sessions are really closed before exiting the acceptor
// (looping on ioAcceptor.getManagedSessions() to see if requests are pending)
// But if you know a good way to do that (clean shutdown), I will take it !
// Then realy closed if any session are still opened
acceptor.setDisconnectOnUnbind(true);
acceptor.unbind();
if (executorSerialize != null) {
executorSerialize.shutdownNow();
executorSerialize = null;
}
// Did I forgot something ?
I will post a second message for the client part... ;-)
Of course, any comment or correction are most welcomed !
Frederic
----- Original Message -----
From: "Frédéric Brégier"
Sent: Tuesday, November 20, 2007 7:55 PM
Subject: Re: [jira] Created: (DIRMINA-477) Update page about differences between1.x and 2.x
Hi Trustin and all of you !
I come back to MINA since I feel that MINA 2 is on the way to get out.
And I start to look what could be my effort to switch from beta 2 (trunk)
from 6 months ago to the current status of trunk.
I found some points that might be good to add on the page you started to
write.
As a beginning :
- change from get/set Attachment to get/setAttribute (OK there are still
there but deprecated)
It is not a big deal, of course, if you except the flag in Eclipse ;-)
- a full example on thread, in fact an example with both levels
(SocketAcceptor and ExecutorFilter)
since they are now really different with the introduction of
Unordered/OrderedThreadPoolExecutor.
Specially since from before in SocketAcceptor (now NioSocketAcceptor
right ?), the interface is different
with an Executor at first and IoProcessor at second, which I don't know
at all what to do with it.
I think, like others, I use Mina on multiprocessor server, so I can
afford multiple thread on
NioSocketAcceptor and other threads (if needed but I need it since I do
Oracle) in filter.
Just a question I've just thinking about : Am I correct if I say
Executors.newCachedThreadPool()
will no more allows order as it is point in this page of transition in
filter ?
Of course, page in "configuring thread model" is no more correct for V2
(as far as I understand).
- an example of how to configure Read and Write ThrottleFilter and what
could be a good default (if one
can say of course)
I will come back if I see anything else...
Just a question perhaps stupid :
I have the idea to perhaps use StreamWriteFilter or StreamIoHandler to
transfer some files
but with a protocol exchange before and after the file transfer (to verify
the access, the rules,
to make some pre or post operations, probably making an MD5 check of the
transfered file...).
I have look at the mailing list but I didn't find a good example of what
could be the best
but also I didn't understand how to "get" the file on the other side.
That is to say : I saw some code to send file (using StreamWF) but no on
receiving this file?
I'm surely missing something, obviously...
As always, Mina is going better and better... Just I feel like almost a new
user to Mina
after 6 months without coding Mina stuff, even If I read all the mailing
list (great one !).
Frederic
----- Original Message -----
From: "Trustin Lee (JIRA)"
Sent: Wednesday, November 14, 2007 8:08 AM
Subject: [jira] Created: (DIRMINA-477) Update page about differences
between1.x and 2.x
Update page about differences between 1.x and 2.x
-------------------------------------------------
Key: DIRMINA-477
URL: https://issues.apache.org/jira/browse/DIRMINA-477
Project: MINA
Issue Type: Task
Components: Web Site / Documentation
Reporter: Trustin Lee
Fix For: 2.0.0-M1
Our current web site doesn't describe what have been changed in 2.x
comparing to 1.x. We need to carefully put all changes together there so
people can migrate more easily.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Created: (DIRMINA-477) Update page about differences between1.x and 2.x
Posted by Frédéric Brégier <fr...@free.fr>.
Hi Trustin and all of you !
I come back to MINA since I feel that MINA 2 is on the way to get out.
And I start to look what could be my effort to switch from beta 2 (trunk)
from 6 months ago to the current status of trunk.
I found some points that might be good to add on the page you started to
write.
As a beginning :
- change from get/set Attachment to get/setAttribute (OK there are still
there but deprecated)
It is not a big deal, of course, if you except the flag in Eclipse ;-)
- a full example on thread, in fact an example with both levels
(SocketAcceptor and ExecutorFilter)
since they are now really different with the introduction of
Unordered/OrderedThreadPoolExecutor.
Specially since from before in SocketAcceptor (now NioSocketAcceptor
right ?), the interface is different
with an Executor at first and IoProcessor at second, which I don't know
at all what to do with it.
I think, like others, I use Mina on multiprocessor server, so I can
afford multiple thread on
NioSocketAcceptor and other threads (if needed but I need it since I do
Oracle) in filter.
Just a question I've just thinking about : Am I correct if I say
Executors.newCachedThreadPool()
will no more allows order as it is point in this page of transition in
filter ?
Of course, page in "configuring thread model" is no more correct for V2
(as far as I understand).
- an example of how to configure Read and Write ThrottleFilter and what
could be a good default (if one
can say of course)
I will come back if I see anything else...
Just a question perhaps stupid :
I have the idea to perhaps use StreamWriteFilter or StreamIoHandler to
transfer some files
but with a protocol exchange before and after the file transfer (to verify
the access, the rules,
to make some pre or post operations, probably making an MD5 check of the
transfered file...).
I have look at the mailing list but I didn't find a good example of what
could be the best
but also I didn't understand how to "get" the file on the other side.
That is to say : I saw some code to send file (using StreamWF) but no on
receiving this file?
I'm surely missing something, obviously...
As always, Mina is going better and better... Just I feel like almost a new
user to Mina
after 6 months without coding Mina stuff, even If I read all the mailing
list (great one !).
Frederic
----- Original Message -----
From: "Trustin Lee (JIRA)"
Sent: Wednesday, November 14, 2007 8:08 AM
Subject: [jira] Created: (DIRMINA-477) Update page about differences
between1.x and 2.x
Update page about differences between 1.x and 2.x
-------------------------------------------------
Key: DIRMINA-477
URL: https://issues.apache.org/jira/browse/DIRMINA-477
Project: MINA
Issue Type: Task
Components: Web Site / Documentation
Reporter: Trustin Lee
Fix For: 2.0.0-M1
Our current web site doesn't describe what have been changed in 2.x
comparing to 1.x. We need to carefully put all changes together there so
people can migrate more easily.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DIRMINA-477) Update page about differences between
1.x and 2.x
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRMINA-477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Emmanuel Lecharny updated DIRMINA-477:
--------------------------------------
Fix Version/s: (was: 2.0.0-RC2)
2.0.0
> Update page about differences between 1.x and 2.x
> -------------------------------------------------
>
> Key: DIRMINA-477
> URL: https://issues.apache.org/jira/browse/DIRMINA-477
> Project: MINA
> Issue Type: Task
> Components: Web Site / Documentation
> Reporter: Trustin Lee
> Assignee: Ashish Paliwal
> Fix For: 2.0.0
>
>
> Our current web site doesn't describe what have been changed in 2.x comparing to 1.x. We need to carefully put all changes together there so people can migrate more easily.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DIRMINA-477) Update page about differences between
1.x and 2.x
Posted by "Julien Vermillard (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRMINA-477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Julien Vermillard updated DIRMINA-477:
--------------------------------------
Fix Version/s: (was: 2.0.0-M2)
2.0.0-M3
> Update page about differences between 1.x and 2.x
> -------------------------------------------------
>
> Key: DIRMINA-477
> URL: https://issues.apache.org/jira/browse/DIRMINA-477
> Project: MINA
> Issue Type: Task
> Components: Web Site / Documentation
> Reporter: Trustin Lee
> Assignee: Trustin Lee
> Fix For: 2.0.0-M3
>
>
> Our current web site doesn't describe what have been changed in 2.x comparing to 1.x. We need to carefully put all changes together there so people can migrate more easily.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DIRMINA-477) Update page about differences between
1.x and 2.x
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRMINA-477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Emmanuel Lecharny updated DIRMINA-477:
--------------------------------------
Fix Version/s: (was: 2.0.1)
2.0.2
> Update page about differences between 1.x and 2.x
> -------------------------------------------------
>
> Key: DIRMINA-477
> URL: https://issues.apache.org/jira/browse/DIRMINA-477
> Project: MINA
> Issue Type: Task
> Components: Web Site / Documentation
> Reporter: Trustin Lee
> Assignee: Ashish Paliwal
> Fix For: 2.0.2
>
>
> Our current web site doesn't describe what have been changed in 2.x comparing to 1.x. We need to carefully put all changes together there so people can migrate more easily.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DIRMINA-477) Update page about differences
between 1.x and 2.x
Posted by "Trustin Lee (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRMINA-477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Trustin Lee reassigned DIRMINA-477:
-----------------------------------
Assignee: Trustin Lee
> Update page about differences between 1.x and 2.x
> -------------------------------------------------
>
> Key: DIRMINA-477
> URL: https://issues.apache.org/jira/browse/DIRMINA-477
> Project: MINA
> Issue Type: Task
> Components: Web Site / Documentation
> Reporter: Trustin Lee
> Assignee: Trustin Lee
> Fix For: 2.0.0-M1
>
>
> Our current web site doesn't describe what have been changed in 2.x comparing to 1.x. We need to carefully put all changes together there so people can migrate more easily.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DIRMINA-477) Update page about differences between
1.x and 2.x
Posted by "Julien Vermillard (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRMINA-477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Julien Vermillard updated DIRMINA-477:
--------------------------------------
Fix Version/s: (was: 2.0.0-M3)
2.0.0-M4
> Update page about differences between 1.x and 2.x
> -------------------------------------------------
>
> Key: DIRMINA-477
> URL: https://issues.apache.org/jira/browse/DIRMINA-477
> Project: MINA
> Issue Type: Task
> Components: Web Site / Documentation
> Reporter: Trustin Lee
> Assignee: Trustin Lee
> Fix For: 2.0.0-M4
>
>
> Our current web site doesn't describe what have been changed in 2.x comparing to 1.x. We need to carefully put all changes together there so people can migrate more easily.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRMINA-477) Update page about differences
between 1.x and 2.x
Posted by "Ashish Paliwal (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRMINA-477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12741310#action_12741310 ]
Ashish Paliwal commented on DIRMINA-477:
----------------------------------------
Have added some basic details on JMX and Spring integration. Since the modules have been re-written, adding precise differences shall not help.
Do we know of any other stuff that needs to be documented or we close this issue?
> Update page about differences between 1.x and 2.x
> -------------------------------------------------
>
> Key: DIRMINA-477
> URL: https://issues.apache.org/jira/browse/DIRMINA-477
> Project: MINA
> Issue Type: Task
> Components: Web Site / Documentation
> Reporter: Trustin Lee
> Assignee: Trustin Lee
> Fix For: 2.0.0-RC1
>
>
> Our current web site doesn't describe what have been changed in 2.x comparing to 1.x. We need to carefully put all changes together there so people can migrate more easily.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DIRMINA-477) Update page about differences
between 1.x and 2.x
Posted by "Ashish Paliwal (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRMINA-477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ashish Paliwal reassigned DIRMINA-477:
--------------------------------------
Assignee: Ashish Paliwal (was: Trustin Lee)
> Update page about differences between 1.x and 2.x
> -------------------------------------------------
>
> Key: DIRMINA-477
> URL: https://issues.apache.org/jira/browse/DIRMINA-477
> Project: MINA
> Issue Type: Task
> Components: Web Site / Documentation
> Reporter: Trustin Lee
> Assignee: Ashish Paliwal
> Fix For: 2.0.0-RC1
>
>
> Our current web site doesn't describe what have been changed in 2.x comparing to 1.x. We need to carefully put all changes together there so people can migrate more easily.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRMINA-477) Update page about differences
between 1.x and 2.x
Posted by "Niklas Therning (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRMINA-477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12557928#action_12557928 ]
Niklas Therning commented on DIRMINA-477:
-----------------------------------------
We also need to document changes in Spring integration. E.g. the KeystoreFactoryBean and SSLContextFactoryBean have been removed. Instead you use something like:
<bean id="keyStoreFactory" class="o.a.m.filter.ssl.KeyStoreFactory">
<property name="..." value="..."/>
...
</bean>
<bean id="keyStore" factory-bean="keyStoreFactory" factory-method="newInstance"/>
SslContextFactory is used similarly.
And also, DefaultIoFilterChainBuilderFactoryBean is now gone. DefaultIoFilterChainBuilder now has a setFilters() method which can be used directly from Spring.
> Update page about differences between 1.x and 2.x
> -------------------------------------------------
>
> Key: DIRMINA-477
> URL: https://issues.apache.org/jira/browse/DIRMINA-477
> Project: MINA
> Issue Type: Task
> Components: Web Site / Documentation
> Reporter: Trustin Lee
> Assignee: Trustin Lee
> Fix For: 2.0.0-M1
>
>
> Our current web site doesn't describe what have been changed in 2.x comparing to 1.x. We need to carefully put all changes together there so people can migrate more easily.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DIRMINA-477) Update page about differences between
1.x and 2.x
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRMINA-477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Emmanuel Lecharny updated DIRMINA-477:
--------------------------------------
Fix Version/s: 2.0.1
(was: 2.0.0)
Postponed to 2.0.1
> Update page about differences between 1.x and 2.x
> -------------------------------------------------
>
> Key: DIRMINA-477
> URL: https://issues.apache.org/jira/browse/DIRMINA-477
> Project: MINA
> Issue Type: Task
> Components: Web Site / Documentation
> Reporter: Trustin Lee
> Assignee: Ashish Paliwal
> Fix For: 2.0.1
>
>
> Our current web site doesn't describe what have been changed in 2.x comparing to 1.x. We need to carefully put all changes together there so people can migrate more easily.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DIRMINA-477) Update page about differences between
1.x and 2.x
Posted by "Julien Vermillard (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRMINA-477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Julien Vermillard updated DIRMINA-477:
--------------------------------------
Fix Version/s: (was: 2.0.0-RC1)
2.0.0-RC2
> Update page about differences between 1.x and 2.x
> -------------------------------------------------
>
> Key: DIRMINA-477
> URL: https://issues.apache.org/jira/browse/DIRMINA-477
> Project: MINA
> Issue Type: Task
> Components: Web Site / Documentation
> Reporter: Trustin Lee
> Assignee: Ashish Paliwal
> Fix For: 2.0.0-RC2
>
>
> Our current web site doesn't describe what have been changed in 2.x comparing to 1.x. We need to carefully put all changes together there so people can migrate more easily.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-477) Update page about differences between
1.x and 2.x
Posted by "Trustin Lee (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRMINA-477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Trustin Lee closed DIRMINA-477.
-------------------------------
Resolution: Fixed
Looks like we are pretty much done with this. Please post a message to the mailing list whenever you find any subtle incompatibilities, then we will revise the document.
> Update page about differences between 1.x and 2.x
> -------------------------------------------------
>
> Key: DIRMINA-477
> URL: https://issues.apache.org/jira/browse/DIRMINA-477
> Project: MINA
> Issue Type: Task
> Components: Web Site / Documentation
> Reporter: Trustin Lee
> Assignee: Trustin Lee
> Fix For: 2.0.0-M1
>
>
> Our current web site doesn't describe what have been changed in 2.x comparing to 1.x. We need to carefully put all changes together there so people can migrate more easily.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DIRMINA-477) Update page about differences between
1.x and 2.x
Posted by "Julien Vermillard (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRMINA-477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Julien Vermillard updated DIRMINA-477:
--------------------------------------
Fix Version/s: (was: 2.0.0-M5)
2.0.0-RC1
> Update page about differences between 1.x and 2.x
> -------------------------------------------------
>
> Key: DIRMINA-477
> URL: https://issues.apache.org/jira/browse/DIRMINA-477
> Project: MINA
> Issue Type: Task
> Components: Web Site / Documentation
> Reporter: Trustin Lee
> Assignee: Trustin Lee
> Fix For: 2.0.0-RC1
>
>
> Our current web site doesn't describe what have been changed in 2.x comparing to 1.x. We need to carefully put all changes together there so people can migrate more easily.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DIRMINA-477) Update page about differences between
1.x and 2.x
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRMINA-477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Emmanuel Lecharny updated DIRMINA-477:
--------------------------------------
Fix Version/s: (was: 2.0.0-M4)
2.0.0-RC1
Documentation will be fixed for 2.0-RC1
> Update page about differences between 1.x and 2.x
> -------------------------------------------------
>
> Key: DIRMINA-477
> URL: https://issues.apache.org/jira/browse/DIRMINA-477
> Project: MINA
> Issue Type: Task
> Components: Web Site / Documentation
> Reporter: Trustin Lee
> Assignee: Trustin Lee
> Fix For: 2.0.0-RC1
>
>
> Our current web site doesn't describe what have been changed in 2.x comparing to 1.x. We need to carefully put all changes together there so people can migrate more easily.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DIRMINA-477) Update page about differences between
1.x and 2.x
Posted by "Mike Heath (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRMINA-477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mike Heath updated DIRMINA-477:
-------------------------------
Fix Version/s: (was: 2.0.0-M1)
2.0.0-M2
> Update page about differences between 1.x and 2.x
> -------------------------------------------------
>
> Key: DIRMINA-477
> URL: https://issues.apache.org/jira/browse/DIRMINA-477
> Project: MINA
> Issue Type: Task
> Components: Web Site / Documentation
> Reporter: Trustin Lee
> Assignee: Trustin Lee
> Fix For: 2.0.0-M2
>
>
> Our current web site doesn't describe what have been changed in 2.x comparing to 1.x. We need to carefully put all changes together there so people can migrate more easily.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Reopened: (DIRMINA-477) Update page about differences
between 1.x and 2.x
Posted by "Trustin Lee (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRMINA-477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Trustin Lee reopened DIRMINA-477:
---------------------------------
I'd better add a list of new features, too, because it will be a good advertisement. :D
> Update page about differences between 1.x and 2.x
> -------------------------------------------------
>
> Key: DIRMINA-477
> URL: https://issues.apache.org/jira/browse/DIRMINA-477
> Project: MINA
> Issue Type: Task
> Components: Web Site / Documentation
> Reporter: Trustin Lee
> Assignee: Trustin Lee
> Fix For: 2.0.0-M1
>
>
> Our current web site doesn't describe what have been changed in 2.x comparing to 1.x. We need to carefully put all changes together there so people can migrate more easily.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.