Develop Reference

Java Spring Rest Client Connection Reset Error

I have implemented rest client to consume a rest webservice using below code,
Client client = Client.create();
client.addFilter(new HTTPBasicAuthFilter(USERNAME,PASSWORD));
WebResource webResource = client.resource(URL);
ClientResponse clientResponse = webResource.type("application/json").accept("application/json").post(ClientResponse.class, REQUEST);
But I am facing below error,
com.sun.jersey.api.client.ClientHandlerException: java.io.IOException: Connection reset by peer
at com.sun.jersey.client.urlconnection.URLConnectionClientHandler.handle(URLConnectionClientHandler.java:155)
at com.sun.jersey.api.client.filter.HTTPBasicAuthFilter.handle(HTTPBasicAuthFilter.java:105)
at com.sun.jersey.api.client.Client.handle(Client.java:652)
at com.sun.jersey.api.client.WebResource.handle(WebResource.java:682)
at com.sun.jersey.api.client.WebResource.access$200(WebResource.java:74)
at com.sun.jersey.api.client.WebResource$Builder.post(WebResource.java:570)
at org.springframework.jms.listener.adapter.MessageListenerAdapter.onMessage(MessageListenerAdapter.java:339)
at org.springframework.jms.listener.AbstractMessageListenerContainer.doInvokeListener(AbstractMessageListenerContainer.java:535)
at org.springframework.jms.listener.AbstractMessageListenerContainer.invokeListener(AbstractMessageListenerContainer.java:495)
at org.springframework.jms.listener.AbstractMessageListenerContainer.doExecuteListener(AbstractMessageListenerContainer.java:467)
at org.springframework.jms.listener.AbstractPollingMessageListenerContainer.doReceiveAndExecute(AbstractPollingMessageListenerContainer.java:323)
at org.springframework.jms.listener.AbstractPollingMessageListenerContainer.receiveAndExecute(AbstractPollingMessageListenerContainer.java:241)
at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.invokeListener(DefaultMessageListenerContainer.java:1056)
at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.executeOngoingLoop(DefaultMessageListenerContainer.java:1048)
at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.run(DefaultMessageListenerContainer.java:947)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.io.IOException: Connection reset by peer
at sun.nio.ch.FileDispatcherImpl.readv0(Native Method)
at sun.nio.ch.SocketDispatcher.readv(SocketDispatcher.java:43)
at sun.nio.ch.IOUtil.read(IOUtil.java:278)
at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:440)
at weblogic.socket.NIOInputStream.readInternal(NIOInputStream.java:148)
at weblogic.socket.NIOInputStream.read(NIOInputStream.java:90)
at weblogic.socket.NIOInputStream.read(NIOInputStream.java:73)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
at java.io.BufferedInputStream.read1(BufferedInputStream.java:286)
at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
at weblogic.net.http.MessageHeader.isHTTP(MessageHeader.java:310)
at weblogic.net.http.MessageHeader.parseHeader(MessageHeader.java:232)
at weblogic.net.http.HttpClient.parseHTTP(HttpClient.java:554)
at weblogic.net.http.HttpURLConnection.getInputStream(HttpURLConnection.java:688)
at weblogic.net.http.SOAPHttpURLConnection.getInputStream(SOAPHttpURLConnection.java:41)
at weblogic.net.http.HttpURLConnection.getResponseCode(HttpURLConnection.java:1545)
at com.sun.jersey.client.urlconnection.URLConnectionClientHandler._invoke(URLConnectionClientHandler.java:253)
at com.sun.jersey.client.urlconnection.URLConnectionClientHandler.handle(URLConnectionClientHandler.java:153)
... 17 more
But If I restart the server this issue is not appearing for some time and again it appears. Has anyone faced similar issue ? I don't get any proper solution when googled.
I am using Weblogic Server in client side and rest service is also deployed in remote weblogic server.
EDIT- When I tried with curl command in the same server where it is throwing this error, it is retrieving the results.

Connection reset by peer" is the TCP/IP equivalent of slamming the phone back on the hook. It's more polite than merely not replying, leaving one hanging. But it's not the FIN-ACK expected of the truly polite TCP/IP converseur.
check here

Mule HTTP connection reset

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.

Elasticsearch MasterNotDiscoveredException Java Node Client

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?

Unknown hostname exception when trying to connect to qpid host

