I might be overstepping the boundedness of this topic (get it?) but I think users should be able to configure the size of various thread pools that Restlet uses.
This is a question that comes always comes up with my clients, and I have to say "Well, I don't know, but Restlet does perform well enough and I trust it..." These things don't always make a significant difference in performance, but people do care a lot about thread count. -Tal On 06/24/2010 10:40 AM, Tim Peierls wrote: > What was the date of that snapshot? It looks like there's a fix as of > June 11, revision 6696 in svn. > > But (talking to Jerome and Thierry now) I'm a little worried that this > fix isn't really addressing the heart of the problem. In particular, > the use of thread pool per BaseHelper instance prevents efficient > re-use of threads in the JVM. > > Also, defaulting coreThreads=1 and maxThreads=255 with a > SynchronousQueue seems like it's asking for trouble with CPU count << > 255. What about a bounded queue with high capacity to get through the > bursts, but keep the pool size to some small multiple of the CPU > count? Remember that core size is _not_ really min size. > > (And a minor nit: BaseHelper.workerService is a volatile instance > field, so visibility isn't problem, but there are some atomicity > issues -- at init time and shutdown time. Fix to the latter just means > copying volatile value to local variable before testing and using. > Fixing former ... needs some thought. Maybe it's OK as is.) > > --tim > > On Tue, Jun 22, 2010 at 6:02 AM, Nina Jeliazkova <[email protected] > <mailto:[email protected]>> wrote: > > Hello All, > > I am experiencing memory/thread leak ,with Restlet-2.0-RC4 and > Restlet-2.0-SNAPSHOT , when using ClientResource . Basically, > ClientResource doesn't close the thread it spawns and this result > in number of inactive threads and severe memory leak. > > Here is some very simple code to illustrate this behaviour. The > same code runs fine in Restlet-2.0-M6 (which doesn't span new > thread in ClientResource). > > public void run(int instances) throws Exception { > > for (int i=0; i < instances;i++) { > ClientResource clientResource = null; > Representation r = null; > try { > clientResource = new > ClientResource("http://restlet.org" <http://restlet.org>); > r = clientResource.get(); > } finally { > try { r.release(); } catch (Exception x) {} > try { clientResource.release(); } catch (Exception > x) {} > } > } > } > > public static void main(String[] args) throws Exception { > ThreadTest test = new ThreadTest(); > test.run(1000); > } > > > I guess there might be something missing in the code to explicitly > close threads, but since the same code runs fine in M6, it is > quite confusing to experience leaks after upgrade. > > Best regards, > Nina Jeliazkova > > P.S. Inactive threads while executing the example above > > > ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2625824

