Unable to login to admin (dotCMS 3.2)

[Hidde Boonstra]

Hi all,

we are experiencing some weird behavior in dotCMS 3.2 and we're not sure its a bug, so we would like to see if other people are experiencing similar problems. Every now and then we are unable to login to the admin due to an exception occurring: 

java.lang.IllegalStateException: setAttribute: Session [...] has already been invalidated

The weird thing is, that if we throw away our cookies, the exception will still occur and with the same Session ID. Even in another browser (but the same user) the exception occurs as if the session is bound to the user and not the session cookie. Restarting dotCMS is the only way around this once it occurs. The context of the exception is:

java.lang.IllegalStateException: setAttribute: Session [D1743BAC50863C6FA718997620C8505D] has already been invalidated

at org.apache.catalina.session.StandardSession.setAttribute(StandardSession.java:1476)

at org.apache.catalina.session.StandardSession.setAttribute(StandardSession.java:1441)

at org.apache.catalina.session.StandardSessionFacade.setAttribute(StandardSessionFacade.java:142)

at com.liferay.portal.events.LoginPostAction.run(LoginPostAction.java:83)

... 73 more

Has anyone else seen this behavior?

Thanks,

Hidde.

[Brent Griffin]

I have not seen this behavior but I do have something for you to try.  Next time this happens, access destroy.jsp on the root of your server.  i.e. http://localhost:8080/destroy.jsp  This page will destroy your session on the server and should prevent a restart.

Ok, now some questions to help us diagnose what is happening:

Is it possible that you are accessing another dotcms server with this same browser that could be causing the browser to get confused with its cookies or cache?  Is this just on one particular browser or all browsers?  Is this limited to a subset of users or is everyone experiencing this problem?

Brent Griffin

Sr. Java Architect

Director of Quality Assurance

dotCMS

[Hidde Boonstra]

Hi Brent,

thanks for your reply.

On Wednesday, May 13, 2015 at 2:24:45 PM UTC+2, Brent Griffin wrote:

I have not seen this behavior but I do have something for you to try.  Next time this happens, access destroy.jsp on the root of your server.  i.e. http://localhost:8080/destroy.jsp  This page will destroy your session on the server and should prevent a restart.

Excellent, if that works it would save us a lot of trouble! We will try, the next time this issue returns.

 

Ok, now some questions to help us diagnose what is happening:

Is it possible that you are accessing another dotcms server with this same browser that could be causing the browser to get confused with its cookies or cache?  Is this just on one particular browser or all browsers?  Is this limited to a subset of users or is everyone experiencing this problem?

I always have multiple servers open in the same browser. I find it unlikely that this would confuse the browser, even though it confuses me sometimes ;-) 

Last time the issue appeared, I was using Firefox (37.0.2) but the same exception (for the same Session ID) was logged when I tried to login using Chrome (42). So login request from two separate browsers caused a stacktrace containing the same Session ID.

[Brent Griffin]

Are you connecting directly to the dotCMS server or do you have another server in front of dotCMS (i.e. nginx, apache, etc)?

[Hidde Boonstra]

In the development environment, where the problem currently occurs, we are connected directly to dotCMS. I have been checking the source and it seems that if you disable 'AUTH_SIMULTANEOUS_LOGINS' the previous session of a user will be marked as stale upon login. Could it be that multiple tabs with the same session, combined with the new 'session expired!' popup doesn't play nice with disabling simultaneous logins?

I will do some tests today (waiting for sessions to expire while continuing work in another tab) and report back.

Regards,

Hidde.

[Hidde Boonstra]

Typical... I haven't been able to reproduce the problem, but since nobody else on the forum reported similar problems I will assume the problems lay somewhere in our custom code.

Thanks!,

H.