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 >>>>>> >>>>>> >>>> >>>> >> >>
