| Re: [jetty-users] Customizing jetty worker threadpool |
The problem with the demux approach is ... the point in time that you need to pick a thread pool, the request object doesn't exist yet, so you can't use information from the request to make that determination.What about having 2 connectors instead?Create a special "internal" connector with its own ThreadPool (Executor) to use.But that will only help with the initial connection serving.If the request uses Async anything, then the thread can be released back into the pool, with later processing handled from the Server thread pool.--Joakim Erdfelt <joakim@xxxxxxxxxxx>Expert advice, services and support from from the Jetty & CometD expertsOn Thu, May 21, 2015 at 4:44 PM, Hrishikesh Gadre <gadre.solr@xxxxxxxxx> wrote:_______________________________________________Hi Joakim,Thanks for the feedback. I think QoSFilter is an interesting alternative but I think it does not quite fit the requirement. Let me elaborate my use-case for better understanding.Every external request typically spawns multiple internal requests for multiple servers (e.g. for scatter/gather queries). Hence it is important to reserve a certain % of thread-pool capacity for internal requests. Without this reservation, it is quite possible that the thread-pool is consumed entirely by external requests - thereby creating a distributed deadlock (since the external request depends upon the result of internal request which can not be processed due to unavailability of threads).After reading the docs, I am not sure if QosFilter will be able to provide this reservation capability out-of-box. i.e. it ensures to pick a higher priority request from the backlog but doesn't prevent the system to occupy the entire thread-pool with low-priority requests.Is my understanding correct? Also can you please elaborate the threading model used with the jetty continuation?>>Or use the QoSFilter to setup a higher priority for internal vs external requests. :-)--Joakim Erdfelt <joakim@xxxxxxxxxxx>Expert advice, services and support fromÂfrom the Jetty & CometD expertsOn Thu, May 21, 2015 at 3:10 PM, Hrishikesh Gadre <gadre.solr@xxxxxxxxx> wrote:Hi,I am currently working on an application which comprises of multiple servers. Each server is deployed using a dedicated Jetty instance. Each server accepts HTTP requests from external clients as well as other servers in the system. i.e. the servers form the peer-to-peer system using HTTP protocol.I am currently working on a feature to separate out internal vs external requests such that a % of worker threads are reserved for internal requests and remaining threads for external ones.I could think of couple of approaches to solve this problem. Can you please take a look and provide feedback?(1) Using Servlet 3 specificationThe idea would be to define two separate thread-pools internally and submit the asynchronous request based on request type. My understanding here is that it would require an additional thread switch as compared to synchronous request processing (jetty_acceptor -> jetty_selector -> jetty_worker -> app_thread). Is this accurate? If yes is there a way to avoid this?(2) Somehow customizing the Jetty implementation such that we reserve a % of jetty worker threads for internal requests and other for external requests. The flow would look like this,jetty_acceptor -> jetty_selector (Demux) ----> jetty_worker_pool_for_internal|-----> jetty_worker_pool_for_externalThe demux here would look at the HTTP request to figure out its type and submit it to appropriate thread-pool. Is this possible? If yes, any pointers?Any other approach I may have missed?Thanks in advance,-Hrishikesh
jetty-users mailing list
jetty-users@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users