Hi guys, I have changed the stores.xml into server side routing: <routing>server</routing> <routing-strategy>consistent-routing</routing-strategy>
But seems that the java client is not able to use server side routing yet, as the ClientConfig.java says:
/** * Set the tier at which routing occurs. Client-side routing occurs on the * client, and server-side routing on the server. This is not yet used, as * the java client only supports client-side routing. * * @param routingTier The routing tier to use for routing requests */ public ClientConfig setRoutingTier(RoutingTier routingTier) { this.routingTier = Utils.notNull(routingTier); return this; }
> Hi guys,
> I have changed the stores.xml into server side routing:
> <routing>server</routing>
> <routing-strategy>consistent-routing</routing-strategy>
> But seems that the java client is not able to use server side routing yet, > as the ClientConfig.java says:
> /**
> * Set the tier at which routing occurs. Client-side routing occurs on > the
> * client, and server-side routing on the server. This is not yet > used, as
> * the java client only supports client-side routing.
> * > * @param routingTier The routing tier to use for routing requests
> */
> public ClientConfig setRoutingTier(RoutingTier routingTier) {
> this.routingTier = Utils.notNull(routingTier);
> return this;
> }
On Fri, Nov 2, 2012 at 4:14 AM, Felix.Xu <ygnhz...@gmail.com> wrote:
> Resolved, I've implemented a new client.
> 在 2012年10月31日星期三UTC+8下午5时03分26秒，Felix.Xu写道：
>> Hi guys,
>> I have changed the stores.xml into server side routing:
>> <routing>server</routing>
>> <routing-strategy>**consistent-routing</routing-**strategy>
>> But seems that the java client is not able to use server side routing
>> yet, as the ClientConfig.java says:
>> /**
>> * Set the tier at which routing occurs. Client-side routing occurs
>> on the
>> * client, and server-side routing on the server. This is not yet
>> used, as
>> * the java client only supports client-side routing.
>> *
>> * @param routingTier The routing tier to use for routing requests
>> */
>> public ClientConfig setRoutingTier(RoutingTier routingTier) {
>> this.routingTier = Utils.notNull(routingTier);
>> return this;
>> }
>> so, is there any solution to this problem?
> --
> You received this message because you are subscribed to the Google Groups
> "project-voldemort" group.
> To unsubscribe from this group, send email to
> project-voldemort+unsubscribe@googlegroups.com.
> Visit this group at http://groups.google.com/group/project-voldemort?hl=en > .
> Hi guys,
> I have changed the stores.xml into server side routing:
> <routing>server</routing>
> <routing-strategy>consistent-routing</routing-strategy>
> But seems that the java client is not able to use server side routing yet, > as the ClientConfig.java says:
> /**
> * Set the tier at which routing occurs. Client-side routing occurs on > the
> * client, and server-side routing on the server. This is not yet > used, as
> * the java client only supports client-side routing.
> * > * @param routingTier The routing tier to use for routing requests
> */
> public ClientConfig setRoutingTier(RoutingTier routingTier) {
> this.routingTier = Utils.notNull(routingTier);
> return this;
> }
On Fri, Nov 2, 2012 at 10:38 AM, Felix.Xu <ygnhz...@gmail.com> wrote:
> Sure, but I've added and modified quite a few classes, I'll write a blog
> and paste it here. BTW, can I submit the changes into Voldemort project?
> 在 2012年10月31日星期三UTC+8下午5时03分26秒，Felix.Xu写道：
>> Hi guys,
>> I have changed the stores.xml into server side routing:
>> <routing>server</routing>
>> <routing-strategy>**consistent-routing</routing-**strategy>
>> But seems that the java client is not able to use server side routing
>> yet, as the ClientConfig.java says:
>> /**
>> * Set the tier at which routing occurs. Client-side routing occurs
>> on the
>> * client, and server-side routing on the server. This is not yet
>> used, as
>> * the java client only supports client-side routing.
>> *
>> * @param routingTier The routing tier to use for routing requests
>> */
>> public ClientConfig setRoutingTier(RoutingTier routingTier) {
>> this.routingTier = Utils.notNull(routingTier);
>> return this;
>> }
>> so, is there any solution to this problem?
> --
> You received this message because you are subscribed to the Google Groups
> "project-voldemort" group.
> To unsubscribe from this group, send email to
> project-voldemort+unsubscribe@googlegroups.com.
> Visit this group at http://groups.google.com/group/project-voldemort?hl=en > .
On Friday, November 2, 2012 4:52:59 AM UTC-7, ctasada wrote:
> You can open an issue or a pull request in the GitHub Project.
> On Fri, Nov 2, 2012 at 10:38 AM, Felix.Xu <ygnh...@gmail.com <javascript:>
> > wrote:
>> Sure, but I've added and modified quite a few classes, I'll write a blog >> and paste it here. BTW, can I submit the changes into Voldemort project?
>> 在 2012年10月31日星期三UTC+8下午5时03分26秒，Felix.Xu写道：
>>> Hi guys,
>>> I have changed the stores.xml into server side routing:
>>> <routing>server</routing>
>>> <routing-strategy>**consistent-routing</routing-**strategy>
>>> But seems that the java client is not able to use server side routing >>> yet, as the ClientConfig.java says:
>>> /**
>>> * Set the tier at which routing occurs. Client-side routing occurs >>> on the
>>> * client, and server-side routing on the server. This is not yet >>> used, as
>>> * the java client only supports client-side routing.
>>> * >>> * @param routingTier The routing tier to use for routing requests
>>> */
>>> public ClientConfig setRoutingTier(RoutingTier routingTier) {
>>> this.routingTier = Utils.notNull(routingTier);
>>> return this;
>>> }
>>> so, is there any solution to this problem?
>> -- >> You received this message because you are subscribed to the Google Groups >> "project-voldemort" group.
>> To unsubscribe from this group, send email to >> project-voldem...@googlegroups.com <javascript:>.
>> Visit this group at >> http://groups.google.com/group/project-voldemort?hl=en.
My apologies for not updating the thread. We are indeed working on a thin client architecture which moves the complicated quorum based routing to a separate entity : 'Coordinator' and also makes the protocol between the client and the coordinator less chatty.
It'll be interesting to hear what are your reasons of moving to a server side only routing ? What are the main issues that you face in your thick client currently ?
The advantage of defining the Coordinator is that once the logic is factored out, it gives us the flexibility to deploy it wherever we choose (for instance: on separate physical machines in front of the cluster or on the server nodes itself).
> Chinmay leads that project. He is on vacation at the moment and will be > back towards the end of Nov.
> Thanks,
> Lei Gao
> On Friday, November 2, 2012 4:52:59 AM UTC-7, ctasada wrote:
>> You can open an issue or a pull request in the GitHub Project.
>> On Fri, Nov 2, 2012 at 10:38 AM, Felix.Xu <ygnh...@gmail.com> wrote:
>>> Sure, but I've added and modified quite a few classes, I'll write a blog >>> and paste it here. BTW, can I submit the changes into Voldemort project?
>>> 在 2012年10月31日星期三UTC+8下午5时03分26秒，Felix.Xu写道：
>>>> Hi guys,
>>>> I have changed the stores.xml into server side routing:
>>>> <routing>server</routing>
>>>> <routing-strategy>**consistent-routing</routing-**strategy>
>>>> But seems that the java client is not able to use server side routing >>>> yet, as the ClientConfig.java says:
>>>> /**
>>>> * Set the tier at which routing occurs. Client-side routing occurs >>>> on the
>>>> * client, and server-side routing on the server. This is not yet >>>> used, as
>>>> * the java client only supports client-side routing.
>>>> * >>>> * @param routingTier The routing tier to use for routing requests
>>>> */
>>>> public ClientConfig setRoutingTier(RoutingTier routingTier) {
>>>> this.routingTier = Utils.notNull(routingTier);
>>>> return this;
>>>> }
>>>> so, is there any solution to this problem?
>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "project-voldemort" group.
>>> To unsubscribe from this group, send email to >>> project-voldem...@googlegroups.com.
>>> Visit this group at >>> http://groups.google.com/group/project-voldemort?hl=en.
Is there any documentation or GitHub fork to follow up the progress of this
project? The idea of having a "Coordinator" to deal with all the routing
logic is interesting. From my point of view, if I'm understanding it
properly, it will simplify the whole codebase. It will allow to decide if
the routing should be done in the client or the server side.
I'm not in favor of having a separate machine to coordinate, because then
we would introduce a "Single Point of Failure". I would prefer something
more in the line of Cassandra or MongoDB when dealing with routing.
My 2 cents.
On Fri, Nov 30, 2012 at 12:53 AM, Chinmay Soman
<chinmay.cere...@gmail.com>wrote:
Its my task for this weekend to collate all the docs into a public wiki.
Btw, its not going to be one single machine as a single point of failure. You can choose to deploy a set of coordinators responsible for a single cluster. The benefits of separating the coordinator from the server nodes are not very obvious at this point. However it does make the deployment model and debugging very easy.
I figure we need a lot more benchmarking to figure out the right deployment.
On Friday, November 30, 2012 12:19:46 AM UTC-8, ctasada wrote:
> Hi Chinmay,
> Is there any documentation or GitHub fork to follow up the progress of > this project? The idea of having a "Coordinator" to deal with all the > routing logic is interesting. From my point of view, if I'm understanding > it properly, it will simplify the whole codebase. It will allow to decide > if the routing should be done in the client or the server side.
> I'm not in favor of having a separate machine to coordinate, because then > we would introduce a "Single Point of Failure". I would prefer something > more in the line of Cassandra or MongoDB when dealing with routing.
> My 2 cents.
> On Fri, Nov 30, 2012 at 12:53 AM, Chinmay Soman <chinmay...@gmail.com<javascript:> > > wrote:
On Saturday, December 1, 2012 12:41:45 AM UTC-8, Chinmay Soman wrote:
> Its my task for this weekend to collate all the docs into a public wiki.
> Btw, its not going to be one single machine as a single point of failure. > You can choose to deploy a set of coordinators responsible for a single > cluster. The benefits of separating the coordinator from the server nodes > are not very obvious at this point. However it does make the deployment > model and debugging very easy.
> I figure we need a lot more benchmarking to figure out the right > deployment.
> On Friday, November 30, 2012 12:19:46 AM UTC-8, ctasada wrote:
>> Hi Chinmay,
>> Is there any documentation or GitHub fork to follow up the progress of >> this project? The idea of having a "Coordinator" to deal with all the >> routing logic is interesting. From my point of view, if I'm understanding >> it properly, it will simplify the whole codebase. It will allow to decide >> if the routing should be done in the client or the server side.
>> I'm not in favor of having a separate machine to coordinate, because then >> we would introduce a "Single Point of Failure". I would prefer something >> more in the line of Cassandra or MongoDB when dealing with routing.
>> My 2 cents.
>> On Fri, Nov 30, 2012 at 12:53 AM, Chinmay Soman <chinmay...@gmail.com>wrote:
> I'll keep this updated with the design specs, benchmarks and so on. Feel > free to edit / comment on the same.
> Thank you for the patience ! > C
> On Saturday, December 1, 2012 12:41:45 AM UTC-8, Chinmay Soman wrote:
>> Its my task for this weekend to collate all the docs into a public wiki.
>> Btw, its not going to be one single machine as a single point of failure. >> You can choose to deploy a set of coordinators responsible for a single >> cluster. The benefits of separating the coordinator from the server nodes >> are not very obvious at this point. However it does make the deployment >> model and debugging very easy.
>> I figure we need a lot more benchmarking to figure out the right >> deployment.
>> On Friday, November 30, 2012 12:19:46 AM UTC-8, ctasada wrote:
>>> Hi Chinmay,
>>> Is there any documentation or GitHub fork to follow up the progress of >>> this project? The idea of having a "Coordinator" to deal with all the >>> routing logic is interesting. From my point of view, if I'm understanding >>> it properly, it will simplify the whole codebase. It will allow to decide >>> if the routing should be done in the client or the server side.
>>> I'm not in favor of having a separate machine to coordinate, because >>> then we would introduce a "Single Point of Failure". I would prefer >>> something more in the line of Cassandra or MongoDB when dealing with >>> routing.
>>> My 2 cents.
>>> On Fri, Nov 30, 2012 at 12:53 AM, Chinmay Soman <chinmay...@gmail.com>wrote:
>> I'll keep this updated with the design specs, benchmarks and so on. Feel >> free to edit / comment on the same.
>> Thank you for the patience ! >> C
>> On Saturday, December 1, 2012 12:41:45 AM UTC-8, Chinmay Soman wrote:
>>> Its my task for this weekend to collate all the docs into a public wiki.
>>> Btw, its not going to be one single machine as a single point of >>> failure. You can choose to deploy a set of coordinators responsible for a >>> single cluster. The benefits of separating the coordinator from the server >>> nodes are not very obvious at this point. However it does make the >>> deployment model and debugging very easy.
>>> I figure we need a lot more benchmarking to figure out the right >>> deployment.
>>> On Friday, November 30, 2012 12:19:46 AM UTC-8, ctasada wrote:
>>>> Hi Chinmay,
>>>> Is there any documentation or GitHub fork to follow up the progress of >>>> this project? The idea of having a "Coordinator" to deal with all the >>>> routing logic is interesting. From my point of view, if I'm understanding >>>> it properly, it will simplify the whole codebase. It will allow to decide >>>> if the routing should be done in the client or the server side.
>>>> I'm not in favor of having a separate machine to coordinate, because >>>> then we would introduce a "Single Point of Failure". I would prefer >>>> something more in the line of Cassandra or MongoDB when dealing with >>>> routing.
>>>> My 2 cents.
>>>> On Fri, Nov 30, 2012 at 12:53 AM, Chinmay Soman <chinmay...@gmail.com>wrote:
+ 1 server side routing makes deployments much easier. I like the implementation approach: using REST with a fast Netty based server to take care of both the REST API and the "thin client" / "server-side routing" project.
I'm afraid I'm a bit too late to the party to be of much use, but since you've mentioned REST: about a year ago, I've thought a bit of what a (polyglot) REST API for Voldemort could look like and wrote down the thoughts here:
My goal, however, was to see how much of the Voldemort protocol could simply be handled by HTTP alone (e.g., HTTP-300 for conflict resolution) -- which I am not certain is the right approach.
> > > I'll keep this updated with the design specs, benchmarks and so on. Feel free to edit / comment on the same.
> > > Thank you for the patience !
> > > C
> > > On Saturday, December 1, 2012 12:41:45 AM UTC-8, Chinmay Soman wrote:
> > > > Its my task for this weekend to collate all the docs into a public wiki.
> > > > Btw, its not going to be one single machine as a single point of failure. You can choose to deploy a set of coordinators responsible for a single cluster. The benefits of separating the coordinator from the server nodes are not very obvious at this point. However it does make the deployment model and debugging very easy.
> > > > I figure we need a lot more benchmarking to figure out the right deployment.
> > > > On Friday, November 30, 2012 12:19:46 AM UTC-8, ctasada wrote:
> > > > > Hi Chinmay,
> > > > > Is there any documentation or GitHub fork to follow up the progress of this project? The idea of having a "Coordinator" to deal with all the routing logic is interesting. From my point of view, if I'm understanding it properly, it will simplify the whole codebase. It will allow to decide if the routing should be done in the client or the server side.
> > > > > I'm not in favor of having a separate machine to coordinate, because then we would introduce a "Single Point of Failure". I would prefer something more in the line of Cassandra or MongoDB when dealing with routing.
> > > > > My 2 cents.
> > > > > On Fri, Nov 30, 2012 at 12:53 AM, Chinmay Soman <chinmay...@gmail.com> wrote:
> > > > > > wherever
> -- > You received this message because you are subscribed to the Google Groups "project-voldemort" group.
> To unsubscribe from this group, send email to project-voldemort+unsubscribe@googlegroups.com (mailto:project-voldemort+unsubscribe@googlegroups.com).
> Visit this group at http://groups.google.com/group/project-voldemort?hl=en.
Currently, the HTTP protocol is designed to return all the conflicting records with the resolution happening on the thin client side. We could technically also have the failure detection on the coordinator, if we're using the default mechanism. The only problem occurs with custom resolution which is difficult to manage / deploy on the coordinator.
On Tuesday, December 4, 2012 4:36:27 PM UTC-8, Alex Feinberg wrote:
> + 1 server side routing makes deployments much easier. I like the > implementation approach: using REST with a fast Netty based server to take > care of both the REST API and the "thin client" / "server-side routing" > project.
> I'm afraid I'm a bit too late to the party to be of much use, but since > you've mentioned REST: about a year ago, I've thought a bit of what a > (polyglot) REST API for Voldemort could look like and wrote down the > thoughts here:
> My goal, however, was to see how much of the Voldemort protocol could > simply be handled by HTTP alone (e.g., HTTP-300 for conflict resolution) -- > which I am not certain is the right approach.
> Thanks! > - af
> -- > Alex Feinberg
> On Monday, December 3, 2012 at 11:05 PM, Chinmay Soman wrote:
> > > > I'll keep this updated with the design specs, benchmarks and so on. > Feel free to edit / comment on the same.
> > > > Thank you for the patience ! > > > > C
> > > > On Saturday, December 1, 2012 12:41:45 AM UTC-8, Chinmay Soman > wrote: > > > > > Its my task for this weekend to collate all the docs into a public > wiki.
> > > > > Btw, its not going to be one single machine as a single point of > failure. You can choose to deploy a set of coordinators responsible for a > single cluster. The benefits of separating the coordinator from the server > nodes are not very obvious at this point. However it does make the > deployment model and debugging very easy.
> > > > > I figure we need a lot more benchmarking to figure out the right > deployment.
> > > > > On Friday, November 30, 2012 12:19:46 AM UTC-8, ctasada wrote: > > > > > > Hi Chinmay,
> > > > > > Is there any documentation or GitHub fork to follow up the > progress of this project? The idea of having a "Coordinator" to deal with > all the routing logic is interesting. From my point of view, if I'm > understanding it properly, it will simplify the whole codebase. It will > allow to decide if the routing should be done in the client or the server > side.
> > > > > > I'm not in favor of having a separate machine to coordinate, > because then we would introduce a "Single Point of Failure". I would prefer > something more in the line of Cassandra or MongoDB when dealing with > routing.
> > > > > > My 2 cents.
> > > > > > On Fri, Nov 30, 2012 at 12:53 AM, Chinmay Soman < > chinmay...@gmail.com> wrote: > > > > > > > wherever
> > -- > > You received this message because you are subscribed to the Google > Groups "project-voldemort" group. > > To unsubscribe from this group, send email to > project-voldem...@googlegroups.com <javascript:> (mailto: > project-voldemort+unsubscribe@googlegroups.com <javascript:>). > > Visit this group at > http://groups.google.com/group/project-voldemort?hl=en.
Yes, my proposal also "punts" on that and uses the existing multiple-versions API ( http 300 -- commonly used to let a user decide which language to display a multi-language website in: http://www.checkupdown.com/status/E300.html ) inside HTTP to deal with that. The server would then provide the thin client with URIs to the different conflicting conflicting version… -- if they just want to do "last write wins" they would only have to fetch the one with the latest timestamp, or they could fetch all, etc…
[ Slightly off topic, thinking out loud: ]
Tangential idea/random thought: if you assign a coordinator per partition using ZK and then serialize all writes to the quorum for that partition through that coordinator instance (as a configurable option, *NOT* the default setting, of course!), then (due to TCP ordering guarantees) would that means concurrent vector clocks are not possible? I think this is effectively an grossly over-simplified multi-Paxos/ZAB -- ZK leader election to select a coordinator for a partition is phase 1, writing to a quorum is phase 2, and epoch in this case is "until the ephemeral node gets deleted" -- so unless the coordinator dies, the cost of a write is just a single round trip (same as any quorum write).
This also means that each node is receiving writes in the same order.
On Tuesday, December 4, 2012 at 11:21 PM, Chinmay Soman wrote:
> Thanks Alex, I'll go through that proposal.
> Currently, the HTTP protocol is designed to return all the conflicting records with the resolution happening on the thin client side. We could technically also have the failure detection on the coordinator, if we're using the default mechanism. The only problem occurs with custom resolution which is difficult to manage / deploy on the coordinator.
> C
> On Tuesday, December 4, 2012 4:36:27 PM UTC-8, Alex Feinberg wrote:
> > + 1 server side routing makes deployments much easier. I like the implementation approach: using REST with a fast Netty based server to take care of both the REST API and the "thin client" / "server-side routing" project.
> > I'm afraid I'm a bit too late to the party to be of much use, but since you've mentioned REST: about a year ago, I've thought a bit of what a (polyglot) REST API for Voldemort could look like and wrote down the thoughts here:
> > My goal, however, was to see how much of the Voldemort protocol could simply be handled by HTTP alone (e.g., HTTP-300 for conflict resolution) -- which I am not certain is the right approach.
> > Thanks!
> > - af
> > --
> > Alex Feinberg
> > On Monday, December 3, 2012 at 11:05 PM, Chinmay Soman wrote:
> > > > > I'll keep this updated with the design specs, benchmarks and so on. Feel free to edit / comment on the same.
> > > > > Thank you for the patience !
> > > > > C
> > > > > On Saturday, December 1, 2012 12:41:45 AM UTC-8, Chinmay Soman wrote:
> > > > > > Its my task for this weekend to collate all the docs into a public wiki.
> > > > > > Btw, its not going to be one single machine as a single point of failure. You can choose to deploy a set of coordinators responsible for a single cluster. The benefits of separating the coordinator from the server nodes are not very obvious at this point. However it does make the deployment model and debugging very easy.
> > > > > > I figure we need a lot more benchmarking to figure out the right deployment.
> > > > > > On Friday, November 30, 2012 12:19:46 AM UTC-8, ctasada wrote:
> > > > > > > Hi Chinmay,
> > > > > > > Is there any documentation or GitHub fork to follow up the progress of this project? The idea of having a "Coordinator" to deal with all the routing logic is interesting. From my point of view, if I'm understanding it properly, it will simplify the whole codebase. It will allow to decide if the routing should be done in the client or the server side.
> > > > > > > I'm not in favor of having a separate machine to coordinate, because then we would introduce a "Single Point of Failure". I would prefer something more in the line of Cassandra or MongoDB when dealing with routing.
> > > > > > > My 2 cents.
> > > > > > > On Fri, Nov 30, 2012 at 12:53 AM, Chinmay Soman <chinmay...@gmail.com> wrote:
> > > > > > > > wherever
> > > --
> > > You received this message because you are subscribed to the Google Groups "project-voldemort" group.
> > > To unsubscribe from this group, send email to project-voldem...@googlegroups.com (javascript:) (mailto:project-voldemort+unsubscribe@googlegroups.com (javascript:)).
> > > Visit this group at http://groups.google.com/group/project-voldemort?hl=en.
> --
> You received this message because you are subscribed to the Google Groups "project-voldemort" group.
> To unsubscribe from this group, send email to project-voldemort+unsubscribe@googlegroups.com (mailto:project-voldemort+unsubscribe@googlegroups.com).
> Visit this group at http://groups.google.com/group/project-voldemort?hl=en.
