Solr
  1. Solr
  2. SOLR-844

A SolrServer impl to front-end multiple urls

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.3
    • Fix Version/s: 1.4
    • Component/s: clients - java
    • Labels:
      None

      Description

      Currently a CommonsHttpSolrServer can talk to only one server. This demands that the user have a LoadBalancer or do the roundrobin on their own. We must have a LBHttpSolrServer which must automatically do a Loadbalancing between multiple hosts. This can be backed by the CommonsHttpSolrServer

      This can have the following other features

      • Automatic failover
      • Optionally take in a file /url containing the the urls of servers so that the server list can be automatically updated by periodically loading the config
      • Support for adding removing servers during runtime
      • Pluggable Loadbalancing mechanism. (round-robin, weighted round-robin, random etc)
      • Pluggable Failover mechanisms
      1. SOLR-844.patch
        2 kB
        Noble Paul
      2. SOLR-844.patch
        19 kB
        Shalin Shekhar Mangar
      3. SOLR-844.patch
        16 kB
        Noble Paul
      4. SOLR-844.patch
        16 kB
        Noble Paul
      5. SOLR-844.patch
        13 kB
        Noble Paul
      6. SOLR-844.patch
        13 kB
        Noble Paul
      7. SOLR-844.patch
        7 kB
        Noble Paul
      8. SOLR-844.patch
        7 kB
        Noble Paul

        Activity

        Hide
        Yonik Seeley added a comment -

        Thanks Jason, I just committed a fix for this that changed it to milliseconds.

        Show
        Yonik Seeley added a comment - Thanks Jason, I just committed a fix for this that changed it to milliseconds.
        Hide
        Jason Falk added a comment -

        There seems to be an issue here with the check interval. The documentation and even the default value assume that the check interval is measured in milliseconds, when in fact the code below has the TimeUnit as seconds.

        getAliveCheckRunner(new WeakReference<LBHttpSolrServer>(this)), this.interval, this.interval, TimeUnit.SECONDS);

        So basically right now the check interval is 60,000 seconds...yikes.

        Show
        Jason Falk added a comment - There seems to be an issue here with the check interval. The documentation and even the default value assume that the check interval is measured in milliseconds, when in fact the code below has the TimeUnit as seconds. getAliveCheckRunner(new WeakReference<LBHttpSolrServer>(this)), this.interval, this.interval, TimeUnit.SECONDS); So basically right now the check interval is 60,000 seconds...yikes.
        Hide
        Shalin Shekhar Mangar added a comment -

        Committed revision 765912.

        Show
        Shalin Shekhar Mangar added a comment - Committed revision 765912.
        Hide
        Noble Paul added a comment -

        a bug fix as reported by a user

        http://markmail.org/thread/bvysveoibqcndj4n

        Show
        Noble Paul added a comment - a bug fix as reported by a user http://markmail.org/thread/bvysveoibqcndj4n
        Hide
        Shalin Shekhar Mangar added a comment -

        LBHttpSolrServer had the wrong import of SolrException which was causing compile failures when running tests through ant build file.

        Committed revision 756682.

        Show
        Shalin Shekhar Mangar added a comment - LBHttpSolrServer had the wrong import of SolrException which was causing compile failures when running tests through ant build file. Committed revision 756682.
        Hide
        Shalin Shekhar Mangar added a comment -

        Committed revision 756381.

        Thanks to everybody who contributed!

        Show
        Shalin Shekhar Mangar added a comment - Committed revision 756381. Thanks to everybody who contributed!
        Hide
        Shalin Shekhar Mangar added a comment -

        Changes

        1. Javadoc updated to say about load balancing strategy, which failures mark a server to be a failure, how do they come back up and other alternatives to this class
        2. Changed locking – all places where the two lists are modified are placed inside a lock, the reads are not locked
        3. It uses the exception thrown by CommonsHttpSolrServer to detect when to mark server as dead
        Show
        Shalin Shekhar Mangar added a comment - Changes Javadoc updated to say about load balancing strategy, which failures mark a server to be a failure, how do they come back up and other alternatives to this class Changed locking – all places where the two lists are modified are placed inside a lock, the reads are not locked It uses the exception thrown by CommonsHttpSolrServer to detect when to mark server as dead
        Hide
        Noble Paul added a comment -

        #implementation changed to do the pings in a separate thread. This keeps the code simple

        1. javadocs added
        Show
        Noble Paul added a comment - #implementation changed to do the pings in a separate thread. This keeps the code simple javadocs added
        Hide
        Hoss Man added a comment -

        I still think the javadocs should be beefed up a bit... at a minimum the info from "When to use this ?", "How does the Load Balancing happen ?", and "How does it know if a server has come back up ?" sections of the wiki page Noble made should be in the class level javadocs ... some of the "How does it know..." info made it into the javadocs for setAliveCheckInterval, but considering how important that method is there should be a ref to it in the class docs – and there definitely needs to be some explicit mention of the "The ping is done not in a separate thread, it is done in a thread which made a normal request." fact, i would never have guessed that looking at the public docs in the class.

        And as I mentioned before: if there are concerns that this class will be misused (and it certainly seems like there are) then it really needs to contain javadocs explaining when it doesn't make sense to use it and some alternative suggestions (if nothing else, a link to wikipedia: http://en.wikipedia.org/wiki/Load_balancing_(computing))

        Show
        Hoss Man added a comment - I still think the javadocs should be beefed up a bit... at a minimum the info from "When to use this ?", "How does the Load Balancing happen ?", and "How does it know if a server has come back up ?" sections of the wiki page Noble made should be in the class level javadocs ... some of the "How does it know..." info made it into the javadocs for setAliveCheckInterval, but considering how important that method is there should be a ref to it in the class docs – and there definitely needs to be some explicit mention of the "The ping is done not in a separate thread, it is done in a thread which made a normal request." fact, i would never have guessed that looking at the public docs in the class. And as I mentioned before: if there are concerns that this class will be misused (and it certainly seems like there are) then it really needs to contain javadocs explaining when it doesn't make sense to use it and some alternative suggestions (if nothing else, a link to wikipedia: http://en.wikipedia.org/wiki/Load_balancing_(computing) )
        Hide
        Shalin Shekhar Mangar added a comment -

        So what's the verdict on this one? Seems like most concerns were taken care of. Anything else we should do to get this committed?

        Show
        Shalin Shekhar Mangar added a comment - So what's the verdict on this one? Seems like most concerns were taken care of. Anything else we should do to get this committed?
        Hide
        Shalin Shekhar Mangar added a comment -

        Hoss, did you get a chance to see the latest patch?

        Show
        Shalin Shekhar Mangar added a comment - Hoss, did you get a chance to see the latest patch?
        Hide
        Noble Paul added a comment -

        Same patch with javadocs

        Show
        Noble Paul added a comment - Same patch with javadocs
        Hide
        Hoss Man added a comment -

        A wiki page is added here: http://wiki.apache.org/solr/LBHttpSolrServer

        Actually i was referring to a need for javadoc comments in the class since there are none in the current patch.

        the wiki and/or static pages like hte tutorial make sense for features all users need to be aware of, but when we're talking about solrj code that java apps will explicitly compile against there isreally no substitute for good package, class, and method level javadocs.

        Show
        Hoss Man added a comment - A wiki page is added here: http://wiki.apache.org/solr/LBHttpSolrServer Actually i was referring to a need for javadoc comments in the class since there are none in the current patch. the wiki and/or static pages like hte tutorial make sense for features all users need to be aware of, but when we're talking about solrj code that java apps will explicitly compile against there isreally no substitute for good package, class, and method level javadocs.
        Hide
        Otis Gospodnetic added a comment -

        Good comment from Wunder's made on the ML:

        This would be useful if there was search-specific balancing,
        like always send the same query back to the same server. That
        can make your cache far more effective.

        wunder

        Show
        Otis Gospodnetic added a comment - Good comment from Wunder's made on the ML: This would be useful if there was search-specific balancing, like always send the same query back to the same server. That can make your cache far more effective. wunder
        Hide
        Noble Paul added a comment - - edited

        Hoss. Thanks

        If the behavior of this class can be documented in a straight forward way (spelling out both success and failure cases)...

        A wiki page is added here: http://wiki.apache.org/solr/LBHttpSolrServer

        Show
        Noble Paul added a comment - - edited Hoss. Thanks If the behavior of this class can be documented in a straight forward way (spelling out both success and failure cases)... A wiki page is added here: http://wiki.apache.org/solr/LBHttpSolrServer
        Hide
        Hoss Man added a comment -

        i haven't reviewed the technical merits of hte patch, but on the subject of the idea...

        In general i agree with ian/otis: functionality like this could very easily be abused/missued by novice users who may not realize that more robust solutions may be out there and can be just as easy to setup. That said: any code that does what it's documentation says it does is going to be use to someone.

        my concern with the patch as written is that it doesn't have any documentation explaining what it does, or what the caveats are to useing it (ie: how it behaves in failure cases, what approach it takes to blanacing load, etc...) so it won't be clear to people when/if it fits their use cases.

        The "Hits" class in Lucene-Java is a great example of code whose existence tended to do more harm then good – it was a simple API that was easy to use, but the implementation had a lot of "gotchas" that were hidden behind a black box and were too complicated to document cleanly for novice users; many people who used it ran into performance problems or problemswith closed IndexSearchers and came away with a bad impression of Lucene. ... we just need to make sure we don't make more mistakes like that with convinienceclasses and "simple" APIs for hard problems.

        If the behavior of this class can be documented in a straight forward way (spelling out both success and failure cases) as well as when it doesn't make sense to use it, then i see no reason not to commit. (I'm assuming of course that the code actually works)

        However....

        I'm curious as to whether or not anyone has done any research into existing java libraries that implement http load balancing. (I assume someone somewhere has implemented a generic wrapper/plugin for HttpCLient that does this already ... it's just a question of if it's OpenSource with a freindly liscence for us to link against)

        Show
        Hoss Man added a comment - i haven't reviewed the technical merits of hte patch, but on the subject of the idea ... In general i agree with ian/otis: functionality like this could very easily be abused/missued by novice users who may not realize that more robust solutions may be out there and can be just as easy to setup. That said: any code that does what it's documentation says it does is going to be use to someone. my concern with the patch as written is that it doesn't have any documentation explaining what it does, or what the caveats are to useing it (ie: how it behaves in failure cases, what approach it takes to blanacing load, etc...) so it won't be clear to people when/if it fits their use cases. The "Hits" class in Lucene-Java is a great example of code whose existence tended to do more harm then good – it was a simple API that was easy to use, but the implementation had a lot of "gotchas" that were hidden behind a black box and were too complicated to document cleanly for novice users; many people who used it ran into performance problems or problemswith closed IndexSearchers and came away with a bad impression of Lucene. ... we just need to make sure we don't make more mistakes like that with convinienceclasses and "simple" APIs for hard problems. If the behavior of this class can be documented in a straight forward way (spelling out both success and failure cases) as well as when it doesn't make sense to use it, then i see no reason not to commit. (I'm assuming of course that the code actually works) However.... I'm curious as to whether or not anyone has done any research into existing java libraries that implement http load balancing. (I assume someone somewhere has implemented a generic wrapper/plugin for HttpCLient that does this already ... it's just a question of if it's OpenSource with a freindly liscence for us to link against)
        Hide
        Noble Paul added a comment -

        One quick fix needed: if (size < 1) new SolrServerException("No more SolrServers alive");

        oops. nice catch . It should have been

        throw new SolrServerException("No more SolrServers alive");
        
        Show
        Noble Paul added a comment - One quick fix needed: if (size < 1) new SolrServerException("No more SolrServers alive"); oops. nice catch . It should have been throw new SolrServerException( "No more SolrServers alive" );
        Hide
        Mark Miller added a comment -

        I'd like to look at it closer, but I havn't had a chance yet.

        One quick fix needed: if (size < 1) new SolrServerException("No more SolrServers alive");

        Missing the return in front of new.

        • Mark
        Show
        Mark Miller added a comment - I'd like to look at it closer, but I havn't had a chance yet. One quick fix needed: if (size < 1) new SolrServerException("No more SolrServers alive"); Missing the return in front of new. Mark
        Hide
        Shalin Shekhar Mangar added a comment -

        Mark, did you get a chance to look at the new patch?

        Overall, I'd like to see some more reactions on the idea/patch. I think it is a good idea and ground work for more advanced functionalities.

        Show
        Shalin Shekhar Mangar added a comment - Mark, did you get a chance to look at the new patch? Overall, I'd like to see some more reactions on the idea/patch. I think it is a good idea and ground work for more advanced functionalities.
        Hide
        Noble Paul added a comment -

        If you are using that lock pretty much everywhere anyway, why use a thread safe list?

        The lock is used to ensure that only one thread does a check for isAlive at any given point in time. So all the variables which are modified during that is threadsafe.

        Show
        Noble Paul added a comment - If you are using that lock pretty much everywhere anyway, why use a thread safe list? The lock is used to ensure that only one thread does a check for isAlive at any given point in time. So all the variables which are modified during that is threadsafe.
        Hide
        Noble Paul added a comment -

        some bugs were fixed (missing lock.unLock())

        Show
        Noble Paul added a comment - some bugs were fixed (missing lock.unLock())
        Hide
        Mark Miller added a comment -

        I am not convinced its right though. If you are using that lock pretty much everywhere anyway, why use a thread safe list? Something doesnt quite jive with me - I'll let others take a look and decide though. I see that locking is done both with the lock and in one place the synchronize keyword. I think something is off myself. I havn't spent a lot of time, so perhaps it works, but I think a more standard treatment would be better for code maintainability.

        Show
        Mark Miller added a comment - I am not convinced its right though. If you are using that lock pretty much everywhere anyway, why use a thread safe list? Something doesnt quite jive with me - I'll let others take a look and decide though. I see that locking is done both with the lock and in one place the synchronize keyword. I think something is off myself. I havn't spent a lot of time, so perhaps it works, but I think a more standard treatment would be better for code maintainability.
        Hide
        Noble Paul added a comment -

        Hi Mark, thanks

        I am in no hurry in getting this committed. I am just trying to raise opinions from other committers/users.

        For instance, you access isEmpty on a shared variable, then get the lock and access the shared variable

        The Object in question is a threadsafe object (CopyOnWriteArrayList) so I believe it should not hurt.

        Show
        Noble Paul added a comment - Hi Mark, thanks I am in no hurry in getting this committed. I am just trying to raise opinions from other committers/users. For instance, you access isEmpty on a shared variable, then get the lock and access the shared variable The Object in question is a threadsafe object (CopyOnWriteArrayList) so I believe it should not hurt.
        Hide
        Mark Miller added a comment -

        I think your missing Otis' point Noble. He is not dismissing this patch on its technical or useful merits. Hes pointing out that a couple of people have voiced skepticism and no one has voted for the issue. When thats the case, its not normal to put the issue in without more discussion. Which is what is happening, but I don't think your arguments alone should get the code committed. Rather, after you have expressed your arguments, we wait for votes, or more input. A couple people seem like they like the idea as well, but that info has just started coming, so lets let it play out a little before committing.

        My opinion:

        My initial thought was negative as well, for the obvious reasons. However, its such a simple thing (at least for this basic support), improves efficiency a bit, and could be a lot easier for a solr user to setup than a load balancer they don't know. I think I am a +1 myself.

        On the patch: I havn't spent a lot of time looking at it, but I think its best practice to only access shared variables within the lock. For instance, you access isEmpty on a shared variable, then get the lock and access the shared variable. I realize you want to save the lock cost, but if you need the lock, you shouldn't do that.

        • Mark
        Show
        Mark Miller added a comment - I think your missing Otis' point Noble. He is not dismissing this patch on its technical or useful merits. Hes pointing out that a couple of people have voiced skepticism and no one has voted for the issue. When thats the case, its not normal to put the issue in without more discussion. Which is what is happening, but I don't think your arguments alone should get the code committed. Rather, after you have expressed your arguments, we wait for votes, or more input. A couple people seem like they like the idea as well, but that info has just started coming, so lets let it play out a little before committing. My opinion: My initial thought was negative as well, for the obvious reasons. However, its such a simple thing (at least for this basic support), improves efficiency a bit, and could be a lot easier for a solr user to setup than a load balancer they don't know. I think I am a +1 myself. On the patch: I havn't spent a lot of time looking at it, but I think its best practice to only access shared variables within the lock. For instance, you access isEmpty on a shared variable, then get the lock and access the shared variable. I realize you want to save the lock cost, but if you need the lock, you shouldn't do that. Mark
        Hide
        Noble Paul added a comment -

        I'm not sure there is a clear consensus about this functionality being a good thing

        This is not a Solr functionality. This is an external feature. Solr is agnostic about it.

        Most of our users use Solr with an external LoadBalancer. It does not mean that that is the best solution always. They do it because that is the only way .We are trying to offer a choice.

        A very good comparison would be memcached client . It does load balancing at the client side . I have copied some ideas from there too. I have already mentioned the example of mysql.

        The problems with the existing solutions is that there is no automatic failover. This implementation has it.

        Show
        Noble Paul added a comment - I'm not sure there is a clear consensus about this functionality being a good thing This is not a Solr functionality. This is an external feature. Solr is agnostic about it. Most of our users use Solr with an external LoadBalancer. It does not mean that that is the best solution always. They do it because that is the only way .We are trying to offer a choice. A very good comparison would be memcached client . It does load balancing at the client side . I have copied some ideas from there too. I have already mentioned the example of mysql. The problems with the existing solutions is that there is no automatic failover. This implementation has it.
        Hide
        Shalin Shekhar Mangar added a comment - - edited

        Walter Underwood on solr-dev:

        This would be useful if there was search-specific balancing, like always send the same query back to the same server. That can make your cache far more effective.

        That is an interesting thought. Right now Solrj does not have the means to construct the Query/Filter objects which are used as the key for the Solr caches. Let us try to figure out if/how it can be implemented.

        I'm not sure there is a clear consensus about this functionality being a good thing (also 0 votes). Perhaps we can get more people's opinions?

        Yes Otis. That is exactly what I wanted to do with my comment

        I guess most people think that this is a solved problem and I agree. Solr has always required users to have load balancers and I guess our users have come to accept it. But if you look at the new distributed systems being developed (Katta/Bailey/CouchDB/Voldemort, etc.), almost none of them assume an external load balancer or fail over system in their design. If they do, external systems are made optional (Voldemort). Right now we force people to use and maintain an external system if they have a Solr master/slave architecture. Apache and mod_proxy_balancer are great but have a higher latency than hardware based load balancers and these are not cheap.

        The current patch is very simple. However, better ways to handle configuration and load balancing can be added. I think this can be a good starting point for the Solr 2.0 proposals. Unfortunately, very few of us have time to implement all of the proposals in a big bang way. But if we focus on one issue at a time, we will get somewhere close sooner. This might not be the code which ends up in Solr 2.0 but I think it can provide a good transition path.

        Thoughts?

        Show
        Shalin Shekhar Mangar added a comment - - edited Walter Underwood on solr-dev: This would be useful if there was search-specific balancing, like always send the same query back to the same server. That can make your cache far more effective. That is an interesting thought. Right now Solrj does not have the means to construct the Query/Filter objects which are used as the key for the Solr caches. Let us try to figure out if/how it can be implemented. I'm not sure there is a clear consensus about this functionality being a good thing (also 0 votes). Perhaps we can get more people's opinions? Yes Otis. That is exactly what I wanted to do with my comment I guess most people think that this is a solved problem and I agree. Solr has always required users to have load balancers and I guess our users have come to accept it. But if you look at the new distributed systems being developed (Katta/Bailey/CouchDB/Voldemort, etc.), almost none of them assume an external load balancer or fail over system in their design. If they do, external systems are made optional (Voldemort). Right now we force people to use and maintain an external system if they have a Solr master/slave architecture. Apache and mod_proxy_balancer are great but have a higher latency than hardware based load balancers and these are not cheap. The current patch is very simple. However, better ways to handle configuration and load balancing can be added. I think this can be a good starting point for the Solr 2.0 proposals. Unfortunately, very few of us have time to implement all of the proposals in a big bang way. But if we focus on one issue at a time, we will get somewhere close sooner. This might not be the code which ends up in Solr 2.0 but I think it can provide a good transition path. Thoughts?
        Hide
        Otis Gospodnetic added a comment - - edited

        I'm not sure there is a clear consensus about this functionality being a good thing (also 0 votes). Perhaps we can get more people's opinions?

        Show
        Otis Gospodnetic added a comment - - edited I'm not sure there is a clear consensus about this functionality being a good thing (also 0 votes). Perhaps we can get more people's opinions?
        Hide
        Shalin Shekhar Mangar added a comment -

        Guys, are there any objections in committing this to trunk? If not, I'd like to go over the patch and commit it in a few days. I don't think this needs to go to a separate contrib since it is such a small piece of code and doesn't have any extra dependencies.

        Show
        Shalin Shekhar Mangar added a comment - Guys, are there any objections in committing this to trunk? If not, I'd like to go over the patch and commit it in a few days. I don't think this needs to go to a separate contrib since it is such a small piece of code and doesn't have any extra dependencies.
        Hide
        Noble Paul added a comment -

        with a test case and a few fixes

        Show
        Noble Paul added a comment - with a test case and a few fixes
        Hide
        Noble Paul added a comment -

        The distributed searcher could have an option that returns the shard set. A Solr client library could run the distributed search/merge and return that to its calling app.

        Do you mean to say that the client library must handle the distributed search?
        That may not be a good idea.

        Anyway, here's a use case for load balancing...

        Is it a point against this or for this?

        Show
        Noble Paul added a comment - The distributed searcher could have an option that returns the shard set. A Solr client library could run the distributed search/merge and return that to its calling app. Do you mean to say that the client library must handle the distributed search? That may not be a good idea. Anyway, here's a use case for load balancing... Is it a point against this or for this?
        Hide
        Lance Norskog added a comment -

        Concur with dubious reaction. However, what you mention about multiple hops is a valid point.

        The distributed searcher could have an option that returns the shard set. A Solr client library could run the distributed search/merge and return that to its calling app. A similar list of active "all-in-one" servers could also be handed back to this mythical client library.

        Anyway, here's a use case for load balancing: we wanted to take a server out of the load balancer, rewarm its caches, then put it back in the balancer.

        Show
        Lance Norskog added a comment - Concur with dubious reaction. However, what you mention about multiple hops is a valid point. The distributed searcher could have an option that returns the shard set. A Solr client library could run the distributed search/merge and return that to its calling app. A similar list of active "all-in-one" servers could also be handed back to this mythical client library. Anyway, here's a use case for load balancing: we wanted to take a server out of the load balancer, rewarm its caches, then put it back in the balancer.
        Hide
        Noble Paul added a comment -

        there were a few bugs

        Show
        Noble Paul added a comment - there were a few bugs
        Hide
        Noble Paul added a comment - - edited

        A simple round-robin based implementtaion. Keeps two lists of servers live and dead. If a request to a server fails it is added to the list of dead servers.

        Periodically (once in a minute) the dead servers are pinged to find if they are up again. The ping is done in a thread which makes a normal request. A thread checks only one server

        Needs another ConfigLBHttpSolrServer which can be driven from a config file (local/http)

        Show
        Noble Paul added a comment - - edited A simple round-robin based implementtaion. Keeps two lists of servers live and dead. If a request to a server fails it is added to the list of dead servers. Periodically (once in a minute) the dead servers are pinged to find if they are up again. The ping is done in a thread which makes a normal request. A thread checks only one server Needs another ConfigLBHttpSolrServer which can be driven from a config file (local/http)
        Hide
        Noble Paul added a comment -

        no probs.
        I'm sure that we do not use that internally , but there may be users who would find it useful. (one man's meat is another man's poison)

        Another use case is distributed search. Do we really want to have an extra hop (Loadbalancer) for a shard to communicate to other shards? That is a few dozen requests per client request . How many LoadBalancers would we need to handle such load?

        Is it big enough to merit a contrib package for itself?. Maybe.

        Show
        Noble Paul added a comment - no probs. I'm sure that we do not use that internally , but there may be users who would find it useful. (one man's meat is another man's poison) Another use case is distributed search. Do we really want to have an extra hop (Loadbalancer) for a shard to communicate to other shards? That is a few dozen requests per client request . How many LoadBalancers would we need to handle such load? Is it big enough to merit a contrib package for itself?. Maybe.
        Hide
        Otis Gospodnetic added a comment -

        I had a similar reaction as Ian.
        If we decide we really need this, I wonder if it can be made a contrib instead of living in the core.

        Show
        Otis Gospodnetic added a comment - I had a similar reaction as Ian. If we decide we really need this, I wonder if it can be made a contrib instead of living in the core.
        Hide
        Noble Paul added a comment -

        Firstly there are about a thousand ways you can handle load balancing already out there on the backend side (both hardware and software)

        Yes , But each extra layer introduces its own overhead. (in latency , hardware and maintenance). Moreover we are introducing a single point of failure.

        This is similar to a MySql driver providing a feature to connect to multiple servers (maters/slaves) . it does round-robin at the driver side and provide automatic failover. http://dev.mysql.com/doc/refman/5.0/en/connector-j-reference-replication-connection.html

        Secondly doing it on the client side means you will need to track ALL the clients who use your service

        Let us discuss how best this can be handled. This is just an extension of what we already have , (a thin wrapper).

        Show
        Noble Paul added a comment - Firstly there are about a thousand ways you can handle load balancing already out there on the backend side (both hardware and software) Yes , But each extra layer introduces its own overhead. (in latency , hardware and maintenance). Moreover we are introducing a single point of failure. This is similar to a MySql driver providing a feature to connect to multiple servers (maters/slaves) . it does round-robin at the driver side and provide automatic failover. http://dev.mysql.com/doc/refman/5.0/en/connector-j-reference-replication-connection.html Secondly doing it on the client side means you will need to track ALL the clients who use your service Let us discuss how best this can be handled. This is just an extension of what we already have , (a thin wrapper).
        Hide
        Ian Holsman added a comment -

        your opening a can of worms in this one Noble.

        Firstly there are about a thousand ways you can handle load balancing already out there on the backend side (both hardware and software). you can achieve what you want today by using the apache webserver and mod_proxy_balancer - http://httpd.apache.org/docs/2.2/mod/mod_proxy_balancer.html

        Secondly doing it on the client side means you will need to track ALL the clients who use your service. I don't think the URL config thing won't work well in practice.

        Thirdly load balancing isn't easy. I've had the joy of debugging load balancing errors and outages, and wouldn't want to have to go through that again

        Show
        Ian Holsman added a comment - your opening a can of worms in this one Noble. Firstly there are about a thousand ways you can handle load balancing already out there on the backend side (both hardware and software). you can achieve what you want today by using the apache webserver and mod_proxy_balancer - http://httpd.apache.org/docs/2.2/mod/mod_proxy_balancer.html Secondly doing it on the client side means you will need to track ALL the clients who use your service. I don't think the URL config thing won't work well in practice. Thirdly load balancing isn't easy. I've had the joy of debugging load balancing errors and outages, and wouldn't want to have to go through that again

          People

          • Assignee:
            Shalin Shekhar Mangar
            Reporter:
            Noble Paul
          • Votes:
            1 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development