ADF 10g: AM pool dropped to zero after the jbo.ampool.timetolive is reached

Question

Hi,
JDev: 10.1.3.2.0.4066
I have a problem where all appModules in the application module pool are removed when the jbo.ampool.timetolive threshold is reached, even the currently referenced ones. This causing serious performance issues in our application. I have seen reports from Steve Muench on his blog (http://radio-weblogs.com/0118231/2006/03/30.html) that this issue can happen under certain circumstances but the link is broken, so am not sure what the reason is. Does anyone have a link to where this was moved to? Steve also has added (Disabling jbo.ampool.timetolive on this forum of how to "disabled the time to live consideration" but the timetolive is still removing all the appModules in the pool. Why is the pool being completely wiped out after the timetolive?
Here is the BC4J configuration that is being used:
NB:
* web session timeout is 45 minutes
* I am using a JDBC pool as well
      <AppModuleConfig name="Oracle">
         <DeployPlatform>LOCAL</DeployPlatform>
         <JDBCName>cvclaims_Oracle</JDBCName>
         <jbo.TypeMapEntries>Java</jbo.TypeMapEntries>
         <jbo.project>Model</jbo.project>
         <AppModuleJndiName>my.adf.root.RootAppModule</AppModuleJndiName>        
         <java.naming.factory.initial>oracle.jbo.common.JboInitialContextFactory</java.naming.factory.initial>
         <ApplicationName>my.adf.root.RootAppModule</ApplicationName>        
         <jbo.locking.mode>optimistic</jbo.locking.mode>        
         <jbo.ampool.initpoolsize>50</jbo.ampool.initpoolsize>
         <jbo.ampool.maxpoolsize>100</jbo.ampool.maxpoolsize>
         <jbo.recyclethreshold>50</jbo.recyclethreshold>
         <jbo.ampool.maxavailablesize>50</jbo.ampool.maxavailablesize>
         <jbo.ampool.minavailablesize>50</jbo.ampool.minavailablesize>
         <jbo.poolmaxavailablesize>51</jbo.poolmaxavailablesize>
         <jbo.maxpoolsize>51</jbo.maxpoolsize>
         <jbo.initpoolsize>51</jbo.initpoolsize>
         <jbo.poolminavailablesize>51</jbo.poolminavailablesize>
         <jbo.ampool.maxinactiveage>2760000</jbo.ampool.maxinactiveage>
         <jbo.ampool.monitorsleepinterval>60000</jbo.ampool.monitorsleepinterval>
         <jbo.ampool.timetolive>2850000</jbo.ampool.timetolive>
      </AppModuleConfig> Here is the code that logs out a user:
                // Check whether the URL is the LOGOUT URL
                if (requestURL.endsWith(logoutUrl)) {
                    // Log out, invalidate the session.
                    // Tried the patch mentioned in this thread with no change:
                    // ADF BC/ Faces - Logout exception
                    // This linked blog reports that the below ADFContext
                    // addition fixed it:
                    // http://vgoldin.blogspot.com/2007/02/adf-invalidating-web-session-in-apache.html
                    // but there may be more than one problem here.
                    // Others have suggested just wrapping the invalidate code
                    // in try/catch.
                    // Trying both here.
                    try {
                        ADFContext.getCurrent().removeScope(ADFContext.SESSION_SCOPE);
                    } catch (Exception e) {
                        e.printStackTrace();
                    try {
                        session.invalidate();
                    } catch (Exception e) {
                        e.printStackTrace();
                    MDC.remove(MDC_USERNAME);
                    if (!logoutDestinationUrlChecked && logoutDestinationUrl.startsWith("/")) {
                        logoutDestinationUrlChecked = true;
                        logoutDestinationUrl = request.getContextPath() + logoutDestinationUrl;
                        // relative path, prefix with request context path;
                    log.debug("Session is invalidated, redirecting to " + logoutDestinationUrl);
                    // we do redirect instead of forward so that this filter
                    // will be visisted again for the requested logout
                    // destination
                    // forcing a new login when applicable.
                    response.sendRedirect(response.encodeRedirectURL(logoutDestinationUrl)); DumpPoolStatistics.jsp page output
This page is explained in Steve Muench's blog
head:Application module lifetime statistics
Number of application module creations,3208
Number of application module removals,3184
head:State management statistics
Number of transactional state activations,2073
Number of transactional state passivations,2873
head:Application pool use statistics
Number of application pool check outs,193821
Number of application pool check ins,193818
Number of referenced application modules that were reused,183071
Number of referenced application modules that were recycled,0
Number of unreferenced application modules that were recycled,7594
Number of application pool check out failures,8
head:Application module statistics
Total number of application modules in the pool,24
Maximum number of application modules in the pool,50
Average number of application modules in the pool,23
Total number of available application modules in the pool,21
Average number of available application modules in the pool,21
Average number of unavailable application modules in the pool,2
Total number of referenced application modules in the pool,24
head:Application module age statistics
Number of referenced instances unused for >10 min,7
Number of referenced instances unused for >5 min,2
Number of referenced instances unused for >1 min,6
Number of referenced instances used during last 1 min,9
Number of instances unused for >10 min,0
Number of instances unused for >5 min,0
Number of instances unused for >1 min,0
Number of instances used during last 1 min,0
head:Session statistics
Number of sessions registered with the pool,32
Average number of sessions referencing transactional state,427
head:Session age statistics
Number of sessions inactive for >10 min,14
Number of sessions inactive for >5 min,2
Number of sessions inactive for >1 min,7
Number of sessions active during last 1 min,9 The above DumpPoolStatistics page shows the AM pool shortly after the timetolive has kicked in. There is 24 app modules in the pool despite the jbo.ampool.minavailablesize being 50. There is also 32 users in the application so I would of expected there to be a corresponding number of appModules.
Thanks
Barry
Edited by: Bar on Mar 9, 2011 5:18 PM
Edited by: Bar on Mar 9, 2011 5:20 PM

Answer 1

I believe my problem is that the jbo.ampool.minavailablesize is higher than the normal load on the system. This is stopping app modules to be removed once the jbo.ampool.maxinactiveage time is reached, therefore the only time an AM is removed is when the jbo.ampool.timetolive limit is reached.
e.g.
* 35 users log into the application in the morning. The AM pool contains 35 AM's
* GC on the pool happens. If an AM has reached the jbo.ampool.maxinactiveage then they will not be removed because it would mean that the pool (currently 35) drops below the jbo.ampool.minavailablesize (50)
* GC happens again and the jbo.ampool.timetolive threshold is now reached on all AM's so they are all removed from the pool.