The client doesn't check for an active connection on its own, and instead relies on the network API response.
On a user command, the client prepares a REST request to the PubNub API and passes it to the networking API for processing. If there were no issues and the response arrived in time (the timeout is configurable), the results are parsed and wrapped into objects which are returned using callbacks.
If there was an issue during request processing, the networking API returns information about the error, which is then parsed and wrapped into objects and returned to the caller.
In case of network issues, realtime APIs return a status object with its category set to
There are also a set of other error categories:
PNNetworkIssuesCategory - no network connection when the client tried to send the request.
PNTLSConnectionFailedCategory - TLS handshake issues, generally due to poor connection quality and packet loss/delays.
PNTimeoutCategory - no response received before the specified timeout.
PNUnknownCategory - non-200 HTTP response code received from the server.
The Heartbeat API can be used as way to detect when network issues appear. Heartbeats send a request at a set interval (configured during client instance configuration) and use the observer's callback to report successful and failed attempts. If the network quality degrades between calls to this API, a socket with an active long-poll (subscribe API for realtime messages) may not notice those issues and end up listening for events on a broken pipe.
These status events may indicate network issues:
PNNetworkIssuesCategory. Java V4 has exclusive statuses that can reveal deeper information about the network from the browser APIs.
This status may arrive if a non-subscribe request doesn't receive a response from the server in time. This may happen only if:
- There are issues on the service itself
- There is a proxy between the client and the PubNub service, and the proxy doesn't send the request or return a response in time
- There are issues with poor network signal quality (or there is a lot of noise on the band)
No connection at the moment the request is sent. This status is returned immediately to the calling API through a callback.
- During subscription API usage, the client stumbled on a network issue or an unexpected response has been received.
- There were network issues and the networking API reported back to our SDK to generate error.
- service itself (may happen only if data provided to client has been malformed and break composed URI) or intermediate software (proxy server) returned response which can't be parsed by subscribe parser.
This status is exclusive to Java V4 and indicates that the browser reported network stability and the SDK was instructed to reconnect. This status is the first status fired after a connectivity disruption.
This status is exclusive to Java V4 and indicates that the browser reported network instability and the SDK has lost its connection to the host. This status is fired, but there are no guarantees on the chain of events (for example, the subscribe may time out first); in this situation, everything is dependent on the browser.
PNUnexpectedDisconnectCategory which can be generated in the middle of client lifecycle while it subscribed to real-time data channels.
In case that this status arrives, client starts pinging PubNub services using Time API every 10 seconds. As soon as a request is processed successfully, client will try to restore subscription on channels on which it was subscribed previously. If configured to keep timetoken on subscription restore, client will try to catch up on missed messages.
When client completes subscription restore after
PNUnexpectedDisconnectCategory it will generate
PNReconnectedCategory to notify observers what client has been reconnected to real-time data channels.
If more than 100 messages will arrive (from PubNub in-memory messages cache), it is better to use history API to fetch potentially missed messages. To be notified about this case,
requestMessageCountThreshold should be set to 100 - this will tell client to send
The Java V4 platform ships with reconnection policy disabled by default and can be enabled by setting
PNConfiguration to one of the following values:
PNReconnectionPolicy.NONE- indicates that
NOaction will taken when there is a network or internet issue.
PNReconnectionPolicy.LINEAR- SDK will try to reconnect each 3 seconds.
PNReconnectionPolicy.EXPONENTIAL- SDK uses the Exponential Backoff algorithm to reconnect when there is a network or internet issue. SDK uses
32seconds. See: https://en.wikipedia.org/wiki/Exponential_backoff for more details.
On some platforms, application owners have more visibility into networking conditions than the SDK. You can call the pubnub.reconnect() on each of the SDKs to force the SDK to try and reach out PubNub.
403 response on a subscribe event occurs when Access Manager is enabled and the user doesn't have access to the
channel or the
grant TTL has expired. In this case you need to create a new auth key, grant access to the user (from your server) and subscribe again.
For more info please check: http://www.pubnub.com/docs/java-se-java/pam-security#handling-permission-denied-errors