WebSphere Application Server & Liberty

WebSphere Application Server & Liberty

Join this online group to communicate across IBM product users and experts by sharing advice and best practices with peers and staying up to date regarding product enhancements.

 View Only
Back to discussions
Expand all | Collapse all

WebSphere IBM Liberty Session timeout during prcessing request

  • 1.  WebSphere IBM Liberty Session timeout during prcessing request

    Posted Wed June 12, 2019 05:05 AM

    Hello All,

    We have web application developed using jsf myfaces 1.2, we have recently migrated this application to IBM WebSphere Liberty version 18 by using custom jsf implementation we don't use Liberty feature jsf2.0, everything was working smoothly on test env, however when we moved to production we started to see some performance issues, where the users session is terminated during processing request which take much time, we have enabled a session tracking trace, and we can see that during processing the request , the application server think that the user is not authorized and invalidate the session, any idea why the application server think that this user is not authorized however the user is authenticated and has access to this protected page, and the same action sometimes work without any issue.



    Trace :
    [6/11/19 13:35:50:294 TRT] 00000010 WASSessionCor < MemoryStore getSession RETURN # com.ibm.ws.session.store.memory.MemorySession #
     {
     _sessionId=7G39czc4Fp8p3ZVFBjKd9oP
    hashCode : 687245724
    create time : Tue Jun 11 13:32:54 TRT 2019
    last access : Tue Jun 11 13:35:20 TRT 2019
    max inactive interval : 1800
    user name : user:LDAP/CN=USERID,OU=OU,DC=DC,DC=DC,DC=DC
    valid session : true
    new session : false
    overflowed : false
    app name : default_host/appNameMi

    Attribute Names=[jsf_sequence, referenceId, com.ibm.faces.JWL.HX_PORTAL_ENCODING, org.apache.myfaces.application.jsp.JspStateManagerImpl.SERIALIZED_VIEW, javax.faces.request.charset, position_AS_BI_S, totalPagesNA, userName, employee]
     _refCount=1
     }

    [6/11/19 13:35:50:294 TRT] 00000010 WASSessionCor 1 MemorySession getLastAccessedTime 1560249320002 AppName=default_host/appName; Id=7G39czc4Fp8p3ZVFBjKd9oP , _removeAttrOnInvalidate -->true
    [6/11/19 13:35:50:294 TRT] 00000010 WASSessionCor > MemoryStore checkSessionStillValid ENTRY
    [6/11/19 13:35:50:294 TRT] 00000010 WASSessionCor 1 MemorySession getRefCount 1 AppName=default_host/appName; Id=7G39czc4Fp8p3ZVFBjKd9oP , _removeAttrOnInvalidate -->true
    [6/11/19 13:35:50:294 TRT] 00000010 WASSessionCor < MemoryStore checkSessionStillValid RETURN
    [6/11/19 13:35:50:294 TRT] 00000010 WASSessionCor 1 MemorySession incrementRefCount to 2 from 1 AppName=default_host/appName; Id=7G39czc4Fp8p3ZVFBjKd9oP , _removeAttrOnInvalidate -->true
    [6/11/19 13:35:50:294 TRT] 00000010 SessionMonito >  IncrementActiveCount Entry
    [6/11/19 13:35:50:294 TRT] 00000010 SessionMonito <  IncrementActiveCount Exit
    [6/11/19 13:35:50:294 TRT] 00000010 WASSessionCor 1 SessionEventDispatcher sessionAccessed sessionObservers.size()=1
    [6/11/19 13:35:50:294 TRT] 00000010 WASSessionCor 1 MemorySession getVersion() 0 AppName=default_host/appName; Id=7G39czc4Fp8p3ZVFBjKd9oP , _removeAttrOnInvalidate -->true
    [6/11/19 13:35:50:294 TRT] 00000010 WASSessionCor > SessionAffinityManagerImpl setCookie ENTRY
    [6/11/19 13:35:50:294 TRT] 00000010 WASSessionCor < SessionAffinityManagerImpl setCookie RETURN
    [6/11/19 13:35:50:294 TRT] 00000010 WASSessionCor > HttpSessionContextImpl checkSecurity ENTRY
    [6/11/19 13:35:50:294 TRT] 00000010 WASSessionCor 1 MemorySession getUserName user:LDAP/CN=USERID,OU=OU,DC=DC,DC=DC,DC=DC AppName=default_host/appName; Id=7G39czc4Fp8p3ZVFBjKd9oP , _removeAttrOnInvalidate -->true
    [6/11/19 13:35:50:294 TRT] 00000010 WSSecuritySer >  isSecurityEnabled Entry
    [6/11/19 13:35:50:294 TRT] 00000010 WSSecuritySer <  isSecurityEnabled Exit 
                                     true
    [6/11/19 13:35:50:294 TRT] 00000010 WASSessionCor 1 HttpSessionContextImpl checkSecurity calling getUser
    [6/11/19 13:35:50:294 TRT] 00000010 SecurityConte >  getUser Entry
    [6/11/19 13:35:50:294 TRT] 00000010 SecurityConte >  getCallerWSCredential Entry
    [6/11/19 13:35:50:294 TRT] 00000010 SubjectManage >  getCallerSubject Entry
    [6/11/19 13:35:50:294 TRT] 00000010 SubjectManage >  <init> Entry
    [6/11/19 13:35:50:294 TRT] 00000010 SubjectManage <  <init> Exit 
                                     com.ibm.ws.security.context.SubjectManager@eef2a43c
    [6/11/19 13:35:50:294 TRT] 00000010 SubjectManage >  getCallerSubject Entry
    [6/11/19 13:35:50:294 TRT] 00000010 SubjectThread >  getCallerSubject Entry
    [6/11/19 13:35:50:294 TRT] 00000010 SubjectThread <  getCallerSubject Exit 
                                     null
    [6/11/19 13:35:50:294 TRT] 00000010 SubjectManage <  getCallerSubject Exit 
                                     null
    [6/11/19 13:35:50:294 TRT] 00000010 SubjectManage <  getCallerSubject Exit 
                                     null
    [6/11/19 13:35:50:294 TRT] 00000010 SecurityConte <  getCallerWSCredential Exit 
                                     null
    [6/11/19 13:35:50:294 TRT] 00000010 SecurityConte <  getUser Exit 
                                     null
    [6/11/19 13:35:50:294 TRT] 00000010 srt           1 com.ibm.ws.webcontainer.srt.SRTServletRequest getRunningCollaborators  value --> false
    [6/11/19 13:35:50:295 TRT] 00000010 WASSessionCor 1 HttpSessionContextImpl doSecurityCheck UnauthorizedSessionRequestException thrown - invalidating session
    [6/11/19 13:35:50:295 TRT] 00000010 WASSessionCor > MemorySession invalidate ENTRY  AppName=default_host/appName; Id=7G39czc4Fp8p3ZVFBjKd9oP ,



    ------------------------------
    Omar Adel
    ------------------------------


  • 2.  RE: WebSphere IBM Liberty Session timeout during prcessing request

    Posted Thu June 13, 2019 10:01 AM
    Omar
    " we have recently migrated this application to IBM WebSphere Liberty version 18 by using custom jsf implementation we don't use Liberty feature jsf2.0, "

    Your use of a custom JSF implementation and not the Liberty provided feature means that the trace information needed to diagnose your problem isn't present in the trace.

    In my experience this means that you'll need to instrument your custom JSF implementation with  additional code for tracing , just as IBM does with the Liberty (and tWAS) provided feature in order to accurately determine the root cause.

    ------------------------------
    Tom Alcott
    Senior Technical Staff Member
    IBM
    ------------------------------

    Original Message