I am trying to ping a locally executed elasticsearch using elasticsearch.jquery.min.js, and every time I get the message "no live connection".
ETA: In Chrome, I see what looks like a pretty low level of "Connection Refused". I am developing MacOS X and my browser points to the page via http://localhost/~myuserid/SiteName/ . When I turn to localhost:9200 , this clearly falls under the CORS domain requirements.
I see the following error in the Chrome console:
XMLHttpRequest cannot load http://localhost:9200/?hello=elasticsearch!. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost' is therefore not allowed access.
Per http://enable-cors.org/server_apache.html I added the following to / etc / apache 2 / httpd.conf:
<Directory /> Header set Access-Control-Allow-Origin "localhost:9200" AllowOverride none Require all denied </Directory>
and run
$ sudo apachectl -t $ sudo apachectl -k graceful
but the error persists. Is there another setting that I skip?
I am new to elasticsearch.js. Is there anything I need to do on the elasticsearch side to allow client connections from the browser, or something like that?
I follow the book in my ping attempt:
var client = new $.es.Client({ hosts: 'localhost:9200' }); client.ping( { requestTimeout: Infinity, // undocumented params are appended to the query string hello: "elasticsearch!" }, function (error) { if (error) { console.error('elasticsearch cluster is down!'); console.error(error); } else { console.log('All is well'); } } );
but I get the following errors:
"WARNING: 2015-10-10T07:00:16Z" elasticsearch.jquery.min.js:14:10575 Unable to revive connection: http://localhost:9200/ "WARNING: 2015-10-10T07:00:16Z" elasticsearch.jquery.min.js:14:10575 No living connections
I can connect using curl on the command line, just fine, pull and paste data, etc:
$ curl "localhost:9200/_cat/indices?v" health status index pri rep docs.count docs.deleted store.size pri.store.size green open fuddle 1 0 3 0 12.9kb 12.9kb green open faddle 1 0 0 0 144b 144b
Additional ETA Diagnostics. Google Chrome shows the following network paths for a failed attempt. At the HTTP level, the response looks like it is happening.
General Remote Address:[::1]:9200 Request URL:http://localhost:9200/?hello=elasticsearch! Request Method:HEAD Status Code:200 OK Response Headers Content-Length:0 Content-Type:text/plain; charset=UTF-8 Request Headers Accept:text/plain, */*; q=0.01 Accept-Encoding:gzip, deflate, sdch Accept-Language:en-US,en;q=0.8 Connection:keep-alive Content-Length:0 Host:localhost:9200 Origin:http://localhost Referer:http://localhost/~browsc3/Opticon/ User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.101 Safari/537.36 Query String Parameters view URL encoded hello:elasticsearch!
The same request in wget:
wget http://localhost:9200/?hello=elasticsearch! --2015-10-10 09:47:13-- http://localhost:9200/?hello=elasticsearch! Resolving localhost... ::1, 127.0.0.1 Connecting to localhost|::1|:9200... connected. HTTP request sent, awaiting response... 200 OK Length: 342 [application/json] Saving to: 'index.html?hello=elasticsearch!' index.html?hello=elastics 100%[=====================================>] 342 --.-KB/s in 0s 2015-10-10 09:47:13 (65.2 MB/s) - 'index.html?hello=elasticsearch!' saved [342/342]
I am really at a loss where to go from here. I see a lot of links to a bug on googlz, but none of these circumstances seem remotely similar. Looks like I'm just finding an error in the wrong configuration, but I can not find anything that could indicate what it is.