Hi,
I am still migrating a myFaces/richfaces app from JSF 1.2 to 2.1
Tomahawk is updated from 12-1.1.10 to 20-1.1.11.
App runs under Tomcat 6.0.32
On pages with a t:datatable I am getting following stack:
Caused by: java.lang.NoSuchMethodError:
I have been doing some research on this topic and I know that there is
quite a bit of information out there. Unfortunately, I usually do not
notice articles that recommend JVM tuning setting for servers with X amount
of memory. I have an issue with a production tomcat server that is running
two
you are not going to like this answer...
every application is different.
the memory required is the memory required.
if you need more, give it more or redesign the app.
there are tuning tips to trade large stop the world gc pauses for fewer
shorter pauses and increased heap
if the server us dedicated and has 8gb of ram... you could give 6gb (or 3g
if a 32bit os as more will nor be used on 32bit os)... BUT when the stop
the world big Garbage Collection triggers (and it will trigger eventually
as the last resort to resolve heap fragmentation) then that gc will be 6
and please don't give more than 1,6 GB if using a 32 bit JVM!
The more ram you give, the less threads you can spawn on 32 bit JVMs!
This was so bad, that we couldn't even get 100 parallel threads when going near
1.8GB ;)
I hope not many people need to deal with this stuff nowadays anymore though
nio based servlet containers should reduce the number of threads required
though... but yeah i forgot about that competing limit
- Stephen
---
Sent from my Android phone, so random spelling mistakes, random nonsense
words and other nonsense are a direct result of using swype to type on the
We had similar issue (long request processing) and we redesigned the
application - created the content in background, stored file on disk
and represented link to download.
On 19.12.2011, at 22:05, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
nio based servlet containers should
use the concurrent garbace collector can mitigate stop-the-world, you can
configure where the concurrent process starts so most of the time stop the
world never actually takes place.
But, back to the original problem of exporting, you may wish to stream the
data instead of reading it all into
On 20 December 2011 00:01, Ted r6squee...@gmail.com wrote:
use the concurrent garbace collector can mitigate stop-the-world, you can
configure where the concurrent process starts so most of the time stop the
world never actually takes place.
NOTHING you can do will prevent the major stop the
I did use the word mitigate :)
secondly yes you can almost prevent it with the concurrent collector. The
concurrent collector will not stop-the-world unless it can not keep up or
due to not-enough-contiguous free space.
So the simple example would be :
1) your application uses at most 64 megs of
10 matches
Mail list logo
