Hi Martin,

I'm experiencing a locking-related issue using MSM with non-sticky
sessions.

Using:
MSM 1.6.1
Tomcat 7.0.23
spymemcached 2.7.3

Here's my MSM config:

<Manager
className="de.javakaffee.web.msm.MemcachedBackupSessionManager"
memcachedNodes="n1:node1.domain.name:11211,n2:node2.domain.name:
11211"
sticky="false"
lockingMode="auto"
requestUriIgnorePattern=".*\.(ico|png|gif|jpg|css|js)$"
sessionBackupAsync="false"
sessionBackupTimeout="2000"
operationTimeout="1000"
/>

One of my requests checks to see if a session exists, and if it
doesn't it creates a session and redirects to itself. Using
lockingMode="auto" I experience behavior where this request will get
stuck in a redirect loop for an arbitrary amount of time before
correctly picking up the session. I've seen it get stuck for anywhere
between a few seconds to 5 minutes. If I set lockingMode="all" the
issue is fixed, but this is obviously undesirable as most my requests
are read-only.

I had picked lockingMode="auto" because it seemed like the smartest
option. The documentation says: "readonly requests are detected, for
them the session is not locked. For requests that are not classified
as 'readonly' the session is locked". I'm wondering how this behavior
works exactly - can you please explain how read-only requests are
detected and kept track of and/or point me to the relevant source
code?

I've also noticed the following warning, though I haven't confirmed
that it's related to this issue:

"WARNING: Reached timeout when trying to aquire lock for session [ID].
Will use this session without this lock."

What does "Will use this session without this lock" mean here - does
that mean the request is effectively read-only and any writes will be
ignored? That seems like it should be a last resort, so would you say
I have a latency issue with writing to memcached? What setting
controls the timeout in question here? I assumed it was
operationTimeout but as you can see that's currently set to a generous
1000 millis.

If I can't use lockingMode="auto" it seems like I'd need to use
uriPattern to match specific requests that need to be locked. That
would be annoying to maintain though.

Please let me know if you need any more information.

Paul

