The major changes are:
- Use `PSThreadOptions.ReuseThread` for the `InitialSessionState` when creating `Runspace`, so that every `PowerShellManager` only creates one thread and then reuse it afterwards. The default behavior is to create a new thread every time `PowerShell.Invoke` is called.
- Update `RequestProcessor` to process `InvocationRequest` in asynchronously via tasks.
- Implement `PowerShellManagerPool` using `BlockingCollection`
- make upper bound of the pool configurable via an environment variable `PSWorkerInProcConcurrencyUpperBound`
- make the pool able to expand in a lazy way
- checkout `PowerShellManager` via `CheckoutIdleWorker` on the main thread. Once getting an idle instance back, the main thread will queue a task to process an invocation request on a thread-pool thread and forget about it -- the main thread then can go ahead to process the next message.
- Update the `RpcLogger` and make every `PowerShellManager` have its own logger instance.
- also update the way to set the `RequestId` and `InvocationId` for logger. The original way to setup the context only works for single-thread design.
- Update `MessagingStream` to use a `BlockingCollection` to hold all messages that are about to be written out, then use a single thread-pool thread to take out items and write them to the gRPC channel.
- currently, the way we write out response/log messages is completely task-based/async, using a semaphore for synchronization. However, this approach doesn't guarantee the order of the message.
- this is because there could be multiple tasks blocked on the semaphore, and releasing the semaphore allows a blocked task to enter the semaphore, but there is no guaranteed order, such as first-in-first-out, for blocked threads to enter the semaphore.
- so, the unblocked task could be a random one, and thus change the arrival order of the message when writing the message to the gRPC channel.
- Remove the two system logging we have in our worker, because they drastically worsen the processing time per an invocation request when there are a lot in-coming invocation requests.
- the logging for "TriggerMetadata" parameter is not that useful, and should be removed
- the execution time logging is good to have, but not necessary, especially when it impact the throughput.
* first e2e test
* conditionally chmod +x
* actually run the tests :)
* get job differently
* don't fail if we cant get the job
* honor configuration
* handle env:CONFIGURATION not set
* address Pragna's feedback
* add TestFunctionApp change
* elaborate test name
* add additional test cases
* typo
* add trigger metadata tests and Error test
* new lines
* address Steve's feedback
* address Steve's feedback
* nit extra line
* add logic to grab dependencies
* move psdepends logic
* PSDepends is not a required dependency
* move comment
* actually include install deps script
* fix path
* commit handle Azure authentication
* move WriteAsync out of using
* authenticate to azure per-request and address feedback
* moved Auth to Azure in Worker Init for now