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

StompBrokerRelayMessageHandler - many log errors

We use spring websockets with tomcat 7 over stomp and sockjs.
Our log is filled with errors of such:
[WEBAPP] 16 Aug 2015 08:11:24 ERROR StompBrokerRelayMessageHandler - Failed to forward DISCONNECT session=7ufvyfvf
[WEBAPP] 16 Aug 2015 08:13:47 ERROR StompBrokerRelayMessageHandler - Failed to forward DISCONNECT session=d017bxnq
Any ideas why? and how can we remove\mitigate this?

Sorry, I'm a little bit late. Nevertheless, was confronted with the same/similar problem. I guess you're using a messagebroker like rabbitmq.
ERROR StompBrokerRelayMessageHandler:584 - TCP connection failure in session uwdglayp: Transport failure: Connection reset by peer
Sometimes it is a forward failure, often connection failure.
What did I do? After changing the logging level to debug, I figured out, that the spring application sends two DISCONNECT messages to the messagebroker.
Calling stomp.disconnect() on client side results in sending a DISCONNECT message (STOMP) and in closing the socket (socketJS).
The StompBrokerRelayMessageHandler informs the Broker about the DISCONNECT message and additionally sends a DISCONNECT, because the socket was closed by the client, both async. There is no chance that Spring can catch the second disconnect and the second disconnect will occur in an error.
What specifies STOMP? (DISCONNECT SPEC)
A client can disconnect from the server at anytime by closing the socket but there is no guarantee that the previously sent frames have been received by the server
My solution:
Modify the STOMP Client and just close the socket without sending a DISCONNECT message (client will close socket)
Another solution:
Send only a DISCONNECT message (spring will close socket)
I'll check other implementations of STOMP to find a better solution.

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?

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.

CXF Timeout not working

I created a web service client using cxf configured through Spring as shown below:
<!-- HTTP Conduit -->
<http-conf:conduit name="*.http-conduit">
<http-conf:client ConnectionTimeout="30000"
ReceiveTimeout="30000" />
</http-conf:conduit>
<!-- Client Proxies -->
<jaxws:client name="wsClient" serviceName="..."
serviceClass="..."
address="..." wsdlLocation="...">
</jaxws:client>
Now when the service is up, everything's working OK, But the problem is, when the service is down timeout values in the HTTPConduit are being ignored and I get the following error after 1 second:
org.apache.cxf.interceptor.Fault: Could not send Message.
at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:64)
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:263)
at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:570)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:479)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:382)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:335)
at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96)
at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:136)
Caused by: java.net.ConnectException: Tried all: '1' addresses, but could not connect over HTTP to server: '192.168.80.55', port: '24004'
at weblogic.net.http.HttpClient.openServer(HttpClient.java:333)
at weblogic.net.http.HttpClient.openServer(HttpClient.java:425)
at weblogic.net.http.HttpClient.New(HttpClient.java:252)
at weblogic.net.http.HttpURLConnection.connect(HttpURLConnection.java:213)
at weblogic.net.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:279)
at org.apache.cxf.transport.http.HTTPCon2014-08-30 13:06:59 ERROR: javax.xml.ws.WebServiceException: Could not send Message.
Any clue why the consumer doesn't stay for the timeout duration before raising this error?

Timeout does not apply when the server is 'down'.
The ConnectionTimeout is how much to wait before connecting.
The ReceiveTimeout is how much to wait before receving a response.
In your case, there is no server listening on that port, so when your clients try to connect, the clients fails immediatly.

What do you mean by 'down'? Service responds with a 404? Closed port (connection refused)? Host is down (no connection possible due to timeout)?