Resurrect Channel.id() #1810

Closed
trustin opened this Issue Sep 4, 2013 · 12 comments

Projects

None yet

6 participants

@trustin
Member
trustin commented Sep 4, 2013

If we don't insist the type of Channel.id() to be an integer, I think we might be able to make it unique for sure. For example, it could be hashCode + identityHashCode + nanoTime + sequence. Practically, this should never collide.

@normanmaurer
Member

@trustin good idea... will you work on this ?

@fredericBregier
Member

Just a proposal : why not using uuid (real one) such that unicity is provable ?

@fredericBregier
Member

Note: not uuid from jvm but another implementation...

@trustin
Member
trustin commented Sep 4, 2013

Yeah, we can do that, too. 3.x had to work with Java 5 which did not have access to the hardware address of the network interface, but the minimum requirement of 4.x is Java 6, so we can definitely do that.

@trustin
Member
trustin commented Sep 4, 2013

I think we can even use the UUID from JDK as long as we feed all the fields by ourselves.

@normanmaurer
Member

@trustin you will take care?

@hepin1989

the id can be everything,Long or String ,I think there is no need to insist it as an Integer

@fredericBregier
Member

From my own research, what I've found on various implementation as probably the best is the following combination in UUID:

  • partial MAC address (to ensure difference between 2 hosts), set statically at the beginning of the JVM
  • a JVM PID (to ensure difference between 2 JVM on the same host), set statically at the beginning of the JVM
  • partial timestamp in ms (since nano is not always implemented and so last bytes are just 0, and since most of the front bytes are 0)
  • and finally a counter to prevent 2 same values on the same ms (as AtomicLong) (this is the tricker part I've found that ensures that 2 immediate consecutive or simultaneous demands of UUID are still different)

My 2 cents...

@matlach
matlach commented Sep 10, 2013

like hepin1989 said, id should be anything,

to me:

  • channel.id() should return an java.lang.Object (or maybe a T to avoid cast ?)
  • it should be allowed for user to provide a certain implementation for a "ChannelIdGenerator" interface with a given "public Object generateId(Channel channel)" method to implements
  • the default proposed netty channel id strategy should implement this interface

As for the implementation detail of the id, I think fredericBregier have a good point.
Maybe also looking on how jgroups and/or infinispan generate their unique cluster id could be helpful ?

@darionyaphet

@trustin @normanmaurer

UUID maybe human unreadable .....

@normanmaurer
Member

I think there is no need for make it human readable

Am 21.09.2013 um 18:06 schrieb yaphet notifications@github.com:

@trustin @normanmaurer

UUID maybe human unreadable .....


Reply to this email directly or view it on GitHub.

@hepin1989

mostly,we using the channel as a key for the map<channelId,channel>,why should it be human readable?

@trustin trustin added a commit that closed this issue Nov 18, 2013
@trustin trustin Resurrect Channel.id() with global uniqueness
- Fixes #1810
- Add a new interface ChannelId and its default implementation which generates globally unique channel ID.
- Replace AbstractChannel.hashCode with ChannelId.hashCode() and ChannelId.shortValue()
- Add variants of ByteBuf.hexDump() which accept byte[] instead of ByteBuf.
2235873
@trustin trustin closed this in 2235873 Nov 18, 2013
@trustin trustin was assigned Nov 18, 2013
@trustin trustin added a commit that referenced this issue Feb 13, 2014
@trustin trustin Resurrect Channel.id() with global uniqueness
- Fixes #1810
- Add a new interface ChannelId and its default implementation which generates globally unique channel ID.
- Replace AbstractChannel.hashCode with ChannelId.hashCode() and ChannelId.shortValue()
- Add variants of ByteBuf.hexDump() which accept byte[] instead of ByteBuf.
40003ed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment