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