7

The documentation is not clear on how long a subscription is good for. I have found references (forums posts) that say 2 hours but unable to find a documented source within SF docs. However, this part has me a bit perplexed (all quotes from docs):

(emphasis mine)

The client receives events from the server while it maintains a long-lived connection.

  • If no events are generated and the client is waiting and the server closes the connection, after two minutes the client should reconnect immediately.

--

Socket timeout: 110 seconds

A client receives events (JSON-formatted HTTP responses) while it waits on a connection. If no events are generated and the client is still waiting, the connection times out after 110 seconds and the server closes the connection. Clients should reconnect before two minutes to avoid the connection timeout.

The docs on the protocol state

Long polling, also called Comet programming, allows emulation of an information push from a server to a client. Similar to a normal poll, the client connects and requests information from the server. However, instead of sending an empty response if information isn't available, the server holds the request and waits until information is available (an event occurs). The server then sends a complete response to the client. The client then immediately re-requests information. The client continually maintains a connection to the server, so it’s always waiting to receive a response. In the case of server timeouts, the client connects again and starts over.

Testing summary

I had a Lightning component open and subscribed. Waited 90 seconds and sent the API request to update the subscribed record. The message was received. Waited 60 more seconds and updated again and the message was received. So at least in this minimal test neither of the above appears to be true. I think I am misreading it or something....

I guess I may be missing some terminology assumptions or related information that provides clarity.

Q: Once you establish a connection and subscribe to the push topic, do you have to resubscribe/connect every 110 seconds if no events are received or not...

Bonus If the answer is yes to the above, how would you do this in Lightning. Would using a set timeout for close to two minutes be the correct way

  • By any chance did you do some testing to validate that after 110s you would need to resubscribe your topic? (still needs clarification in the doc) I personally don't recall having to resubscribe my topic after 110 seconds of not receiving events. However, that was a while back.. 2Yrs+ – glls May 9 '17 at 17:04
  • It did not seem to need it but I need to confirm before I just blindly assume. For all I know it could be a "soft" enforce and start to fail when installed in subscriber orgs or something. – Eric May 9 '17 at 17:33
1
+200

I can say from personal experience that the subscription to the channel does not seem to require a re-subscription every now and then(be it 110s, 2 mins, or 2 hrs).

About a year ago I created a PushTopic and subscribed to it for a test project and stopped using it almost immediately.

enter image description here

Today, I went back to my dev org and updated/ created a new case and my test visualforce page immediately got the updated and created cases pushed in the view.

So, In my experience, you don't need to re-subscribe to the Push topic once you have created and subscribed to it, even if there are no events received.

I think the 2 hour duration might be in reference to the duration of the session, since when you init cometd you use the session id in the request headers. However, as you are aware, the session expires after 2hrs of inactivity (default). So this does not really apply to the subscription of the Pushtopic.

from the Force.com Cookbook

The session timeout value is the amount of time a single session ID remains valid before expiring. Sessions expire automatically after a predetermined length of inactivity, which can be configured in Salesforce.com by clicking Setup | Security Controls. The default is 120 minutes (two hours). If you make an API call, the inactivity timer is reset to zero.

In the end, the protocol's documentation would seem the most accurate, specifically:

The client continually maintains a connection to the server, so it’s always waiting to receive a response. In the case of server timeouts, the client connects again and starts over.

Since the client connects using long polling, the event is supposed to generate a request, and a handshake is done.

So, the client receives events from the server while it maintains this long-lived connection. I believe this is the Streaming part, no new handshake seems to be done, responses for each event are sent from the server to the client until any of the below 2 scenarios occur according to using_streaming_api_client_connection:

If the client receives events, it should reconnect immediately to receive the next set of events. If the reconnection doesn't occur within 40 seconds, the server expires the subscription and the connection closes. The client must start over with a handshake and subscribe again.

If no events are generated and the client is waiting and the server closes the connection, after two minutes the client should reconnect immediately.

When the documentation states:

The client must start over with a handshake and subscribe again.

OR

the client should reconnect immediately.

it is simply describing the behavior of the client, not that you would have to trigger or do the request yourself for a new handshake.

  • Right, not speaking of the actual creation of the push topic. That is available until is is remove. the question is once the VF page starts listening. Specifically as related to the information in the question around the socket timeouts and the need to resubscribe as outlined in the documentation (thats does not appear to be accurate) – Eric May 13 '17 at 21:44
  • You are right, it is'int. However, the subscription is based on the sessionid, so as long as it is valid, cometd will continue streaming the items you subscribed to. – glls May 14 '17 at 1:00
  • How does that reconcile with "f no events are generated and the client is still waiting, the connection times out after 110 seconds" in the documentation? – Eric May 14 '17 at 1:16
  • let me update the last paragraph to answer that, since this is the confusing part of the documentation =P – glls May 14 '17 at 1:23
  • Like I said. If my vf is waiting there for an event (is is the client) then according to the documentation if no events are received within 110 seconds/2 minutes I would need to re-subscribe.....also your quotes are a bit off. can you include links where you got them from cause they are diff than the docs - This (your quote) "If no events are generated and the client is waiting and the server closes the connection, after two minutes the client should reconnect immediately." is different than the docs and says something totally different – Eric May 14 '17 at 1:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.