Auto-discover host manager

[GoogleCodeExporter]

In an effort to reduce the legwork necessary for client applications connecting 
to the Terrastore cluster, consider adding a host manager that can 
automatically discover the Terrastore server nodes at connection time.

This would be roughly equivalent to client application code that:

1) Establishes a connection to a single known-good Terrastore server.
2) Fetches the cluster statistics to get the list of all active servers.
3) Finally establishes a new connection for use by the application that is an 
OrderedHostManager (or something similar) populated with the full list of 
Terrastore servers.

Further consider enhancing the communication protocol to allow events to 
propagate to the client.  One such event may inform the client that a server 
has joined or left the cluster.  This could allow the client to dynamically add 
the server to its list.

Original issue reported on code.google.com by teonanac...@gmail.com on 21 Feb 2011 at 1:21

[GoogleCodeExporter]

Just a note on your last paragraph about events: I strongly disagree with such 
a kind of coupling between servers and clients; if we had to build "external" 
events, that is, events to be consumed by external parties, I would surely use 
a message queue for that.

That said, this is different from the auto-discovery, so we should open another 
issue for that.

Original comment by sergio.b...@gmail.com on 21 Feb 2011 at 6:27

[GoogleCodeExporter]

Sven, any comments about the auto-discovery host manager?

Original comment by sergio.b...@gmail.com on 21 Feb 2011 at 6:28

• Added labels: Type-Feature, Priority-Medium, Project-Terrastore-JavaClient

[GoogleCodeExporter]

Understood on the events; was just another idea.  :)

It could easily be approximated, anyway, by periodically querying the cluster 
status and acting accordingly on the client.

Original comment by teonanac...@gmail.com on 21 Feb 2011 at 6:33

[GoogleCodeExporter]

I think one more round of thought needs to go into this one before we give it a 
go.

I agree that external events to the client should not be part of the http 
protocol, but if we are going to do auto discovery I'd like to see that it's a 
bit more dynamic than just feeding the client with the currently running 
servers at the time that the client is created.

Although, forcing a JMS spec and implementation onto the users of the client 
just doesn't seem right to me either.

In the meantime, we could go for a much simpler solution:
The way the current OrderedHostManager works, is that it keeps using the server 
address at the top of the list until that server becomes unavailable, whereupon 
it moves that address to the bottom of the list and keeps going. 
Although we'll probably want to introduce a more advanced HostManager dealing 
with multiple servers sometime in the future, one way of dealing with the 
autodiscovery _now_ would be to have the AutoDiscoveryHostManager re-"discover" 
the lay of the land each time a server address is demoted to the bottom the 
list. 

On another note, a similar feature was suggested about 6 months ago, but was 
informally rejected for some reason. I thought it was a reasonable idea then, 
and I feel the same way now. 
I'll see if we can get some input from Martin, who suggesteed it back then.

Original comment by johansso...@gmail.com on 21 Feb 2011 at 8:41

[GoogleCodeExporter]

> In the meantime, we could go for a much simpler solution: [CUT]

I'm not sure to get what you mean.
I was thinking to setup the client with a seed server and poll the seed for 
cluster stats, then use them to automatically feed the client with other 
servers ... are you thinking about something different?

> On another note, a similar feature was suggested about 6 months ago, but was 
informally rejected for some reason.

Where did we discuss it?
I can't find it on the issue tracker ...

Original comment by sergio.b...@gmail.com on 21 Feb 2011 at 9:03

[GoogleCodeExporter]

The solution I'm trying to describe is a bit simpler than that. 
Every time a server address is demoted, as implemented in OrderedHostManager 
today, we'd not only switch to the next address in the list but also query that 
next server address for cluster stats and refresh the entire list.

No, last time the issue was raised it didn't happen in the issue tracker. 
Either on the discussion group or per private email. Don't recall.

Original comment by johansso...@gmail.com on 21 Feb 2011 at 9:12