Skip to main content

Hello,

After upgrading from assyst 11.2.6 and then to 11.4.3 and 11.4.4, some assyst Users started complaining about frequent disconnections from assyst Portal, well bellow the session timeout period defined in your system: 25200 seconds, which corresponds to our default shift time of 7 hours

 

Yesterday I experienced this while updating an item form, suddenly I was logged off with a message that my session had expired. 

 

I’m finding it very difficult to track this issue. Any ideas on how to track this issue ?

 

After analyzing my server.log file, I noticed the following issues several messages like the following:

 

Unhandled exception: org.jboss.resteasy.spi.UnhandledException: RESTEASY003770: Response is committed, can't handle exception.

Bellow that message, in general, just bellow it there’s a mesasge like this: “ java.lang.IllegalStateException: UT010006: Cannot call getWriter(), getOutputStream() already called”

 

In both message there’s a full stack trace, making the log extremely large.  In 12 hours since last restart, our server.log is roughly 15k lines in size.

Will you be able to check “Maximum Session Life” system parameter value?
You can define this time in minutes. This type of scenario can happen if this parameter value is less than ‘session timeout period’ in your case 7 hours. 


Hello Rajana,

 

It’s set to 720, which translates to 12 hours. Is there any issue when it’s higher than ‘session timeout period’?


Hi Otmar, 

I’d suggest using max session life instead of the session timeout setting as max session life will ask your users whether or not they are active once the defined time limit has been reached and then either kick them out if no response is given or extend their session if they tell assyst that they are still working. This in theory means that no user will ever be kicked out when they are in the middle of working on something inside assyst.

Setting it to your average shift length is a good idea, i’d maybe suggest going slightly over this number to avoid people being asked at the very end of their shift. For example if their shift is 7 hours and they clock on 5 minutes early they will then be asked 5 minutes before their shift ends and if they respond to the popup their session will then be extended despite their shift finishing in 5 minutes. 8 hours is probably a good number to use for 7 hour shift lengths.

I believe you can disable the session timeout setting by setting the parameter value to 0, i’d give this a test to confirm.

I’m not sure what the errors you are seeing are related to or whether or not they are session related either. You could have two different issues occurring at the same time with no relation to each other. As a result I’d suggest logging a ticket with the support team to have the errors in your server log investigated properly.

Hope this helps!

Cheers,
Robert


Hello Robert,

 

Last november 10th I’ve submitted a ticket with the support team, but that’s one of those hard to catch that endure for several months.

So far, they’ve asked me to capture the exact moment an assyst user is logged off so they can trace it on the server.log file. However, there’s nothing on server.log file and we’re still wating instructions on the proper log settings to get these details on server.log file.

 

About the session timeout parameter, after checking the wiki page, I could not find any information that indicates that zero would disable it. Based on the information about the default value, I guess that setting it to zero would make it have it’s default value.

 

Moreover, if session timeout is set to 7 hours (our shift time) and max session life is set to 10 hours, shouldn’t it last for at least 7 hours? Last monday I’m pretty sure I’ve been disconnected roughly around 5 hours after my first login while on event’s form. 

I was looking for ideas of capturing it also on client side, so maybe, I could check that client side info with server.log file. Any ideas on how to do this on the client side? And what about the server configurations to enable logging of users who have been disconnected? 


Hi Otmar,

You’re correct, if the max session life is set to 10 hours you shouldn’t be disconnected before the 10 hour period is up - if this is happening it may suggest that something else is killing the session rather than the timeout settings.

For troubleshooting it would be much better to see what’s happening from the client side. Personally, I’d suggest a user who experiences the disconnects to run a networking app such as Fiddler to capture the network traffic at the time of disconnect as this would give a good indication of what happens at the point of failure. It would likely mean running Fiddler all day though, but it’s probably the only way of making sure the disconnect is captured. The support team may have other suggestions for ways to do this.

Cheers,
Robert
 


Reply