"Could not acquire threading lock - possible deadlock" with blocking mock responses

[msg555]

trafficstars

It seems a recent update put a global lock around each mocked response. However prior to this release we were inserting delays in our mocked responses to simulate request latency as part of our threading tests. Now that there is this global lock our tests are running substantially slower, aren't testing any meaningful interleaving, and are leading to deadlock exceptions as the lock sometimes cannot be acquire in 10 seconds.

Any advice on how to deal with this? Should we look to inject latency into our tests in another way? Is there some way this use case can be supported?

Version where problem appears: 1.10.0

[jamielennox]

Short response as I'm on mobile, but was expecting some edge cases from this lock.

In my opinion there's no reason to sleep in a unit test, but it does depend on what your threads are doing.

I assume you're trying to simulate a timeout? In which case I recommend just having the mock throw the timeout exception that you actually use in your code flow.

Is it more complex than this? How?

[doronz88]

I also stumbled on this error. I have very slow responses in my mock that take more then 10 seconds to accomplish. Will you be willing to add a configurable timeout?