0

While exploring Streaming API, found the API documentation and have gone through that. To integrate this the documentation mentions that Bayeux client is needed, for which CometD API is suggested. I had a few questions related to that:

  • Since it provides real-time updates/events, doesn't have a dedicated thread open between the two servers, the integration server(subscriber) and Salesforce server(publisher). Especially because CometD uses long polling.

  • So, if the answer to the above one is true and there is indeed a dedicated thread, then is that thread shared between subscribed Push Topics or a dedicated thread for each subscribed Push Topic.

  • What would be the maximum number of dedicated threads blocked continuously, between publisher and subscriber.

  • Any way to avoid these dedicated threads and make this communication between publisher and subscriber as asynchronous.

| improve this question | |
1

[Disclaimer, I'm the CometD lead, so I can answer about CometD - what SalesForce uses may be slightly different although for this particular question I think the answer below holds for SalesForce too]

CometD is based on non-blocking I/O and therefore it does not need a dedicated thread per connection. This is true for both HTTP (long-polling) and WebSocket transports.

The communication between subscriber and publisher is already completely asynchronous and non-blocking.

| improve this answer | |
  • Thanks for the answer. But still curious how does CometD provide real time updates. If there is no open thread between the ServerA(event producer) and ServerB(event subscriber), then how would ServerA notify ServerB that an event has occurred on a topic of interest. Are there any ports opened up on ServerB(event subscriber) to get notified? -Thanks Nagesh – Nagesh Borate Sep 26 '17 at 9:29
  • I did not say that there is no thread. Non-blocking I/O works in a way that one thread (or just few threads) listen for I/O events on a large number of sockets (typically thousands per thread). When the producer sends data on a socket to the consumer, the thread waiting for I/O events is woken up and can handle the event. There is not a thread per connection, but a thread for all connections. How the I/O event is then handled is an implementation detail. Some implementations use the same thread, some dispatch the handling to a new thread. – sbordet Sep 26 '17 at 13:15

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.