Hello Mahesh,
CC) Siraj,
Thanks a lot for your minutely reply.
Sth comment inline, maybe the case become more and
more perplexing.
> To get the correct monitoring statistics, the monitoring
> level must be set to at least low. Please check if this
> has been done.
I have set "LOW" for monitoring level of EJB Container.
> 1. Whats the timeout value. If it is zero, it will not be
> removed at all. Also, the timeout value is just a hint.
> The timeout that is set is also the frequency at which the
> reaper thread attempts to cleanup the entries. So wait for
> one more cycle and if it is still not removed, let us know.
I agree with your explanation, and I checked my setting again.
(1 for "Max Cache Size", 2 for "Cache Resize Quantity", 30sec
for "Removal Timeout", default value for "Removal Selection
Policy" and 30sec for "Cahce Idle Timeout"). and the problem
was reproduced.
> 2. It should be removed. I'll check if this is reproducible.
I reproduce it again.
Not merely this but also when removal-timeout is less than or
equal to cache-idle-timeout, the passivate function still take
effect.
#My comprehensiveness is that the passivate function should
lose effectiveness.
> 3. It should be. Again please check if monitoring level is
> not "OFF".
I set HIGH for monitoring level. and the RemoveCount of SFSB
was not increased when calling an @Remove method
> 4. Stateful session beans are never pooled and hence new
> beans are created.
Sorry for inexplicit statement. The scene I described just is
that Stateless Session bean and Entities in the pool. If one
module contains several SLSBs(for assumption Bean1, Bean2,
Bean3), When one request only for Bean1 comes and there is no
available idle instance, EJB Container will increase new
instance for all the beans(Bean1, Bean2, Bean3) according
Resize Quantity.
#I think EJB Container just need to inrease instance according
the request and Resize Quantity.(e.g. the case described above
I think EJB Container need to increase instance for Bean1 only).
This proposal maybe bring down appserver's load and enhance
appserver's availability.
> 5. Maybe an admin gui issue? Siraj could you take a look at this?
To) Siraj
I look forward to your help on this issue with appreciate ahead.
Thanks.
Wu
--
A new email address of FJWAN is launched from Apr.1 2007.
The updated address is: wujie_at_cn.fujitsu.com
--------------------------------------------------
Wu Jie
Nanjing Fujitsu Nanda Software Tech. Co., Ltd.(FNST)
8/F., Civil Defense Building, No.189 Guangzhou Road,
Nanjing, 210029, China
TEL: +86+25-86630566-918
FAX: +86+25-83317685
EMAIL: wujie_at_cn.fujitsu.com
--------------------------------------------------
This communication is for use by the intended recipient(s) only and may contain
information that is privileged, confidential and exempt from disclosure under
applicable law. If you are not an intended recipient of this communication, you
are hereby notified that any dissemination, distribution or copying hereof is
strictly prohibited. If you have received this communication in error, please
notify me by reply e-mail, permanently delete this communication from your
system, and destroy any hard copies you may have printed