I am trying to connect with a Java application from localhost to my elasticsearch cluster on a root server. My problem is that the java client is not able to get a connection.
Ports 9200-9299 and 9300-9400 are opened on the root server(groupelite.de).
I configured my elasticsearch cluster to use unicast discovery and set its inet ip address as "network.host".
This is how I instantiate my client:
NodeBuilder.nodeBuilder()
.clusterName("neeedo-es")
.settings(ImmutableSettings.settingsBuilder()
.classLoader(classOf[Settings].getClassLoader)
.put("discovery.zen.ping.unicast.hosts", "groupelite.de:9300")
.put("node.name", "neeedo-client"))
.client(true)
.data(false)
.node()
And this is my elasticsearch.yml https://gist.github.com/MeiSign/ccfdcc62643c1185bab3
The firewall on the server should be turned off. You can also reach es with http http://www.groupelite.de:9200/
The server is running ubuntu 14.04. Elasticsearch version is 1.4.2 on client and server.
Iam not very used to networking stuff but I hope to get some ideas from you guys what is wrong.
Edit 1:
The server log is showing a ConnectionClosed Exception from time to time. But it does not appear when the client tries to connect, you cant see the client in the logs at all.
[2015-01-31 18:31:45,921][WARN ][transport.netty] [neeedo-s1] exception caught on transport layer [[id: 0x1685f631]], closing connection
java.net.SocketException: Network is unreachable
at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:716)
at org.elasticsearch.common.netty.channel.socket.nio.NioClientBoss.connect(NioClientBoss.java:152)
at org.elasticsearch.common.netty.channel.socket.nio.NioClientBoss.processSelectedKeys(NioClientBoss.java:105)
at org.elasticsearch.common.netty.channel.socket.nio.NioClientBoss.process(NioClientBoss.java:79)
at org.elasticsearch.common.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:318)
at org.elasticsearch.common.netty.channel.socket.nio.NioClientBoss.run(NioClientBoss.java:42)
at org.elasticsearch.common.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108)
at org.elasticsearch.common.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Edit 2:
I have found out that it works when I use a transport client in my application. Does this give any hint what is wrong?
Related
I have mule application deployed on tomcat Web-Server. i am exposing web service and using the below HTTP connector
<http:inbound-endpoint host="0.0.0.0" port="9198" path="customer/payment/debit" exchange-pattern="request-response">
<mule-ss:http-security-filter realm="mule-realm" securityProviders="userprovider" />
</http:inbound-endpoint>
then i am using jaxws-service for publish the web-service
<cxf:jaxws-service serviceClass="com.cit.wsdl.customer.payment.debit.v1_0.PaymentDebit" service="PaymentDebitService" soapVersion="1.2" />
the problem that i am getting the below error :
ERROR org.mule.module.logging.DispatchingLogger : Caught exception in
Exception Strategy: Connection resetjava.net.SocketException:
Connection reset at
java.net.SocketInputStream.read(SocketInputStream.java:196) at
java.net.SocketInputStream.read(SocketInputStream.java:122) at
java.net.SocketInputStream.read(SocketInputStream.java:210) at
org.apache.commons.httpclient.HttpParser.readRawLine(HttpParser.java:78)
at
org.apache.commons.httpclient.HttpParser.readLine(HttpParser.java:106)
at
org.mule.transport.http.HttpServerConnection.readLine(HttpServerConnection.java:243)
at
org.mule.transport.http.HttpServerConnection.getRequestLine(HttpServerConnection.java:509)
at
org.mule.transport.http.HttpRequestDispatcherWork.run(HttpRequestDispatcherWork.java:70)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
The client get the below error :
"Exception: An error occurred while receiving the HTTP response to
http://10.255.142.36:9198/customer/payment/debit. This could be due
to the service endpoint binding not using the HTTP protocol. This
could also be due to an HTTP request context being aborted by the
server (possibly due to the service shutting down). See server logs
for more details. "
The above error is happened randomly but there are requests successfully received to the server and handled by mule.
'java.net.SocketException: Connection reset' is not something failing in Mule OR tomcat, but it is failing at tcp level.
Looks like Http(application) level communication established between client and Mule/tomcat(as tcp acknowledgement received from server) and then tcp connection got reset, to figure out root cause you need to use wireshark. alternately you need to make sure there is no network connection drop.
I'm using couchbase-client 2.3.2 for Java and Couchbase server Community 4.0
So I'm experimenting with running Couchbase on non-standard ports using the documentation at Couchbase website
I've managed to start Couchbase using these alternate ports but I've only managed to change some of the ports in the java client, here's my code:
final CouchbaseEnvironment env = DefaultCouchbaseEnvironment.builder()
.bootstrapCarrierDirectPort(21210)
.bootstrapHttpDirectPort(9091)
.build();
return CouchbaseCluster.create(env, "10.0.2.15");
My program is able to connect to couchbase and so some things, however I still need to change the view port (default 8092) and the query port (default 8093) in the client. as a result I'm met with these errors:
2016-09-30 14:03:49.696 [] WARN c.c.c.c.e.Endpoint - [null][QueryEndpoint]: Could not connect to endpoint, retrying with delay 32 MILLISECONDS: ! java.net.ConnectException: Connection refused: /10.0.2.15:8093
2016-09-30 14:03:52.077 [] WARN c.c.c.c.e.Endpoint - [null][ViewEndpoint]: Could not connect to endpoint, retrying with delay 2048 MILLISECONDS: ! java.net.ConnectException: Connection refused: /10.0.2.15:8092
So the client still tries to connect to 8092 and 8093 when in fact I've changed those to 9092 and 9093
From the JavaDoc on 2.3.4 (http://docs.couchbase.com/sdk-api/couchbase-java-client-2.3.4/), I believe what you want is this:
DefaultCouchbaseEnvironment.Builder viewEndpoints(int viewServiceEndpoints)
Even though it's completely undocumented, you need to add those ports to static_config as well:
{capi_port, 9092}.
{query_port, 9093}.
and then it works, hope someone at couchbase sees this and updates their documentation :)
I have elasticsearch running on a windows machine (10.0.0.51 on my network). I have deployed an app to a linux virtual machine (10.0.0.10). When my app starts it tries to connect to Elasticsearch and create a node using the Java API:
node = nodeBuilder().client(true).clusterName(CLUSTER_NAME).node();
client = node.client();
However in the Elasticsearch console I get the error:
[2015-04-15 14:28:10,559][WARN ][discovery.zen.ping.multicast] [Matt Murdock] failed to connect to requesting node [Gatecrasher][dFF2VpWTQvCrilRKyVSC5Q][localhost.localdomain][inet[/10.0.0.10:9300]]{data=false, client=true}
org.elasticsearch.transport.ConnectTransportException: [Gatecrasher][inet[/10.0.0.10:9300]] connect_timeout[30s]
at org.elasticsearch.transport.netty.NettyTransport.connectToChannels(NettyTransport.java:797)
at org.elasticsearch.transport.netty.NettyTransport.connectToNode(NettyTransport.java:731)
at org.elasticsearch.transport.netty.NettyTransport.connectToNode(NettyTransport.java:704)
at org.elasticsearch.transport.TransportService.connectToNode(TransportService.java:216)
at org.elasticsearch.discovery.zen.ping.multicast.MulticastZenPing$Receiver$1.run(MulticastZenPing.java:542)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.net.ConnectException: Connection timed out: no further information: /10.0.0.10:9300
at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:716)
at org.elasticsearch.common.netty.channel.socket.nio.NioClientBoss.connect(NioClientBoss.java:152)
at org.elasticsearch.common.netty.channel.socket.nio.NioClientBoss.processSelectedKeys(NioClientBoss.java:105)
at org.elasticsearch.common.netty.channel.socket.nio.NioClientBoss.process(NioClientBoss.java:79)
at org.elasticsearch.common.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:337)
at org.elasticsearch.common.netty.channel.socket.nio.NioClientBoss.run(NioClientBoss.java:42)
at org.elasticsearch.common.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108)
at org.elasticsearch.common.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42)
... 3 more
I can connect to Elasticsearch when running both apps from the same machine.
UPDATE:
I just loaded elastic search on to the same VM as my app and I couldn't connect. I can only connect when running my app from and Elastic search on the same windows machine.
It was a network issue with my Linux machine. I did various things including turning ofrf the firewall and it started working. I think that the firewall was blocking access.
I am getting
Caused by: java.net.NoRouteToHostException: No route to host
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:351)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:213)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:200)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
at java.net.Socket.connect(Socket.java:529)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:564)
at sun.reflect.GeneratedMethodAccessor638.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.commons.httpclient.protocol.ReflectionSocketFactory.createSocket(ReflectionSocketFactory.java:140)
at org.apache.commons.httpclient.protocol.SSLProtocolSocketFactory.createSocket(SSLProtocolSocketFactory.java:130)
at org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:707)
at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:387)
at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:171)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:323)
javadoc says
Signals that an error occurred while attempting to connect a socket to
a remote address and port. Typically, the remote host cannot be
reached because of an intervening firewall, or if an intermediate
router is down.
Is this error on client side or remote side or it can be either of these?
Basically it says that your client cannot connect to the server due to the address is inaccessible from the client machine.
Please check that the address you are connecting to is accessible, either via ping command in your Command Prompt (Windows) or terminal (Unix-based):
ping <address>
or if it's a web server you can try to check it in your web browser.
The ping command is helpful for me in most cases, since I would know why exactly I can't connect to the address. It can be a mistyped address or like the javadoc suggests, problem with firewall.
Either. It could be a firewall on the client machine blocking outgoing calls or somewhere at the other end.
It may be possible the ping will provide responses, but the application may still fail to connect.
If that is the case, I would suggest using telnet to try and connect to the host using the desired port, telnet host.address port
If the connection is refused then the port on the host will need to be allowed. It that succeeds, but the application still won't connect:
Verify the address:port being used in your application are the same as those used in the telnet test.
It may be a local port on the client blocking the connection, in which case you would need to allow the port on the client
In my case it was solved like this:
1 - Clear the cache with 'yarn cache clean' or 'npm cache clean --force'
2 - after that reboot the pc.
If you clear the cache but do not reboot, the data will still be stored 'somewhere' on the network, so the port will not connect, it is still busy.
After restarting it connects smoothly.
I hope I was helpful!
I had the same issue, and resolve it by disabling the firewall on both sides :
systemctl disable firewalld
service firewalld stop
I had the same issue, I did run iptables flush on host server, this fixed the issue.
# iptables --flush
When I try to connect to cassandra within my java application I receive the exception at the end of this message. I am using pelops library to access database. Database is working on linux and my development environment is on windos 7. Intresting line is
WARNING: 10.0.0.7 NodeContext killing all pooled connections for session 44
10.0.0.7 is the IP of the cassandra node. And I can connect this node with cassandra-cli. After a few hours of googling I decided to ask, what i am doing wrong?
Complete stack trace is below.
SEVERE: org.apache.thrift.transport.TTransportException: java.net.ConnectException: Connection refused: connect
at org.apache.thrift.transport.TSocket.open(TSocket.java:185)
at org.wyki.cassandra.pelops.ThriftPool$Connection.open(ThriftPool.java:329)
at org.wyki.cassandra.pelops.ThriftPool$NodeContext.createConnection(ThriftPool.java:438)
at org.wyki.cassandra.pelops.ThriftPool$NodeContext.access$5(ThriftPool.java:429)
at org.wyki.cassandra.pelops.ThriftPool$NodeContext$1.run(ThriftPool.java:494)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.net.ConnectException: Connection refused: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
at java.net.Socket.connect(Socket.java:529)
at java.net.Socket.connect(Socket.java:478)
at org.apache.thrift.transport.TSocket.open(TSocket.java:180)
... 7 more
WARNING: 10.0.0.7 NodeContext killing all pooled connections for session 44
"Connection refused" means that Cassandra isn't listening on the interface you're connecting to. By default Cassandra listens on port 9160 on localhost. You will need to change that if you want to connect externally; read the comments for ThriftAddress in the configuration file.
Pelops isn't doing anything remotely tricky when it comes to making connections to Cassandra so it seems very unlikely it's Pelops specific.
I've just had a quick look at the Hector connection code and it looks pretty much the same:
https://github.com/rantav/hector/blob/master/core/src/main/java/me/prettyprint/cassandra/connection/HThriftClient.java
The cassandra-cli code looks pretty much the same as well:
https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/cli/CliMain.java#L57
p.s. Cassandra should not be configured to listen on 0.0.0.0. See the "Why can't I make Cassandra listen on 0.0.0.0 (all my addresses)?" on the Cassandra FAQ.
It seems that this is a problem with pelops, which is a library on top of cassandra's thrift client. It has some problems for connection to Cassandra working on linux and client on a windows machine.
I've got the same exception connecting with "any" client to cassandra remotely:
ConnectException: Connection refused
Looking through SO I couldn't find a quick solution for that, just reading carefully through cassandra docs and comments within cassandra.yaml - they are very handy!
So for me worked following:
change rpc_address value to the hostname or ipaddress you are using to connect to the cassandra instance with the client