One advantage of upgrading is that while jetty-6-style continuations were a Jetty-specific mechanism, the jetty-7-style continuations are portable and work with a variety of containers. This means that they'll work asynchronously with Jetty 6/7/8 and any servlet-3.0 containers. They're also still compatible with servlet-2.5 containers, where they'll be blocking.
We're using two instances of Jetty. I've modified the name of the thread pool for each of them, which will allow us to quickly identify what threadpool is maxing out.
other than the maxed out issue.... you can share a thread pool between jetty instances if you wish to reduce Idle threads.
Actually, I prefer to have seperated thread pools. Sharing resources between distinct functionality is causing trouble in Openfire already - I don't want to add to that. ( http://www.igniterealtime.org/community/docs/DOC-1925 )
We should experiment a little to find an optimal default value for their sizes, and make those configurable too. Daniel, are you in a position where you can experiment with sizes of the thread pools, to see what works with you?
Well I am still having an issue where the pool is slowly being used up but I am confident that it is by the Plugin Servlet.
I have continued this discussion on this thread: http://www.igniterealtime.org/community/thread/40945
I have no idea how the servlets work but will hopefully get some time to look at it this week.
We should resolve what is causing this before changing anything. In theory I think the default size should be fine.
Remember the threads are not actually being "used up". The pool of available threads is just growing to meet demand.
But you don't have to meet that demand. You can limit the pool size and in almost all cases will get hardly any noticeable difference
in performance - often you get better performance. It is really rare that the server actually needs to simultaneously progress >250