Search Discussions

  • Martin Grotzke at Jun 4, 2012 at 7:34 pm
    Hi Paul,
    On 06/04/2012 08:26 PM, Paul Bellora wrote:
    I had picked lockingMode="auto" because it seemed like the smartest
    option. The documentation says: "readonly requests are detected, for
    them the session is not locked. For requests that are not classified
    as 'readonly' the session is locked". I'm wondering how this behavior
    works exactly - can you please explain how read-only requests are
    detected and kept track of and/or point me to the relevant source
    code?
    1a) When a session is looked up in memcached the session is locked (see
    MemcachedSessionService.loadFromMemcached,
    LockingStrategyAuto.onBeforeLoadFromMemcached) - unless the request is
    already known to be readonly.
    1b) When the session could not be found the lock is released

    2) When the request is finished (and the session was loaded), the lock
    is released and the requestURI is registered as readonly if the session
    was not modified or as modifying otherwise (see
    LockingStrategyAuto.onAfterBackupSession).

    I see two possible issues in the code:
    - When the lock is released this is done asynchronously (see e.g.
    LockingStrategy.releaseLock: memcached.delete returns a Future that's
    not get()'ed)
    - Another issue might be caused by parallel requests in the same tomcat,
    where the first locks the session and the second waits for the lock.
    Right now it seems to me as if this case is not yet properly handled
    (see MemcachedSessionService.findSession/loadFromMemcached).

    I've also noticed the following warning, though I haven't confirmed
    that it's related to this issue:

    "WARNING: Reached timeout when trying to aquire lock for session [ID].
    Will use this session without this lock."

    What does "Will use this session without this lock" mean here - does
    that mean the request is effectively read-only and any writes will be
    ignored?
    No, it does mean: we use the session and also write changes through to
    memcached.
    Yes, this could be somehow configurable so that users can choose how
    such a case should be handled. Any opinions?

    That seems like it should be a last resort, so would you say
    I have a latency issue with writing to memcached? What setting
    controls the timeout in question here? I assumed it was
    operationTimeout but as you can see that's currently set to a generous
    1000 millis.
    Yes, it's operationTimeout. Connection to memcached might be one issue,
    another reason might be some other/parallel request (running in another
    tomcat) holding the lock for such a long time.

    If I can't use lockingMode="auto" it seems like I'd need to use
    uriPattern to match specific requests that need to be locked. That
    would be annoying to maintain though.
    Right, and I'd be happy if we could improve lockingMode="auto".

    Please let me know if you need any more information.
    To start you should activate debug logging and see if this provides some
    insights (and/or share logs here):
    http://code.google.com/p/memcached-session-manager/wiki/SetupAndConfiguration#Configure_logging


    Another approach would be to create an integration test that shows the
    issue (NonStickySessionsIntegrationTest already has some) and use this
    for debugging.

    Cheers,
    Martin
  • Paul Bellora at Jun 5, 2012 at 9:42 pm
    Hi Martin,

    Thanks for the quick and detailed reply! Unfortunately I haven't had time
    to examine the issue any further. For the time being I'm just using
    lockingMode="all". I'll try your suggestions when I get a chance.

    Paul
    On Mon, Jun 4, 2012 at 3:34 PM, Martin Grotzke wrote:

    Hi Paul,
    On 06/04/2012 08:26 PM, Paul Bellora wrote:
    I had picked lockingMode="auto" because it seemed like the smartest
    option. The documentation says: "readonly requests are detected, for
    them the session is not locked. For requests that are not classified
    as 'readonly' the session is locked". I'm wondering how this behavior
    works exactly - can you please explain how read-only requests are
    detected and kept track of and/or point me to the relevant source
    code?
    1a) When a session is looked up in memcached the session is locked (see
    MemcachedSessionService.loadFromMemcached,
    LockingStrategyAuto.onBeforeLoadFromMemcached) - unless the request is
    already known to be readonly.
    1b) When the session could not be found the lock is released

    2) When the request is finished (and the session was loaded), the lock
    is released and the requestURI is registered as readonly if the session
    was not modified or as modifying otherwise (see
    LockingStrategyAuto.onAfterBackupSession).

    I see two possible issues in the code:
    - When the lock is released this is done asynchronously (see e.g.
    LockingStrategy.releaseLock: memcached.delete returns a Future that's
    not get()'ed)
    - Another issue might be caused by parallel requests in the same tomcat,
    where the first locks the session and the second waits for the lock.
    Right now it seems to me as if this case is not yet properly handled
    (see MemcachedSessionService.findSession/loadFromMemcached).

    I've also noticed the following warning, though I haven't confirmed
    that it's related to this issue:

    "WARNING: Reached timeout when trying to aquire lock for session [ID].
    Will use this session without this lock."

    What does "Will use this session without this lock" mean here - does
    that mean the request is effectively read-only and any writes will be
    ignored?
    No, it does mean: we use the session and also write changes through to
    memcached.
    Yes, this could be somehow configurable so that users can choose how
    such a case should be handled. Any opinions?

    That seems like it should be a last resort, so would you say
    I have a latency issue with writing to memcached? What setting
    controls the timeout in question here? I assumed it was
    operationTimeout but as you can see that's currently set to a generous
    1000 millis.
    Yes, it's operationTimeout. Connection to memcached might be one issue,
    another reason might be some other/parallel request (running in another
    tomcat) holding the lock for such a long time.

    If I can't use lockingMode="auto" it seems like I'd need to use
    uriPattern to match specific requests that need to be locked. That
    would be annoying to maintain though.
    Right, and I'd be happy if we could improve lockingMode="auto".

    Please let me know if you need any more information.
    To start you should activate debug logging and see if this provides some
    insights (and/or share logs here):

    http://code.google.com/p/memcached-session-manager/wiki/SetupAndConfiguration#Configure_logging


    Another approach would be to create an integration test that shows the
    issue (NonStickySessionsIntegrationTest already has some) and use this
    for debugging.

    Cheers,
    Martin
  • Paul Bellora at Jun 8, 2012 at 6:17 pm
    Hi Martin,

    I have an update for your about the above described issue, and more
    questions.

    Even with lockingMode="all" I am still seeing the above described issue.
    The issue seems to be exposed by a request in my application that handles
    auto-login - it creates a new session and then immediately redirects.

    From what I can tell the following is happening: On the first request, a
    new session is created - when that request ends I can see the session in
    Tomcat, and the session cookie in the browser, but I don't see the session
    in memcached. It is only *after the second request finishes* that the
    session appears in memcached.

    Is it possible that your manager is holding off on writing the new session
    until the second request? I can understand why this optimization might have
    been made for sticky sessions, but I think it would be a bug for non-sticky.

    Please let me know if you need more information. Unfortunately I haven't
    been able to get logging working on my dev environment - I can bang on that
    more if it's necessary.

    Thanks,
    Paul
    On Tue, Jun 5, 2012 at 5:42 PM, Paul Bellora wrote:

    Hi Martin,

    Thanks for the quick and detailed reply! Unfortunately I haven't had time
    to examine the issue any further. For the time being I'm just using
    lockingMode="all". I'll try your suggestions when I get a chance.

    Paul


    On Mon, Jun 4, 2012 at 3:34 PM, Martin Grotzke <
    martin.grotzke@googlemail.com> wrote:
    Hi Paul,
    On 06/04/2012 08:26 PM, Paul Bellora wrote:
    I had picked lockingMode="auto" because it seemed like the smartest
    option. The documentation says: "readonly requests are detected, for
    them the session is not locked. For requests that are not classified
    as 'readonly' the session is locked". I'm wondering how this behavior
    works exactly - can you please explain how read-only requests are
    detected and kept track of and/or point me to the relevant source
    code?
    1a) When a session is looked up in memcached the session is locked (see
    MemcachedSessionService.loadFromMemcached,
    LockingStrategyAuto.onBeforeLoadFromMemcached) - unless the request is
    already known to be readonly.
    1b) When the session could not be found the lock is released

    2) When the request is finished (and the session was loaded), the lock
    is released and the requestURI is registered as readonly if the session
    was not modified or as modifying otherwise (see
    LockingStrategyAuto.onAfterBackupSession).

    I see two possible issues in the code:
    - When the lock is released this is done asynchronously (see e.g.
    LockingStrategy.releaseLock: memcached.delete returns a Future that's
    not get()'ed)
    - Another issue might be caused by parallel requests in the same tomcat,
    where the first locks the session and the second waits for the lock.
    Right now it seems to me as if this case is not yet properly handled
    (see MemcachedSessionService.findSession/loadFromMemcached).

    I've also noticed the following warning, though I haven't confirmed
    that it's related to this issue:

    "WARNING: Reached timeout when trying to aquire lock for session [ID].
    Will use this session without this lock."

    What does "Will use this session without this lock" mean here - does
    that mean the request is effectively read-only and any writes will be
    ignored?
    No, it does mean: we use the session and also write changes through to
    memcached.
    Yes, this could be somehow configurable so that users can choose how
    such a case should be handled. Any opinions?

    That seems like it should be a last resort, so would you say
    I have a latency issue with writing to memcached? What setting
    controls the timeout in question here? I assumed it was
    operationTimeout but as you can see that's currently set to a generous
    1000 millis.
    Yes, it's operationTimeout. Connection to memcached might be one issue,
    another reason might be some other/parallel request (running in another
    tomcat) holding the lock for such a long time.

    If I can't use lockingMode="auto" it seems like I'd need to use
    uriPattern to match specific requests that need to be locked. That
    would be annoying to maintain though.
    Right, and I'd be happy if we could improve lockingMode="auto".

    Please let me know if you need any more information.
    To start you should activate debug logging and see if this provides some
    insights (and/or share logs here):

    http://code.google.com/p/memcached-session-manager/wiki/SetupAndConfiguration#Configure_logging


    Another approach would be to create an integration test that shows the
    issue (NonStickySessionsIntegrationTest already has some) and use this
    for debugging.

    Cheers,
    Martin
  • Martin Grotzke at Jun 8, 2012 at 9:02 pm
    Hi Paul,
    On 06/08/2012 08:17 PM, Paul Bellora wrote:
    Hi Martin,

    I have an update for your about the above described issue, and more
    questions.

    Even with lockingMode="all" I am still seeing the above described issue.
    The issue seems to be exposed by a request in my application that
    handles auto-login - it creates a new session and then immediately
    redirects.

    From what I can tell the following is happening: On the first request, a
    new session is created - when that request ends I can see the session in
    Tomcat, and the session cookie in the browser, but I don't see the
    session in memcached. It is only /after the second request finishes/
    that the session appears in memcached.
    So all your code is doing is creating a session and then redirects?

    Describes this everything I have to do (in some sample webapp) to
    reproduce your issue? Can you reproduce this with a plain new webapp
    just doing this?
    Is it possible that your manager is holding off on writing the new
    session until the second request?
    No.

    Cheers,
    Martin

    I can understand why this optimization
    might have been made for sticky sessions, but I think it would be a bug
    for non-sticky.

    Please let me know if you need more information. Unfortunately I haven't
    been able to get logging working on my dev environment - I can bang on
    that more if it's necessary.

    Thanks,
    Paul

    On Tue, Jun 5, 2012 at 5:42 PM, Paul Bellora wrote:

    Hi Martin,

    Thanks for the quick and detailed reply! Unfortunately I haven't
    had time to examine the issue any further. For the time being I'm
    just using lockingMode="all". I'll try your suggestions when I get
    a chance.

    Paul


    On Mon, Jun 4, 2012 at 3:34 PM, Martin Grotzke
    wrote:

    Hi Paul,
    On 06/04/2012 08:26 PM, Paul Bellora wrote:
    I had picked lockingMode="auto" because it seemed like the smartest
    option. The documentation says: "readonly requests are
    detected, for
    them the session is not locked. For requests that are not
    classified
    as 'readonly' the session is locked". I'm wondering how this behavior
    works exactly - can you please explain how read-only requests are
    detected and kept track of and/or point me to the relevant source
    code?
    1a) When a session is looked up in memcached the session is
    locked (see
    MemcachedSessionService.loadFromMemcached,
    LockingStrategyAuto.onBeforeLoadFromMemcached) - unless the
    request is
    already known to be readonly.
    1b) When the session could not be found the lock is released

    2) When the request is finished (and the session was loaded),
    the lock
    is released and the requestURI is registered as readonly if the
    session
    was not modified or as modifying otherwise (see
    LockingStrategyAuto.onAfterBackupSession).

    I see two possible issues in the code:
    - When the lock is released this is done asynchronously (see e.g.
    LockingStrategy.releaseLock: memcached.delete returns a Future
    that's
    not get()'ed)
    - Another issue might be caused by parallel requests in the same
    tomcat,
    where the first locks the session and the second waits for the lock.
    Right now it seems to me as if this case is not yet properly handled
    (see MemcachedSessionService.findSession/loadFromMemcached).

    I've also noticed the following warning, though I haven't confirmed
    that it's related to this issue:

    "WARNING: Reached timeout when trying to aquire lock for
    session [ID].
    Will use this session without this lock."

    What does "Will use this session without this lock" mean here - does
    that mean the request is effectively read-only and any writes will be
    ignored?
    No, it does mean: we use the session and also write changes
    through to
    memcached.
    Yes, this could be somehow configurable so that users can choose how
    such a case should be handled. Any opinions?

    That seems like it should be a last resort, so would you say
    I have a latency issue with writing to memcached? What setting
    controls the timeout in question here? I assumed it was
    operationTimeout but as you can see that's currently set to a generous
    1000 millis.
    Yes, it's operationTimeout. Connection to memcached might be one
    issue,
    another reason might be some other/parallel request (running in
    another
    tomcat) holding the lock for such a long time.

    If I can't use lockingMode="auto" it seems like I'd need to use
    uriPattern to match specific requests that need to be locked. That
    would be annoying to maintain though.
    Right, and I'd be happy if we could improve lockingMode="auto".

    Please let me know if you need any more information.
    To start you should activate debug logging and see if this
    provides some
    insights (and/or share logs here):
    http://code.google.com/p/memcached-session-manager/wiki/SetupAndConfiguration#Configure_logging


    Another approach would be to create an integration test that
    shows the
    issue (NonStickySessionsIntegrationTest already has some) and
    use this
    for debugging.

    Cheers,
    Martin

    --
    inoio gmbh - http://inoio.de
    Breitenfelder Str. 13c, 20251 Hamburg
    Amtsgericht Hamburg, HRB 123031
    Geschäftsführer: Dennis Brakhane, Martin Grotzke, Ole Langbehn
  • Martin Grotzke at Jun 8, 2012 at 9:05 pm

    On 06/08/2012 11:02 PM, Martin Grotzke wrote:
    Hi Paul,
    On 06/08/2012 08:17 PM, Paul Bellora wrote:
    Hi Martin,

    I have an update for your about the above described issue, and more
    questions.

    Even with lockingMode="all" I am still seeing the above described issue.
    The issue seems to be exposed by a request in my application that
    handles auto-login - it creates a new session and then immediately
    redirects.

    From what I can tell the following is happening: On the first request, a
    new session is created - when that request ends I can see the session in
    Tomcat, and the session cookie in the browser, but I don't see the
    session in memcached. It is only /after the second request finishes/
    that the session appears in memcached.
    So all your code is doing is creating a session and then redirects?

    Describes this everything I have to do (in some sample webapp) to
    reproduce your issue? Can you reproduce this with a plain new webapp
    just doing this?
    Do you use container managed (e.g. form based) auth?

    Cheers,
    Martin

    Is it possible that your manager is holding off on writing the new
    session until the second request?
    No.

    Cheers,
    Martin

    I can understand why this optimization
    might have been made for sticky sessions, but I think it would be a bug
    for non-sticky.

    Please let me know if you need more information. Unfortunately I haven't
    been able to get logging working on my dev environment - I can bang on
    that more if it's necessary.

    Thanks,
    Paul

    On Tue, Jun 5, 2012 at 5:42 PM, Paul Bellora <pbellora@whosay.com
    wrote:

    Hi Martin,

    Thanks for the quick and detailed reply! Unfortunately I haven't
    had time to examine the issue any further. For the time being I'm
    just using lockingMode="all". I'll try your suggestions when I get
    a chance.

    Paul


    On Mon, Jun 4, 2012 at 3:34 PM, Martin Grotzke
    <martin.grotzke@googlemail.com
    wrote:

    Hi Paul,
    On 06/04/2012 08:26 PM, Paul Bellora wrote:
    I had picked lockingMode="auto" because it seemed like the smartest
    option. The documentation says: "readonly requests are
    detected, for
    them the session is not locked. For requests that are not
    classified
    as 'readonly' the session is locked". I'm wondering how this behavior
    works exactly - can you please explain how read-only requests are
    detected and kept track of and/or point me to the relevant source
    code?
    1a) When a session is looked up in memcached the session is
    locked (see
    MemcachedSessionService.loadFromMemcached,
    LockingStrategyAuto.onBeforeLoadFromMemcached) - unless the
    request is
    already known to be readonly.
    1b) When the session could not be found the lock is released

    2) When the request is finished (and the session was loaded),
    the lock
    is released and the requestURI is registered as readonly if the
    session
    was not modified or as modifying otherwise (see
    LockingStrategyAuto.onAfterBackupSession).

    I see two possible issues in the code:
    - When the lock is released this is done asynchronously (see e.g.
    LockingStrategy.releaseLock: memcached.delete returns a Future
    that's
    not get()'ed)
    - Another issue might be caused by parallel requests in the same
    tomcat,
    where the first locks the session and the second waits for the lock.
    Right now it seems to me as if this case is not yet properly handled
    (see MemcachedSessionService.findSession/loadFromMemcached).

    I've also noticed the following warning, though I haven't confirmed
    that it's related to this issue:

    "WARNING: Reached timeout when trying to aquire lock for
    session [ID].
    Will use this session without this lock."

    What does "Will use this session without this lock" mean here - does
    that mean the request is effectively read-only and any writes will be
    ignored?
    No, it does mean: we use the session and also write changes
    through to
    memcached.
    Yes, this could be somehow configurable so that users can choose how
    such a case should be handled. Any opinions?

    That seems like it should be a last resort, so would you say
    I have a latency issue with writing to memcached? What setting
    controls the timeout in question here? I assumed it was
    operationTimeout but as you can see that's currently set to a generous
    1000 millis.
    Yes, it's operationTimeout. Connection to memcached might be one
    issue,
    another reason might be some other/parallel request (running in
    another
    tomcat) holding the lock for such a long time.

    If I can't use lockingMode="auto" it seems like I'd need to use
    uriPattern to match specific requests that need to be locked. That
    would be annoying to maintain though.
    Right, and I'd be happy if we could improve lockingMode="auto".

    Please let me know if you need any more information.
    To start you should activate debug logging and see if this
    provides some
    insights (and/or share logs here):
    http://code.google.com/p/memcached-session-manager/wiki/SetupAndConfiguration#Configure_logging


    Another approach would be to create an integration test that
    shows the
    issue (NonStickySessionsIntegrationTest already has some) and
    use this
    for debugging.

    Cheers,
    Martin

    --
    inoio gmbh - http://inoio.de
    Breitenfelder Str. 13c, 20251 Hamburg
    Amtsgericht Hamburg, HRB 123031
    Geschäftsführer: Dennis Brakhane, Martin Grotzke, Ole Langbehn
  • Martin Grotzke at Jun 9, 2012 at 9:43 pm

    On 06/08/2012 11:05 PM, Martin Grotzke wrote:
    On 06/08/2012 11:02 PM, Martin Grotzke wrote:
    On 06/08/2012 08:17 PM, Paul Bellora wrote:

    Is it possible that your manager is holding off on writing the new
    session until the second request?
    No.
    At least not by intention ;-)

    It seems there were issues with non-sticky sessions and container
    managed auth, which might be the reason for what you experience.

    Can you test the attached jars? They contain several changes to request
    tracking and non-sticky session handling.

    Cheers,
    Martin


    Cheers,
    Martin

    I can understand why this optimization
    might have been made for sticky sessions, but I think it would be a bug
    for non-sticky.

    Please let me know if you need more information. Unfortunately I haven't
    been able to get logging working on my dev environment - I can bang on
    that more if it's necessary.

    Thanks,
    Paul

    On Tue, Jun 5, 2012 at 5:42 PM, Paul Bellora <pbellora@whosay.com
    wrote:

    Hi Martin,

    Thanks for the quick and detailed reply! Unfortunately I haven't
    had time to examine the issue any further. For the time being I'm
    just using lockingMode="all". I'll try your suggestions when I get
    a chance.

    Paul


    On Mon, Jun 4, 2012 at 3:34 PM, Martin Grotzke
    <martin.grotzke@googlemail.com
    wrote:

    Hi Paul,
    On 06/04/2012 08:26 PM, Paul Bellora wrote:
    I had picked lockingMode="auto" because it seemed like the smartest
    option. The documentation says: "readonly requests are
    detected, for
    them the session is not locked. For requests that are not
    classified
    as 'readonly' the session is locked". I'm wondering how this behavior
    works exactly - can you please explain how read-only requests are
    detected and kept track of and/or point me to the relevant source
    code?
    1a) When a session is looked up in memcached the session is
    locked (see
    MemcachedSessionService.loadFromMemcached,
    LockingStrategyAuto.onBeforeLoadFromMemcached) - unless the
    request is
    already known to be readonly.
    1b) When the session could not be found the lock is released

    2) When the request is finished (and the session was loaded),
    the lock
    is released and the requestURI is registered as readonly if the
    session
    was not modified or as modifying otherwise (see
    LockingStrategyAuto.onAfterBackupSession).

    I see two possible issues in the code:
    - When the lock is released this is done asynchronously (see e.g.
    LockingStrategy.releaseLock: memcached.delete returns a Future
    that's
    not get()'ed)
    - Another issue might be caused by parallel requests in the same
    tomcat,
    where the first locks the session and the second waits for the lock.
    Right now it seems to me as if this case is not yet properly handled
    (see MemcachedSessionService.findSession/loadFromMemcached).

    I've also noticed the following warning, though I haven't confirmed
    that it's related to this issue:

    "WARNING: Reached timeout when trying to aquire lock for
    session [ID].
    Will use this session without this lock."

    What does "Will use this session without this lock" mean here - does
    that mean the request is effectively read-only and any writes will be
    ignored?
    No, it does mean: we use the session and also write changes
    through to
    memcached.
    Yes, this could be somehow configurable so that users can choose how
    such a case should be handled. Any opinions?

    That seems like it should be a last resort, so would you say
    I have a latency issue with writing to memcached? What setting
    controls the timeout in question here? I assumed it was
    operationTimeout but as you can see that's currently set to a generous
    1000 millis.
    Yes, it's operationTimeout. Connection to memcached might be one
    issue,
    another reason might be some other/parallel request (running in
    another
    tomcat) holding the lock for such a long time.

    If I can't use lockingMode="auto" it seems like I'd need to use
    uriPattern to match specific requests that need to be locked. That
    would be annoying to maintain though.
    Right, and I'd be happy if we could improve lockingMode="auto".

    Please let me know if you need any more information.
    To start you should activate debug logging and see if this
    provides some
    insights (and/or share logs here):
    http://code.google.com/p/memcached-session-manager/wiki/SetupAndConfiguration#Configure_logging


    Another approach would be to create an integration test that
    shows the
    issue (NonStickySessionsIntegrationTest already has some) and
    use this
    for debugging.

    Cheers,
    Martin

    --
    inoio gmbh - http://inoio.de
    Breitenfelder Str. 13c, 20251 Hamburg
    Amtsgericht Hamburg, HRB 123031
    Geschäftsführer: Dennis Brakhane, Martin Grotzke, Ole Langbehn
  • Andy O'Neill at Jun 13, 2012 at 8:52 pm
    Are these changes checked in? I'm experiencing the same issue and it looks
    like this helps a lot.

    We use Spring Security. POSTing the log-in form to Spring Security takes
    1200ms to return with the current master branch of m-s-m and we see
    'WARNING: Reached timeout when trying to aquire lock for session
    A39AC1F68288EAE83C6D655E1486FA47-n1. Will use this session without this
    lock.'

    With the jars in this thread I don't see that timeout and the POST returns
    in < 300ms (this is on a test server, so that's acceptable performance).

    I don't see this issue on a server running 1.6.1 m-s-m.
    On Saturday, June 9, 2012 5:43:22 PM UTC-4, Martin Grotzke wrote:
    On 06/08/2012 11:05 PM, Martin Grotzke wrote:
    On 06/08/2012 11:02 PM, Martin Grotzke wrote:
    On 06/08/2012 08:17 PM, Paul Bellora wrote:

    Is it possible that your manager is holding off on writing the new
    session until the second request?
    No.
    At least not by intention ;-)

    It seems there were issues with non-sticky sessions and container
    managed auth, which might be the reason for what you experience.

    Can you test the attached jars? They contain several changes to request
    tracking and non-sticky session handling.

    Cheers,
    Martin


    Cheers,
    Martin

    I can understand why this optimization
    might have been made for sticky sessions, but I think it would be a
    bug
    for non-sticky.

    Please let me know if you need more information. Unfortunately I
    haven't
    been able to get logging working on my dev environment - I can bang on
    that more if it's necessary.

    Thanks,
    Paul

    On Tue, Jun 5, 2012 at 5:42 PM, Paul Bellora <pbellora@whosay.com
    wrote:

    Hi Martin,

    Thanks for the quick and detailed reply! Unfortunately I haven't
    had time to examine the issue any further. For the time being I'm
    just using lockingMode="all". I'll try your suggestions when I
    get
    a chance.

    Paul


    On Mon, Jun 4, 2012 at 3:34 PM, Martin Grotzke
    <martin.grotzke@googlemail.com
    wrote:

    Hi Paul,
    On 06/04/2012 08:26 PM, Paul Bellora wrote:
    I had picked lockingMode="auto" because it seemed like the smartest
    option. The documentation says: "readonly requests are
    detected, for
    them the session is not locked. For requests that are not
    classified
    as 'readonly' the session is locked". I'm wondering how this behavior
    works exactly - can you please explain how read-only
    requests are
    detected and kept track of and/or point me to the relevant
    source
    code?
    1a) When a session is looked up in memcached the session is
    locked (see
    MemcachedSessionService.loadFromMemcached,
    LockingStrategyAuto.onBeforeLoadFromMemcached) - unless the
    request is
    already known to be readonly.
    1b) When the session could not be found the lock is released

    2) When the request is finished (and the session was loaded),
    the lock
    is released and the requestURI is registered as readonly if
    the
    session
    was not modified or as modifying otherwise (see
    LockingStrategyAuto.onAfterBackupSession).

    I see two possible issues in the code:
    - When the lock is released this is done asynchronously (see
    e.g.
    LockingStrategy.releaseLock: memcached.delete returns a Future
    that's
    not get()'ed)
    - Another issue might be caused by parallel requests in the
    same
    tomcat,
    where the first locks the session and the second waits for the
    lock.
    Right now it seems to me as if this case is not yet properly
    handled
    (see MemcachedSessionService.findSession/loadFromMemcached).

    I've also noticed the following warning, though I haven't confirmed
    that it's related to this issue:

    "WARNING: Reached timeout when trying to aquire lock for
    session [ID].
    Will use this session without this lock."

    What does "Will use this session without this lock" mean
    here
    - does
    that mean the request is effectively read-only and any
    writes
    will be
    ignored?
    No, it does mean: we use the session and also write changes
    through to
    memcached.
    Yes, this could be somehow configurable so that users can
    choose how
    such a case should be handled. Any opinions?

    That seems like it should be a last resort, so would you say
    I have a latency issue with writing to memcached? What
    setting
    controls the timeout in question here? I assumed it was
    operationTimeout but as you can see that's currently set to
    a
    generous
    1000 millis.
    Yes, it's operationTimeout. Connection to memcached might be
    one
    issue,
    another reason might be some other/parallel request (running
    in
    another
    tomcat) holding the lock for such a long time.

    If I can't use lockingMode="auto" it seems like I'd need to
    use
    uriPattern to match specific requests that need to be
    locked. That
    would be annoying to maintain though.
    Right, and I'd be happy if we could improve
    lockingMode="auto".
    Please let me know if you need any more information.
    To start you should activate debug logging and see if this
    provides some
    insights (and/or share logs here):
    http://code.google.com/p/memcached-session-manager/wiki/SetupAndConfiguration#Configure_logging

    Another approach would be to create an integration test that
    shows the
    issue (NonStickySessionsIntegrationTest already has some) and
    use this
    for debugging.

    Cheers,
    Martin

    --
    inoio gmbh - http://inoio.de
    Breitenfelder Str. 13c, 20251 Hamburg
    Amtsgericht Hamburg, HRB 123031
    Geschäftsführer: Dennis Brakhane, Martin Grotzke, Ole Langbehn
  • Martin Grotzke at Jun 13, 2012 at 9:03 pm

    On 06/13/2012 10:48 PM, Andy O'Neill wrote:
    Are these changes checked in? I'm experiencing the same issue and it
    looks like this helps a lot.
    They're in master since the last weekend.
    We use Spring Security. POSTing the log-in form to Spring Security takes
    1200ms to return with the current master branch of m-s-m and we see
    'WARNING: Reached timeout when trying to aquire lock for session
    A39AC1F68288EAE83C6D655E1486FA47-n1. Will use this session without this
    lock.'

    With the jars in this thread I don't see that timeout and the POST
    returns in < 300ms (this is on a test server, so that's acceptable
    performance).
    The jars in the thread should contain the same functionality as current
    master.
    I don't see this issue on a server running 1.6.1 m-s-m.
    Can you activate debug logging and see if this provides some insights
    (and/or share logs here):
    http://code.google.com/p/memcached-session-manager/wiki/SetupAndConfiguration#Configure_logging

    It would also be good to run memcached with -vv to see when keys (and
    locks) are set/deleted.

    Cheers,
    Martin
    On Saturday, June 9, 2012 5:43:22 PM UTC-4, Martin Grotzke wrote:
    On 06/08/2012 11:05 PM, Martin Grotzke wrote:
    On 06/08/2012 11:02 PM, Martin Grotzke wrote:
    On 06/08/2012 08:17 PM, Paul Bellora wrote:

    Is it possible that your manager is holding off on writing the new
    session until the second request?
    No.
    At least not by intention ;-)

    It seems there were issues with non-sticky sessions and container
    managed auth, which might be the reason for what you experience.

    Can you test the attached jars? They contain several changes to request
    tracking and non-sticky session handling.

    Cheers,
    Martin


    Cheers,
    Martin

    I can understand why this optimization
    might have been made for sticky sessions, but I think it would
    be a bug
    for non-sticky.

    Please let me know if you need more information. Unfortunately I
    haven't
    been able to get logging working on my dev environment - I can
    bang on
    that more if it's necessary.

    Thanks,
    Paul

    On Tue, Jun 5, 2012 at 5:42 PM, Paul Bellora
    <pbellora@whosay.com >>> wrote:
    Hi Martin,

    Thanks for the quick and detailed reply! Unfortunately I
    haven't
    had time to examine the issue any further. For the time
    being I'm
    just using lockingMode="all". I'll try your suggestions
    when I get
    a chance.

    Paul


    On Mon, Jun 4, 2012 at 3:34 PM, Martin Grotzke
    <martin.grotzke@googlemail.com
    wrote:

    Hi Paul,
    On 06/04/2012 08:26 PM, Paul Bellora wrote:
    I had picked lockingMode="auto" because it seemed like
    the
    smartest
    option. The documentation says: "readonly requests are
    detected, for
    them the session is not locked. For requests that are not
    classified
    as 'readonly' the session is locked". I'm wondering
    how this
    behavior
    works exactly - can you please explain how read-only
    requests are
    detected and kept track of and/or point me to the
    relevant source
    code?
    1a) When a session is looked up in memcached the session is
    locked (see
    MemcachedSessionService.loadFromMemcached,
    LockingStrategyAuto.onBeforeLoadFromMemcached) - unless the
    request is
    already known to be readonly.
    1b) When the session could not be found the lock is
    released
    2) When the request is finished (and the session was
    loaded),
    the lock
    is released and the requestURI is registered as readonly
    if the
    session
    was not modified or as modifying otherwise (see
    LockingStrategyAuto.onAfterBackupSession).

    I see two possible issues in the code:
    - When the lock is released this is done asynchronously
    (see e.g.
    LockingStrategy.releaseLock: memcached.delete returns a
    Future
    that's
    not get()'ed)
    - Another issue might be caused by parallel requests in
    the same
    tomcat,
    where the first locks the session and the second waits
    for the lock.
    Right now it seems to me as if this case is not yet
    properly handled
    (see
    MemcachedSessionService.findSession/loadFromMemcached).
    I've also noticed the following warning, though I haven't confirmed
    that it's related to this issue:

    "WARNING: Reached timeout when trying to aquire lock for
    session [ID].
    Will use this session without this lock."

    What does "Will use this session without this lock"
    mean here
    - does
    that mean the request is effectively read-only and any
    writes
    will be
    ignored?
    No, it does mean: we use the session and also write changes
    through to
    memcached.
    Yes, this could be somehow configurable so that users
    can choose how
    such a case should be handled. Any opinions?

    That seems like it should be a last resort, so would
    you say
    I have a latency issue with writing to memcached? What
    setting
    controls the timeout in question here? I assumed it was
    operationTimeout but as you can see that's currently
    set to a
    generous
    1000 millis.
    Yes, it's operationTimeout. Connection to memcached
    might be one
    issue,
    another reason might be some other/parallel request
    (running in
    another
    tomcat) holding the lock for such a long time.

    If I can't use lockingMode="auto" it seems like I'd
    need to use
    uriPattern to match specific requests that need to be
    locked. That
    would be annoying to maintain though.
    Right, and I'd be happy if we could improve
    lockingMode="auto".
    Please let me know if you need any more information.
    To start you should activate debug logging and see if this
    provides some
    insights (and/or share logs here):
    http://code.google.com/p/memcached-session-manager/wiki/SetupAndConfiguration#Configure_logging
    <http://code.google.com/p/memcached-session-manager/wiki/SetupAndConfiguration#Configure_logging>

    Another approach would be to create an integration test
    that
    shows the
    issue (NonStickySessionsIntegrationTest already has
    some) and
    use this
    for debugging.

    Cheers,
    Martin

    --
    inoio gmbh - http://inoio.de
    Breitenfelder Str. 13c, 20251 Hamburg
    Amtsgericht Hamburg, HRB 123031
    Geschäftsführer: Dennis Brakhane, Martin Grotzke, Ole Langbehn
    --
    inoio gmbh - http://inoio.de
    Breitenfelder Str. 13c, 20251 Hamburg
    Amtsgericht Hamburg, HRB 123031
    Geschäftsführer: Dennis Brakhane, Martin Grotzke, Ole Langbehn
  • Andy O'Neill at Jun 14, 2012 at 7:29 pm
    I have come to understand this delay in the context of what I thought was a
    completely separate problem (session fixation prevention).

    In this issue I explain a patch required to make the sessionId change on
    login, without which Spring Security's SessionFixationStrategy causes a
    logout after login
    http://code.google.com/p/memcached-session-manager/issues/detail?id=143

    When I do have that patch applied, m-s-m has this locking timeout during
    login (but does work eventually)
    (log here https://gist.github.com/2932371)

    I can leave that patch applied, but if I change my app to allow the
    sessionId to remain the same before and after login, the timeout does not
    occur and logins are fast.

    My current solution is to enable the session-fixation-prevention for very
    secure apps, and disable it for speed on less sensitive apps. Is anyone
    else using session-fixation-prevention with m-s-m? What does your stack
    look like?


    On Wednesday, June 13, 2012 5:03:03 PM UTC-4, Martin Grotzke wrote:
    On 06/13/2012 10:48 PM, Andy O'Neill wrote:
    Are these changes checked in? I'm experiencing the same issue and it
    looks like this helps a lot.
    They're in master since the last weekend.
    We use Spring Security. POSTing the log-in form to Spring Security takes
    1200ms to return with the current master branch of m-s-m and we see
    'WARNING: Reached timeout when trying to aquire lock for session
    A39AC1F68288EAE83C6D655E1486FA47-n1. Will use this session without this
    lock.'

    With the jars in this thread I don't see that timeout and the POST
    returns in < 300ms (this is on a test server, so that's acceptable
    performance).
    The jars in the thread should contain the same functionality as current
    master.
    I don't see this issue on a server running 1.6.1 m-s-m.
    Can you activate debug logging and see if this provides some insights
    (and/or share logs here):

    http://code.google.com/p/memcached-session-manager/wiki/SetupAndConfiguration#Configure_logging

    It would also be good to run memcached with -vv to see when keys (and
    locks) are set/deleted.

    Cheers,
    Martin
    On Saturday, June 9, 2012 5:43:22 PM UTC-4, Martin Grotzke wrote:
    On 06/08/2012 11:05 PM, Martin Grotzke wrote:
    On 06/08/2012 11:02 PM, Martin Grotzke wrote:
    On 06/08/2012 08:17 PM, Paul Bellora wrote:

    Is it possible that your manager is holding off on writing the
    new
    session until the second request?
    No.
    At least not by intention ;-)

    It seems there were issues with non-sticky sessions and container
    managed auth, which might be the reason for what you experience.

    Can you test the attached jars? They contain several changes to request
    tracking and non-sticky session handling.

    Cheers,
    Martin


    Cheers,
    Martin

    I can understand why this optimization
    might have been made for sticky sessions, but I think it would
    be a bug
    for non-sticky.

    Please let me know if you need more information. Unfortunately I
    haven't
    been able to get logging working on my dev environment - I can
    bang on
    that more if it's necessary.

    Thanks,
    Paul

    On Tue, Jun 5, 2012 at 5:42 PM, Paul Bellora
    <pbellora@whosay.com > >>> wrote:
    Hi Martin,

    Thanks for the quick and detailed reply! Unfortunately I
    haven't
    had time to examine the issue any further. For the time
    being I'm
    just using lockingMode="all". I'll try your suggestions
    when I get
    a chance.

    Paul


    On Mon, Jun 4, 2012 at 3:34 PM, Martin Grotzke
    <martin.grotzke@googlemail.com
    wrote:
    Hi Paul,
    On 06/04/2012 08:26 PM, Paul Bellora wrote:
    I had picked lockingMode="auto" because it seemed like
    the
    smartest
    option. The documentation says: "readonly requests
    are
    detected, for
    them the session is not locked. For requests that are
    not
    classified
    as 'readonly' the session is locked". I'm wondering
    how this
    behavior
    works exactly - can you please explain how read-only
    requests are
    detected and kept track of and/or point me to the
    relevant source
    code?
    1a) When a session is looked up in memcached the session
    is
    locked (see
    MemcachedSessionService.loadFromMemcached,
    LockingStrategyAuto.onBeforeLoadFromMemcached) - unless
    the
    request is
    already known to be readonly.
    1b) When the session could not be found the lock is
    released
    2) When the request is finished (and the session was
    loaded),
    the lock
    is released and the requestURI is registered as readonly
    if the
    session
    was not modified or as modifying otherwise (see
    LockingStrategyAuto.onAfterBackupSession).

    I see two possible issues in the code:
    - When the lock is released this is done asynchronously
    (see e.g.
    LockingStrategy.releaseLock: memcached.delete returns a
    Future
    that's
    not get()'ed)
    - Another issue might be caused by parallel requests in
    the same
    tomcat,
    where the first locks the session and the second waits
    for the lock.
    Right now it seems to me as if this case is not yet
    properly handled
    (see
    MemcachedSessionService.findSession/loadFromMemcached).
    I've also noticed the following warning, though I
    haven't
    confirmed
    that it's related to this issue:

    "WARNING: Reached timeout when trying to aquire lock
    for
    session [ID].
    Will use this session without this lock."

    What does "Will use this session without this lock"
    mean here
    - does
    that mean the request is effectively read-only and any
    writes
    will be
    ignored?
    No, it does mean: we use the session and also write
    changes
    through to
    memcached.
    Yes, this could be somehow configurable so that users
    can choose how
    such a case should be handled. Any opinions?

    That seems like it should be a last resort, so would
    you say
    I have a latency issue with writing to memcached? What
    setting
    controls the timeout in question here? I assumed it
    was
    operationTimeout but as you can see that's currently
    set to a
    generous
    1000 millis.
    Yes, it's operationTimeout. Connection to memcached
    might be one
    issue,
    another reason might be some other/parallel request
    (running in
    another
    tomcat) holding the lock for such a long time.

    If I can't use lockingMode="auto" it seems like I'd
    need to use
    uriPattern to match specific requests that need to be
    locked. That
    would be annoying to maintain though.
    Right, and I'd be happy if we could improve
    lockingMode="auto".
    Please let me know if you need any more information.
    To start you should activate debug logging and see if
    this
    provides some
    insights (and/or share logs here):
    http://code.google.com/p/memcached-session-manager/wiki/SetupAndConfiguration#Configure_logging
    <
    http://code.google.com/p/memcached-session-manager/wiki/SetupAndConfiguration#Configure_logging>

    Another approach would be to create an integration test
    that
    shows the
    issue (NonStickySessionsIntegrationTest already has
    some) and
    use this
    for debugging.

    Cheers,
    Martin

    --
    inoio gmbh - http://inoio.de
    Breitenfelder Str. 13c, 20251 Hamburg
    Amtsgericht Hamburg, HRB 123031
    Geschäftsführer: Dennis Brakhane, Martin Grotzke, Ole Langbehn
    --
    inoio gmbh - http://inoio.de
    Breitenfelder Str. 13c, 20251 Hamburg
    Amtsgericht Hamburg, HRB 123031
    Geschäftsführer: Dennis Brakhane, Martin Grotzke, Ole Langbehn
  • Martin Grotzke at Jun 14, 2012 at 8:29 pm
    Hi Andy,

    I've only just seen your email here, please check
    http://code.google.com/p/memcached-session-manager/issues/detail?id=143
    for my comments.

    Cheers,
    Martin

    On 06/14/2012 09:29 PM, Andy O'Neill wrote:
    I have come to understand this delay in the context of what I thought
    was a completely separate problem (session fixation prevention).

    In this issue I explain a patch required to make the sessionId change on
    login, without which Spring Security's SessionFixationStrategy causes a
    logout after login
    http://code.google.com/p/memcached-session-manager/issues/detail?id=143

    When I do have that patch applied, m-s-m has this locking timeout during
    login (but does work eventually)
    (log here https://gist.github.com/2932371)

    I can leave that patch applied, but if I change my app to allow the
    sessionId to remain the same before and after login, the timeout does
    not occur and logins are fast.

    My current solution is to enable the session-fixation-prevention for
    very secure apps, and disable it for speed on less sensitive apps. Is
    anyone else using session-fixation-prevention with m-s-m? What does your
    stack look like?



    On Wednesday, June 13, 2012 5:03:03 PM UTC-4, Martin Grotzke wrote:
    On 06/13/2012 10:48 PM, Andy O'Neill wrote:
    Are these changes checked in? I'm experiencing the same issue and it
    looks like this helps a lot.
    They're in master since the last weekend.
    We use Spring Security. POSTing the log-in form to Spring Security takes
    1200ms to return with the current master branch of m-s-m and we see
    'WARNING: Reached timeout when trying to aquire lock for session
    A39AC1F68288EAE83C6D655E1486FA47-n1. Will use this session without this
    lock.'

    With the jars in this thread I don't see that timeout and the POST
    returns in < 300ms (this is on a test server, so that's acceptable
    performance).
    The jars in the thread should contain the same functionality as current
    master.
    I don't see this issue on a server running 1.6.1 m-s-m.
    Can you activate debug logging and see if this provides some insights
    (and/or share logs here):
    http://code.google.com/p/memcached-session-manager/wiki/SetupAndConfiguration#Configure_logging
    <http://code.google.com/p/memcached-session-manager/wiki/SetupAndConfiguration#Configure_logging>


    It would also be good to run memcached with -vv to see when keys (and
    locks) are set/deleted.

    Cheers,
    Martin
    On Saturday, June 9, 2012 5:43:22 PM UTC-4, Martin Grotzke wrote:
    On 06/08/2012 11:05 PM, Martin Grotzke wrote:
    On 06/08/2012 11:02 PM, Martin Grotzke wrote:
    On 06/08/2012 08:17 PM, Paul Bellora wrote:

    Is it possible that your manager is holding off on writing
    the new
    session until the second request?
    No.
    At least not by intention ;-)

    It seems there were issues with non-sticky sessions and container
    managed auth, which might be the reason for what you experience.

    Can you test the attached jars? They contain several changes
    to request
    tracking and non-sticky session handling.

    Cheers,
    Martin


    Cheers,
    Martin

    I can understand why this optimization
    might have been made for sticky sessions, but I think it
    would
    be a bug
    for non-sticky.

    Please let me know if you need more information.
    Unfortunately I
    haven't
    been able to get logging working on my dev environment - I
    can
    bang on
    that more if it's necessary.

    Thanks,
    Paul

    On Tue, Jun 5, 2012 at 5:42 PM, Paul Bellora
    <pbellora@whosay.com <mailto:pbellora@whosay.com > >>> <mailto:pbellora@whosay.com wrote:
    Hi Martin,

    Thanks for the quick and detailed reply! Unfortunately I
    haven't
    had time to examine the issue any further. For the time
    being I'm
    just using lockingMode="all". I'll try your suggestions
    when I get
    a chance.

    Paul


    On Mon, Jun 4, 2012 at 3:34 PM, Martin Grotzke
    <martin.grotzke@googlemail.com
    wrote:
    Hi Paul,
    On 06/04/2012 08:26 PM, Paul Bellora wrote:
    I had picked lockingMode="auto" because it
    seemed like
    the
    smartest
    option. The documentation says: "readonly
    requests are
    detected, for
    them the session is not locked. For requests
    that are not
    classified
    as 'readonly' the session is locked". I'm wondering
    how this
    behavior
    works exactly - can you please explain how
    read-only
    requests are
    detected and kept track of and/or point me to the
    relevant source
    code?
    1a) When a session is looked up in memcached the
    session is
    locked (see
    MemcachedSessionService.loadFromMemcached,
    LockingStrategyAuto.onBeforeLoadFromMemcached) -
    unless the
    request is
    already known to be readonly.
    1b) When the session could not be found the lock is
    released
    2) When the request is finished (and the session was
    loaded),
    the lock
    is released and the requestURI is registered as
    readonly
    if the
    session
    was not modified or as modifying otherwise (see
    LockingStrategyAuto.onAfterBackupSession).

    I see two possible issues in the code:
    - When the lock is released this is done
    asynchronously
    (see e.g.
    LockingStrategy.releaseLock: memcached.delete
    returns a
    Future
    that's
    not get()'ed)
    - Another issue might be caused by parallel
    requests in
    the same
    tomcat,
    where the first locks the session and the second
    waits
    for the lock.
    Right now it seems to me as if this case is not yet
    properly handled
    (see
    MemcachedSessionService.findSession/loadFromMemcached).
    I've also noticed the following warning, though
    I haven't
    confirmed
    that it's related to this issue:

    "WARNING: Reached timeout when trying to aquire
    lock for
    session [ID].
    Will use this session without this lock."

    What does "Will use this session without this lock"
    mean here
    - does
    that mean the request is effectively read-only
    and any
    writes
    will be
    ignored?
    No, it does mean: we use the session and also
    write changes
    through to
    memcached.
    Yes, this could be somehow configurable so that users
    can choose how
    such a case should be handled. Any opinions?

    That seems like it should be a last resort, so
    would
    you say
    I have a latency issue with writing to
    memcached? What
    setting
    controls the timeout in question here? I assumed
    it was
    operationTimeout but as you can see that's
    currently
    set to a
    generous
    1000 millis.
    Yes, it's operationTimeout. Connection to memcached
    might be one
    issue,
    another reason might be some other/parallel request
    (running in
    another
    tomcat) holding the lock for such a long time.

    If I can't use lockingMode="auto" it seems like I'd
    need to use
    uriPattern to match specific requests that need
    to be
    locked. That
    would be annoying to maintain though.
    Right, and I'd be happy if we could improve
    lockingMode="auto".
    Please let me know if you need any more
    information.
    To start you should activate debug logging and see
    if this
    provides some
    insights (and/or share logs here):
    http://code.google.com/p/memcached-session-manager/wiki/SetupAndConfiguration#Configure_logging
    <http://code.google.com/p/memcached-session-manager/wiki/SetupAndConfiguration#Configure_logging>
    <http://code.google.com/p/memcached-session-manager/wiki/SetupAndConfiguration#Configure_logging
    <http://code.google.com/p/memcached-session-manager/wiki/SetupAndConfiguration#Configure_logging>>

    Another approach would be to create an integration
    test
    that
    shows the
    issue (NonStickySessionsIntegrationTest already has
    some) and
    use this
    for debugging.

    Cheers,
    Martin

    --
    inoio gmbh - http://inoio.de
    Breitenfelder Str. 13c, 20251 Hamburg
    Amtsgericht Hamburg, HRB 123031
    Geschäftsführer: Dennis Brakhane, Martin Grotzke, Ole Langbehn
    --
    inoio gmbh - http://inoio.de
    Breitenfelder Str. 13c, 20251 Hamburg
    Amtsgericht Hamburg, HRB 123031
    Geschäftsführer: Dennis Brakhane, Martin Grotzke, Ole Langbehn
    --
    inoio gmbh - http://inoio.de
    Breitenfelder Str. 13c, 20251 Hamburg
    Amtsgericht Hamburg, HRB 123031
    Geschäftsführer: Dennis Brakhane, Martin Grotzke, Ole Langbehn

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupmemcached-session-manager @
categoriesmemcached
postedJun 4, '12 at 6:26p
activeJun 14, '12 at 8:29p
posts11
users3
websitememcached.org

People

Translate

site design / logo © 2022 Grokbase