Any error messages pop up or users simply get logged out? which version are you using, what kind of environment you have? Are there any external integrations? some things you can check :
- What value is set for 'Process timeout' under server information -> timeouts tab? set it to max 60(mx)
- What value is set for 'Floating License timeout' under server information -> timeouts tab? set it to max 99(max)
- In case of External Authentication what value is set under server information -> EA tab ->EA Server timeout ->RPC? leave it blank if it does not have a value.
Also refer to white papers + known errors, this might be a know issue with some workaround.
This is the error that the users are getting, sometimes right after they log in:
"ARERR  Session is invalid or has timed out. Please reload page to log in again."
We have two seperate prod instances on two VMs. We also have a 'poor man's load balancer', a dns which resolves to one of the two ip addresses arbitrarily with no logic. We plan to put in true netscalers once they are fully configured.
we are running version 7.6.04
I am currently looking for the server information settings amey mentioned. We remote desktop into the VM, where do I find these settings?
If your users are connected via Mid-Tiers I'm pretty sure your DNS load balancing simply won't work. Although I'd be very positive about it in previous versions, it's to be confirmed in 188.8.131.52. I know BMC made changes to session management by MT in this version.
Sessions are opened and stored on each MT. Your "invalid session" messages occur when a client system is connected to the first server and decides to refresh its DNS cache for your server, and gets the IP address of the second server. The server simply doesn't know about it because no session was opened on it for this user.
Testing should be quick :
- by activating "session" logs in "fine" mode on each MT : you'll see both sessions creation on the first MT and errors on the second
- try disabling the second address in the DNS during off-peak hours
once you login to remedy, on the home page click on 'AR System Administration Console' -> 'System' -> 'General' -> 'Server Information'.
I agree with svyon, either too many sessions between the client and app server are getting established or the load balancer is not efficient enough.
Recently when we faced this issue, logging out -> closing the browser and logging in again using new browser window helped us get past.
Process Timeout: 5
Floating License Timeout: 1
EA RPC: blank
Thanks syvon, amey. We will try to test our current setup to see if anything can be done to improve this behavior.
Question - when we get the netscalers up and running, which will be actual load balancers, will this still be a problem do you think?
You need to check those:
-> timeout "chain" (Apache / tomcat / Load Balancer / Mid-tier, it's an example) is coherent,
-> check if you're using some kind of "sticky" in front of the mid-tiers (like cookie persistence),
-> if you're using a mid-tier that is before ARS 7.6.04 sp2 + hotfix 011812, you should consider update because there is a "false" positive 9201 that is solved with hotfix for mid-tier 011812. Basically users had those 9201 errors but in fact they could continue to work.
To see if it's "real" 9201 errors, enable fiddler on some user's desktops and logs at FINE + detailed text (all checkbox checked) mid-tier side, then when the 9201 happens, check in fiddler logs if you find a "9201" error and check also in mid-tier logs.
If you don't see it in fiddler or mid-tier, it means it's a "false positive" I mentionned.
If it's a real one, check the JSESSIONID. If it changed, that explains why the 9201 happened and you should focus on why it changed.
In fact Fiddler is a tool you install on your desktop that captures all internet traffic. This way you can see exactly the GET/POST/COOKIES sent/received by IE or Firefox
This way you can see if the Session ID (JSESSIONID) remains the same for all requests or changes.
If you're using Apache with multiple Tomcat back ends, you need to enable sticky sessions. This involves a change to context.xml (I think setting a value on the engine element), and changes to workers.properties. Saying that, there's almost no reason to use a webserver front end to Tomcat/Mid Tier.
If you're using a load balancer of any kind, sticky sessions must be set because BMC Mid Tier doesn't replicate sessions.
SSO Plugin for BMC, HP and more.