Custom messageSent

[Pavel Zdenek <pa...@gmail.com>]

Greetings fellow min(a)ers!

I understand the controversy over messageSent,  because the "feature"
of firing twice per each actual object being encoded is annoying me as
well. Anyway, i do need such sort of event information in my current
pet project, something has to happen in the persistent layer after the
message delivery is confirmed. Unfortunately, the most recommended
hack solution with waiting on WriteFuture is neither applicable,
because i do physically send out a multiple IoBuffers for each
abstract message written. I need to get the messageSent on the last
one, not the first one (as it happens now). I am thinking about
setting up a wait condition after session.write and signalling it from
the correct messageSent. But i am too unfamiliar with the threading
model of Mina, to say whether it's a good idea. Somebody with better
understanding say?

Thanks, Pavel Z.


2009/11/17, Mathieu Sacrispeyre <ma...@novamems.com>:
>
>
> Ok I guess I do not need to give you a sample anymore.
> Please tell us when the correction is available in the trunk.
>
> Emmanuel Lecharny wrote:
>> Pavel Zdenek wrote:
>>> 2009/11/17, Emmanuel Lecharny <el...@apache.org>:
>>>
>>>> <snip/>
>>>>> - if the use of mina described here is correct
>>>>>
>>>>>
>>>> Enqueueing two codecs is a bit courageous...
>>>>
>>>>
>>>
>>> Nice, i was just going to write my own post on the matter of
>>> enqueueing two codecs, which as well stopped working for me with RC1.
>>> I did have found a reason why it stopped working, and it matches with
>>> the "courage" label. On revision 790000 of 30 June,
>>> ProtocolCodecFilter has been actually modified to PROHIBIT multiple
>>> instances in the chain. The private AttributeKeys had been changed to
>>> static. Which means that there exists only one encoder and decoder
>>> instance per whole chain, and that is the one for which the initCodec
>>> has been called as the last one. Unfortunately the rewrite of existing
>>> instances is completely silent.
>>>
>> Damnit ! That's my fault. I didn't realized back then that moving
>> those elements to static as such a side effect. I must have been
>> totally drunk...
>>> I have even contacted the commiter directly some weeks ago, but he
>>> didn't respond. There surely must be a deeper reason, an architectural
>>> decision, which have induced this change?
>>>
>> Well, AFAIR, it was probably an idiotic attempt to optimize the code.
>>
>> Btw, as I said in my response to Pavel, don't mail privately to
>> committers, it kills the communication. As everyone can see, one's
>> problem can ring a bell for another one user, and at the end, a
>> solutiuon to a problem can be found.
>>> About my reasons for being courageous: i do a server which accepts
>>> traffic from microcontroller based GPRS stations with very limited
>>> memory resources. Because of that, messages are packetized to about
>>> 0.5kB which is the limit of what the client can prepare at once. Each
>>> packet has own header with length and sequence number. For that i
>>> obviously need a CumulativeProtocolDecoder. After receiving all
>>> packets, server does join them, checks CRC and THEN i need the actual
>>> DemuxingProtocolCodecFactory to handle the big thing. There is about
>>> 20 different message types, so i really would like to use what is
>>> already done, instead of reinventing my own demuxing wheel somehow
>>> inside the SessionHandler.
>>>
>> When I wrote 'courageous', I meant that the initial code wasn't
>> totally intended to allow codecs to be chained. At least in 2.0. The
>> ProtocolCodecFilter messageReceived() code starts with :
>>
>>    public void messageReceived(NextFilter nextFilter, IoSession session,
>>            Object message) throws Exception {
>>        LOGGER.debug( "Processing a MESSAGE_RECEIVED for session {}",
>> session.getId() );
>>              if (!(message instanceof IoBuffer)) {
>>            nextFilter.messageReceived(session, message);
>>            return;
>>        }
>>        ...
>>
>> It's obvious that if the next filter is a codec, then you must pass a
>> IoBuffer. This is absolutely not what we want to pass, as the first
>> codec is usually transforming a IoBuffer to some other data structure,
>> and the second codec is supposed to deal with this very data structure.
>>
>> This is the reason I said 'courageous' : you have to know about this
>> atrocious hack in order to get the second codec to work, that means
>> you also have to store the intermediate result in the session. No fun ...
>>
>> Unless I'm totally wrong, of course !
>>> What is the architecturally correct and acceptably less courageous
>>> advice on implementing such protocol?
>>>
>> From a pragmatic POV, when using MINA 2.0, try to get all the codec in
>> one simple filter. That could lead to some complex stateful decoder,
>> but at least, you have the hand on the code.
>>
>> Hope that MINA 3.0 will be better !
>>
>>
>

Re: Custom messageSent

[Emmanuel Lecharny <el...@apache.org>]

Pavel Zdenek wrote:
> 2009/11/23, Emmanuel Lecharny <el...@apache.org>:
>   
>> Pavel Zdenek wrote:
>>     
>>> Greetings fellow min(a)ers!
>>>
>>> I understand the controversy over messageSent,  because the "feature"
>>> of firing twice per each actual object being encoded is annoying me as
>>> well. Anyway, i do need such sort of event information in my current
>>> pet project, something has to happen in the persistent layer after the
>>> message delivery is confirmed. Unfortunately, the most recommended
>>> hack solution with waiting on WriteFuture is neither applicable,
>>> because i do physically send out a multiple IoBuffers for each
>>> abstract message written. I need to get the messageSent on the last
>>> one, not the first one (as it happens now). I am thinking about
>>> setting up a wait condition after session.write and signalling it from
>>> the correct messageSent. But i am too unfamiliar with the threading
>>> model of Mina, to say whether it's a good idea. Somebody with better
>>> understanding say?
>>>
>>>       
>> The way it works is that each 'message' is enqueued until it's sent.
>> Then a MessageSent event is generated. Sadly, we don't associate a umber
>> with each message, so it's difficult to correlate a MessageSent event
>> with a given message, except that AFAIR, the IoBuffer is present in the
>> messageSent event.
>>
>> If so, you may be able to compare the message content with what you know
>> to be the last message sent (you can store it in the session for
>> instance). This is from the top of my head...
>>     
>
> Fortunately my protocol is strictly synchronous request/response, so
> the message matching will be much easier. Safety question: may it
> happen, that the session handling (which writes a response object into
> the session) will be the same thread as the one which initiates
> messageSent? From my observation, this is not the case, but i prefer
> asking first and shoot a code later...
>   
It depends if you have an executor in your chain. If you don't, then 
every message processing for a session will be processed by a single 
thread : the one associated with the IoProcessor (as the IoProcessor 
holds the selctor, it makes sense).

Now, if you have an executor, you may have a message processed by 
different threads, as the exector acts as a demultiplexer : it picks a 
thread in the pool and ask it to process the message. If your executor 
is used in both side (you can perfectly ask the executor not to be used 
when writing messages), then another thread will e used to write the 
message (not sure what will be the impact though ...)
> Is there any document describing the threading model of MINA? I
> remember seeing some comprehensive picture about Netty, long time
> ago...
>   
Time's flying ... There are a few slides available, not sure if they are 
accurate.

At some point, we should write some samples to demonstrate the different 
use cases.
> Thanks a lot,
>
> Pavel Z.
>
>   


-- 
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org

Re: Custom messageSent

[Pavel Zdenek <pa...@gmail.com>]

2009/11/23, Emmanuel Lecharny <el...@apache.org>:
> Pavel Zdenek wrote:
>> Greetings fellow min(a)ers!
>>
>> I understand the controversy over messageSent,  because the "feature"
>> of firing twice per each actual object being encoded is annoying me as
>> well. Anyway, i do need such sort of event information in my current
>> pet project, something has to happen in the persistent layer after the
>> message delivery is confirmed. Unfortunately, the most recommended
>> hack solution with waiting on WriteFuture is neither applicable,
>> because i do physically send out a multiple IoBuffers for each
>> abstract message written. I need to get the messageSent on the last
>> one, not the first one (as it happens now). I am thinking about
>> setting up a wait condition after session.write and signalling it from
>> the correct messageSent. But i am too unfamiliar with the threading
>> model of Mina, to say whether it's a good idea. Somebody with better
>> understanding say?
>>
> The way it works is that each 'message' is enqueued until it's sent.
> Then a MessageSent event is generated. Sadly, we don't associate a umber
> with each message, so it's difficult to correlate a MessageSent event
> with a given message, except that AFAIR, the IoBuffer is present in the
> messageSent event.
>
> If so, you may be able to compare the message content with what you know
> to be the last message sent (you can store it in the session for
> instance). This is from the top of my head...

Fortunately my protocol is strictly synchronous request/response, so
the message matching will be much easier. Safety question: may it
happen, that the session handling (which writes a response object into
the session) will be the same thread as the one which initiates
messageSent? From my observation, this is not the case, but i prefer
asking first and shoot a code later...

Is there any document describing the threading model of MINA? I
remember seeing some comprehensive picture about Netty, long time
ago...

Thanks a lot,

Pavel Z.

Re: Custom messageSent

[Emmanuel Lecharny <el...@apache.org>]

Pavel Zdenek wrote:
> Greetings fellow min(a)ers!
>
> I understand the controversy over messageSent,  because the "feature"
> of firing twice per each actual object being encoded is annoying me as
> well. Anyway, i do need such sort of event information in my current
> pet project, something has to happen in the persistent layer after the
> message delivery is confirmed. Unfortunately, the most recommended
> hack solution with waiting on WriteFuture is neither applicable,
> because i do physically send out a multiple IoBuffers for each
> abstract message written. I need to get the messageSent on the last
> one, not the first one (as it happens now). I am thinking about
> setting up a wait condition after session.write and signalling it from
> the correct messageSent. But i am too unfamiliar with the threading
> model of Mina, to say whether it's a good idea. Somebody with better
> understanding say?
>   
The way it works is that each 'message' is enqueued until it's sent. 
Then a MessageSent event is generated. Sadly, we don't associate a umber 
with each message, so it's difficult to correlate a MessageSent event 
with a given message, except that AFAIR, the IoBuffer is present in the 
messageSent event.

If so, you may be able to compare the message content with what you know 
to be the last message sent (you can store it in the session for 
instance). This is from the top of my head...

In 3.0, it would be really a good idea to add an incremental per session 
message number to deal with such cases...

-- 
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org