Zen

Hi Shay,

we're interested in using Zen as the discovery mechanism for our services.
Rather than having yet another discovery mechanism, we'd quite like to reuse
Zen. Don't suppose you have any docs on how to use Zen outside elastic
search do you?

Thanks,

Paul.

--

Paul Loy
paul@keteracel.com

Not, not really... . Also, I have not invested a lot in making it completely
separated from elasticsearch, it is a module, but it depends on other
modules like the transport and so on, and it is tied to the cluster state
publishing of elasticsearch (though that can be separated out).

-shay.banon

On Tue, Jun 22, 2010 at 7:44 PM, Paul Loy keteracel@gmail.com wrote:

Hi Shay,

we're interested in using Zen as the discovery mechanism for our services.
Rather than having yet another discovery mechanism, we'd quite like to reuse
Zen. Don't suppose you have any docs on how to use Zen outside elastic
search do you?

Thanks,

Paul.

--

Paul Loy
paul@keteracel.com

By the way, another question, do you plan to use Zen with a running ES
cluster, and just want to know the state of the cluster more intimately? If
so, this is simpler to do.

-shay.banon

On Tue, Jun 22, 2010 at 11:04 PM, Shay Banon
shay.banon@elasticsearch.comwrote:

Not, not really... . Also, I have not invested a lot in making it
completely separated from elasticsearch, it is a module, but it depends on
other modules like the transport and so on, and it is tied to the cluster
state publishing of elasticsearch (though that can be separated out).

-shay.banon

On Tue, Jun 22, 2010 at 7:44 PM, Paul Loy keteracel@gmail.com wrote:

Hi Shay,

we're interested in using Zen as the discovery mechanism for our services.
Rather than having yet another discovery mechanism, we'd quite like to reuse
Zen. Don't suppose you have any docs on how to use Zen outside elastic
search do you?

Thanks,

Paul.

--

Paul Loy
paul@keteracel.com

That's very interesting. Basically we're using Gridgain as well as
Elasticsearch. Ideally we want to write a discovery SPI for Gridgain that
can use the same discovery instance as Elasticsearch so we are not
duplicating discovery chatter. If Zen emitted events, perhaps, then we could
just hook a custom GG discovery SPI into that.

Or we could just query Zen I suppose, but I like the idea of not doing
anything until something changes. Less Threads = good!

Thanks,

Paul.

On Wed, Jul 14, 2010 at 1:27 PM, Shay Banon shay.banon@elasticsearch.comwrote:

By the way, another question, do you plan to use Zen with a running ES
cluster, and just want to know the state of the cluster more intimately? If
so, this is simpler to do.

-shay.banon

On Tue, Jun 22, 2010 at 11:04 PM, Shay Banon <shay.banon@elasticsearch.com

wrote:

Not, not really... . Also, I have not invested a lot in making it
completely separated from elasticsearch, it is a module, but it depends on
other modules like the transport and so on, and it is tied to the cluster
state publishing of elasticsearch (though that can be separated out).

-shay.banon

On Tue, Jun 22, 2010 at 7:44 PM, Paul Loy keteracel@gmail.com wrote:

Hi Shay,

we're interested in using Zen as the discovery mechanism for our
services. Rather than having yet another discovery mechanism, we'd quite
like to reuse Zen. Don't suppose you have any docs on how to use Zen outside
Elasticsearch do you?

Thanks,

Paul.

--

Paul Loy
paul@keteracel.com

--

Paul Loy
paul@keteracel.com
http://www.keteracel.com/paul

Agreed. Its a bit low level, but here is something that you can do:

ClusterService clusterService = ((InternalNode)
node).injector().getInstance(ClusterService.class);
clusterService.add(new MyClusterEventListenre());

MyClusterEventListener implements ClusterStateEventListener {
public void clusterChanged(ClusterChangedEvent event) {
// work mainly with event.state().nodes(), and even.nodesDelta()
// NOTE: don't do anything time consuming on this thread! (like
IO calls or blocking)
}
}

You can add your listener after you build the node, but not start it, so you
will get all the events.

-shay.banon

On Wed, Jul 14, 2010 at 3:32 PM, Paul Loy keteracel@gmail.com wrote:

