You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently each RemoteChannel creates it's own Thread Pools (aka: ExecutorServices) for executing requests. When many RemoteChannels are created, this creates an unnecessarily large number of Executor Services, which in theory could simply be shared.
Instead of RemoteChannels creating their own ExecutorServices, we should instead provide the ability to pass in externally created and manages ones, that may then be shared across numerous RemoteChannels. eg: A Platform implementation could simply own a set of ExecutorServices that could be provided to RemoteChannels when required.
One way to determine the number of threads (a JVM using Bedrock) should initially / maximally allocate might be to determine how much memory the said JVM has been allocated as a percentage of available memory and use that as an indication of the percentage of over all resources (cores and threads) that could be used, at least as a starting point.
Alternatively we could determine the number of other JVMs running locally, especially Bedrock-based ones, and use that to determine the number of threads.
The text was updated successfully, but these errors were encountered:
brianoliver
changed the title
Introduced Shared Threads for RemoteChannels per Platform
Introduce Shared Threads for RemoteChannels per Platform
Jan 10, 2017
Currently each RemoteChannel creates it's own Thread Pools (aka: ExecutorServices) for executing requests. When many RemoteChannels are created, this creates an unnecessarily large number of Executor Services, which in theory could simply be shared.
Instead of RemoteChannels creating their own ExecutorServices, we should instead provide the ability to pass in externally created and manages ones, that may then be shared across numerous RemoteChannels. eg: A Platform implementation could simply own a set of ExecutorServices that could be provided to RemoteChannels when required.
One way to determine the number of threads (a JVM using Bedrock) should initially / maximally allocate might be to determine how much memory the said JVM has been allocated as a percentage of available memory and use that as an indication of the percentage of over all resources (cores and threads) that could be used, at least as a starting point.
Alternatively we could determine the number of other JVMs running locally, especially Bedrock-based ones, and use that to determine the number of threads.
The text was updated successfully, but these errors were encountered: