|Re: Session timeout issues [message #1757882 is a reply to message #1757878]
||Tue, 21 March 2017 08:39
| Urs Beeli
Registered: October 2012
Location: Bern, Switzerland
Thanks for you input regarding scout.max.user.idle.time. In our web.xml files there is also the following part:
<!-- Session timeout in minutes -->
So how does scout.max.user.idle.time and the session-timeout in web.xml interact? Do they need to be in sync? Or does one override the other?
Websphere offers the possibility to to have have different clusters on the same Websphere installation and each cluster can have several independent servers onto which you can deploy your applications. Each of those servers runs its own JVM. Deploying more than one WAR file into such a server, they both run in the same JVM, though.
Our setup is as follows:
+ Cluster for Application A
+ 2 Servers for Application A, each with their own JVM
+ Cluster for Application B
+ 2 Servers for Application B, each with their own JVM
+ Cluster for Application C
+ 2 Servers for Application C, each with their own JVM
+ Cluster for Application D
+ 2 Servers for Application D, each with their own JVM
So while all these applications have the same hostname in their URL, they each have a port of their own and their two WAR files have a JVM of their own. So I don't see how a singleton from application A's JVM can be in conflict with the singleton of application B's JVM.
[Updated on: Tue, 21 March 2017 08:40]
Report message to a moderator
|Re: Session timeout issues [message #1757890 is a reply to message #1757882]
||Tue, 21 March 2017 11:30
| Beat Schwarzentrub
Registered: November 2010
The session-timeout specified in the web.xml is the HTTP session timeout managed by the web container. When no resources of the application are touched for the specified time, the HTTP session is invalidated by the container.|
Because the Scout UI regularly polls for asynchronous events on the server (json?poll requests), the HTTP session is touched on each poll request and would never expire. Therefore, Scout checks internally if a request is a "real" user request or just a poll request. If no user request happened for scout.max.user.idle.time, the HTTP session is invalidated by Scout.
Regarding the timeout issue:
Having a separate JVM for each application should indeed not cause any trouble related to the singleton CookieManager.
The behavior you describe sounds really strange. If the browser is closed, all session cookies and the session storage should be cleared. Are you having the same issue, when you open the browser in "incognito mode"? Are you able to debug the UI server? If yes, try setting a breakpoint at org.eclipse.scout.rt.ui.html.json.JsonRequestHelper.createSessionTimeoutResponse() to find the cause of the repeated timeout messages. Unfortunately, we don't have a lot of experience with Websphere WAS, but we did not hear about such an issue yet. Maybe, there is another network component involved that caches user cookies?
Powered by FUDForum
. Page generated in 0.01963 seconds