How to enable server side routing in java client?

[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?

[Felix.Xu]

Resolved, I've implemented a new client.

在 2012年10月31日星期三UTC+8下午5时03分26秒，Felix.Xu写道：

[Carlos Tasada]

Hi Felix,

If you can paste your solution here, it will help for future reference and help other Voldemort users.

Thanks.

--
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.
 
 

[Felix.Xu]

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写道：

[Carlos Tasada]

You can open an issue or a pull request in the GitHub Project.

--

[Lei Gao]

We are working on a 'thin client' implementatoin as we speak. It's discussed in more details in a separate thread:

https://groups.google.com/forum/?fromgroups=#!topic/project-voldemort/0W0OWSy_2MA

Chinmay leads that project. He is on vacation at the moment and will be back towards the end of Nov.  

Thanks,

Lei Gao

[Chinmay Soman]

 
 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).

[Carlos Tasada]

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

[Chinmay Soman]

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.

[Chinmay Soman]

I've created this project page for the thin client:

https://github.com/voldemort/voldemort/wiki/Voldemort-thin-client

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

[ctasada]

Looks great Chinmay!. 

Is there already some published code to check? ;)

[Chinmay Soman]

Its in my branch: 

https://github.com/icefury71/voldemort/tree/temp_coordinator_changes

There might be some cleanup necessary (which is why I havent pushed it in the voldemort repository as a branch).

[Alex Feinberg]

+ 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:

https://github.com/afeinberg/voldemort/wiki/REST-API-Proposal

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

> --
> 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 (mailto:project-voldem...@googlegroups.com).

[Chinmay Soman]

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

> To unsubscribe from this group, send email to project-voldem...@googlegroups.com (mailto:project-voldemort+unsub...@googlegroups.com).

[Alex Feinberg]

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.

Just a thought,

- af


--
Alex Feinberg

> > > To unsubscribe from this group, send email to project-voldem...@googlegroups.com (javascript:) (mailto:project-voldem...@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-voldem...@googlegroups.com (mailto:project-voldem...@googlegroups.com).