> - We can add heartbeats to the SUBSCRIBE call. > This would need to be > part of a separate operator Call, because one platform (browsers) that > might subscribe to the master does not support two-way streaming.
This doesn't make sense to me, the heartbeats should still be part of the same connection (request and response are infinite and heartbeating) by default. Splitting into a separate call is messy and shouldn't be what we force everyone to do, it should only be done in cases that it's impossible to use a single connection (e.g. browsers). On Sat, Nov 10, 2018 at 12:03 AM Joseph Wu <jos...@mesosphere.io> wrote: > Hi all, > > During some internal scale testing, we noticed that, when Mesos streaming > endpoints are accessed via certain proxies (or load balancers), the proxies > might not close connections after they are complete. For the Mesos master, > which only has the /api/v1 SUBSCRIBE streaming endpoint, this can generate > unnecessary authorization requests and affects performance. > > We are considering a few potential solutions: > > - We can add heartbeats to the SUBSCRIBE call. This would need to be > part of a separate operator Call, because one platform (browsers) that > might subscribe to the master does not support two-way streaming. > - We can add (optional) arguments to the SUBSCRIBE call, which tells the > master to disconnect it after a while. And the client would have to > remake > the connection every so often. > - We can change the master to hold subscribers in a circular buffer, and > disconnect the oldest ones if there are too many connections. > > We're tracking progress on this issue here: > https://issues.apache.org/jira/browse/MESOS-9258 > Some prototypes of the code changes involved are also linked in the JIRA. > > Please chime in if you have any suggestions or if any of these options > would be undesirable/bad, > ~Joseph >
