4
1;原来的代码是toString, 而不是 hashcode. 2:原来的二代码，在多消费者，或者一个消费者重启多次情况下，也难以保证相同的参数路由到同一个provider上。
Q
[apache/dubbo]1:采用hashcode方法;2:支持多消费者一致性Hash
A
回答
0
也没有用 如果没有重写hashCode native的hashCode应该是内存地址之类的 那么即使值相等的两个对象的hashCode也不一样
6
所以要解决这个只能定制一个规范 所有参数必须重写toString或者hashCode 实际上这种规范很难彻底被执行 所以... 我觉得只能提醒大家使用这个的时候要慎重
1
当然要重写 对应参数的 hashcode 方法。 文档是： 【缺省只对第一个参数Hash，】
8
那文档描述也需要修改 例如使用这个的前提是 hash所依赖的参数都需要重写hashCode,保证相同值的参数的hashCode是一致的
5
关键问题是:
对应的参数需要重写hashCode,native的hashCode是不可以的 而实际上这个规范在实际操作中很难保证 所以文档中要特别注明
0
我认为 文档说的够清楚了。
9
文档是这样子的： http://dubbo.io/User+Guide-zh.htm#UserGuide-zh-%E8%B4%9F%E8%BD%BD%E5%9D%87%E8%A1%A1
没有强调参数对象需要重写hashCode或者是toString
9
对的，文档约束为对第一个参数的散列
0
比较同意hangping40的观点，用invoker的url中的IP+port来代替fullString，因为fullString在每次启动的时候都有不确定的因素，比如timestamp。会导致每次启动映射到hash环的位置可能会不同。
3
ip端口也不是很好