On Fri, Jan 28, 2011 at 4:19 PM, Emmanuel Lecharny <[email protected]>wrote:
> On 1/28/11 3:45 PM, Francesco Vivoli wrote:
>
>> Hi
>>
>> thanks a lot for clarifying this. Now I know that acceptors can be shared
>> indeed:)
>>
>> The thing is, I still doubt I could set things up as you say, given that
>> we
>> actually have a sort of protocol registry that handles different protocols
>> for different remote devices at runtime and I need to be able to
>> shutdown/reconfigure/restart a service at runtime...
>>
>
> AFAIR,you should be able to unbind a specific SocketServer at runtime too.
Nice to know!
>
> To explain the cause of my post, I'm _trying_ to debug a weird situation
>> where, under still obscure circumstances, there appears to be a slight
>> delay
>> in sending an ACK message to remote peers.
>>
>> Basically our protocol does something along the lines of:
>>
>> class IbisProtocolDecoder extends CumulativeProtocolDecoder {
>>
>>
>> public boolean doDecode(IoSession session, IoBuffer rawBuffer,
>>
>> ProtocolDecoderOutput out) throws Exception {
>>
>>
>> //get message from the line
>>
>> //calculate CRC
>>
>> if(crc OK){
>>
>> //send line ACK right on
>>
>> WriteFuture wf = session.write(new OutputLineMessage());
>>
>> }else
>>
>> //raise exception
>>
>> //forward decoded message to the handler
>>
>> TerminaleInputMessage msg = new TerminaleInputMessage();
>>
>> msg.readData(dataFromMsg);
>>
>> out.write(msg)
>>
>> }
>>
>> }
>>
>>
>> I've just added the WriteFuture statement and I'm seeing some variance in
>> the delay between session.write() and when this operation is completed;
>> namely sometimes it gets to 1300ms, while normally it's around 20ms...
>>
>>
>> I'm puzzled with these results. Initially I was thinking that ACKs where
>> delayed because of some threads blocking somewhere and causing requests to
>> be enqueued but I don't know if this's the case. Ideas are welcome:)
>>
> 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?
>
> 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.
cheers
Francesco
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
>
