Hi Scott,
Thanks for the pointer. I managed to get it to work, more or less,
using the new way:
--
...
--
and the old "bean" way:
--
org.leaf.ConnectionPoolDataSource
java:comp/env/jdbc/MyPool
...
--
However, I find it more flexible to use the ol
Doh! :) I'm sorry, I thought you meant 256m heap. Yes, 256m PermGen
should be more than enough, unless it has turned into a memory hog in
the last version.
Have you checked, with JConsole for example, that the setting is
really being taken into account? Just to discard if it is a
configura
Well, good to know. I'll stick to our current solution until we can
move to the 4.X branch.
Thanks for the info.
D.
S'està citant Scott Ferguson :
> Daniel López wrote:
>> Hi Scott,
>>
>> I'm still using 3.1.*, is JMS in those versions production ready?
>> Documentation is a bit scarce so I'm
S'està citant Scott Ferguson :
> Daniel López wrote:
>> Hi there,
>>
>> We are migrating all of our instances to Resin 3.1.5 (3.1.8-9 have a JPA
>> bug that prevents us to go the latest version) and I've been asked by
>> our admins if it would be possible to have ONE monitor to see all the
>> diff
And why is it that a servlet filter is "outside the application"? I
consider it to be part of the application; it is simply a matter that
those services are not provided directly by the framework used to
implement the logic.
Otherwise each framework would have to provide that capability.
I h
Hi,
Be aware though, that hot redeployment requires all the
libraries/classes that reside in WEB-INF to behave correctly,
otherwise they are not recicled and end up consuming all the non-Heap
memory and causing an OOM. And there are tons of libraries out there
that do not behave properly,
