+1 As an API writer (and consumer), this behavior makes sense, and most clients (notably, Apache HttpClient) would be able to handle this transparently (I think - it's been a few years since I messed with it :)
I completely agree that returning a 200 OK with empty (or, worse, stale) data would be confusing to most clients. *Marco Massenzio* *Distributed Systems Engineer* On Wed, Jul 1, 2015 at 9:54 AM, haosdent <[email protected]> wrote: > Oh, I got it. I would discuss document this with @adam. Thank you for your > great advice. > > On Thu, Jul 2, 2015 at 12:33 AM, James DeFelice <[email protected]> > wrote: > > > Sure, that makes sense. I guess I was wondering if we should document a > > recommended retry-limit threshold for people writing clients - along > with a > > recommended approach for backing off before retrying again. > > > > On Wed, Jul 1, 2015 at 12:29 PM, haosdent <[email protected]> wrote: > > > > > Hi, @James Thank you very much for your good question. My current patch > > > could not avoid this problem. I think you could handle this in client > > side, > > > give it up or return error when redirect times overflow your define > > limit. > > > > > > On Thu, Jul 2, 2015 at 12:23 AM, James DeFelice < > > [email protected]> > > > wrote: > > > > > > > In a cluster that's having network problems and the selected leader > is > > > > "flapping" is there an upper limit on how many subsequent redirects a > > > > client may expect to receive before it should give up for some period > > of > > > > time? For example: > > > > > > > > client requests /tasks.json from master1 > > > > master1 sends redirect to master2 > > > > master1 is elected as leader > > > > client requests /tasks.json from master2 > > > > master2 redirects to master1 > > > > master3 is elected as leader > > > > client requests /tasks.json from master1 > > > > master1 redirects to master3 > > > > ... > > > > > > > > > > > > On Wed, Jul 1, 2015 at 6:09 AM, haosdent <[email protected]> wrote: > > > > > > > > > Hi, @Tomas Senart. Currently, my patch is to redirect the request > to > > > > > correct url. For example: > > > > > > > > > > $ curl -i http://master1:5050/master/tasks.json > > > > > HTTP/1.1 307 Temporary Redirect > > > > > Date: Mon, 01 Jun 2015 06:30:08 GMT > > > > > Location: http://master2:5050/master/tasks.json > > > > > Content-Length: 0 > > > > > > > > > > Assume master1 is not a leader, master 2 is the leader. When you > send > > > > your > > > > > request to master1, you could recieve the redirection to master2. > And > > > the > > > > > location field in response headers also contains the correct url. > And > > > > this > > > > > is a single patch, not a precursor for something else. Also thanks > > the > > > > help > > > > > from @adam and @alex. :-) > > > > > > > > > > On Wed, Jul 1, 2015 at 12:12 PM, Tomás Senart <[email protected] > > > > > > wrote: > > > > > > > > > > > Hi Haosdent, > > > > > > > > > > > > Thanks for the heads up. Would you be able to share the rationale > > for > > > > > this > > > > > > change? Is it a precursor for something else? > > > > > > > > > > > > Best, > > > > > > Tomás > > > > > > On Tue 30 Jun 2015 at 19:24 haosdent <[email protected]> wrote: > > > > > > > > > > > > > Hi All, > > > > > > > > > > > > > > We intend to introduce a breaking change[1] in the http > > endpoints. > > > > For > > > > > > > below http endpoints, when user request to a master which is > not > > a > > > > > > leader, > > > > > > > user would got a 302 redirect to the leader master. > > > > > > > * /slaves > > > > > > > * /state > > > > > > > * /stateSummary > > > > > > > * /roles > > > > > > > * /teardown > > > > > > > * /tasks > > > > > > > For other endpoints in master, the behaviour is not change. If > > your > > > > > > > existing framework relied on this behaviour, I suggest add a > > logic > > > to > > > > > > > handle 302 redirect response. Let me know if you have any > > > > > > queries/concerns. > > > > > > > Thank you very much. > > > > > > > > > > > > > > Links: > > > > > > > [1] Tracking JIRA: > > > https://issues.apache.org/jira/browse/MESOS-1865 > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > Best Regards, > > > > > > > Haosdent Huang > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Best Regards, > > > > > Haosdent Huang > > > > > > > > > > > > > > > > > > > > > -- > > > > James DeFelice > > > > 585.241.9488 (voice) > > > > 650.649.6071 (fax) > > > > > > > > > > > > > > > > -- > > > Best Regards, > > > Haosdent Huang > > > > > > > > > > > -- > > James DeFelice > > 585.241.9488 (voice) > > 650.649.6071 (fax) > > > > > > -- > Best Regards, > Haosdent Huang >
