The elasticSearch runs fine on my centos as a non-service. I run it as
"sh bin/elasticsearch". The client I installed using composer is PHP
v2.0. It just won't do anything it used to do before. I used this before
and I could search, index documents, make index. Right now I cannot do
anything because of this error. The strangest thing is that
ElasticSearch seems to be running fine, and I can also call it with curl
like:
curl localhost:9200
Please advise on the PHP API failure? I tried:
Opening port 9200 on my centos 6 for all
Used every method from the book in PHP API: search, index, delete
index, etc...always get the sme result this exception is thrown in the
Elasticsearch/Client class
Changed the owner of the directory nodes to centos, apache, elasticsearch - no use.
I am assuming this is what installing it is doing: I got the certificate and now I point to it. This is the config and calling the delete action which throws the "...no alive nodes..." exception:
require 'autoload.php'; //to call the cert installer autoloader
SOrry for being brief, I'm tired of looking for a solution for this so much, I hardly know what I am writing..... 1.My node is up, I can see the stats when I call curl localhost:9200
2.I opened 9200 port completely for everyone
3.I DID notice that I have an SSL error when I try to call: curl https://localhost:9200
4.I don't user any kind of user/pass 5.So I don't have this problem either, I think.
So regarding 3. That's the probable cause, what do you recommend I do? thanks!
No problem, here to help As an aside, if you run into issues in the future feel free to drop a ticket at the ES-PHP repo...I tend to notice those faster.
Hmm, do you know what kind of error you are getting? Usually curl will spew some error code ("Curl error 7", etc) which can help debug the issue.
Are you using Shield? Elasticsearch doesn't have SSL support by default, so if you are trying to access a non-Shield node, SSL is probably failing because it doesn't speak SSL
I don't strictly need to use https, I thought maybe the PHP API client always uses it. If per default it doesn't (when I don't specify it in the setHosts method call), then something else is the problem, since I did try that (not calling the setHosts method) and got the same result. I also tried explicitly stating the host as ["http://localhost:9200"] - by calling this array in the setHosts method - to no avail.
Hi, I already copied and pasted the whole code to you. Which code exactly do you mean? Here is the snippet of the whole log, from the moment I close the server and run it again until the error hapens - it looks like it has not been even touched by my code, so this is not really useful:
[2016-01-27 21:51:11,405][INFO ][node ] [Black Goliath] stopping ...
[2016-01-27 21:51:11,465][INFO ][node ] [Black Goliath] stopped
[2016-01-27 21:51:11,466][INFO ][node ] [Black Goliath] closing ...
[2016-01-27 21:51:11,470][INFO ][node ] [Black Goliath] closed
[2016-01-27 21:51:16,682][INFO ][node ] [Pip the Troll] version[1.4.2], pid[21971], build[927caff/2014-12-16T14:11:12Z]
[2016-01-27 21:51:16,683][INFO ][node ] [Pip the Troll] initializing ...
[2016-01-27 21:51:16,687][INFO ][plugins ] [Pip the Troll] loaded [], sites []
[2016-01-27 21:51:19,698][INFO ][node ] [Pip the Troll] initialized
[2016-01-27 21:51:19,698][INFO ][node ] [Pip the Troll] starting ...
[2016-01-27 21:51:19,827][INFO ][transport ] [Pip the Troll] bound_address {inet[/0:0:0:0:0:0:0:0:9300]}, publish_address {inet[/172.31.49.3:9300]}
[2016-01-27 21:51:19,864][INFO ][discovery ] [Pip the Troll] elasticsearch/Lc0Jw6O6Q2eeuQD0L8eiCA
[2016-01-27 21:51:23,642][INFO ][cluster.service ] [Pip the Troll] new_master [Pip the Troll][Lc0Jw6O6Q2eeuQD0L8eiCA][ip-172-31-49-3][inet[/172.31.49.3:9300]], reason: zen-disco-join (elected_as_master)
[2016-01-27 21:51:23,697][INFO ][http ] [Pip the Troll] bound_address {inet[/0:0:0:0:0:0:0:0:9200]}, publish_address {inet[/172.31.49.3:9200]}
[2016-01-27 21:51:23,697][INFO ][node ] [Pip the Troll] started
[2016-01-27 21:51:24,582][INFO ][gateway ] [Pip the Troll] recovered [2] indices into cluster_state
Hm. Can you try both localhost:9200 and 127.0.0.1:9200 ? I ran into that issue on my Mac recently after the El Capitan update, something about the loopback devices got confused.
What platform are you on, btw?
Are you on the most recent version of ES-PHP (v2.1.4)?
I tried 127.0.0.1 too - no success.
Server is Centos. I need it on Centos (as I mentioned earlier). Our server is running on Centos. How can I know the version of the PHP API? Anyway, I remember I tried using previous versions, because I did use it before. I always get the same error. I can tell you which exact subversion I use, but I am sure it is version 2...
Gah, I'm really sorry...juggling issues on the forum in down-time of another task. Sorry for being distracted.
You can check your composer.lock file to see the currently used version. I'd recommend updating to most recent of ES-PHP, just to help rule out bugs in the client library.
Do you use SELinux policies on centos? Are those configured to allow "non-standard" ports? I've seen situations where libcurl is denied access to non-standard ports due to the SELinux policy, but regular curl commands (through the binary) work fine.
Otherwise I'm really not sure, will continue thinking about it. Sorry this has been such a hassle
Hi, I am sorry, it seems I mixed two servers, the one thatI need is centos and it doesn't even respond to curl localhost:9200, it just throws this error:
curl: (7) couldn't connect to host
Can you help me again, I need tis server up and running more than the one I asked you about earlier. I apologize for the mixup once again. Can you tell me what can be the reason for not even curl localhost:9200 being able to pull through?
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.