Re: could not retrieve data randomly
Now I finally confirmed that it is a flappy item issue which had been mentioned before: https://groups.google.com/forum/#!topic/elasticsearch/a-LELkkLRoE but it apears in version 1.2.3 Is there any advise about this issue? I am also interest in that whether there is an internal mechanism in elasticsearch to avoid this situation? I AM ALSO FRUSTRATED BY NO ANSWER HERE. 在 2014年10月14日星期二UTC+9下午12时43分17秒，xzer LR写道： > > additional information: > > The replica factor of my index is 1, which means there are only 2 copies > in the cluster. > > Since I can get the data every 2 times, I guess that there is one missing > copy, but how can I confirm it? > > The cluster health api resports green. > -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/dbe9c2f0-7571-437d-ad6c-4dff06ea3114%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: could not retrieve data randomly
additional information: The replica factor of my index is 1, which means there are only 2 copies in the cluster. Since I can get the data every 2 times, I guess that there is one missing copy, but how can I confirm it? The cluster health api resports green. -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/6f5a1bb1-ec40-4c4f-8943-8172de46ac62%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: could not retrieve data randomly
I need help about this, help!!! -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/823060d2-d4a4-4ffb-965c-26c69b953bb1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: could not retrieve data randomly
Is there anybody can help me with this issue? -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/afb83b2f-5735-44cb-89d3-90efc974b256%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
could not retrieve data randomly
I have a cluster with 3 physical servers and elasticsearch 1.2.3 installed.
I updated some data at yestoday and then today I got a strange issue:
I query data as following:
{
"query": {
"bool": {
"must": [
{
"term": {
"applicationDateRouting.patentDocumentId": "11387107"
}
}
],
"must_not": [],
"should": []
}
},
"from": 0,
"size": 10,
"sort": [],
"facets": {}
}
then I could get the expected one row data at the first time, then I query
again, I will get nothing as following response:
{
- took: 40
- timed_out: false
- _shards: {
- total: 10
- successful: 10
- failed: 0
}
- hits: {
- total: 0
- max_score: null
- hits: [ ]
}
}
then, I query again, I get one row, again, nothing, again, one row, again,
nothing
In my application, we are using filter instead of query and we got the same
issue as above.
It seems a bug of elasticsearch, is there any idea about how to analyze
this issue?
--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/b0b75829-e054-445b-a118-874f23ea30cd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
how to upgrade a cluster
I am upgrading a cluster in version 1.0.3 to 1.2.3 and I am confused by something. According to the description at here: http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/setup-upgrade.html I can disable the allocation before I started the upgrading process. Then I disabled the allocation at first, after that I upgrade one of my node to 1.2.3, then restart the elasticsearch, I saw the node join the existing cluster well, but the upgraded node was keeping blank without any shards recognized, since the allocation has been disabled, the other nodes in old version did not do any reshard too. But according to the document I parsed above, it says that even I disable the allocation, " With shard reallocation disabled, the nodes will join the cluster with their indices intact" I guess that if I proceed to upgrade the left nodes, all the shards will become unavailable since the restarted node does not recognize existing shards when allocation is disabled, thus I stopped my operation after the first node was upgraded. My question is how I can upgrade my nodes with allocation disabled? Is it a bug? If I have to upgrade all the nodes with allocation enabling, it seems that a vast amount of unnecessary IO for resharding will occur. -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/87b642e8-0f80-487b-8634-321fa2f3cb42%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Can I use the java client of newer version to connect to a old version server?
Thank you for the comment, according to the source, it seems you are right.
I will try a converse test
在 2014年7月14日星期一UTC+9下午6时36分03秒，Jörg Prante写道：
>
> You can not connect a newer TransportClient to a server which is older.
> You can connect an older TransportClient to a newer server (without being
> able to use new features).
>
> Jörg
>
>
> On Mon, Jul 14, 2014 at 10:36 AM, xzer LR >
> wrote:
>
>> I think I got the reason.
>>
>> At first, I noticed that the row number from the exception stack is not
>> compatible to the client 1.2.2 source, then it exactly occurred at the old
>> version 1.0.3 server side.
>>
>> Then the service side exception told us that it failed from reading the
>> last string array:
>>
>>
>> https://github.com/elasticsearch/elasticsearch/blob/1.0/src/main/java/org/elasticsearch/action/admin/cluster/state/ClusterStateRequest.java#L132
>>
>> I recognized that the real problem is the client size did not check the
>> version correctly, then I digged the source more deeply, then I found the
>> following row which seems wrong:
>>
>>
>> https://github.com/elasticsearch/elasticsearch/blob/1.0/src/main/java/org/elasticsearch/client/transport/TransportClientNodesService.java#L164
>>
>> DiscoveryNode node = new DiscoveryNode("#transport#-" +
>> tempNodeIdGenerator.incrementAndGet(), transportAddress, version);
>>
>> *The nodes passed to construct the transport client are simply
>> initialized as the current client version.*
>>
>> I have no idea how to fix it but it seems that it should be reported as a
>> bug?
>>
>>
>>
>>
>>
>> 在 2014年7月12日星期六UTC+9上午4时29分01秒，Ivan Brusic写道：
>>>
>>> The code is suspicious since it has an explicit check for versions prior
>>> to 1.2
>>>
>>> https://github.com/elasticsearch/elasticsearch/
>>> blob/master/src/main/java/org/elasticsearch/action/admin/cluster/state/
>>> ClusterStateRequest.java#L121-L124
>>>
>>> Don't know much else about the code to comment further.
>>>
>>> Cheers,
>>>
>>> Ivan
>>>
>>>
>>> On Fri, Jul 11, 2014 at 3:30 AM, xzer LR wrote:
>>>
>>>> I am using TransportClient, the following is how I retrieve the client
>>>> instance:
>>>>
>>>> Client client = new TransportClient(sb.build()).addTransportAddresses(
>>>> esAddresses);
>>>>
>>>> 在 2014年7月11日星期五UTC+9下午6时51分26秒，David Pilato写道：
>>>>>
>>>>> Are you using a TransportClient or NodeClient?
>>>>> If NodeClient, could you try with the TransportClient?
>>>>>
>>>>> --
>>>>> *David Pilato* | *Technical Advocate* | *Elasticsearch.com*
>>>>> @dadoonet <https://twitter.com/dadoonet> | @elasticsearchfr
>>>>> <https://twitter.com/elasticsearchfr>
>>>>>
>>>>>
>>>>> Le 11 juillet 2014 à 11:14:59, xzer LR (xia...@gmail.com) a écrit:
>>>>>
>>>>> As a test result, I got exceptions when I tried to use the newest
>>>>> 1.2.2 java client to connect to a 1.0.3 cluster:
>>>>>
>>>>> 18:05:41.020 [elasticsearch[Slipstream][tra
>>>>> nsport_client_worker][T#1]{New I/O worker #1}] [INFO ] []
>>>>> org.elasticsearch.client.transport[105] - [Slipstream] failed to get
>>>>> local cluster state for
>>>>> [#transport#-1][e-note][inet[/192.168.200.81:9300]],
>>>>> disconnecting...
>>>>> org.elasticsearch.transport.RemoteTransportException:
>>>>> [server-cat][inet[/192.168.21.81:9300]][cluster/state]
>>>>> java.lang.IndexOutOfBoundsException: Readable byte limit exceeded: 48
>>>>> at org.elasticsearch.common.netty.buffer.AbstractChannelBuffer.
>>>>> readByte(AbstractChannelBuffer.java:236) ~[elasticsearch-1.2.2.jar:na]
>>>>> at org.elasticsearch.transport.netty.ChannelBufferStreamInput.r
>>>>> eadByte(ChannelBufferStreamInput.java:132)
>>>>> ~[elasticsearch-1.2.2.jar:na]
>>>>> at
>>>>> org.elasticsearch.common.io.stream.StreamInput.readVInt(StreamInput.java:141)
>>>>>
>>>>> ~[elasticsearch-1.2.2.jar:na]
>>>>> at
>>>>> org.elasticsearch.common.io.stream.StreamInput.readString(StreamInput.java:272)
>>>>>
>>>>> ~[elasticsearch-1.2.2.jar:na]
>>>>&
Re: Can I use the java client of newer version to connect to a old version server?
I think I got the reason.
At first, I noticed that the row number from the exception stack is not
compatible to the client 1.2.2 source, then it exactly occurred at the old
version 1.0.3 server side.
Then the service side exception told us that it failed from reading the
last string array:
https://github.com/elasticsearch/elasticsearch/blob/1.0/src/main/java/org/elasticsearch/action/admin/cluster/state/ClusterStateRequest.java#L132
I recognized that the real problem is the client size did not check the
version correctly, then I digged the source more deeply, then I found the
following row which seems wrong:
https://github.com/elasticsearch/elasticsearch/blob/1.0/src/main/java/org/elasticsearch/client/transport/TransportClientNodesService.java#L164
DiscoveryNode node = new DiscoveryNode("#transport#-" + tempNodeIdGenerator
.incrementAndGet(), transportAddress, version);
*The nodes passed to construct the transport client are simply initialized
as the current client version.*
I have no idea how to fix it but it seems that it should be reported as a
bug?
在 2014年7月12日星期六UTC+9上午4时29分01秒，Ivan Brusic写道：
>
> The code is suspicious since it has an explicit check for versions prior
> to 1.2
>
>
> https://github.com/elasticsearch/elasticsearch/blob/master/src/main/java/org/elasticsearch/action/admin/cluster/state/ClusterStateRequest.java#L121-L124
>
> Don't know much else about the code to comment further.
>
> Cheers,
>
> Ivan
>
>
> On Fri, Jul 11, 2014 at 3:30 AM, xzer LR >
> wrote:
>
>> I am using TransportClient, the following is how I retrieve the client
>> instance:
>>
>> Client client = new
>> TransportClient(sb.build()).addTransportAddresses(esAddresses);
>>
>> 在 2014年7月11日星期五UTC+9下午6时51分26秒，David Pilato写道：
>>>
>>> Are you using a TransportClient or NodeClient?
>>> If NodeClient, could you try with the TransportClient?
>>>
>>> --
>>> *David Pilato* | *Technical Advocate* | *Elasticsearch.com*
>>> @dadoonet <https://twitter.com/dadoonet> | @elasticsearchfr
>>> <https://twitter.com/elasticsearchfr>
>>>
>>>
>>> Le 11 juillet 2014 à 11:14:59, xzer LR (xia...@gmail.com) a écrit:
>>>
>>> As a test result, I got exceptions when I tried to use the newest
>>> 1.2.2 java client to connect to a 1.0.3 cluster:
>>>
>>> 18:05:41.020 [elasticsearch[Slipstream][transport_client_worker][T#1]{New
>>> I/O worker #1}] [INFO ] [] org.elasticsearch.client.transport[105] -
>>> [Slipstream] failed to get local cluster state for
>>> [#transport#-1][e-note][inet[/192.168.200.81:9300]], disconnecting...
>>> org.elasticsearch.transport.RemoteTransportException:
>>> [server-cat][inet[/192.168.21.81:9300]][cluster/state]
>>> java.lang.IndexOutOfBoundsException: Readable byte limit exceeded: 48
>>> at org.elasticsearch.common.netty.buffer.AbstractChannelBuffer.readByte(
>>> AbstractChannelBuffer.java:236) ~[elasticsearch-1.2.2.jar:na]
>>> at org.elasticsearch.transport.netty.ChannelBufferStreamInput.readByte(
>>> ChannelBufferStreamInput.java:132) ~[elasticsearch-1.2.2.jar:na]
>>> at
>>> org.elasticsearch.common.io.stream.StreamInput.readVInt(StreamInput.java:141)
>>>
>>> ~[elasticsearch-1.2.2.jar:na]
>>> at
>>> org.elasticsearch.common.io.stream.StreamInput.readString(StreamInput.java:272)
>>>
>>> ~[elasticsearch-1.2.2.jar:na]
>>> at org.elasticsearch.common.io.stream.HandlesStreamInput.
>>> readString(HandlesStreamInput.java:61) ~[elasticsearch-1.2.2.jar:na]
>>> at org.elasticsearch.common.io.stream.StreamInput.
>>> readStringArray(StreamInput.java:362) ~[elasticsearch-1.2.2.jar:na]
>>> at org.elasticsearch.action.admin.cluster.state.
>>> ClusterStateRequest.readFrom(ClusterStateRequest.java:132)
>>> ~[elasticsearch-1.2.2.jar:na]
>>> at org.elasticsearch.transport.netty.MessageChannelHandler.
>>> handleRequest(MessageChannelHandler.java:209)
>>> ~[elasticsearch-1.2.2.jar:na]
>>> at org.elasticsearch.transport.netty.MessageChannelHandler.
>>> messageReceived(MessageChannelHandler.java:109)
>>> ~[elasticsearch-1.2.2.jar:na]
>>>
>>> I didn't find any metioned break change about this exceptioin.
>>>
>>> 在 2014年7月4日星期五UTC+9下午3时31分07秒，David Pilato写道：
>>>>
>>>> Well. It depends.
>>>>
>>>> 1.0 is incompatible with 0.90
>>>> 1.2 should work with 1.x IIRC.
>>>>
>>>> From 1.0, we try to keep this compatible. If not, release notes wil
Re: Can I use the java client of newer version to connect to a old version server?
I am using TransportClient, the following is how I retrieve the client
instance:
Client client = new
TransportClient(sb.build()).addTransportAddresses(esAddresses);
在 2014年7月11日星期五UTC+9下午6时51分26秒，David Pilato写道：
>
> Are you using a TransportClient or NodeClient?
> If NodeClient, could you try with the TransportClient?
>
> --
> *David Pilato* | *Technical Advocate* | *Elasticsearch.com*
> @dadoonet <https://twitter.com/dadoonet> | @elasticsearchfr
> <https://twitter.com/elasticsearchfr>
>
>
> Le 11 juillet 2014 à 11:14:59, xzer LR (xia...@gmail.com ) a
> écrit:
>
> As a test result, I got exceptions when I tried to use the newest 1.2.2
> java client to connect to a 1.0.3 cluster:
>
> 18:05:41.020
> [elasticsearch[Slipstream][transport_client_worker][T#1]{New I/O worker
> #1}] [INFO ] [] org.elasticsearch.client.transport[105] - [Slipstream]
> failed to get local cluster state for
> [#transport#-1][e-note][inet[/192.168.200.81:9300]], disconnecting...
> org.elasticsearch.transport.RemoteTransportException:
> [server-cat][inet[/192.168.21.81:9300]][cluster/state]
> java.lang.IndexOutOfBoundsException: Readable byte limit exceeded: 48
> at
> org.elasticsearch.common.netty.buffer.AbstractChannelBuffer.readByte(AbstractChannelBuffer.java:236)
>
> ~[elasticsearch-1.2.2.jar:na]
> at
> org.elasticsearch.transport.netty.ChannelBufferStreamInput.readByte(ChannelBufferStreamInput.java:132)
>
> ~[elasticsearch-1.2.2.jar:na]
> at
> org.elasticsearch.common.io.stream.StreamInput.readVInt(StreamInput.java:141)
> ~[elasticsearch-1.2.2.jar:na]
> at
> org.elasticsearch.common.io.stream.StreamInput.readString(StreamInput.java:272)
>
> ~[elasticsearch-1.2.2.jar:na]
> at
> org.elasticsearch.common.io.stream.HandlesStreamInput.readString(HandlesStreamInput.java:61)
>
> ~[elasticsearch-1.2.2.jar:na]
> at
> org.elasticsearch.common.io.stream.StreamInput.readStringArray(StreamInput.java:362)
>
> ~[elasticsearch-1.2.2.jar:na]
> at
> org.elasticsearch.action.admin.cluster.state.ClusterStateRequest.readFrom(ClusterStateRequest.java:132)
>
> ~[elasticsearch-1.2.2.jar:na]
> at
> org.elasticsearch.transport.netty.MessageChannelHandler.handleRequest(MessageChannelHandler.java:209)
>
> ~[elasticsearch-1.2.2.jar:na]
> at
> org.elasticsearch.transport.netty.MessageChannelHandler.messageReceived(MessageChannelHandler.java:109)
>
> ~[elasticsearch-1.2.2.jar:na]
>
> I didn't find any metioned break change about this exceptioin.
>
> 在 2014年7月4日星期五UTC+9下午3时31分07秒，David Pilato写道：
>>
>> Well. It depends.
>>
>> 1.0 is incompatible with 0.90
>> 1.2 should work with 1.x IIRC.
>>
>> From 1.0, we try to keep this compatible. If not, release notes will tell
>> you.
>>
>> --
>> David ;-)
>> Twitter : @dadoonet / @elasticsearchfr / @scrutmydocs
>>
>>
>> Le 4 juil. 2014 à 07:09, xzer LR a écrit :
>>
>> For some reasons, we have several separated elasticsearch clusters for
>> our front applicaitons. We want to upgrade our clusters' version to the
>> newest version but apparently it is impossible to upgrade all the clusters
>> at the same time, which means our single application have to connect to
>> multiple clusters with different versions.
>>
>> My question is whether the elasticsearch java client has the ability to
>> work correctly with an old version server?
>> --
>> 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.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/elasticsearch/baa98ec5-ffcf-46f9-bfdd-7afbd213b19d%40googlegroups.com
>>
>> <https://groups.google.com/d/msgid/elasticsearch/baa98ec5-ffcf-46f9-bfdd-7afbd213b19d%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> 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 .
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/elasticsearch/77e32825-812a-46c8-82b4-93a5e4b12788%40googlegroups.com
>
> <https://groups.google.com/d/msgid/elasticsearch/77e32825-812a-46c8-82b4-93a5e4b12788%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/df3afd7e-b0a5-4d26-a777-fc887427bbed%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Can I use the java client of newer version to connect to a old version server?
As a test result, I got exceptions when I tried to use the newest 1.2.2
java client to connect to a 1.0.3 cluster:
18:05:41.020 [elasticsearch[Slipstream][transport_client_worker][T#1]{New
I/O worker #1}] [INFO ] [] org.elasticsearch.client.transport[105] -
[Slipstream] failed to get local cluster state for
[#transport#-1][e-note][inet[/192.168.200.81:9300]], disconnecting...
org.elasticsearch.transport.RemoteTransportException:
[server-cat][inet[/192.168.21.81:9300]][cluster/state]
java.lang.IndexOutOfBoundsException: Readable byte limit exceeded: 48
at
org.elasticsearch.common.netty.buffer.AbstractChannelBuffer.readByte(AbstractChannelBuffer.java:236)
~[elasticsearch-1.2.2.jar:na]
at
org.elasticsearch.transport.netty.ChannelBufferStreamInput.readByte(ChannelBufferStreamInput.java:132)
~[elasticsearch-1.2.2.jar:na]
at
org.elasticsearch.common.io.stream.StreamInput.readVInt(StreamInput.java:141)
~[elasticsearch-1.2.2.jar:na]
at
org.elasticsearch.common.io.stream.StreamInput.readString(StreamInput.java:272)
~[elasticsearch-1.2.2.jar:na]
at
org.elasticsearch.common.io.stream.HandlesStreamInput.readString(HandlesStreamInput.java:61)
~[elasticsearch-1.2.2.jar:na]
at
org.elasticsearch.common.io.stream.StreamInput.readStringArray(StreamInput.java:362)
~[elasticsearch-1.2.2.jar:na]
at
org.elasticsearch.action.admin.cluster.state.ClusterStateRequest.readFrom(ClusterStateRequest.java:132)
~[elasticsearch-1.2.2.jar:na]
at
org.elasticsearch.transport.netty.MessageChannelHandler.handleRequest(MessageChannelHandler.java:209)
~[elasticsearch-1.2.2.jar:na]
at
org.elasticsearch.transport.netty.MessageChannelHandler.messageReceived(MessageChannelHandler.java:109)
~[elasticsearch-1.2.2.jar:na]
I didn't find any metioned break change about this exceptioin.
在 2014年7月4日星期五UTC+9下午3时31分07秒，David Pilato写道：
>
> Well. It depends.
>
> 1.0 is incompatible with 0.90
> 1.2 should work with 1.x IIRC.
>
> From 1.0, we try to keep this compatible. If not, release notes will tell
> you.
>
> --
> David ;-)
> Twitter : @dadoonet / @elasticsearchfr / @scrutmydocs
>
>
> Le 4 juil. 2014 à 07:09, xzer LR > a
> écrit :
>
> For some reasons, we have several separated elasticsearch clusters for our
> front applicaitons. We want to upgrade our clusters' version to the newest
> version but apparently it is impossible to upgrade all the clusters at the
> same time, which means our single application have to connect to multiple
> clusters with different versions.
>
> My question is whether the elasticsearch java client has the ability to
> work correctly with an old version server?
>
> --
> 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 .
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/elasticsearch/baa98ec5-ffcf-46f9-bfdd-7afbd213b19d%40googlegroups.com
>
> <https://groups.google.com/d/msgid/elasticsearch/baa98ec5-ffcf-46f9-bfdd-7afbd213b19d%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/77e32825-812a-46c8-82b4-93a5e4b12788%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Can I use the java client of newer version to connect to a old version server?
For some reasons, we have several separated elasticsearch clusters for our front applicaitons. We want to upgrade our clusters' version to the newest version but apparently it is impossible to upgrade all the clusters at the same time, which means our single application have to connect to multiple clusters with different versions. My question is whether the elasticsearch java client has the ability to work correctly with an old version server? -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/baa98ec5-ffcf-46f9-bfdd-7afbd213b19d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
I am confused by the postFilter and filter of elasticsearch‘s java client
AFAIK, There are three types search I can perform on elasticsearch:
1. query => which will do scoring and affect the hit
2. filter => which will not do scoring and affect the hit
3. post_filter => which will be applied on the result of query/filter and
will not affect the hit and facet aggregation
At the java client library side, I am assuming there should be same three
types of apis existing, yes I found three.
But unfortunately the setFilter method of SearchRequestBuilder had been
marked as deprecated and also had
been delegated to the setPostFilter method of itself.
My question is how can I perform a filter query by java client? I found a
way by that I can do filter query as following:
search.setQuery(
QueryBuilders.filteredQuery(
QueryBuilders.matchAllQuery(),
FilterBuilders.termFilter("xx", "v")
)
);
But it seems so strange that I have to declare an unnecessary match all
query.
--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/6aefc449-3997-4128-b9ee-715d7a998b5c%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: load balance on heterogeneous nodes in a cluster
Thanks for the replies, we are now considering and discussing our balance policy, all the information is helpful. -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/d5c82e84-9680-4d11-8e8f-d7fa0a9fcb37%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
load balance on heterogeneous nodes in a cluster
I am now evaluating elasticsearch as our text search solution. But the problem is that we cannot guarantee that we can always allocate same hardware for our cluster when new nodes are added, therefor we need a solution to distribute the load in a smart way based on the machine power. I read the document and source, I found there is a BalancedShardsAllocator for balancing the shards between nodes with consideration of shards count. But basically, the BalancedShardsAllocator still considers the nodes in the cluster as homogeneous. It seems that we can implement our own ShardsAllocator to distribute shards by predefined machine factor(the simplest way maybe), I want to know whether there is something I missed or there is already some built-in function affording the ability we want? And I also have the related second question, currently our search is not IO-bound because we have big-enough memory on all of our machines but there are different counts of cpu cores in every machine, I want the client search can be distributed to nodes based on the count of cpu cores rather than simple round-robin. Is there any way to do that? -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/35708394-19e7-4ab2-ab1a-f632039da26e%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
