Re: Cannot restore a snapshot with IndexMissingException[[_snapshot] missing]
Note to self mostly. I later noticed it happening when trying to transfer snapshots between repositories (i.e. snapshot on one, restore on the other). It would happen when snapshot was not visible on the cluster where restore operation was taking place. -- 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/0c8ecafc-13af-4db2-9287-3e7216776a91%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: issues with using repository-hdfs plug in for snapshot/restore operation
I had a similar scenario, running CDH 4.6, unable to initialise the repository with hadoop2 version and started changing gradle as Brent suggests. However, maintaining our own version was a bit too much in our case. As Costin pointed to me here https://groups.google.com/forum/?fromgroups=#!topic/elasticsearch/613YHEUAtuA, the lightweight jar is there for the plethora of distributions, as long as you have your hadoop jars on the classpath. -- 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/dffaaab2-8e66-4574-a755-a1577a6343bc%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Elastic search - exporting index from existing cluster to a different cluster
We run into a similar problems recently after a very recent upgrade from ES 1.2.2 to ES 1.3.4. In our scenario, we have two ES clusters and a HDFS system which both can access. Indices are created on one of them, snapshotted to HDFS repository (named after the index) and then restored on the other cluster. This worked fine (when ignoring random error messages) on 1.2.2. After the upgrade to 1.3.4, however, clusters don't seem to be able to see new snapshots made on the other system. Files sit in HDFS, it is possible to restore locally, accessing: https://snapshot-cluster.domain.com/_snapshot/repository_name/_all returns the expected list while https://restore-cluster.domain.com/_snapshot/repository_name/_all is empty. Beforehand, the lists were identical. I will try to check version 1.3.2 tomorrow, but remaining clueless at the moment. -- 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/f241a3aa-fd8d-486c-8f6b-40faa701bccd%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Snapshot/restore between clusters not working after upgrade to 1.3.4
We run into a problem recently after a very recent upgrade from ES 1.2.2 to ES 1.3.4. In our scenario, we have two ES clusters and a HDFS system which both can access. Indices are created on one of them, snapshotted to HDFS repository (named after the index) and then restored on the other cluster. This worked fine (when ignoring random error messages) on 1.2.2. After the upgrade to 1.3.4, however, clusters don't seem to be able to see new snapshots made on the other system. Files sit in HDFS, it is possible to restore locally, accessing: https://snapshot-cluster.domain.com/_snapshot/repository_name/_all returns the expected list while https://restore-cluster.domain.com/_snapshot/repository_name/_all is empty. Beforehand, the lists were identical. I will try to check version 1.3.2 tomorrow, but remaining clueless at the moment. -- 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/24ab44cf-0195-4742-a11d-807d51b84db2%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Smart Chineese Analysis Plugin - smartcn_word smartcn_sentence deprecation upgrade strategy
While trying to upgrade from ES 1.2.2 to 1.3.4, we have noticed that since Smart Chinese Analysis plugin release 2.3.0 *smartcn_sentence* and *smarcn_word* have been deprecated as a result of changes in Lucene. At the moment we do have dozens of indices which already use those classes in their mappings and are trying to figure out how to proceed with the upgrade. Is there a best / preferred strategy to do that? Thanks, Mateusz -- 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/48f7aa51-fbef-4364-ab12-e329cea6f110%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Smart Chineese Analysis Plugin - smartcn_word smartcn_sentence deprecation upgrade strategy
Just switched to 2.3.1, that was just too fast. Merci bien! -- 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/782b924f-fef1-4806-8eb3-22ae53486c59%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Cannot restore a snapshot with IndexMissingException[[_snapshot] missing]
We manage to occasionally put ES cluster into a particular state, where it would fail to restore index from a valid snapshot with 404 and: IndexMissingException[[_snapshot] missing] This is an exact quote, note '_snapshot', which is not the name of the index. Nothing in the main logs. The very same restore operation (i.e. same command) would work one hour and fail the next. As far as we observed, it usually follows series of snapshot / restore operations, when some of the indices would be closed to allow restore to happen and then be reopened. It is possible that we call 'open' and 'close' on indices that are already in the intended state, although not sure if this is relevant. Not sure if related, but at the same time trying to list all snapshots in a repository ( by say getting https://my-cluster.com/_snapshot/repository_name/_all ends up with Nginx 502-ing. Again, nothing in the logs. At the moment, we're still trying to figure out the possible cause, but would be grateful for any advice if anyone might have experienced this before. Thanks, Mateusz -- 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/60d2f784-a51b-4e42-b40f-409bbf895b9a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Cannot restore a snapshot with IndexMissingException[[_snapshot] missing] error
We manage to occasionally put ES cluster into a particular state, where it would fail to restore index from a valid snapshot with: Failed to restore the repository with the following error: 404, IndexMissingException[[_snapshot] missing] This is an exact quote, note '_snapshot', which is not the name of the index. Nothing in the main logs. The very same restore operation (i.e. same command) would work one hour and fail the next. As far as we observed, it usually follows series of snapshot / restore operations, when some of the indices would be closed to allow restore to happen and then be reopened. It is possible that we call 'open' and 'close' on indices that are already in the intended state, although not sure if this is relevant. Not sure if related, but at the same time trying to list all snapshots in a repository ( by say getting https://my-cluster.com/_snapshot/repository_name/_all ends up with Nginx 502-ing. Again, nothing in the logs. At the moment, we're still trying to figure out the possible cause, but would be grateful for any advice if anyone might have experienced this before. Thanks, Mateusz -- 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/02ab1609-a719-4a14-a638-ba730cdeaee7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Hadoop] Hadoop plugin indices with ':' colon - not able to snapshot (?)
Hi Costin, thanks for the response.
Yes, I understand that this is a restricted character and would require
escaping.
There are perhaps 2 separate issues here:
1) If 'indices' is not specified, i.e.
curl -XPUT localhost:9200/_snapshot/hdfs-cluster/snapshot_1
elasticsearch is going to complain with the mentioned error when it finds
any index with colon in its name and stop.
2) If 'indices' is in use, I don't see a way(would be great to be proved
wrong) to escape the name, i.e. doing something like this
curl -XPUT localhost:9200/_snapshot/hdfs-cluster/snapshot_2 -d '{indices:
crawl%3A1}'
finishes empty as the index with such a name does not exist.
That's why I though escaping might be done somewhere in the plugin?
Mateusz
--
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/e635a780-4b11-44b0-b435-243fd22a8fb4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [Hadoop] Hadoop plugin indices with ':' colon - not able to snapshot (?)
I'm afraid it's the other way around, i.e. we already have 50 indices or so (+tools) using colon in the base name. And just to check that as well, specifying alias in 'indices' instead of the base name still results in the same error. -- 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/00f0f6ba-30f5-40d1-a414-6d8a55ed099a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Hadoop] Hadoop plugin indices with ':' colon - not able to snapshot (?)
Thanks. Yes, will try to dig around the plugin code. Not entirely sure I get how generic this is, my understanding was that's it was more HDFS-specific. -- 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/658c8899-6467-49b0-9946-2e7af7ea17e4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Elasticsearch-Hadoop repository plugin Cloudera Hadoop 2.0.0-cdh4.6.0
(Much delayed) thank you Costin. Indeed, on Ubuntu, changing ES_CLASSPATH to include hadoop and hadoop/lib directories in /etc/default/elasticsearch (and exporting it in /etc/init.d/elasticsearch) and installing light plugin version did work. -- 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/f3dc7f6a-3dc0-4793-af8e-ea4390540204%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Elasticsearch-Hadoop repository plugin Cloudera Hadoop 2.0.0-cdh4.6.0
(Much delayed) thank you Costin.
Indeed, on Ubuntu, changing ES_CLASSPATH to include hadoop and hadoop/lib
directories in /etc/default/elasticsearch (and exporting it in
/etc/init.d/elasticsearch) and installing light plugin version did work.
On Thursday, 14 August 2014 20:59:39 UTC, Costin Leau wrote:
Hi,
The hdfs repository relies on vanilla Hadoop 2.2 since that's the official
stable version of Yarn. Since you are using a
different
Hadoop version, use the 'light' version as explained in the docs - this
contains only the repository-hdfs, without the
Hadoop dependency
(since you already have it installed).
In other words, both the error that you see as well as the 2.0.1
(regarding JobLocalizer) seems to be related to the
differences between
vanilla Hadoop 2.2 and the one you are using.
Hope this helps,
On 8/14/14 7:36 PM, Mateusz Kaczynski wrote:
I'm trying to get es-hadoop repository plugin working on our hadoop
2.0.0-cdh4.6.0 distribution and it seems like I'm
quite lost.
I installed plugin's -hadoop2 version on the machines on our hadoop
cluster (which also run our stage elasticsearch nodes).
When attempting to create a repository on one of the datanodes with:
curl -XPUT 1.0.0.1:9200/_snapshot/hdfs -d '{type:hdfs,
settings: {uri: hdfs://1.0.0.10:54310,
path:/es_backup}}'
I end up with the logs being filled with the following error:
Caused by: com.google.protobuf.InvalidProtocolBufferException: Protocol
message contained an invalid tag (zero).
at
com.google.protobuf.InvalidProtocolBufferException.invalidTag(InvalidProtocolBufferException.java:89)
at
com.google.protobuf.CodedInputStream.readTag(CodedInputStream.java:108)
at
org.apache.hadoop.ipc.protobuf.RpcHeaderProtos$RpcResponseHeaderProto.init(RpcHeaderProtos.java:1398)
at
org.apache.hadoop.ipc.protobuf.RpcHeaderProtos$RpcResponseHeaderProto.init(RpcHeaderProtos.java:1362)
at
org.apache.hadoop.ipc.protobuf.RpcHeaderProtos$RpcResponseHeaderProto$1.parsePartialFrom(RpcHeaderProtos.java:1492)
at
org.apache.hadoop.ipc.protobuf.RpcHeaderProtos$RpcResponseHeaderProto$1.parsePartialFrom(RpcHeaderProtos.java:1487)
at
com.google.protobuf.AbstractParser.parsePartialFrom(AbstractParser.java:200)
at
com.google.protobuf.AbstractParser.parsePartialDelimitedFrom(AbstractParser.java:241)
at
com.google.protobuf.AbstractParser.parseDelimitedFrom(AbstractParser.java:253)
at
com.google.protobuf.AbstractParser.parseDelimitedFrom(AbstractParser.java:259)
at
com.google.protobuf.AbstractParser.parseDelimitedFrom(AbstractParser.java:49)
at
org.apache.hadoop.ipc.protobuf.RpcHeaderProtos$RpcResponseHeaderProto.parseDelimitedFrom(RpcHeaderProtos.java:2364)
at
org.apache.hadoop.ipc.Client$Connection.receiveRpcResponse(Client.java:996)
at org.apache.hadoop.ipc.Client$Connection.run(Client.java:891)
Is it possible that this is caused by the incompatible hadoop versions
(2.2 used by plugin with 2.0 being installed) and
it is necessary to get it build with downgraded version?
Also, to build the jar, is it just
gradle build -Pdistro=hadoopYarn ?
Because release 2.0.1 does not quite work for me as it fails to find
JobLocalizer.class.
Regards,
Mateusz
--
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: mailto:
elasticsearch+unsubscr...@googlegroups.com javascript:.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/5aff7e2a-eb3e-4bb8-8698-05fec6a67e87%40googlegroups.com
https://groups.google.com/d/msgid/elasticsearch/5aff7e2a-eb3e-4bb8-8698-05fec6a67e87%40googlegroups.com?utm_medium=emailutm_source=footer.
For more options, visit https://groups.google.com/d/optout.
--
Costin
--
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/4ae0b343-72aa-459e-930e-559852c5d310%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[Hadoop] Hadoop plugin indices with ':' colon - not able to snapshot (?)
Whenever I try to take a snapshot of an index which contains a ':' colon in
its name,I end up with the following trace:
{
error:IllegalArgumentException[java.net.URISyntaxException: Relative
path in absolute URI: crawl:1]; nested: URISyntaxException[Relative path in
absolute URI: crawl:1]; ,
status:500
}
It does not matter if the 'indices' argument is provided or not, the
snapshot name is set to 'snapshot'. I have tried to specify the index
escaping the sign with '%3a' but in this case the name does not fit any
available indices.
I assume this is related to https://issues.apache.org/jira/browse/HDFS-13
filenames with ':' colon throws java.lang.IllegalArgumentException?
The question is, is there a way to somehow escape the character (if not
within the request then perhaps code itself?) and if so, would creating a
feature request make sense?
Many thanks,
Mateusz
--
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/ce4b5ffb-f473-4862-8b67-bec1f08bd840%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Elasticsearch-Hadoop repository plugin Cloudera Hadoop 2.0.0-cdh4.6.0
I'm trying to get es-hadoop repository plugin working on our hadoop
2.0.0-cdh4.6.0 distribution and it seems like I'm quite lost.
I installed plugin's -hadoop2 version on the machines on our hadoop cluster
(which also run our stage elasticsearch nodes).
When attempting to create a repository on one of the datanodes with:
curl -XPUT 1.0.0.1:9200/_snapshot/hdfs -d '{type:hdfs, settings:
{uri: hdfs://1.0.0.10:54310, path:/es_backup}}'
I end up with the logs being filled with the following error:
Caused by: com.google.protobuf.InvalidProtocolBufferException: Protocol
message contained an invalid tag (zero).
at
com.google.protobuf.InvalidProtocolBufferException.invalidTag(InvalidProtocolBufferException.java:89)
at com.google.protobuf.CodedInputStream.readTag(CodedInputStream.java:108)
at
org.apache.hadoop.ipc.protobuf.RpcHeaderProtos$RpcResponseHeaderProto.init(RpcHeaderProtos.java:1398)
at
org.apache.hadoop.ipc.protobuf.RpcHeaderProtos$RpcResponseHeaderProto.init(RpcHeaderProtos.java:1362)
at
org.apache.hadoop.ipc.protobuf.RpcHeaderProtos$RpcResponseHeaderProto$1.parsePartialFrom(RpcHeaderProtos.java:1492)
at
org.apache.hadoop.ipc.protobuf.RpcHeaderProtos$RpcResponseHeaderProto$1.parsePartialFrom(RpcHeaderProtos.java:1487)
at
com.google.protobuf.AbstractParser.parsePartialFrom(AbstractParser.java:200)
at
com.google.protobuf.AbstractParser.parsePartialDelimitedFrom(AbstractParser.java:241)
at
com.google.protobuf.AbstractParser.parseDelimitedFrom(AbstractParser.java:253)
at
com.google.protobuf.AbstractParser.parseDelimitedFrom(AbstractParser.java:259)
at
com.google.protobuf.AbstractParser.parseDelimitedFrom(AbstractParser.java:49)
at
org.apache.hadoop.ipc.protobuf.RpcHeaderProtos$RpcResponseHeaderProto.parseDelimitedFrom(RpcHeaderProtos.java:2364)
at
org.apache.hadoop.ipc.Client$Connection.receiveRpcResponse(Client.java:996)
at org.apache.hadoop.ipc.Client$Connection.run(Client.java:891)
Is it possible that this is caused by the incompatible hadoop versions (2.2
used by plugin with 2.0 being installed) and it is necessary to get it
build with downgraded version?
Also, to build the jar, is it just
gradle build -Pdistro=hadoopYarn ?
Because release 2.0.1 does not quite work for me as it fails to find
JobLocalizer.class.
Regards,
Mateusz
--
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/5aff7e2a-eb3e-4bb8-8698-05fec6a67e87%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Sort Order when relevance is equal
Seconding question. Also, is it possible that the default order for an equal relevance score changed between 1.0 and 1.2 ? We've noticed seemingly random ordering in our regression when updating. On Wednesday, 14 May 2014 00:49:55 UTC, Erich Lin wrote: Ignoring the bouncing results problem with multiple shards , is the order of results deterministic when sorting by relevance score or any other field. What I mean by this is if two documents have the same score, 1) will they always be in the same order if we set the preference parameter to an arbitrary string like the user’s session ID. 2) If so, is there a way to predict this deterministic order? Is it done by ID of the documents as a tiebreaker etc? 3) If not, could we specify that or do we have to do a secondary sort on ID if we wanted 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/dd34df9d-7ef0-4fec-9f50-2a7e30cfae8e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Sort Order when relevance is equal
Seconding question. Also, is it possible that it changed between versions 1.0 and 1.2? We're trying to upgrade and noticed a seemingly random order of documents with equal relevance in regression testing. On Wednesday, 14 May 2014 00:49:55 UTC, Erich Lin wrote: Ignoring the bouncing results problem with multiple shards , is the order of results deterministic when sorting by relevance score or any other field. What I mean by this is if two documents have the same score, 1) will they always be in the same order if we set the preference parameter to an arbitrary string like the user’s session ID. 2) If so, is there a way to predict this deterministic order? Is it done by ID of the documents as a tiebreaker etc? 3) If not, could we specify that or do we have to do a secondary sort on ID if we wanted 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/284b6bfd-68aa-4717-ab52-73d44f7cc196%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Failed to send release search context - SourceLookup fetching cost (?)
Anyone encountered something similar / related? On Tuesday, 27 May 2014 13:46:19 UTC, Mateusz Kaczynski wrote: We have recently changed some of our code to include additional call to SourceLookup.extractValue(path) in fetch stage. Soon after, we have started experiencing some issues with search stability (with some of our searches failing to finish, others taking very long). I can see search lookup queue getting filled up (to 1000) and I can see the following spamming the logs: es-cluster-3-3 elasticsearch[2014-05-26 18:59:28,584][WARN ][search.action ] [Maeby] Failed to send release search context es-cluster-3-3 elasticsearchorg.elasticsearch.transport.SendRequestTransportException: [Oscar][inet[/ 10.0.0.1/ip-10-0-0-1.eu-west-1.compute.internal:9300]][search/freeContexthttp://10.0.0.1/ip-10-0-0-1.eu-west-1.compute.internal:9300%5D%5D%5Bsearch/freeContext ] es-cluster-3-3 elasticsearch at org.elasticsearch.transport.TransportService.sendRequest(TransportService.java:202) es-cluster-3-3 elasticsearch at org.elasticsearch.transport.TransportService.sendRequest(TransportService.java:173) es-cluster-3-3 elasticsearch at org.elasticsearch.search.action.SearchServiceTransportAction.sendFreeContext(SearchServiceTransportAction.java:103) es-cluster-3-3 elasticsearch at org.elasticsearch.action.search.type.TransportSearchTypeAction$BaseAsyncAction.releaseIrrelevantSearchContexts(TransportSearchTypeAction.java:392) es-cluster-3-3 elasticsearch at org.elasticsearch.action.search.type.TransportSearchQueryThenFetchAction$AsyncAction.finishHim(TransportSearchQueryThenFetchAction.java:191) es-cluster-3-3 elasticsearch at org.elasticsearch.action.search.type.TransportSearchQueryThenFetchAction$AsyncAction.onFetchFailure(TransportSearchQueryThenFetchAction.java:177) es-cluster-3-3 elasticsearch at org.elasticsearch.action.search.type.TransportSearchQueryThenFetchAction$AsyncAction$3.onFailure(TransportSearchQueryThenFetchAction.java:165) es-cluster-3-3 elasticsearch at org.elasticsearch.search.action.SearchServiceTransportAction$10.handleException(SearchServiceTransportAction.java:426) es-cluster-3-3 elasticsearch at org.elasticsearch.transport.TransportService$Adapter$2$1.run(TransportService.java:316) es-cluster-3-3 elasticsearch at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) es-cluster-3-3 elasticsearch at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) es-cluster-3-3 elasticsearch at java.lang.Thread.run(Thread.java:745) es-cluster-3-3 elasticsearchCaused by: org.elasticsearch.transport.NodeNotConnectedException: [Oscar][inet[/ 10.0.0.1/ip-10-0-0-1.eu-west-1.compute.internal:9300]] Node not connected es-cluster-3-3 elasticsearch at org.elasticsearch.transport.netty.NettyTransport.nodeChannel(NettyTransport.java:859) es-cluster-3-3 elasticsearch at org.elasticsearch.transport.netty.NettyTransport.sendRequest(NettyTransport.java:540) es-cluster-3-3 elasticsearch at org.elasticsearch.transport.TransportService.sendRequest(TransportService.java:189) es-cluster-3-3 elasticsearch ... 11 more There is also a long GC running at the same time, not sure if it might be the cause or the effect. Is it at all possible that this might have been caused by a call to SourceLookup.extractValue() assuming the field that is extracted was not specified in the 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/8f226f6e-e453-4bb9-b204-2c61a9f30662%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Failed to send release search context - SourceLookup fetching cost (?)
Anyone encoutered something similar / related? -- 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/498619f8-f05b-44ca-8846-3e15a15946c6%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Failed to send release search context - SourceLookup fetching cost (?)
We have recently changed some of our code to include additional call to SourceLookup.extractValue(path) in fetch stage. Soon after, we have started experiencing some issues with search stability (with some of our searches failing to finish, others taking very long). I can see search lookup queue getting filled up (to 1000) and I can see the following spamming the logs: es-cluster-3-3 elasticsearch[2014-05-26 18:59:28,584][WARN ][search.action ] [Maeby] Failed to send release search context es-cluster-3-3 elasticsearchorg.elasticsearch.transport.SendRequestTransportException: [Oscar][inet[/10.0.0.1/ip-10-0-0-1.eu-west-1.compute.internal:9300]][search/freeContext] es-cluster-3-3 elasticsearch at org.elasticsearch.transport.TransportService.sendRequest(TransportService.java:202) es-cluster-3-3 elasticsearch at org.elasticsearch.transport.TransportService.sendRequest(TransportService.java:173) es-cluster-3-3 elasticsearch at org.elasticsearch.search.action.SearchServiceTransportAction.sendFreeContext(SearchServiceTransportAction.java:103) es-cluster-3-3 elasticsearch at org.elasticsearch.action.search.type.TransportSearchTypeAction$BaseAsyncAction.releaseIrrelevantSearchContexts(TransportSearchTypeAction.java:392) es-cluster-3-3 elasticsearch at org.elasticsearch.action.search.type.TransportSearchQueryThenFetchAction$AsyncAction.finishHim(TransportSearchQueryThenFetchAction.java:191) es-cluster-3-3 elasticsearch at org.elasticsearch.action.search.type.TransportSearchQueryThenFetchAction$AsyncAction.onFetchFailure(TransportSearchQueryThenFetchAction.java:177) es-cluster-3-3 elasticsearch at org.elasticsearch.action.search.type.TransportSearchQueryThenFetchAction$AsyncAction$3.onFailure(TransportSearchQueryThenFetchAction.java:165) es-cluster-3-3 elasticsearch at org.elasticsearch.search.action.SearchServiceTransportAction$10.handleException(SearchServiceTransportAction.java:426) es-cluster-3-3 elasticsearch at org.elasticsearch.transport.TransportService$Adapter$2$1.run(TransportService.java:316) es-cluster-3-3 elasticsearch at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) es-cluster-3-3 elasticsearch at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) es-cluster-3-3 elasticsearch at java.lang.Thread.run(Thread.java:745) es-cluster-3-3 elasticsearchCaused by: org.elasticsearch.transport.NodeNotConnectedException: [Oscar][inet[/10.0.0.1/ip-10-0-0-1.eu-west-1.compute.internal:9300]] Node not connected es-cluster-3-3 elasticsearch at org.elasticsearch.transport.netty.NettyTransport.nodeChannel(NettyTransport.java:859) es-cluster-3-3 elasticsearch at org.elasticsearch.transport.netty.NettyTransport.sendRequest(NettyTransport.java:540) es-cluster-3-3 elasticsearch at org.elasticsearch.transport.TransportService.sendRequest(TransportService.java:189) es-cluster-3-3 elasticsearch ... 11 more There is also a long GC running at the same time, not sure if it might be the cause or the effect. Is it at all possible that this might have been caused by a call to SourceLookup.extractValue() assuming the field that is extracted was not specified in the 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/0b05891b-b578-42fa-8eed-5e5704c4e686%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Plain Highlighter using document-defined analyzer
Any thoughts on this? On Tuesday, 13 May 2014 16:22:13 UTC, Mateusz Kaczynski wrote: We have recently encountered a problem with item highlighting when we changed the way we define analysers. In short, the problem boiled down to PlainHighlighter using analyser for the document type. while we specify analyser on per-document basis. '_analyzer' field is not used (or, from my debugging, even visible) in the highlighter context. As a temporary solution, I made highlighter use the field to which '_analyzer' points to(via path) in the mappings we use, My attempt at it is over here: https://github.com/arachnys/elasticsearch/commit/8082fcab5e22f783536f226eb544da7c27ceabba There are a couple of issues that I am seeking help with: 1) Does this seem like an about - right approach to dealing with the situation? 2) Analyzer field name is hardcoded, as I was unable to figure out how to get it from the document in the correct way (again, the right field is pointed to in '_analyzer' via path). Any suggestions how to do it properly? Regards, Mateusz Kaczyński -- 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/d2962d64-26d6-4984-835a-e6b3bee7731c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Plain Highlighter using document-defined analyzer
We have recently encountered a problem with item highlighting when we changed the way we define analysers. In short, the problem boiled down to PlainHighlighter using analyser for the document type. while we specify analyser on per-document basis. '_analyzer' field is not used (or, from my debugging, even visible) in the highlighter context. As a temporary solution, I made highlighter use the field to which '_analyzer' points to(via path) in the mappings we use, My attempt at it is over here: https://github.com/arachnys/elasticsearch/commit/8082fcab5e22f783536f226eb544da7c27ceabba There are a couple of issues that I am seeking help with: 1) Does this seem like an about - right approach to dealing with the situation? 2) Analyzer field name is hardcoded, as I was unable to figure out how to get it from the document in the correct way (again, the right field is pointed to in '_analyzer' via path). Any suggestions how to do it properly? Regards, Mateusz Kaczyński -- 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/7bbf3576-5fb1-44d1-badd-90f6b6cdf2d1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
