Hi Jason, I totally agree with you. Having options would be the best practice.
Best Tien Dat On 2019/09/26 01:13:59, Jason Joo <[email protected]> wrote: > 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 > >>>>>>>> > >>>>>>>> > >>>>>> > >>>>>> > >>>> > >>>> > >> > >> > >
