# PocketIC/PicJS Server busy error **URL:** \ **Category:** Developers\ **Tags:** pocketic, pic, picjs\ **Created:** [November 25, 2024, 10:45pm UTC](https://forum.dfinity.org/t/pocketic-picjs-server-busy-error/37790 "2024-11-25T22:45:45Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![icme](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/icme/32/4327_2.png) [@icme](https://forum.dfinity.org/u/icme)\ **Post date:** [November 25, 2024, 10:45pm UTC](https://forum.dfinity.org/t/pocketic-picjs-server-busy-error/37790/1 "2024-11-25T22:45:46Z")
In on of my recent PocketIC CI runs, I received the following error. ```auto Server busy at intervalMs (../../node_modules/@hadronous/pic/src/http2-client.ts:156:19) at Timeout.runPoll [as _onTimeout] (../../node_modules/@hadronous/pic/src/util/poll.ts:17:24) ``` Any reason why this might be happening/the case? ---
**Author:** ![icme](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/icme/32/4327_2.png) [@icme](https://forum.dfinity.org/u/icme)\ **Post date:** [November 26, 2024, 2:27am UTC](https://forum.dfinity.org/t/pocketic-picjs-server-busy-error/37790/2 "2024-11-26T02:27:53Z")
Update - ok I see now where this is happening in the logs (but not yet where in my code). Adding some additional context in case others have this issue. ```auto ERROR pocket_ic_server::state_api::state: The instance is deleted immediately after an operation. This is a bug! ``` Then later on: ```auto PocketIC server encountered an error UpdateError { message: "Instance was deleted" } at intervalMs (../../node_modules/@hadronous/pic/src/http2-client.ts:144:19) at Timeout.runPoll [as _onTimeout] (../../node_modules/@hadronous/pic/src/util/poll.ts:17:24) ``` And then farther on down in the tests I get the server busy message. Is the commit from @mraszyk [mentioned here](https://forum.dfinity.org/t/announcing-picjs-typescript-javascript-support-for-pocketic/24479/119) included in the latest version of pic-js? ---
**Author:** ![mraszyk](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/mraszyk/32/7945_2.png) [@mraszyk](https://forum.dfinity.org/u/mraszyk)\ **Post date:** [November 26, 2024, 7:47am UTC](https://forum.dfinity.org/t/pocketic-picjs-server-busy-error/37790/3 "2024-11-26T07:47:25Z")
> in the latest version of pic-js [not yet](https://github.com/hadronous/pic-js/blob/f3ac4195b88ef93f9575bab669fb97267fd89b88/packages/pic/postinstall.mjs#L12): it requires version 7.0.0 of the server ---
**Author:** ![icme](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/icme/32/4327_2.png) [@icme](https://forum.dfinity.org/u/icme)\ **Post date:** [November 26, 2024, 6:27pm UTC](https://forum.dfinity.org/t/pocketic-picjs-server-busy-error/37790/4 "2024-11-26T18:27:38Z")
Update - looks like we solved this for the time being by removing our previous maxWorkers setting of 5 from our jest (test) config file. According to the jest docs, > `maxWorkers:` Specifies the maximum number of workers the worker-pool will spawn for running tests. In single run mode, this defaults to the number of the cores available on your machine minus one for the main thread. In watch mode, this defaults to half of the available cores on your machine to ensure Jest is unobtrusive and does not grind your machine to a halt. **It may be useful to adjust this in resource limited environments like CIs but the defaults should be adequate for most use-cases.** Note that you can specify the maxWorkers value in different ways: - **Number:** `maxWorkers: 4` (Use a maximum of 4 workers) - **Percentage:** `maxWorkers: "50%"` (Use 50% of available CPU cores) - **String:** `maxWorkers: "2"` (Same as using a number) I’m thinking of trying out a percentage configuration to see what the sweet spot is for PocketIC on in different environments. We obviously want the tests to run as quickly as possible, so the maximum parallelization would be preferred, but we do need to create a new instance of pocketIC for each test file (suite) and then tear it down at the end to keep the test contexts separate. @mraszyk do you have any suggestions/intuitions based on your in-depth knowledge of PocketIC of the optimal parallelization setting that we might want to use? ---
**Author:** ![mraszyk](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/mraszyk/32/7945_2.png) [@mraszyk](https://forum.dfinity.org/u/mraszyk)\ **Post date:** [November 27, 2024, 8:28am UTC](https://forum.dfinity.org/t/pocketic-picjs-server-busy-error/37790/5 "2024-11-27T08:28:32Z")
The PocketIC library (pic-js) should deal with the busy case by retrying instead of failing: see, e.g., how it’s done in the [Rust library](https://github.com/dfinity/ic/blob/cdf85cbaf2aa8cc0146e9b55b6ed06683b6f6736/packages/pocket-ic/src/nonblocking.rs#L1383). Then you don’t need to fine tune your parallelism which is inevitably gonna introduce flakiness into your tests. ---
**Author:** ![NathanosDev](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/nathanosdev/32/7204_2.png) [@NathanosDev](https://forum.dfinity.org/u/NathanosDev)\ **Post date:** [November 27, 2024, 9:39am UTC](https://forum.dfinity.org/t/pocketic-picjs-server-busy-error/37790/6 "2024-11-27T09:39:29Z")
> looks like we solved this for the time being by removing our previous maxWorkers setting of 5 from our jest (test) config file. GitHub runners have [4 CPUs](https://docs.github.com/en/actions/using-github-hosted-runners/using-github-hosted-runners/about-github-hosted-runners#standard-github-hosted-runners-for-public-repositories) available. Forcing more workers than the number of CPUs that you have available is not optimal for any Jest project. > In single run mode, this defaults to the number of the cores available on your machine minus one for the main thread. Note that Jest already uses an optimal default configuration. `maxWorkers` is generally used to _limit_ the number of workers, not increase them. ---
**Author:** ![NathanosDev](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/nathanosdev/32/7204_2.png) [@NathanosDev](https://forum.dfinity.org/u/NathanosDev)\ **Post date:** [November 27, 2024, 9:42am UTC](https://forum.dfinity.org/t/pocketic-picjs-server-busy-error/37790/7 "2024-11-27T09:42:39Z")
> The PocketIC library (pic-js) should deal with the busy case by retrying instead of failing. The library already handles this, but what I believe is happening here is that Jest itself times out and runs the `afterEach / afterAll` hooks which delete the instance. Then the still-running operations encounter the deleted instance and throw this error. From the Jest docs (and my above message), the optimal setting for `maxWorkers` is the default which is the number of CPUs minus one (for the main thread). If `maxWorkers` is set to 5, then it’s the number CPUs plus one, so 2 more workers than the optimal setting. This means that some workers will not have a dedicated CPU and so may spend a lot of time idling and eventually cause Jest itself to timeout.