I am using qpid broker(0.28) and qpid JMS client to communicate to the broker. I want to use amqp1.0 protocol and when I try the example given here, using a connection url as amqp://guest:guest#localhost:5672?clientid=test, I get error as it is not able to connect to the qpid host
Caught exception: Unknown hostname localhostjavax.jms.JMSException: Unknown hostname localhost
at org.apache.qpid.amqp_1_0.jms.impl.SessionImpl.(SessionImpl.java:97)
at org.apache.qpid.amqp_1_0.jms.impl.ConnectionImpl.createSession(ConnectionImpl.java:231)
at org.apache.qpid.amqp_1_0.jms.impl.ConnectionImpl.createSession(ConnectionImpl.java:210)
at org.apache.qpid.amqp_1_0.jms.impl.ConnectionImpl.createSession(ConnectionImpl.java:40)
When I change my connection url to amqp://guest:guest#localhost:5672?clientid=test&remote-host=default I get an error as
Caused by: org.apache.qpid.amqp_1_0.client.Sender$SenderCreationException: Peer did not create remote endpoint for link, target: ping
at org.apache.qpid.amqp_1_0.client.Sender.(Sender.java:185)
at org.apache.qpid.amqp_1_0.client.Sender.(Sender.java:113)
at org.apache.qpid.amqp_1_0.client.Sender.(Sender.java:106)
at org.apache.qpid.amqp_1_0.client.Sender.(Sender.java:92)
at org.apache.qpid.amqp_1_0.client.Sender.(Sender.java:78)
at org.apache.qpid.amqp_1_0.client.Sender.(Sender.java:72)
at org.apache.qpid.amqp_1_0.client.Session$1.(Session.java:90)
at org.apache.qpid.amqp_1_0.client.Session.createSender(Session.java:89)
Can someone please help in understanding what exactly is happening? What wrong am I doing?

Jms Broker connection - Test the connection before listening to the queue - java

We have a message listener that listens to the Queue configured. When the Message broker is stopped or down, the application exits abruptly. Is there way to check the JMS broker connection before listening to the queue. The listener code must be enabled only if the JMS Broker is up. We are getting the below exception when we listen to the Queue (with the JMS broker down)
org.springframework.context.ApplicationContextException: Failed to start bean 'xx'; nested exception is org.springframework.jms.UncategorizedJmsException: Uncategorized exception occured during JMS processing; nested exception is javax.jms.JMSException: Could not connect to broker URL: tcp://xx:61616. Reason: java.net.ConnectException: Connection refused: connect
at org.springframework.context.support.DefaultLifecycleProcessor.doStart(DefaultLifecycleProcessor.java:176)
at org.springframework.context.support.DefaultLifecycleProcessor.access$200(DefaultLifecycleProcessor.java:51)
at org.springframework.context.support.DefaultLifecycleProcessor$LifecycleGroup.start(DefaultLifecycleProcessor.java:346)
at org.springframework.context.support.DefaultLifecycleProcessor.startBeans(DefaultLifecycleProcessor.java:149)
at org.springframework.context.support.DefaultLifecycleProcessor.onRefresh(DefaultLifecycleProcessor.java:112)
at org.springframework.context.support.AbstractApplicationContext.finishRefresh(AbstractApplicationContext.java:773)
at org.springframework.boot.context.embedded.EmbeddedWebApplicationContext.finishRefresh(EmbeddedWebApplicationContext.java:142)
at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:485)
at org.springframework.boot.context.embedded.EmbeddedWebApplicationContext.refresh(EmbeddedWebApplicationContext.java:120)
at org.springframework.boot.SpringApplication.refresh(SpringApplication.java:691)
at org.springframework.boot.SpringApplication.run(SpringApplication.java:320)
at org.springframework.boot.SpringApplication.run(SpringApplication.java:952)
at org.springframework.boot.SpringApplication.run(SpringApplication.java:941)

you can not test your connection to be active, as whenever you setup connection with activemq it only succeeds if you have an activemq server running.
A good option can be to do it in Java code by handling 'connection exceptions' and trying to re-connect after specific intervals till no exception occurs.This will help in scenario where ActiveMQ is down before you try and setup connection with it.
Hope it helps,
Good Luck!

Use the failover transport in your clients: failover:(tcp://host:port?TCP_OPTIONS)?FAILOVER_OPTIONS
When the connection isn't available (via the inner TCP transport), the failover transport will continue retrying until it is available and then establish the connection and let your client proceed as normal. This will look like the client is hung, but it's just waiting for the broker to become available before continuing. This configuration will also try to re-connect if the connection is broken for some reason (e.g. you restart your broker).
Most people use the failover transport to allow you to connect to whichever broker out of a group of N is available, but it's completely fine to use it with just one inner TCP transport; it will still try to reconnect periodically whenever it fails to connect to the single TCP transport.