Dear Tphan,

Would you mind to subscribe this mailing list, otherwise the mailing list
administrator will approve every email you send to this address, which you
may not realize.

If you don't know how to do it, pls. follow here. [1]

Ian.

1.
http://dubbo.apache.org/en-us/docs/developers/contributor-guide/mailing-list-subscription-guide_dev.html



On Wed, Sep 25, 2019 at 7:50 AM 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
> > >>>>
> > >>>>
> > >>
> > >>
> >
> >
>

Reply via email to