Connection Error in worker thread

[oniseijin]

Using the client, and making a basic connection, a worker thread keeps on spitting out a connection error every 5 seconds.

Reproduce by using the client, and sleeping for 1 second. This does not seem to affect the functionality though.

Version: 1.0.3

Exception in thread "Thread-1" javax.ws.rs.ProcessingException: java.net.ConnectException: Connection refused: connect at org.glassfish.jersey.client.internal.HttpUrlConnector.apply(HttpUrlConnector.java:287) at org.glassfish.jersey.client.ClientRuntime.invoke(ClientRuntime.java:252) at org.glassfish.jersey.client.JerseyInvocation$1.call(JerseyInvocation.java:684) at org.glassfish.jersey.client.JerseyInvocation$1.call(JerseyInvocation.java:681) at org.glassfish.jersey.internal.Errors.process(Errors.java:315) at org.glassfish.jersey.internal.Errors.process(Errors.java:297) at org.glassfish.jersey.internal.Errors.process(Errors.java:228) at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:444) at org.glassfish.jersey.client.JerseyInvocation.invoke(JerseyInvocation.java:681) at org.glassfish.jersey.client.JerseyInvocation$Builder.method(JerseyInvocation.java:437) at org.glassfish.jersey.client.JerseyInvocation$Builder.post(JerseyInvocation.java:343) at org.symphonyoss.symphony.agent.invoker.ApiClient.invokeAPI(ApiClient.java:673) at org.symphonyoss.symphony.agent.api.DatafeedApi.v1DatafeedCreatePost(DatafeedApi.java:90) at org.symphonyoss.symphony.clients.impl.DataFeedClientImpl.createDatafeed(DataFeedClientImpl.java:95) at org.symphonyoss.client.services.MessageFeedWorkerV2.initDatafeed(MessageFeedWorkerV2.java:95) at org.symphonyoss.client.services.MessageFeedWorkerV2.run(MessageFeedWorkerV2.java:74) at java.lang.Thread.run(Thread.java:745) Caused by: java.net.ConnectException: Connection refused: connect at java.net.DualStackPlainSocketImpl.connect0(Native Method) at java.net.DualStackPlainSocketImpl.socketConnect(DualStackPlainSocketImpl.java:79) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:172) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) at java.net.Socket.connect(Socket.java:589) at sun.security.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:668) at sun.net.NetworkClient.doConnect(NetworkClient.java:175) at sun.net.www.http.HttpClient.openServer(HttpClient.java:432) at sun.net.www.http.HttpClient.openServer(HttpClient.java:527) at sun.net.www.protocol.https.HttpsClient.<init>(HttpsClient.java:264) at sun.net.www.protocol.https.HttpsClient.New(HttpsClient.java:367) at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.getNewHttpClient(AbstractDelegateHttpsURLConnection.java:191) at sun.net.www.protocol.http.HttpURLConnection.plainConnect0(HttpURLConnection.java:1105) at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:999) at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:177) at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1513) at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1441) at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:480) at sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:338) at org.glassfish.jersey.client.internal.HttpUrlConnector._apply(HttpUrlConnector.java:394) at org.glassfish.jersey.client.internal.HttpUrlConnector.apply(HttpUrlConnector.java:285) ... 16 more

[ftbb]

It actually does impact the functionality of real-time services (MessageService, ChatService, RoomService) and admittedly not the best implementation here.

Side note: You should check your connectivity to the Agent Server as this is the root cause of the event.

The SJC real-time datafeed (long-poll) automatically tries to recover itself from a network event.

The problem has been catching both runtime exceptions and more importantly showing the health of the upstream system. There have been some recent additions to the REST API on health checks and I believe I can bubble up the exceptions into the SJC that can be captured, leaving it up to the developer on how to handle the situation (manual shutdown / restart..etc.)

You are not the first one to report issues here, so I'm going to resolve for 1.1.0 milestone.

[PFSymphony]

Hi Frank, when do you think you will get 1.1 out? Oniseijin is working on an important piece for their compliance department that needs to get out shortly.
Is there anything specific he needs to check on the connectivity? the rest of the functionalities of his code seems to be working fine.

[ftbb]

Trying to squeeze in all the 1.48 goodies into it, so it's not this week but before Innovate.

The SNAPSHOT probably by this weekend.

So, what he can do right now with 1.0.3 is implement the health check through the REST API language binding which is exposed through SJC. This can be put into a background thread. At that point he can literally catch issues and restart the client (SymphonyClient.shutdown() first).

    apiClient = org.symphonyoss.symphony.agent.invoker.Configuration.getDefaultApiClient();
    apiClient.getHttpClient().register(MultiPartFeature.class);

    apiClient.setBasePath(agentUrl);

    SystemApi systemApi= new SystemApi(apiClient);

    V2HealthCheckResponse v2HealthCheckResponse = 
    systemApi.v2HealthCheckGet(symAuth.getSessionToken().getToken(), symAuth.getKeyToken().getToken());

     v2HealthCheckRespons.get....(call health checks)

[oniseijin]

I'll double check the Agent connectivity... for my use cases I didn't need to send messages, just get meta data from the pod; could be agent is down, but that exception is indeed too deep.

[ftbb]

Good news then! (I think)

v1.1.0-SNAPSHOT already implements a way to disable real-time services. This means the client is initialized with no services (this is what's long-polling). You will still have access to underlying client implementations (assume you are only using POD calls).

        SymphonyClientConfig symphonyClientConfig = new SymphonyClientConfig();

        //Disable all real-time services
        symphonyClientConfig.set(SymphonyClientConfigID.DISABLE_SERVICES, "True");

        //Create an initialized client
        symClient = SymphonyClientFactory.getClient(
                SymphonyClientFactory.TYPE.V4,symphonyClientConfig);

See: https://github.com/symphonyoss/symphony-java-client/blob/develop/examples/sendmessage/SendMessage.java

[oniseijin]

Thanks! managed to configure to the proper agent URL. Consider me your chaos monkey this month, but did flesh out a problem under the covers ;)