Reached timeout when trying to aquire lock

[cdx-grillo]

I'm seeing a lot of these messages in the catalina.out log. I'm using redis as the session storage. I've tried various context config params to eliminate the log warning. Currently, I have the context.xml set as follows (which seems pretty high for a timeout):

<Manager className="de.javakaffee.web.msm.MemcachedBackupSessionManager" memcachedNodes="redis://my-redis-host-here" sticky="false" sessionBackupAsync="true" operationTimeout="2000" backupThreadCount="10" lockingMode="auto" requestUriIgnorePattern=".*\.(ico|png|gif|jpg|css|js)$" />

Two questions:

1. is this a critical error I need to be concerned about? Currently, I'm testing in dev with one user so just concerned that having 100 concurrent users in prod will exacerbate the problem.

2. Is there a combination of config entries that may solve the problem as it pertains to redis, non-sticky, async session backup operations?

Thanks very much for your time.

~Greg

[magro]

Hi Greg, I'm currently on vacation and writing from my phone...

With one user in dev you definitely should try to understand what's causing the warning. Please search the mailing list, this was reported some times already and the discussions should clarify things a bit. It seems as if some request takes longer, so that another request cannot obtain the lock. So one question is if you see "long" running requests (ajax, assets etc?).

[cdx-grillo]

Hi Martin, Yes, we definitely have some long running requests and I will check the mailing list for similar discussions.

I'm probably just not clear on how the lock works. I can understand if there is a long running request for a specific session id, that specific session may incur a lock warning (perhaps the user opened another browser tab). But, I'm not clear how a lock for one session can effect obtaining a lock for another session? It seems like these would be independent locks based on session id but apparently not so?

Thanks very much for responding on your time off, really appreciate it.

~Greg

[magro]

A lock for one session cannot (should not) affect obtaining a lock for another session, as it's based on the sessionId. You might want to review the related code: https://github.com/magro/memcached-session-manager/blob/master/core/src/main/java/de/javakaffee/web/msm/LockingStrategyAuto.java#L117

[cdx-grillo]

Ok, thanks much for pointing me in the right direction.