Can you refer to a document where it describes:
> A caching thread pool does more than reducing the overhead of
allocating threads.
> It reduces the cost of idle threads to zero (as opposed to keeping
their stack around at a price of up to 16GB memory).
From the javadoc I can't see that this
Inlined replies below.
On 18/02/2012 9:54 AM, Christoph Läubrich wrote:
A CachedThreadpool won't change anything here, it is only usefull if
you have many*short living threads* because it reduces the overhead
assosiated with *allocating* a thread.
The Thread count is manly bound by the thr
Not true. Take another look at his charts:
* The default stack size for threads under 64-bit JVMs is 1MB. Source:
http://www.oracle.com/technetwork/java/hotspotfaq-138619.html
* At 64-bit with 512k stack (notice, this is smaller than the default)
he is still limited to 32k threads an
Hi
I have a csv file in the format
#Comment1
#Comment2
#Comment3
ID,NAME,LEVEL
1,JOHN,3
2,MIKE,4
.
.
One way of reading this might be to specify the columns in csvread as
CSVREAD('test.csv', 'ID|NAME|LEVEL', 'charset=UTF-8
fieldSeparator=|')
and use a 'where' clause when
The latest versions of Java support 10s of thousands of threads. When
they are idle the OS swaps out the memory pages and there is very
little overhead.
http://vanillajava.blogspot.com/2011/07/java-what-is-limit-to-number-of-threads.html
http://stackoverflow.com/questions/2117072/java-thread-creat
A CachedThreadpool won't change anything here, it is only usefull if you
have many* short living threads* because it reduces the overhead
assosiated with *allocating* a thread.
The Thread count is manly bound by the threads stack size and the OS and
not by the JVM itself. If the thread is really
Thomas,
My understanding is that idle threads (even if they are one per
database) will eat up valuable memory. The last time I checked Java
would only allow you to launch a few thousand threads (2000 or so). By
introducing a thread pool you're allowing the user to run more databases
but h
