Rate limiting too restrictive - Max Execution time exceptions

Devices & Integrations
1

Hello,

Following this annoncement,

Since last week (this is quite recent), I’ve seen the same exception in the logs again and again for my Custom Ecobee Device:

Java.util.concurrent.TimeoutException: Execution timed out after 40 units. Start time: Tue Jun 16 22:20:15 UTC 2015 @ line 1483

And, the following exception, for some smartapps,

Java.util.concurrent.TimeoutException: Execution timed out after 20 units.

This is a new issue that I’ve not seen before.

I think that the rate limiting is becoming too restrictive. Can somebody at SmartThings look into it? I’ve opened a support ticket (#106962), but support is pretty overwhelmed right now (based on some other tickets I have).

Thank you.

2 Likes
2

Does your ecobee device have something that runs for a long time? I’ve only seen the timeouts happen when there is something in the code that is running unusually slowly.

Disclaimer: I don’t have much actual knowledge of how we handle rate limiting and timeouts

3

I think that I found a workaround to avoid these timeout issues… I need to test them…

4

I’m surprised you are seeing 40 unit exceptions. I didn’t realize execution could last more than 20 seconds.

1 Like
5

@625alex, it seems that 40 units is the rate limiting for device types (device handlers) which is different from
smartapps (set at 20).

Bye for now.

1 Like
6

Now, it seems that the rate limiting for device handlers is down to 20 units from 40.

As 20 units = 20 seconds, for cloud-to-cloud integration such as MyEcobee and MyAutomatic device handlers, it is starting to be really limiting , and there are more exception in the logs such as

Java.util.concurrent.TimeoutException: Execution timed out after 20 units.

I think that there should be a different rate for those cloud-to-cloud integrations.

My 2 Cents.

1 Like
7

Execution time limit is 20 seconds, not milliseconds. It’s always been as far as I know.

2 Likes
8

@geko, not for device handlers, see my first post (with a 40-unit exception message).

Yes, it is 20 seconds, but sometimes it’s less according to my logs.

My point is that for cloud-to-cloud integrations, it’s too little.

Bye,

9

20 app seconds = how many seconds in elapsed time? It looks to me that it’s few seconds (and less than 20 seconds)…

10

Hi @tslagle13, I’m seeing more and more exceptions regarding rate limiting in my logs.

Will ST reconsider the rate limiting for cloud-to-cloud integrations (such as Ecobee, Automatic, Neurio, etc.) which typically take longer than others to execute?

Those integrations are dependent on the partner’ latency, the network latency,and there may be a lot of factors which impact the delays involved (connection issues, cloud infrastructure, APIs design, etc.)

I think that there should be some specific rate limiting thresholds for cloud-to-cloud integrations that are different from the rest.

Regards.

3 Likes