I am using SignalA android client library in my android application for getting real time data push from server.
i am able to establish the connection with server using HubConnection specified in SignalA framework. After some time(10 or 5 mins once), SignalA tries to reconnect the connection, that i could captured in the callback method(onStateChanged) of HubConnection. Once the connection state was reached 'Reconnecting' state, it is not connecting with the Server further. It always retains the same state as 'Reconnecting'. it is not establishing the connection again.
In this scenario, i am failing to get push from server.
Can anyone provide the solution on this like how can i establish the connection again?
Check out the new version of SignalA. This was a bug that is hopefully fixed in the new version.
Related
I'm trying to make a communication between my App and the server side. The app needs to receive messages from the server because it's remotely controlled. It works as a Background Service.
I'm currently getting the messages from the external MySQL by using HTTPPost, doing requisitions every 20 seconds, but it spends much battery.
I tried doing a Socket connection to a server (build in java): device connects to the server every 20 seconds and close the conn when it just receive the data, but it also spends much battery.
Is there a way of receiving these messages instantly as Whatsapp does?
If the app is open it's most likely a socket connection. This is usually how messengers work.
In the background though it's most probably using push notifications (Check FCM - Firebase Cloud Messaging). This source of info can be unreliable so making a service with requests once a minute or two could be cool
In our messenger, we use long-live HttpsURLConnection as the main channel. The connection is hosted in Service and it is run in separate thread. In case of disconnect, we try to establish a new one. And we stop the service after our application is inactive for 2 minutes.
As the second channel, we use FCM.
This is what concerns messages. We also use WebRTC for multimedia data transfer. And we are going to use SIP calls to init voice- and video- call.
I am using eclipse milo java OPCUA client SDK in our app for OPC implementation.
I am able to create session, subscription and monitor. It is working fine
but when opc server restarts and I try to delete previous session and create a new one with same parameters I get the below exception:
UaException: status=Bad_Timeout, message=timed out waiting for
acknowledge
The line which throws the error is:
EndpointDescription[] endpoints =
UaTcpStackClient.getEndpoints(endpointurl).get();
On server side I get the error:
OPCUAServerEndPoint#_on_client_connection The maximum number of
connection has b een reached - Connection is refused
However, when I try to create the session again with same parameters it does get created
You shouldn't be creating a session by yourself as this is handled for you by the client, and you definitely shouldn't be trying to delete the previous session.
The only thing you need to do is add a SubscriptionListener to the OpcUaSubscriptionManager and handle the onSubscriptionTransferFailed callback.
Receiving this callback means that the client has reconnected and had to create a new session, but the server was unable to transfer its old subscriptions to this session. This usually happens when either it took too long to reconnect and the subscriptions timed out or if something causes the server to lose all of its state, e.g. it gets restarted.
I've added a somewhat convoluted integration test that demonstrates that all of this does indeed work, you can see it here.
I am making rest call to IBM Cloud BPM. Some times calls are working fine.But sometimes it is giving following error.
java.io.IOException: An existing connection was forcibly closed by the remote host.
java.io.IOException: An existing connection was forcibly closed by the remote host
at sun.nio.ch.SocketDispatcher.read0(Native Method)
at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:43)
at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223)
Can any one help me on how to solve this issue.
Any help is greatly appreciated.
Such behavior could be explained if the HTTP Client you use opens persistent connections to the server, and the server occasionally terminates them.
Normally, the connection to an HTTP server is closed after each response. With HTTP "keep-alive" you keep the underlying TCP connection open until certain criteria are met. What those conditions are depends on the server, which is free to close the connection after an arbitrary timeout or number of requests (just as long as it returns the response to the current request).
When the server closes such a connection the client usually reopens it again, and depending on implementation, may throw an exception or print a warning.
For example, Vert.x HttpClient (which opens persistent connections by default) also throws...
java.io.IOException: An existing connection was forcibly closed by the remote host
...when the server terminates them.
I had this error when consuming my API from an outside PC, but when calling from the same PC it worked fine.
To fix to, I went to Control Panel
Right click in Java icon
Go to Advanced Tab
Then check Enable Operating System's restricted environment
Apply and Save
This fixed my problem.
I have faced same issue on windows server.
Then I checked memory utilization of server and it taking more memory so my application is not running.
I have singoff some user profile from
Task Manager-->Users Tab--> Right click and Sign Off
This solution worked for me.
I am developing an Instant chat messaging Application using XMPP framework in android. Chat works fine while I am on chat screen. But if I minimize the app i.e If I put the app in the background on receiver end then also chat works fine while I am continuing sending messages. But when I stop sending messages and leaving the app in background on receiver end then after a certain duration may be like 30 mins or an hour if try to send a new message, it stops receiving messages.
I think the reason should be that XMPP connection is getting broken for some reason. Is there any way to mantain the connection for forever so that it never gets broken. Or do we need to run a service in background in order to do that. If yes please tell me the code for doing so.
Thanks in advance.
One possible solution is to select 'Do not disconnect clients that are idle.'
in the connection manager of openfire web admin.
Open your admin console and go to Server > Server settings > Client connections > Idle connection policy (http://127.0.0.1:9090/client-connections-settings.jsp). Then select the option 'Do not disconnect clients that are idle'.
In this way, openfire won't disconnect inactive users.
I have a RED5 application, which works under Red5 0.8.0 (although it drops the connection on RTMPT after couple seconds). I've checked out the latest revision (which is 4441) and made some changes to the app. Now I cannot connect to the application. I get everytime - NetConnection.Connect.Rejected.
In the logs I see:
[INFO] [http-0.0.0.0-80-exec-3] org.red5.server.net.rtmp.codec.RTMPProtocolDecoder - Action connect
[WARN] [Red5_Scheduler_Worker-3] org.red5.server.net.rtmp.RTMPConnection - Closing RTMPMinaConnection from 0:0:0:0:0:0:0:1%0 : 52966 to localhost (in: 3458 out: 3262), with id 1 due to long handshake
The handshake time is set to 15 seconds, so it must be enough. In the logs I am not even getting any attempts to try to connect. I have a log with the method name in start, connect, disconnect methods, however these won't be shown.
Can anyone help?
due to long handshake can also mean you have still some browser window open that tries to connect to the application after you did re-start red5.
You always have to close all browser windows when you restart red5.
Also the first thing you need to look at is the red5/error.log.
Nothing else counts :)
I guess you have some startup issue, Red5 0.8 are not 100% compatible to latest versions.
Sebastian
A possible case of connection rejection from the server is user authentication failure.If you implement that in the connect method of your application check that the user gets authenticated. RTMP connection closure just tells you that the server pinged the client after every X ms and after certain number of such trials server got no response from the client(which is called as handshake timeout).In that case server closes the connection with the 'idle' client.