Thanks James - Will do on Mon.
On Aug 15, 2014 8:26 PM, "James Taylor" <jamestay...@apache.org> wrote:

> Hi Jody,
> Thanks for reporting this. These are bugs, as the client should detect
> and retry automatically in these cases when necessary. What version of
> Phoenix are you using? Would you mind giving it a shot in 3.1/4.1.
> We'll have an RC out on Monday at the latest.
> Thanks,
> James
>
> On Fri, Aug 15, 2014 at 11:56 AM, Jody Landreneau
> <jodylandren...@gmail.com> wrote:
> > hello phoenix devs,
> >
> > Let me explain an issue I would like to solve. We have multiple phoenix
> > clients running, which could be on several physical machines(diff vms)
> > which act as storage/retreival endpoints. If I change the schema of a
> > table, by adding or removing a field, I get errors in the clients that
> > didn't issue the alter. This is due to an internal client cache that is
> not
> > refreshed. I note that the connections get their cache from this shared
> > client cache so creating/closing connections does not help.
> >
> > I would like to add a timed expiration cache also limited by size to
> > address this issue.  I see that there is a guava cache for server side
> and
> > think that doing something similar on the client side makes sense. It
> could
> > make things much simpler than having to deal with a pruner and other
> code.
> > I was wondering if the community would accept an approach like this.
> Also,
> > we could reduce all the cloning of the cache, potentially just sharing
> one
> > for connections that belong to a client.  I see that there is some work
> to
> > try and manage the capacity of the number of bytes that the cache has.
> > Would it be reasonable to just make the capacity based off the number of
> > tables the cache holds instead of byte detail? It seems that the objects
> > should be fairly light weight and if you go to an approach of sharing the
> > same cache across connection then it should use even less resources.
> >
> > I would like to know if there are some reasons for not taking this
> approach?
> >
> > thanks in advance --
>

Reply via email to