Multiple login in application because of clustering - Websphere

This is a discussion on Multiple login in application because of clustering - Websphere ; Kick out the first login and login now with the id - in this case the previous session is lost We have installed WAS 6.1.0.21 in distributed environment. BOX 1 has the IIS 6.0, WAS Plugin and WAS Dmgr BOX ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: Multiple login in application because of clustering

  1. Multiple login in application because of clustering

    Kick out the first login and login now with the id - in this case the previous session is lost

    We have installed WAS 6.1.0.21 in distributed environment.

    BOX 1 has the IIS 6.0, WAS Plugin and WAS Dmgr
    BOX 2 has a managed node with two JVMs (in cluster)

    We have deployed the application on the cluster in box 2.

    *Problem scenario:*

    When we test this scenario with only one JVM started, we are getting the result which is in accordance with the requirement. But when both the JVMs are up and running, the restricted login mechanism fails.

    This case is arrising when a user already logged in JVM 1 tries to login agian and this time request is directed to JVM 2. Then he is getting a simple login page and not the login validation page as mentioned above.

    *Login Validation Mechanism:*

    Within the application, whenever a user logins, an object of UniversalSesnionMonitor class is getting generated which is holding all the active sessions with Login name. And when any user log into the application, the login name is looked into the session object and that way validation is done.

    *Our understanding:*

    Since we have two JVMs, I guess an object is getting created in each JVM instead of the object getting shared. And hence the validation is happening at JVM level.

    We have enabled session management (Memory to Memory replication) to resolve this issue. Also we have enabled the following options:

    Enable cookies
    Enable rewriting
    Security integration
    Allow serial access

    Any help will be highly appreciated. Thanks in advance.

  2. Re: Multiple login in application because of clustering

    On Sep 11, 8:24*am, "chere...@fr.ibm.com" wrote:
    > Since your list of all active session must be accessible to all new HTTP session (so validation can be done), I suppose that it is not created in the HTTP session cache (which is specific to each client session) which meansthat you are probably using some sort of static class variable somewhere to hold that list.
    > Am I correct?
    > If this is correct, then the behavior that you are experiencing is normal.. Nothing will automatically distribute your list across the nodes/JVMs of your cluster.

    ..... snip ....
    > 2) Use some sort of distributed cache mechanism such as WAS Dynacache which will distribute the list on all JVMs in memory. The possible issue with such technology is the replication latency where a new entry in your list might not be visible to all other JVMs immediately (which can really be a problem in your case).



    some info about dynamic cache for session object sharing,

    http://www.ibm.com/developerworks/we...0606_zhou.html

  3. Re: Multiple login in application because of clustering

    Thanks for the response.



    *1.* I checked with my developers. They are not storing it in a static class. What I understand is they are storing the list of users and objects created in a hash table.



    *2.* I refered to following link for enabling Dynamic cache:



    http://publib.boulder.ibm.com/infoce...esettings.html



    Even after enabling it, I am not getting the desired result. Am I missing anything.



    *3.* after implementing the suggested code level changes we are facing following issue:



    1. Say an user is logged into JVM 1.

    2. Same user is trying to login again and is getting redirected to JVM 2.

    3. There he gets the page to decide whether he wants to forcefully login and end the previous login or whether he wants to cancel this and login using other userid.

    4. He chosses to forcefully login.5. He is able to login and hence invalidating the previous session in JVM2.

    5. But in JVM1 the session is not getting invalidated and the user who is logged in JVM1 with same credentials is facing no problem.



    Please advice.



    Thanks.

  4. Re: Multiple login in application because of clustering

    1. The list of users and objects must be accessible to any new login request. I do not see how this list can be accessible if not stored in a stativ object somewhere. I understand it is stored in a hashtable, the question is how each login request is accessing this hashtable (and make sure that it is always the same hashtable that is accessed)?


    3. You said "after implementing the suggested code level changes we are facing following issue". Which code level changes are you talking about?
    Based on the scenario you described, it does seem that your users/objects hashtable is available on both JVM (since second login directred to JVM2 is asking the user if he wants to forcefully login).

  5. Re: Multiple login in application because of clustering

    1. We have implemented UniversalSessionMonitor class as a Singleton class. Hashtable is a private variable of this class. Hence only one object of this class will be created for one JVM. Hence for 2 JVMs 2 hashtables are getting created.


    2. We have created additional login flag in the database corresponding to user. Whenever user is logged in we are setting the flag. Whenever new login request comes in, we are checking if user entry already exist in the hashtable or the database flag is set. Hence even if hashtable is not accessible in other JVM, due to database flag forceful login page is displayed to the user. We are resetting this flag and also calling the invalidateUser() method to invalidate the user sesion,but user session is not getting invalidated. How do we invalidate the session which is present in other JVM? Is there a way to forecefully replicate the current JVM sessions on the JVM on node 2.


    3. Say User 1 logged in JVM 1. A session gets created in JVM 1 (say session 1). The session gets replicated to JVM 2. Now when we forcefully login, do we actually kill Session 1 in JVM 2?

    Ans: We invalidate the session by user name, this means that we are killing the session 1 which is in JVM2, [ and when replication happens session 1 in JVM1 is also supposed to get invalidated and replaced with new session for that user].

    4. Is it that we are simply looking into database for the user flag and if the flag is set to 1, we are giving out the forceful login page. And when we forcefully login we are creating one more session (say Session 2) in JVM 2 and doing nothing to Session 1 which is already there in JVM2.

    Ans: We are not creating a new session until we are invalidating the Earlier session [if one exists..]

  6. Re: Multiple login in application because of clustering

    Ok, I understand better now. Thanks for the details.
    To invalidate the HTTP session, you need to call the invalidate() method on the HTTPSession object (not sure if this is what you call invalidateUser() below).
    I do not know the behavior of this operation in a cluster environment but I would assume that this should invalidate the session on all nodes.
    With WAS, I am also not sure that invalidate on the HTTPSession is enough to really force a "logout" (redirect to the login page) in the web client. You might also have to clear the LTPA cookie set by WAS (which is really used as the mechanism to determine if the web client is authenticated or not).
    One option would be to have a servlet filter for your web application and add a timestamp or HTTP session id in your database (along with your flag). At each HTTP request, your servlet filter could check if the current HTTP session id matches the one in the database. If not, then invalidate on the HTTP session + clearing the LTPA cookie should force the actual logout (web client will be redirected to the login page).
    Doing a DB query for each HTTP request might cause performance problem. You might also want to cache the current HTTP session id in your memory hashtable and just check from time to time if it changed in your database.

    There might be other/simpler ways to do that as well, I do not know.

  7. Re: Multiple login in application because of clustering

    Thanks a lots for your suggestions..

    A month ago, my development team resolved the issue and we finally delivered the code

    As you suggested, we were already calling session.invalidate() method to destroy session upon forceful login.
    But the issue here was if there exists a user session in other JVM then it was not getting invalidated (from other JVM).

    We implemented following solution to destroy session across all nodes.
    1. Created a JSP (inValidateUser.jsp) which will have logic to invalidate the session. This will take user id as input and invalidate the user if the user is present in the session.
    2. Maintained a list of cluster instance URLs (One URL for each cluster instance) in a property file.
    3. Invoking this JSP on each cluster instance using the URLs maintained in the property file.

    Example:
    try{
    URL url1 = new URL("http://serverName:8080/applContext/inValidateUser.jsp?loginName="+loginName);
    URL url2 = new URL("http://serverName:8082/applContext/inValidateUser.jsp?loginName="+loginName);
    HttpURLConnection urlConnection1 = (HttpURLConnection)url1.openConnection();
    HttpURLConnection urlConnection2 = (HttpURLConnection)url2.openConnection();
    urlConnection1.setDoOutput(true);
    urlConnection1.setRequestMethod("POST");
    urlConnection2.setDoOutput(true);
    urlConnection2.setRequestMethod("POST");

    if ((urlConnection1.getResponseCode() == HttpURLConnection.HTTP_OK)&&
    (urlConnection2.getResponseCode() == HttpURLConnection.HTTP_OK)) {
    System.out.println("OK");
    } else {
    System.out.println("error ");
    }
    }
    catch(Exception ex){
    _log.debug("error in HttpURLConnection......");
    }

+ Reply to Thread