Is there a limit on publish() and subscribe()

General
1

I know there is a limit on how many functions and variables a spark core can have, but is there a limit on how many subscriptions or published events? I don’t seem to see any reference in the docs that there is a limit. I also don’t see any limits on how long your topic (or event) can be in a subscription or publish command.

Thanks
Mike

2

I don’t know about a publish limit apart from one event per second (with sporadic 4 per sec).

But the docs say about Spark.subscribe

NOTE: A Core can register up to 4 event handlers. This means you can call Spark.subscribe() a maximum of 4 times; after that it will return false.
1 Like
3

Does this mean that you can call that function 4 times meaning if I have to read data or get data from my publisher I can get the data 4 times and after that I wan’t be able to get any data from that publisher.
Its because that my handler function is not being accessed.
Thanks Meth

4

No, this means that you can only register four different event handlers, but each of these event handlers can be called/triggerd an unlimited number of times.
Spark.subscribe does not retrieve event data from the cloud, but only registers the handlers that will thereafter do the “event reception” stuff.

5

Hi Thanks for the quick reply and for the explanation. I thought that this was the issue but it seems to be something else. What about the Spark server how does it respond on the events that are being called and or which function does retrieve event data ?
Thanks again for the help

6

To answer this profoundly I’d tag @Dave, but as I see it the cloud server does not actually do anything directly.

I’d rather think that the publishing Core pushes its event data into the cloud where it gets stored for some time (max. time to live TTL) or till another event of the same Core and type gets published.
The subscribing Core in turn just checks regularly if there are any pending events of the expected type and requests the data and feeds it to the event handler fn.

Please @Dave correct me if I’m wrong.

1 Like
7

Hi @Meth,

A device that’s publishing is limited to a maximum rate of 1 event per second, or an average of 60/minute. The firmware will let you do a burst of up to 4/second, but then it’ll harshly rate limit the messages until your firmware stops publishing for some time.

The cloud doesn’t limit how many subscriptions you can make, or how many events are sent to your devices, but I think the firmware can only register 4 subscription handlers at the moment. There is a bug right now where the core firmware doesn’t re-send subscription requests if its connection was lost and re-connected, but I’m hoping the firmware team will have a chance to fix that soon. One workaround might be listening for a heartbeat event, and resetting your core if it’s missing. I wrote an example of that here: https://community.spark.io/t/spurious-subscribe-failures/7243/4?u=dave

I hope that helps!

Thanks,
David

3 Likes
8

Hi @Dave, We haven’t been waiting nearly 900 days for this bug fix, surely? Is there an issue with the time stamps of these posts OR how I’m reading the time stamps? The reason I ask is your post mentioning how you hope the firmware team will fix the bug (providing it’s the same bug) seems to be dated to January 2013. I didn’t even think the original Core was that old?! :smiley: :smiley:

9

Hmm, seeing how the first post is dated Dec 14, I’m guessing my reply above wasn’t in 2013 :slight_smile: I think it’s saying “January 13th, 2015”

10

haha! :smiley:

1 Like
11

Hello @Dave,
I am trying to understand where does the limit for the subscription handlers come from. Can you point me to the part of the code where this limitation is set? What should be done to increase the number of allowable subscription handlers?

Thank you
Dheeraj

12

More interestingly perhaps, what would you need more handlers for? They work as prefixes, so if you subscribe to “pancake”, you’re also going to get “pancake1, pancake2, pancake_what_ever_you_like”. Using the event name, you can filter out which ones are relevant for you, and act accordingly :smile: Just throwing it out there.

3 Likes
13

That’s good to know. I still want to know what’s causing the limitation.

14

I suspect the code is limited by the size of the handler callback array:

Thanks!
David

1 Like