You can check the shard routing changes to know when a shard changed its routing state. Check the different APIs implementations that go and operate on other nodes (for example, the count API). There is no support for pushing changes from the server to the client, _changes would be implemented as a pull option.
Check the mailing list history, I wrote a bit on what and possibly how a changes API would work.
On Wednesday, February 29, 2012 at 5:48 PM, Thomas Peuss wrote:
On 29 Feb., 14:51, Shay Banon <kim...@gmail.com (http://gmail.com)> wrote:
Heya, looks interesting. A had a quick look at the implementation, note that shards can move to a primary mode, and in this case, the tracking code won't happen. This is not how I would implement _changes (in memory circular buffer), but I can see where it might fit certain scenarios.
First of all I know that this plugin is far from beeing finished. I
just followed the mantra "release early".
How would I notice that a shard moves to primary mode? Is there an
event I can catch?
How would you do it? Suggestions are more then welcome!
This is my first deeper contact with the ES codebase and it is IMHO
quite hard to understand how objects and services should be used (or
meant to be used). One thing I do not understand is how I should
contact the other nodes in the cluster to collect their changes.
Another functionality that is missing currently because I do not know
how to do it is the following:
The connection is kept open and all changes that are detected get
pushed out to the client until the client closes the connection. I
have found no notion of a "streaming" response.