1 of 1 people found this helpful
Have you had the network team verify that the load balancer sticky sessions are set above 90 minutes for timeout? This is an issue that was a major pain point for me when I was a Remedy administrator at my last job. Unfortunately I was single threaded and couldn't dedicate a whole lot of time to it. Most of users would get it sporadically, maybe once or twice a week, and I would just explain to them that since we were load balanced if their network connection was interrupted for any reason and the load balancer forced them over to a different mid-tier server then they would get this message since the invitation they were presenting to the new mid-tier was in fact for the mid-tier they had just dropped from. Now if I had a user that claimed they were getting it on a daily basis I would either pass the issue off to the local or corporate network teams to have them try to track their network traffic and determine what might be happening. A failing hard drive actually wound up being the root cause of this issue for one of my users and they were able to catch it before it failed completely. Once the new drive was put in she didn't have the issue anymore.
May be take a look at these BMC KB..
Mid-Tier: ARERR 9201, session timeout problems
Whether this issue is resolved? You got any update on how it was resolved. Kindly update this thread as we are currently facing the same problem in ARS 8.1 SP1 & MT 8.1 SP1. Whether any patch was released by BMC in order to fix this?
We have not been able to resolve this issue yet.
We are also facing the similar issue in our environment. Does anyone resolved this issue
Our Environment Details
AR Server -- 7.6.04 SP4
Midtier -- 8.1 SP1
We also gathered logs for a specific user and we identified that midtier seems to lost the session id suddenly:
Dec 5, 2014 9:06:03 AM - FINE (com.remedy.log.SERVLET) : GoatServlet: No session or new session
Dec 5, 2014 9:06:03 AM - FINE (com.remedy.log.INTERNAL) : Throw Error - 9201
Dec 5, 2014 9:06:03 AM - FINE (com.remedy.log.PERFORMANCE) : Midtier Compression Index: 1
Dec 5, 2014 9:06:03 AM - FINE (com.remedy.log.PERFORMANCE) : CompressionHelper: Sending uncompressed response
Just out of curiosity, how did the hard drive ended up being a culprit ?
There is a MT 8.1SP2 CU_HF with addresses SW00491497 "Session time-out error is frequent.
It was MT_81SP2_2015JUL16_CU_ALL.zip
Upgrading to SP2 and the H/F may help.
Good to know, We have been fighting this for a while. Single MT, no LB. We just started looking at MT 9.1 this week so I am hoping it is fixed in 9.1 too.
Let us know how it goes for you.
1 of 1 people found this helpful
Sorry it's been awhile since this happened and I am now at another company. Lets see if I can remember this right.
The issue was only affecting the one user so I had the local network team check to make sure it wasn't her jack/cable. Once they cleared everything and confirmed they were seeing sporadic quick network drops and reconnects I sent it to desktop services and they ran diags on the laptop and discovered the HD was slowly dying. Once the drive was replaced the never had the issue again.
My guess is that it was causing other hardware/services to fail and then work again but it was so fast and so Remedy was the only one that was showing the problem since here cookie would have been invalid for the new mid-tier she tried to connect to once she was back on the network.
Keep in mind that this was a one in a million shot that the hard drive wound up being the issue. I only brought it up to point out how many different factors there are involved when trying to troubleshoot a load balanced Remedy environment.
OT: Dude!!!! You are still alive! I was starting to worry about you.