Current plan is to keep the load balancer with Phoenix, but that could
change if there's general interest. In the first cut, we weren't planning
on doing any client retries, but that's probably a good idea to add.
James
On Thu, May 25, 2017 at 1:28 PM, Gian Merlino <[email protected]> wrote:
> 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
> > >
> >
>
