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...
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:)
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...
Ok, maybe these points deserves a separate post. I'll do a bit more of
research in the meantime.
Cheers
Francesco
On Thu, Jan 27, 2011 at 10:13 AM, Emmanuel Lecharny <[email protected]>wrote:
> On 1/27/11 9:13 AM, Francesco Vivoli wrote:
>
>> Hi everybody
>>
>> Our application uses a number of NioSocketAcceptor, instantiated using the
>> default constructor. AFAIK this will create N acceptor thread pools (via
>> Executors.newCachedThreadPool()) and N processor pools
>> (SimpleIoProcessorPool), where N is the number of acceptors. Each
>> processor
>> will then serve a session.
>>
>
> Do you know that you can use *one* single Acceptor and still accept
> connections for many different ports ? The NioSocketAcceptor.bind() method
> can accept a list of SocketAddress, not only one single address.
>
> Resource-wise this doesn't seem to be very efficient and I'm thinking of
>> creating a single acceptor, as well a single processor thread pool, to be
>> shared by every IoService.
>>
>> Now, is this the recommended pattern here?
>>
>> One thing left is the size of the processor thread pool: why should it be
>> related to the number of cores, while ExecutorFilter's pool doesn't?
>>
> The acceptor uses one Selector per thread in the IoProcessor pool. If you
> have only one, then all the incoming requests will be processed by this
> IoProcessor, which may be a bottleneck up to a point. As the Selector is
> using a system call under the hood to process the incoming requests, it doe
> snot make a ot of sense to have more IoProcessor running than the number of
> cores.
>
> However, all of this is pretty much theoretical. The best would be to
> conduct some stress tests to validate the number of IoProcessor to create.
>
> Speaking of which, given that each acceptor in our app serve basically
>> just
>> one session, would it make sense to use such a filter? I wouldn't think
>> so.
>> In any case, would it be safe/desiderable to share executors between
>> ExecutorFilters and IoServices ?
>>
> I want to make it clear that an Acceptor does not serve sessions, but
> incoming connections Sessions are managed by the IoProcessor, once the
> connection has been established.
>
> And, yes, challenging the usage of an ExecutorFilter is a valid question.
> Basically, it depends on the typ of application you are using. In some
> cases, it might be necessary to have a Execurot in the filter, even if you
> manage one single session, for instance if your server processes long tasks,
> and if the end user want to stop the execution of a previous request he
> sent. In this case, an Executor can be necessary, otherwise your second
> request won't be processed before the first one is terminated.
>
> Sorry for the maybe naive questions but I haven't found much on this topic
>> around and I'm fairly new here...
>>
>> I'm running 2.0.0M6, on windows 2003 servers.
>>
> 2.0.0-M6 is buggy up to a point you can't imagine. 2.0.2 has been released
> last december, I urge you to switch to this version !
>
> Thanks !
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
>