That's very interesting. Basically we're using Gridgain as well as
Elasticsearch. Ideally we want to write a discovery SPI for Gridgain that
can use the same discovery instance as Elasticsearch so we are not
duplicating discovery chatter. If Zen emitted events, perhaps, then we could
just hook a custom GG discovery SPI into that.

Or we could just query Zen I suppose, but I like the idea of not doing
anything until something changes. Less Threads = good!

Thanks,

Paul.

On Wed, Jul 14, 2010 at 1:27 PM, Shay Banon shay.banon@elasticsearch.comwrote:

By the way, another question, do you plan to use Zen with a running ES
cluster, and just want to know the state of the cluster more intimately? If
so, this is simpler to do.

-shay.banon

On Tue, Jun 22, 2010 at 11:04 PM, Shay Banon <
shay.banon@elasticsearch.com> wrote:

Not, not really... . Also, I have not invested a lot in making it
completely separated from elasticsearch, it is a module, but it depends on
other modules like the transport and so on, and it is tied to the cluster
state publishing of elasticsearch (though that can be separated out).

-shay.banon

On Tue, Jun 22, 2010 at 7:44 PM, Paul Loy keteracel@gmail.com wrote:

Hi Shay,

we're interested in using Zen as the discovery mechanism for our
services. Rather than having yet another discovery mechanism, we'd quite
like to reuse Zen. Don't suppose you have any docs on how to use Zen outside
Elasticsearch do you?

Thanks,

Paul.

--

Paul Loy
paul@keteracel.com

--

Paul Loy
paul@keteracel.com
http://www.keteracel.com/paul

Will give that a go.

Thanks.

On Wed, Jul 14, 2010 at 1:37 PM, Shay Banon shay.banon@elasticsearch.comwrote:

Agreed. Its a bit low level, but here is something that you can do:

ClusterService clusterService = ((InternalNode)
node).injector().getInstance(ClusterService.class);
clusterService.add(new MyClusterEventListenre());

MyClusterEventListener implements ClusterStateEventListener {
public void clusterChanged(ClusterChangedEvent event) {
// work mainly with event.state().nodes(), and even.nodesDelta()
// NOTE: don't do anything time consuming on this thread! (like
IO calls or blocking)
}
}

You can add your listener after you build the node, but not start it, so
you will get all the events.

-shay.banon

On Wed, Jul 14, 2010 at 3:32 PM, Paul Loy keteracel@gmail.com wrote:

That's very interesting. Basically we're using Gridgain as well as
Elasticsearch. Ideally we want to write a discovery SPI for Gridgain that
can use the same discovery instance as Elasticsearch so we are not
duplicating discovery chatter. If Zen emitted events, perhaps, then we could
just hook a custom GG discovery SPI into that.

Or we could just query Zen I suppose, but I like the idea of not doing
anything until something changes. Less Threads = good!

Thanks,

Paul.

On Wed, Jul 14, 2010 at 1:27 PM, Shay Banon <shay.banon@elasticsearch.com

wrote:

By the way, another question, do you plan to use Zen with a running ES
cluster, and just want to know the state of the cluster more intimately? If
so, this is simpler to do.

-shay.banon

On Tue, Jun 22, 2010 at 11:04 PM, Shay Banon <
shay.banon@elasticsearch.com> wrote:

Not, not really... . Also, I have not invested a lot in making it
completely separated from elasticsearch, it is a module, but it depends on
other modules like the transport and so on, and it is tied to the cluster
state publishing of elasticsearch (though that can be separated out).

-shay.banon

On Tue, Jun 22, 2010 at 7:44 PM, Paul Loy keteracel@gmail.com wrote:

Hi Shay,

we're interested in using Zen as the discovery mechanism for our
services. Rather than having yet another discovery mechanism, we'd quite
like to reuse Zen. Don't suppose you have any docs on how to use Zen outside
Elasticsearch do you?

Thanks,

Paul.

--

Paul Loy
paul@keteracel.com

--

Paul Loy
paul@keteracel.com
http://www.keteracel.com/paul

--

Paul Loy
paul@keteracel.com
http://www.keteracel.com/paul