Use Case for specifying a TaskScheduler for Replicator.AddChangeListener

Mobile
1

When is it appropriate/recommended to specify a TaskScheduler when adding a Replicator Change Listener?

We are experiencing occasional “can’t create thread” exceptions when running replication as CbLite spins up a new thread every time it fires off an event to the Change Listener and sometimes that fails.

I’m wondering if passing in the default thread scheduler from the .NET framework will help manage the threads better. I’ve started testing with this change and have not experienced the issue, but it is also very sporadic and difficult to reproduce.

2

@atkinsr

Unless you are very comfortable of knowing how you want to manage your own task scheduler of all cbl events, the best option is to use CBL’s own QueueTaskScheduler which is the .Net CBL default TaskSceduler.

Just simply add change listener as Replicator.AddChangeListener(EventHandler handler). Our QueueTaskScheduler will properly queue and manage the threads of events and firing the changed events from db/document/replicator/query objects all together.

3

Thank you. Yes, it is my preference to use the CBL default TaskScheduler, but it doesn’t seem to wait for threads to become available as we see these “Couldn’t create thread” exceptions in our application logs and they are always originating from the StatusChangedCallback.

System.Threading.Tasks.TaskSchedulerException: An exception was thrown by a TaskScheduler. ---> System.ExecutionEngineException: Couldn't create thread. Error 0x0
...
  at Couchbase.Lite.Support.SerialQueue.DispatchAsync
...
  at Couchbase.Lite.Sync.Replicator.StatusChangedCallback
4

@atkinsr
Unfortunately the info you provide here isn’t enough for us to identify the problem.
We would like to know which .Net CBL version you are using, and the CBL logs when the issue happens (ref: Using Logs for Troubleshooting | Couchbase Docs). And a code snipped for a repro case would be very helpful.