Hi Marc,
> Ok we are doing the final stability stress test.
>
> We have got a puppy called "pitbull" (gig ram 2xXeon) running
> at a good load
> (100 clients 5000 beans in cache at all time many 100,000 in
> DB) and we run
> it for a marathon for stability and leaks.
>
> So far, 24 hours of this "moderate hell" and no problems to
> be reported, the
> ISS station is in orbit for now
>
> no leaks it seems and the "passivating" caches are really solid, not a
> barf... bravo to Simone
> (ALSO PLEASE PUT THE DEFAULT AS YOUR CACHE NOW :)
I know you already told me this, but to be honest, I have no idea of what
should be the reasonable default values for the LRU cache :P
You certainly have more experience about, especially now that you're running
load tests on it...
There are still 2 open issues anyway (well, 1 and a bit):
1) The instance interceptor locking mechanism and the passivation one are
not the same, so there can happen a passivation before locking the context
but after having requested (and successflly obtained) it from the cache.
This of course can happen with a very low probability, but can happen
(especially if the cache max capacity is small, say 10-20)
2) I'm not sure, but in your opinion is the EntityInstanceCache.canPassivate
method correct, even in case of long transactions ? My doubt concerns the
fact that I wrote it when the transaction was set in the context in the
TxInterceptor, not in the container interceptor as it is now.
Regarding the tests, have you tried to put the overager period to 1-2
(seconds) and the max bean age to be 1 (second) ? This should be very hard
for the caches (it can also help to profile better the caches).
Many thanks for the "bravo" above, I really appreciated it (being you the
"grumpy jboss" it has a double value :-)
Regards,
Simon
