I can't seem to find any configuration variable etc. for the polling interval that cometd uses for the subscription channels.

As it polls every second or so, I am hitting the max events per 24h very quickly.

Is there any way to decrease the polling interval so that I can save on the number of events?

Also is there anything that I'm missing here:

    url: window.location.protocol+'//'+window.location.hostname+'/cometd/24.0/',
    requestHeaders: { Authorization: 'OAuth {!$Api.Session_ID}'}

// Subscribe to a topic. JSON-encoded update will be returned in the callback
$.cometd.subscribe('/topic/Channel', function(message) 
    // do stuff here


1 Answer 1


I'm not an expert, but my reading of the Bayeux protocol is that the server holds the cards with respect to polling intervals etc.

That said, my understanding of the Streaming API limits is that event refers to the number of update events (i.e. rows), not the number of polls. I do not think that increasing the polling interval would solve your problem even if that option is available.

Based on a recent post here by a Streaming API PM, it sounds like Salesforce is very liberal with increasing the limits upon request. Your best bet is to file a case and request an increase in the limits. Escalate it directly to the PM via metadaddy if you get bounced, since he was the one who promised it :)

  • Even if that is the case, there are not that many inserts/updates on SF side so that I'm receiving that many events. I have reached 1000 in a couple of hours of testing, playing around with 5-6 records... Feb 13, 2013 at 4:46
  • Hm, if that's the case that limit renders the Streaming API completely useless at the 1000-event (free) tier. Single client, single channel, a few edits each to maybe 5 records? File a case.
    – jkraybill
    Feb 13, 2013 at 5:01
  • Not sure if it's something to do with the query and 'NotifyForFields'... I will test tomorrow again and we'll see :) Feb 13, 2013 at 5:22
  • Sounds likely. From the docs (salesforce.com/us/developer/docs/api_streaming/…): "Use caution when setting NotifyForFields to All. When you use this value, then notifications are generated for all record field changes as long as the new field values match the values in the WHERE clause. Therefore, the number of generated notifications could potentially be large, and you may hit the daily quota of events limit. In addition, because every record change is evaluated and many notifications may be generated, this causes a heavier load on the system."
    – jkraybill
    Feb 13, 2013 at 5:32
  • I think that was the case. I changed it to Select and it seems to be better now. But still, even if you have ALL, you need to update/create a record so that an event is generated :)... Also, for 1 update I receive 1 event but the counter increases by 4 (Hope it doesn't count the connect/handshake etc. calls). #Weird... Feb 14, 2013 at 3:18

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .