Skip to main content

[look for help] sth doubt about EJB Container's pool and cache

5 replies [Last post]
Anonymous

Hello Mahesh Kannan,
Hello Siraj Ghaffar,
Hello GF) Dev Teams,
Hello Everyone,

I'm am got confused by monitoring EJB on glassfish.
The monitor log gives me some images bleow.
1, The instance of EJB3.0 Stateful Session bean is always not
removed from passivation store when timeout.
#I think it should be removed when timeout.
2, When deploy an SFSB application on GF, monitor it without
running it, and find out that the passavation store is not empty.
#I think it should be empty.
3, The RemoveCount of SFSB will not be increased when calling
an @Remove method
#I think it should be increased.
4, When deploy a module which contains several beans(for
assumption Bean1, Bean2, Bean3), when one request for Bean1,
and there is no available instance of Bean1 in the pool, EJB
Container will create some new instances for each bean(why not
Bean1 only), the number of new instance is equals to Resize
Quantity the setting in GUI for pool and cache.
#I think EJB Container should create new instance for Bean1 only,
it will improve GF's availability for more beans.
5, When customize Initial and Minimum Pool Size and leave the other
setting for default(600 for Pool Idle Timeout), the setting for Initial
and Minimum Pool Size will not take effect. But when customize 30
for Pool Idle Timeout, the setting will take effect.
#I am eager to know why.

Did anyone get the same situation? and anyone's help will be appreciated.

Thanks.
Wu.

--

A new email address of FJWAN is launched from Apr.1 2007.
The updated address is: wujie@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@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

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
mk111283
Offline
Joined: 2005-03-29

Hello Wu,

To get the correct monitoring statistics, the monitoring level must be set to at least low. Please check if this has been done.

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.

2. It should be removed. I'll check if this is reproducible.

3. It should be. Again please check if monitoring level is not "OFF"

4. Stateful session beans are never pooled and hence new beans are created.

5. Maybe an admin gui issue? Siraj could you take a look at this?

Thanks.

呉傑

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@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@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

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

Siraj Ghaffar

呉傑 wrote:
> 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?
I'll have to let someone from admin gui team respond to this. Have you
tried from CLI?

Thanks

>
> To) Siraj
> I look forward to your help on this issue with appreciate ahead.
>
> Thanks.
> Wu
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

Wu Jie

Hello Siraj,
CC) Mahesh,

Thanks for your quick reply.
>>> 5. Maybe an admin gui issue? Siraj could you take a look at this?
> I'll have to let someone from admin gui team respond to this. Have you
> tried from CLI?

I'm looking forward to GUI Team's reply, and I'll try it from CLI.

Thanks.
Wu.

--

A new email address of FJWAN is launched from Apr.1 2007.
The updated address is: wujie@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@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

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

codeprince
Offline
Joined: 2007-05-10

This is an interesting topic,and I also want to know the answer.