@danielmewes -- we use that number as the size for a coro_pool, so it would be a lot easier to just bump it up in general. How large do you think we should make it?

I think bumping it up is not a great solution. If we make it too high, it will be useless. If we keep it relatively low, you will still be able to run into it with changefeeds depending on your application.

What would you think about removing the limit completely?

Well, I think we want some limit, since you can't spawn a billion coroutines and expect RethinkDB to function. In that case throttling changefeeds is probably what we want.

How many coroutines can RethinkDB handle while still being fairly responsive? Let's just use like half that number and call it a day.

(Or, I guess removing it entirely is probably fine too if you'd prefer, I don't feel too strongly about this.)

How many coroutines can RethinkDB handle while still being fairly responsive?

That depends on how many of them want to run. I think we can handle tens of thousands of changefeeds, probably more in a cluster. So we should probably allow that many to run on a single connection.

On the other hand if you spawn ten thousand write operations at the same time, that is probably going to cause some memory and certainly latency issues.

The problem specifically with changefeeds is that they wouldn't really be "throttled" in the usual sence, since they can just sit there for hours and keep running. So if your limit of n queries is saturated with changefeeds, you can't run anything on the connection until some of them receive a change.

That's why I thought it would be nice to exclude them from the limit. Could we maybe use a semaphore instead of a coro pool, and have CONTINUE requests to changefeed queries not acquire it? We should know which tokens/cursors are for changefeeds after their first response, which we still send pretty quickly, right?

OK, I changed it to do the semaphore thing and made changefeeds release the semaphore early. The change is in CR 3195 by @Tryneus .

Oh awesome. I think that's the best solution.

I think I'm going to move this to 2.2. It's a slightly non-trivial change, and probably not critical since users can work around it by using multiple connections (assuming they're aware of it).
So please merge into next, but not 2.1.x.

This is in next.