• This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.

Elasticsearch error type parsing_exception

Beanjam

Active member
#1
I have just upgrade my server and Elasticsearch in the process. It was running ok previously but now I am seeing this in the server error log.

Code:
XenForo_Exception: Elasticsearch error: {"root_cause":[{"type":"parsing_exception","reason":"no [query] registered for [filtered]","line":1,"col":72}],"type":"parsing_exception","reason":"no [query] registered for [filtered]","line":1,"col":72} - library/XenES/Search/SourceHandler/ElasticSearch.php:894
I have these versions:

XenForo 1.5.8
XenForo Enhanced Search 1.1.5

The Elasticsearch version is 5.0.0-alpha3 and it's returning this with curl:

Code:
{
  "name" : "Phalanx",
  "cluster_name" : "elasticsearch",
  "version" : {
    "number" : "5.0.0-alpha3",
    "build_hash" : "cad959b",
    "build_date" : "2016-05-26T08:25:57.564Z",
    "build_snapshot" : false,
    "lucene_version" : "6.0.0"
  },
  "tagline" : "You Know, for Search"
}
I have tried:
- Rebuiling the search index
- Disabled dynamic scripting and moved library/XenES/_scripts/* to /etc/elasticsearch/scripts.
- Enabling dynamic scripting by adding the below to /etc/elasticsearch/elasticsearch.yml and restarting Elastic search but this causes another error.

Code:
script.inline: on
script.indexed: on
Code:
XenForo_Exception: Elasticsearch server returned no response. Is it running? - library/XenES/Search/SourceHandler/ElasticSearch.php:900
Is there something I am overlooking here?

Cheers.
 

Beanjam

Active member
#5
I have Elasticsearch 2.3.3 running now and searches are working again, yay! :)

I've tested configuring it both with & without dynamic scripting and both ways are working ok, so what's the benefit of one over another?

It seems like enabling dynamic scripting is easiest way to get things up & running and I wouldn't need to keep moving scripts in case they change in a future XF upgrade. On a single-user server with the bind address as localhost are there any security risks?

Without enabling dynamic scripting, it seems like since Elasticsearch 1.4 only the Groovy script needs to be moved to /etc/elasticsearch/. This is easy enough to do, so is there any disadvantage to this way? I assume adding a symlink to the scripts in library/XenES/_scripts/ instead negates any security benefit though?

I also just noticed that apt-get upgrade wants to install 5.0.0-alpha3 again, so I've had to hold back 2.3.3.
 
Last edited: