Describe the bug
When using OsgiGraphQLHttpServlet, a new thread pool (of 1 thread) is created on every request, and never shut down.
The thread pool is created when creating a GraphQLConfiguration - if no asyncExecutor was provided (which is not possible when using OsgiGraphQLHttpServlet), a new ThreadPoolExecutor is created, without keeping any reference on it, and so never shutting it down. Creating a thread pool transparently without shutting it down is already an issue, but moreover OsgiGraphQLHttpServlet.getConfiguration() is creating a new configuration on every call, which is actually happening in AbstractGraphQLHttpServlet.doRequest() .
To Reproduce
Steps to reproduce the behavior:
Create an OsgiGraphQLHttpServlet
Make http requests
Check the total number of threads
Expected behavior
Don't create a pool automatically, or ensure it's properly closed when it's not used anymore
Don't build new configuration every time we call getConfiguration
Make it possible to pass a custom pool when using OsgiGraphQLHttpServlet. Ideally, it would be nice to be able to pass a full configuration (maybe through a "GraphQLConfigurationProvider")
Describe the bug When using
OsgiGraphQLHttpServlet
, a new thread pool (of 1 thread) is created on every request, and never shut down. The thread pool is created when creating aGraphQLConfiguration
- if no asyncExecutor was provided (which is not possible when usingOsgiGraphQLHttpServlet
), a newThreadPoolExecutor
is created, without keeping any reference on it, and so never shutting it down. Creating a thread pool transparently without shutting it down is already an issue, but moreoverOsgiGraphQLHttpServlet.getConfiguration()
is creating a new configuration on every call, which is actually happening inAbstractGraphQLHttpServlet.doRequest()
.To Reproduce Steps to reproduce the behavior:
Expected behavior
OsgiGraphQLHttpServlet
. Ideally, it would be nice to be able to pass a full configuration (maybe through a "GraphQLConfigurationProvider
")I will try to provide a PR soon