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
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
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
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
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
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
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
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
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
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
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
(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
(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
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:
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
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
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
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
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
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
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
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
22 matches
Mail list logo
