Let's imaging you have 3 ES nodes. When using NEST I can only connect to
one node. So what happens when that node goes down? Isn't that a single
point of failure?
Have you got any concrete plans on releasing an official .NET client?
And if not, are you aware of any .NET client that "play nicely with the
cluster", ie. handle node failure and is generally cluster-aware?
Thanks,
Lasse
--
You received this message because you are subscribed to the Google Groups
"elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to elasticsearch+unsubscribe@googlegroups.com.
It's fairly easy to implement a pool of Connection objects (or however they
called, can't remember now) and switch between them. I agree having a
TransportClient-like implementation where the client is able to failover to
the next node in the list is nice, but as I said its fairly easy to do from
a wrapper. I would also assume this should be easy to implement in the
core, will look at it sometime soon.
Let's imaging you have 3 ES nodes. When using NEST I can only connect to
one node. So what happens when that node goes down? Isn't that a single
point of failure?
Have you got any concrete plans on releasing an official .NET client?
And if not, are you aware of any .NET client that "play nicely with the
cluster", ie. handle node failure and is generally cluster-aware?
Thanks,
Lasse
--
You received this message because you are subscribed to the Google
Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to elasticsearch+unsubscribe@googlegroups.com.
The optimal solution would be to configure the NEST client with IP
addresses to the nodes, and then let NEST deal with all connection tasks,
including removing a dead node from the connection list and re-adding it.
I know it's always a discussion about where to put this functionality, but
take a look at how Couchbase's clients handle this. Very easy to use, and
abstracts the cluster/node-awareness away from the developer.
It's fairly easy to implement a pool of Connection objects (or however
they called, can't remember now) and switch between them. I agree having a
TransportClient-like implementation where the client is able to failover to
the next node in the list is nice, but as I said its fairly easy to do from
a wrapper. I would also assume this should be easy to implement in the
core, will look at it sometime soon.
Let's imaging you have 3 ES nodes. When using NEST I can only connect to
one node. So what happens when that node goes down? Isn't that a single
point of failure?
Have you got any concrete plans on releasing an official .NET client?
And if not, are you aware of any .NET client that "play nicely with the
cluster", ie. handle node failure and is generally cluster-aware?
Thanks,
Lasse
--
You received this message because you are subscribed to the Google
Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to elasticsearch+unsubscribe@googlegroups.com.
Yes, as I said it would be nice to have this within NEST like
Elasticsearch's TransportClient works, but as long as it isn't implemented
it is very easy to do so I wouldn't consider it a show stopper
The optimal solution would be to configure the NEST client with IP
addresses to the nodes, and then let NEST deal with all connection tasks,
including removing a dead node from the connection list and re-adding it.
I know it's always a discussion about where to put this functionality, but
take a look at how Couchbase's clients handle this. Very easy to use, and
abstracts the cluster/node-awareness away from the developer.
It's fairly easy to implement a pool of Connection objects (or however
they called, can't remember now) and switch between them. I agree having a
TransportClient-like implementation where the client is able to failover to
the next node in the list is nice, but as I said its fairly easy to do from
a wrapper. I would also assume this should be easy to implement in the
core, will look at it sometime soon.
Let's imaging you have 3 ES nodes. When using NEST I can only connect to
one node. So what happens when that node goes down? Isn't that a single
point of failure?
Have you got any concrete plans on releasing an official .NET client?
And if not, are you aware of any .NET client that "play nicely with
the cluster", ie. handle node failure and is generally cluster-aware?
Thanks,
Lasse
--
You received this message because you are subscribed to the Google
Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to elasticsearch+unsubscribe@googlegroups.com.
Yes, as I said it would be nice to have this within NEST like
Elasticsearch's TransportClient works, but as long as it isn't implemented
it is very easy to do so I wouldn't consider it a show stopper
The optimal solution would be to configure the NEST client with IP
addresses to the nodes, and then let NEST deal with all connection tasks,
including removing a dead node from the connection list and re-adding it.
I know it's always a discussion about where to put this functionality,
but take a look at how Couchbase's clients handle this. Very easy to use,
and abstracts the cluster/node-awareness away from the developer.
It's fairly easy to implement a pool of Connection objects (or however
they called, can't remember now) and switch between them. I agree having a
TransportClient-like implementation where the client is able to failover to
the next node in the list is nice, but as I said its fairly easy to do from
a wrapper. I would also assume this should be easy to implement in the
core, will look at it sometime soon.
Let's imaging you have 3 ES nodes. When using NEST I can only connect
to one node. So what happens when that node goes down? Isn't that a single
point of failure?
Have you got any concrete plans on releasing an official .NET client?
And if not, are you aware of any .NET client that "play nicely with
the cluster", ie. handle node failure and is generally cluster-aware?
Thanks,
Lasse
--
You received this message because you are subscribed to the Google
Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to elasticsearch+unsubscribe@googlegroups.com.
Yes, as I said it would be nice to have this within NEST like
Elasticsearch's TransportClient works, but as long as it isn't implemented
it is very easy to do so I wouldn't consider it a show stopper
The optimal solution would be to configure the NEST client with IP
addresses to the nodes, and then let NEST deal with all connection tasks,
including removing a dead node from the connection list and re-adding it.
I know it's always a discussion about where to put this functionality,
but take a look at how Couchbase's clients handle this. Very easy to use,
and abstracts the cluster/node-awareness away from the developer.
It's fairly easy to implement a pool of Connection objects (or however
they called, can't remember now) and switch between them. I agree having a
TransportClient-like implementation where the client is able to failover to
the next node in the list is nice, but as I said its fairly easy to do from
a wrapper. I would also assume this should be easy to implement in the
core, will look at it sometime soon.
Let's imaging you have 3 ES nodes. When using NEST I can only connect
to one node. So what happens when that node goes down? Isn't that a single
point of failure?
Have you got any concrete plans on releasing an official .NET
client?
And if not, are you aware of any .NET client that "play nicely with
the cluster", ie. handle node failure and is generally cluster-aware?
Thanks,
Lasse
--
You received this message because you are subscribed to the Google
Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to elasticsearch+unsubscribe@googlegroups.com.
I have put off writing baked in support for this because there are just so
many different approaches to this and writing your own wrapper that handles
your situation best is not that much work as Itamor pointed out.
after that my hands are itching to write a Nest.ConnectionFactory (if you
have a better name please let me know!) nuget package that you can use to
spawn clients of a pool, thoughts, ideas, code are all very much
appreciated.
For the time being I've created a working item for this here:
On Wednesday, October 23, 2013 10:58:35 AM UTC+2, Itamar Syn-Hershko wrote:
No, but I will definitely look at sending a PR of this upstream, seems
like a nice exercise
On Wed, Oct 23, 2013 at 11:57 AM, Lasse Schou <lasse...@gmail.com<javascript:>
wrote:
Alright, got it. You don't have any C# example of this, do you?
Yes, as I said it would be nice to have this within NEST like
Elasticsearch's TransportClient works, but as long as it isn't implemented
it is very easy to do so I wouldn't consider it a show stopper
On Wed, Oct 23, 2013 at 11:52 AM, Lasse Schou <lasse...@gmail.com<javascript:>
wrote:
The optimal solution would be to configure the NEST client with IP
addresses to the nodes, and then let NEST deal with all connection tasks,
including removing a dead node from the connection list and re-adding it.
I know it's always a discussion about where to put this functionality,
but take a look at how Couchbase's clients handle this. Very easy to use,
and abstracts the cluster/node-awareness away from the developer.
It's fairly easy to implement a pool of Connection objects (or however
they called, can't remember now) and switch between them. I agree having a
TransportClient-like implementation where the client is able to failover to
the next node in the list is nice, but as I said its fairly easy to do from
a wrapper. I would also assume this should be easy to implement in the
core, will look at it sometime soon.
On Wed, Oct 23, 2013 at 11:35 AM, Lasse Schou <lasse...@gmail.com<javascript:>
wrote:
Let's imaging you have 3 ES nodes. When using NEST I can only connect
to one node. So what happens when that node goes down? Isn't that a single
point of failure?
Have you got any concrete plans on releasing an official .NET
client?
And if not, are you aware of any .NET client that "play nicely with
the cluster", ie. handle node failure and is generally cluster-aware?
Thanks,
Lasse
--
You received this message because you are subscribed to the Google
Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to elasticsearc...@googlegroups.com <javascript:>.
--
You received this message because you are subscribed to the Google
Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to elasticsearc...@googlegroups.com <javascript:>.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google
Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to elasticsearc...@googlegroups.com <javascript:>.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups
"elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to elasticsearc...@googlegroups.com <javascript:>.
For more options, visit https://groups.google.com/groups/opt_out.
I still think that it would be nice to get an answer if there will be an
official .NET client. It has nothing to do with NEST being good or not
(it's not that all python clients were bad so they had to make an official
one).
Our decision to create our own clients was mostly about consistency for our
users. To do that we created a set of low-level clients that map very
closely to the REST api. We made sure (and are continuously doing so) that
these clients implement all the API endpoints as well as all parameters and
to the right thing.
We tried our best to avoid any design decisions in those clients to make
sure everybody could use them, even if it means creating their own
abstraction on top of it. The overhead of the clients are so small and
their design flexible enough (we hope) that all the other clients can live
on top of these.
"the intention is to provide a solid base which can be used by other
implementors if they want to add specializations. we take care of the hard
stuff like node failover, while sticking very close to the standard ES REST
API". things like LINQ would be out of scope for this client, but eg the
NEST client could be implemented on top of the official .net client to
provide linq support while taking advantage of the networking improvments
I hope that answers your first question. For more information Honza Krai
will be doing a webinar about this - why we chose to do the clients, what
drove the design decisions we took. It should take place next week sometime.
On Thursday, October 24, 2013 5:58:38 AM UTC-5, joe castle wrote:
I still think that it would be nice to get an answer if there will be an
official .NET client. It has nothing to do with NEST being good or not
(it's not that all python clients were bad so they had to make an official
one).
I would like to know if a release date of a first .NET client is already
planned, and if it's the case, when is it ?
Thanks for your replies.
Loïc
Le jeudi 24 octobre 2013 16:47:20 UTC+2, cdhall a écrit :
Yes, there will be an official client for .NET.
Our decision to create our own clients was mostly about consistency for
our users. To do that we created a set of low-level clients that map very
closely to the REST api. We made sure (and are continuously doing so) that
these clients implement all the API endpoints as well as all parameters and
to the right thing.
We tried our best to avoid any design decisions in those clients to make
sure everybody could use them, even if it means creating their own
abstraction on top of it. The overhead of the clients are so small and
their design flexible enough (we hope) that all the other clients can live
on top of these.
"the intention is to provide a solid base which can be used by other
implementors if they want to add specializations. we take care of the hard
stuff like node failover, while sticking very close to the standard ES REST
API". things like LINQ would be out of scope for this client, but eg the
NEST client could be implemented on top of the official .net client to
provide linq support while taking advantage of the networking improvments
I hope that answers your first question. For more information Honza Krai
will be doing a webinar about this - why we chose to do the clients, what
drove the design decisions we took. It should take place next week sometime.
On Thursday, October 24, 2013 5:58:38 AM UTC-5, joe castle wrote:
I still think that it would be nice to get an answer if there will be an
official .NET client. It has nothing to do with NEST being good or not
(it's not that all python clients were bad so they had to make an official
one).
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.