If we are worried about not having enough threads to start the server, couldn't we
require that the pool be configured with enough threads to boot the server? This could be
via a comment in the xml file.
A related concern is how we will deal with several deployment threads trying to
synchronize on the same object locks. I assume this is were additional tuning will come
into play (reducing object lock contention through code modifications). One possible
solution, is that we could manually designate which thread (e.g. "cluster partition
init") is to be used on a per component basis. Before diving into solving this
potential issue, we need to evaluate how expensive object lock contention will be (to
avoid premature optimizing). But, it doesn't hurt to consider that we might need to
do something in this area. If we were to asynchronously deploy in named threads, that
might require a separate thread pool.
Another concern is redeployment in a production app server deployment. We need to be
clear in the thread pool xml file (via comments) as to what JBoss elements use the system
thread pools (there is a long running task pool and short running task pool). If a
customer sizes the pools only on the application needs, then redeployment on a loaded
system could run short of threads needed to redeploy. Even if the pool is increased to
accommodate the number of threads needed for deployment, applications can easily consume
those as well in a loaded system. I'm wondering if we need to introduce throttling
between the users of the system thread pool, as a way to carve up the thread pool between
different types of tasks. Logically, this would create sub-pools of threads, where
perhaps there could be borrowing of the threads between sub-pools. I'm not sure if
this is over-engineering, what could possibly be handled via configuration and operational
considerations (only hot-deploy during idle time).
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4242211#...
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...