Hi, tien
It's such a matter that can hardly say right or wrong. `hashCode` also has its
own purpose but not for load balancing. I agree with you that hashCode() is a
better practice to toString() if we took default implementation away.
Maybe we can make it a configurable item in method level, class level or also
global level like:
algorithm = "hash" / "string" / etc...
or make it an annotation like: (more aggressive, bad practice)
@ConsistentHash
public String some() {}
Maybe the first way is more acceptable.
best regards,
Jason
> On Sep 25, 2019, at 18:05, Tien Dat PHAN <[email protected]> wrote:
>
> Dear Jason,
>
> Thanks for your answer.
>
> The default 'hashCode()' is inconsistent between JVMs. That is why we suggest
> to override it with a customized hashCode generating method, that, of course,
> has to make sure the consistency across multi-JVMs.
>
> On the other hand, 'toString()' can be use as a replacement. But this mean we
> just break the original purpose of 'toString()' method.
>
> At the end, it is clear that using 'hashCode()' will not guarantee the
> consistency between multiple JVMs for default JAVA objects. But with
> customized JAVA objects, with of course proper 'hashCode' implementation,
> using 'hashCode' would be the most relevant approach for Consistent hash
> algorithm.
>
> So do you think it would be reasonable to enable this in the future as an
> additional option? The default option is still using 'toString' method.
>
> Best
> Tien Dat
>
> On 2019/09/25 01:14:39, Jason Joo <[email protected]> wrote:
>> Hi, tien
>>
>> `hashCode` maybe consistent in single node but will be inconsistent between
>> JVM processes.(under default implementation)
>>
>> And you also have the ability to override the `toString()` method.
>>
>> best regards,
>>
>> Jason
>>
>>> On Sep 24, 2019, at 22:00, Tien Dat PHAN <[email protected]> wrote:
>>>
>>> Hi Jason,
>>>
>>> I just had some time looking back at this thread.
>>> I just realized that it may be useful if we apply the consistent hash
>>> algorithm on simply the hashCode() of the first parameters. I think it
>>> would be better compare to use the toString() method.
>>>
>>> With that, users can override the hashCode() method of their own objects.
>>>
>>> What do you think?
>>>
>>> Best regards
>>> Tien Dat PHAN
>>>
>>> On 2019/06/12 11:56:25, Jason Joo <[email protected]> wrote:
>>>> Hi, Dat
>>>>
>>>> Stand at the point of DUBBO maybe it is too complex to support a grammar
>>>> as EL expressions like 'param[0].url' due to invokers are so dynamic in
>>>> same invocation group.
>>>>
>>>> So I think taking an obvious and special partition/hashing parameter is
>>>> acceptable for me instead of taking it as a kind of duplicated information.
>>>>
>>>> Again if you have better ideas it could be welcome in community.
>>>>
>>>>
>>>> best regards,
>>>>
>>>> Jason
>>>>
>>>>> On Jun 12, 2019, at 19:34, [email protected] wrote:
>>>>>
>>>>> Hi Jason,
>>>>>
>>>>> Thanks for sharing your opinion :)
>>>>> This is actually what we are currently doing, for now, as we do not find
>>>>> a better solution for this yet.
>>>>>
>>>>> Best
>>>>> Dat
>>>>>
>>>>> On 2019/06/12 08:28:32, Jason Joo <[email protected]> wrote:
>>>>>> Hi, Tien
>>>>>>
>>>>>> Agree to you that it will break the principle of design if overriding
>>>>>> toString().
>>>>>> Currently consist hash of load balance only support specifying which
>>>>>> argument(s) can take charge in it but not support specify certain
>>>>>> property of a parameter to do so.
>>>>>>
>>>>>> For better understanding maybe add a parameter like
>>>>>>
>>>>>>> MyResponse getResponse(String partitionKey, MyRequestParams params);
>>>>>>
>>>>>>
>>>>>> may be more easy.
>>>>>>
>>>>>> It's only my opinion.
>>>>>>
>>>>>>
>>>>>> best regards,
>>>>>>
>>>>>> Jason
>>>>>>
>>>>>>> On Jun 12, 2019, at 15:31, [email protected] wrote:
>>>>>>>
>>>>>>> Dear Jason,
>>>>>>>
>>>>>>> I am aware of that.
>>>>>>> However, as the MyRequestParams has multiple fields, we would like to
>>>>>>> avoid implementing the toString method that return a string containing
>>>>>>> only the URI field.
>>>>>>> This would break the purpose of the toString method.
>>>>>>>
>>>>>>> Do you know any other approaches/work around for this?
>>>>>>>
>>>>>>> Best
>>>>>>> Dat
>>>>>>>
>>>>>>> On 2019/06/12 00:56:42, Jason Joo <[email protected]> wrote:
>>>>>>>> Hi, Tien
>>>>>>>>
>>>>>>>> Consistent hash is relying mainly the object's "toString()" protocol.
>>>>>>>> So pls make sure your objects have a unique and stable toString()
>>>>>>>> method and it will be ok.
>>>>>>>>
>>>>>>>> best regards,
>>>>>>>>
>>>>>>>> Jason
>>>>>>>>
>>>>>>>>> On Jun 11, 2019, at 16:58, [email protected] wrote:
>>>>>>>>>
>>>>>>>>> Dear experts,
>>>>>>>>>
>>>>>>>>> We are using Dubbo to export our services. For data load balancing,
>>>>>>>>> we would like to use the consistent hash load balancer.
>>>>>>>>> For the default usage of this load balancer, we can define either one
>>>>>>>>> or several parameters of the consumed method to be used as the
>>>>>>>>> hashing data.
>>>>>>>>> We wonder if it is possible to target the hashing on the field of an
>>>>>>>>> object passed as the param.
>>>>>>>>> For instance, the method interface is as follows:
>>>>>>>>>
>>>>>>>>> MyResponse getResponse(MyRequestParams params);
>>>>>>>>>
>>>>>>>>> The object params has a field named URI, which we would like to apply
>>>>>>>>> the hash algorithm upon.
>>>>>>>>> Of course, we can modify our method to:
>>>>>>>>>
>>>>>>>>> MyResponse getResponse(String uri, MyRequestParams params);
>>>>>>>>>
>>>>>>>>> But this really is contradictory with the design goal of
>>>>>>>>> MyRequestParam object (which is defined to wrap all our request
>>>>>>>>> params into one object)
>>>>>>>>>
>>>>>>>>> Best regards
>>>>>>>>> Tien Dat PHAN
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
