UMP error: session already invalidated

book

Article ID: 35005

calendar_today

Updated On:

Products

DX Infrastructure Management NIMSOFT PROBES

Issue/Introduction

Symptoms:


Example:


screenshot of error message from UMP

wasp.log message corresponding with error:

08 Jun 2015 14:53:19,085 ERROR [DataFactoryException:82] getAttribute: Session already invalidated 
08 Jun 2015 14:53:19,088 ERROR [DataFactoryException:84] java.lang.IllegalStateException: getAttribute: Session already invalidated 



Environment

Release: NMSASE99000-6.5-Monitoring Solution-Application Server-for Enterprise
Component:

Resolution

Solution:

This error can be highly environmental.


Here is a general description of what causes the error: 

- when a user logs into UMP a session is created for that user 

- this session times out in 5 minutes 

- if a user is still browsing a page in UMP after the 5 minutes, the session is extended for 1 minute. 

- every 1 minute, the UMP checks to see if the browser is still connected and actively browsing 

- if so, the session is extended for 1 minute again until the user closes the browser. 


The "Session already invalidated" message indicates that, for some reason, the UMP thinks that the browser has disconnected, and the session was allowed to time out. Then, on the next time the browser tries to take some action or refresh the view, etc, the "session already invalidated" error is thrown, indicating that the UMP has already closed this session since it thinks it lost contact with the browser. 


This may be caused by things like: 

- excessive load on the UMP causing it to fail to respond to browser requests in time 

- network issues causing a drop in the established connection between UMP and the browser 

- a proxy server in between UMP and the browser which is not properly set for "sticky sessions" 

- antivirus or network security interfering with the connection between UMP and browser 

- users sharing usernames/passwords, where multiple users are viewing the same page from the same location using the same username -- one user logging out may cause this error to appear for the other users who are using the same username 


Suggested Resolution:


Note that this may not resolve the issue in all cases (especially those caused by environmental/network issues, resource constraints, etc.) but may help.


First, edit the dashboard_engine.cfg and look for the <updateintervals> section (via Raw Configure) - set the following values (some of these may differ only slightly from the current values.) 


Please note, dashboard_engine and dap are no longer valid for UIM 8.2 and above and this section can be skipped for those versions.


update_ums_interval = 79 

dap_query_interval = 37 

stat_verification_interval = 59 

dashboard_cleanup = 77 

tz_offset_check_interval = 1 

query_max_row_count = 100 

robot_list_rebuild_interval = 69 

multi_instance_check_interval = 45 

dynamic_views = 81 

subscription_verification_interval = 73 

system_check = 31 

query_refresh_rate = 57 

dashboards = 46 

variables = 38 

preview_cleanup = 61 


Next, edit the wasp.cfg (via Raw Config) and set the following values:


nimpool_max_wait = 300 

nimpool_timeout = 300 



Next, it's possible to adjust session timeouts to a higher value by modifying settings in 2 files on the UMP server:


C:\Program Files (x86)\Nimsoft\probes\service\wasp\webapps\ROOT\WEB-INF\classes\portal-ext.properties 


locate and modify the following:


session.timeout=5 

session.timeout.warning=1 

session.timeout.auto.extend=true 


change to: 


session.timeout=10 

session.timeout.warning=3 

session.timeout.auto.extend=true 


Next file: C:\Program Files (x86)\Nimsoft\probes\service\wasp\webapps\ROOT\WEB-INF\web.xml file 


locate:

-<session-config> <session-timeout>5</session-timeout> </session-config> 


change to: 


-<session-config> <session-timeout>10</session-timeout> </session-config> 


It may also help to increase the maximum Java memory allocated to the WASP probe (which can be done in the probe's configuration GUI).



Finally, this can be caused by database performance related to high levels of index fragmentation on the database server. The following index rebuild statements will rebuild the indexes on the tables most often affected:





ALTER INDEX ALL ON S_QOS_DATA REBUILD; 


ALTER INDEX ALL ON CM_GROUP REBUILD; 


ALTER INDEX ALL ON CM_COMPUTER_SYSTEM REBUILD; 


ALTER INDEX ALL ON CM_COMPUTER_SYSTEM_ATTR REBUILD; 


ALTER INDEX ALL ON CM_DEVICE REBUILD; 


ALTER INDEX ALL ON CM_DEVICE_ATTRIBUTE REBUILD; 


ALTER INDEX ALL ON CM_CONFIGURATION_ITEM REBUILD; 


ALTER INDEX ALL ON CM_CONFIGURATION_ITEM_METRIC REBUILD; 


ALTER INDEX ALL ON CM_CONFIGURATION_ITEM_ATTRIBUTE REBUILD; 


ALTER INDEX ALL ON CM_CONFIGURATION_ITEM_DEFINITION REBUILD; 


ALTER INDEX ALL ON CM_CONFIGURATION_ITEM_METRIC_DEFINITION REBUILD; 


ALTER INDEX ALL ON NAS_ALARMS REBUILD; 


ALTER INDEX ALL ON NAS_TRANSACTION_SUMMARY REBUILD; 


ALTER INDEX ALL ON NAS_TRANSACTION_LOG REBUILD; 


   

Attachments

1558722536589000035005_sktwi1f5rjvs16wik.jpeg get_app