I'm asking in the context of Druid, which also uses Avatica. Although it sounds like PHOENIX-3654 means Phoenix is intending to go in the direction of client-side load balancing. Are you planning to contribute the work to Avatica or keep it unique to Phoenix? We might want something similar in Druid; client side load balancing will probably work better than using a proxy, given how the servers don't share state at all.
If a backend server goes down, would a PHOENIX-3654 style client transparently retry the query on a different server? Or would it fail and expect the user to retry? Gian On Thu, May 25, 2017 at 12:55 PM, James Taylor <[email protected]> wrote: > If you're using Avatica in the context of Phoenix, you might be interested > in PHOENIX-3654 which is about adding a load balancer to the Phoenix Query > Server. > > Thanks, > James > > On Thu, May 25, 2017 at 12:02 PM, Gian Merlino <[email protected]> wrote: > > > Is anyone out there using Avatica with servers (that don't share > connection > > state) behind load balancers? Is that a workable configuration? I'm > > guessing it might be if sticky sessions are enabled on the load balancer. > > What does the client do when the session switches to a new backend > server? > > > > I found a blog post that talks about some of these issues in the context > of > > Phoenix: > > https://community.hortonworks.com/articles/9377/deploying- > > the-phoenix-query-server-in-production-e.html > > > > It seems to suggest that the client will retry queries and skip to the > most > > recently read offset. Is that behavior on by default? This sounds like it > > won't work for a database that is accepting new data -- the query results > > aren't generally going to be exact matches from run to run just due to > new > > rows being added. In that case, I'm struggling to think of any better > > approach than failing the query and expecting the user to retry if they > > want to. > > > > Gian > > >
