Hi Scott and Daniel,
Thanks for the prompt replies, and sorry for my slow one. It might
be possible to try 3.1.5 in the future. Currently, since we upped
the memory and changed the collector the app is behaving extremely
well, so I don't feel an urgent need to look into it. We'll
defini
On Apr 2, 2008, at 2:25 PM, Knut Forkalsrud wrote:
> This was with version 3.1.4, I haven't tried 3.1.5 yet.
3.1.5 is interesting, since it should handle the null classes faster
(basically, 3.1.5 pre-analyzes all the jars). The locking in 3.1.5 is
the same as 3.1.4.
I've updated the locking
This was with version 3.1.4, I haven't tried 3.1.5 yet.
-Knut
Knut Forkalsrud wrote:
Just a comment on this, we found similar problems not too long ago.
Performance under load turned out to be limited by the synchronized
lock in EnvironmentClassloader. So our fancy new 8 core systems
suddenl
Just a comment on this, we found similar problems not too long ago.
Performance under load turned out to be limited by the synchronized
lock in EnvironmentClassloader. So our fancy new 8 core systems
suddenly were reduced to single thread performance. Some profiling
highlighted two major offende
On Apr 1, 2008, at 11:26 PM, Don Willis wrote:
> Hi all,
>
> We have an application running on Resin 3.0.23. Lately it has been
> slowing down to a crawl on a regular basis. Thread dumps when it's
> slow show lots of threads (~30 to 100) waiting to lock the
> EnvironmentClassLoader. Like this
Don Willis escribió:
> ...Does anybody have a compelling argument why
> having less memory would dramatically slow down Resin's class loading?
Hi,
Te only general reason I can think would be that the lack of memory is
causing the GC to fire too often, so you have a situation where the JVM
res
Hi all,
We have an application running on Resin 3.0.23. Lately it has been
slowing down to a crawl on a regular basis. Thread dumps when it's
slow show lots of threads (~30 to 100) waiting to lock the
EnvironmentClassLoader. Like this one:
"resin-tcp-connection-j2ee.confluence.atlassian.
