On Fri, Jan 28, 2011 at 5:17 PM, Emmanuel Lecharny <[email protected]>wrote:

> On 1/28/11 5:02 PM, Francesco Vivoli wrote:
>
>> No, it's likely that the remote peer hasn't read the data you sent
>>> previously, and the send socket is full, so the write is delayed. To be
>>> confirmed...
>>>
>>> The MessageSent event is only emmitted when the IoProcessor was able to
>>> write the data fully into the socket, and the socket informs the
>>> IoProcessor
>>> when it's ready for a new write.
>>>
>>
>>
>> mmh, I'm not sure I get what you mean here...could you elaborate a bit?
>>
>
> When you write a message to the client (the peer), the system is just
> trying to push it to the socket. if the socket is full, then it will wait
> until it's ready for a new write. A socket can be full if the remote peer
> hasn't read it.
>
> In any case, you write a message, which is translated to bytes, and until
> all the bytes are written into the socket, then the MessageSent event is not
> created.
>
>
ok, got it:) It might be an issue with the terminal server that sits between
the mina service and the remote peer...The devices are actually sending over
a serial line.


>
>>   Last, about upgrading to 2.0.2. I'm trying right now and unfortunately
>>> it
>>>
>>>> seems that this decoder no longer works:( For some reason it doesn't
>>>> hold
>>>> state as it used to do in 2.0.0-M6...
>>>>
>>>>  It should...
>>>
>>>
>>>
>>>  I think I found the sneaky bit.
>>
>>
>> the implementation of this decoder uses class attributes rather the
>> IoSession to hold state, which seems to be the correct approach. Now, how
>> using attributes has been working smoothly for one year it's not clear to
>> me.
>>
> May be we fixed a bug that made you think it was working before :)
>
>
storing the state in the session fixes the problem. It is very possible that
whoever coded this an year ago factored in a mina bug in his work:)

Thanks a lot!
Francesco



>
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
>

Reply via email to