Custom channel identifier alternative

[fatzopilot]

Hi Frederic,

> For the OrderedMemoryAwareThreadPoolExecutor, if order of your messages
> from the client has no 
> value for your business (such that message 2 can be answered before
> message 1 for instance), then 
> you don't have to have such executor in your pipeline. Most of the time,
> when a client have a 
> stateful session, we have to have this order respected, so my suggestion.
> If not for you, just forget 
> it. For more information, please tale a look into the API.
That's good to know in case I need it some time...

> For the reference to the map, I would say that you have to create a
> "global" map that is accessible 
> to all channels. A static object may do the trick for simplicity or any
> other way such as creating this 
> map at the very start of your server and then pass it as a constructor
> argument to the
> pipelineFactory that will include it into each new business handler as a
> constructor argument too.
Hm, I opt for the static map. I'll have to put all depending classes in one
file though...

> The extra codes you need is somehow small (a map, a boolean to see if the
> connection is already 
> initialized, and the getter ans setter for the special Id into
> messageReceived and channelClosed, 
> those closing the current or previous channel if any). You already have
> the id in each message, so 
> this is already done. I don't feel it like a huge amount of work.
OK, I think this is the way to go...

> Now for your proposition, I think Trustin (when he comes back of holidays
> ;-) or others committers 
> could answer your question more precisely. My opinion would be the
> following (note that is only my 
> opinion):

> - so maybe the need could be a map returning a channel from an object,
> assuming that this object is 
> a unique identifier specified by the business: I feel like it is business
> dependent (the necessary 
> functions of comparison between keys is completely implementation
> dependent with regards on the 
> key itself). However perhaps it is possible to have at least a sequeleton
> of this in Netty (that is 
> what you are going to write anyway).
I would really appreciate this :)

> - changing the channel Id (or adding another one) could be more tricky and
> not error prone: this id 
> should be unique (at least during the life of the channel), so as the new
> id sets by the user. If I take 
> your example, what could be the logic then when one client reconnects with
> a new channel whereas 
> in the same time the previous channel is still active? You cannot have two
> channels with the same 
> Id, right? So you have to close one: which one? I would say this kind of
> implementation is quite 
> business dependent too (at least the decision on which one to close). 
> For the moment I cannot see an implementation that would fit any usage...
> but perhaps other people 
> (including you of course) could specify more this kind of things to see
> how to implement it if this is 
> useful.
I see, this isn't a simple thing as there are a lot of things to consider
(concurrent connection attempts and the like). So for the moment, the first
option really would suffice.

> We can imagine different behaviors when this id is set and there is
> another channel already 
> registered with the same id: any previously channel is closed; the new
> channel is refused; some 
> competitions between them must be done (like is the previous one still
> responding and active or no 
> more responsive); ...
The optimal solution in my case would of course be to configure Netty in
such a way that an existing channel is closed whenever its id is used (set)
as an id for a second channel.

> Also setting this id is obviously done when the new channel is already
> connected and probably when 
> a message is received with this special id in the message, so the setting
> must be controled by the 
> programmer and cannot be automatic, which could lead to issues (imagine
> the worst case where the 
> same client just opens two channels almost in the same time, which one is
> correct?).
Hm, yes there is a small chance that the wrong (new channel) may be closed.
In my case though, the client will try to reconnect after a while, so this
isn't an issue...

Frederic, thanks for the clarification. I think I know now what to do....
fatzopilot

 
-- 
View this message in context: http://n2.nabble.com/Custom-channel-identifier-alternative-tp3326889p3332953.html
Sent from the Netty User Group mailing list archive at Nabble.com.