This is my MSM config:
<Manager

className="de.javakaffee.web.msm.MemcachedBackupSessionManager"
memcachedNodes="n1:172.16.0.7:11211"
sticky="false"
lockingMode="auto"
requestUriIgnorePattern=".*\.(png|gif|jpg|css|js|ico)$"
sessionBackupAsync="false"
sessionBackupTimeout="100"
transcoderFactoryClass=
"de.javakaffee.web.msm.serializer.kryo.KryoTranscoderFactory"/>

I got a lot of "LockingStrategyAuto- Found no validity info for
session id " WARN, but my website seems OK.

Is the Found no validity WARN info is something wrong, or I could just
ignore it ?

Thanks

Search Discussions

  • Huang kun at Dec 21, 2011 at 6:26 am
    My website keep running for months and a lot of users visit my website
    every second.

    I switched the session backuped in the memcached. After I restarted
    tomcat, the uses visited before lost all their cookies, so their
    session key can not be found in memcached.

    Is it the reason why "Found no validity info for session id" WARNed?

    That's what I think, is that right?
    On 12月21日, 下午2时10分, huang kun wrote:
    This is my MSM config:
    <Manager

    className="de.javakaffee.web.msm.MemcachedBackupSessionManager"
    memcachedNodes="n1:172.16.0.7:11211"
    sticky="false"
    lockingMode="auto"
    requestUriIgnorePattern=".*\.(png|gif|jpg|css|js|ico)$"
    sessionBackupAsync="false"
    sessionBackupTimeout="100"
    transcoderFactoryClass=
    "de.javakaffee.web.msm.serializer.kryo.KryoTranscoderFactory"/>

    I got a lot of "LockingStrategyAuto- Found no validity info for
    session id " WARN, but my website seems OK.

    Is the Found no validity WARN info is something wrong, or I could just
    ignore it ?

    Thanks
  • Martin Grotzke at Dec 21, 2011 at 10:39 am

    On 12/21/2011 07:26 AM, huang kun wrote:
    My website keep running for months and a lot of users visit my
    website every second.

    I switched the session backuped in the memcached.
    What exactly do you mean with this?
    After I restarted
    tomcat, the uses visited before lost all their cookies, so their
    session key can not be found in memcached.
    In regular/proper usage of msm+memcached (especially your non-sticky
    case) users should not loose their sessions when you restart tomcats.
    Is it the reason why "Found no validity info for session id"
    WARNed?
    If they had lost their cookies then they'll got a new session id that
    should be used further on. Thus I don't think that the warning is caused
    by the lost cookies.

    Cheers,
    Martin

    That's what I think, is that right?
    On 12月21日, 下午2时10分, huang kun wrote:
    This is my MSM config: <Manager

    className="de.javakaffee.web.msm.MemcachedBackupSessionManager"
    memcachedNodes="n1:172.16.0.7:11211" sticky="false"
    lockingMode="auto"
    requestUriIgnorePattern=".*\.(png|gif|jpg|css|js|ico)$"
    sessionBackupAsync="false" sessionBackupTimeout="100"
    transcoderFactoryClass=
    "de.javakaffee.web.msm.serializer.kryo.KryoTranscoderFactory"/>

    I got a lot of "LockingStrategyAuto- Found no validity info for
    session id " WARN, but my website seems OK.

    Is the Found no validity WARN info is something wrong, or I could
    just ignore it ?

    Thanks
    --
    Dennis Brakhane, Martin Grotzke und Ole Langbehn GbR
    Breitenfelder Str. 13c, 20251 Hamburg
  • Martin Grotzke at Dec 21, 2011 at 10:33 am
    Hi,
    On 12/21/2011 07:10 AM, huang kun wrote:
    This is my MSM config:
    <Manager

    className="de.javakaffee.web.msm.MemcachedBackupSessionManager"
    memcachedNodes="n1:172.16.0.7:11211"
    sticky="false"
    lockingMode="auto"
    requestUriIgnorePattern=".*\.(png|gif|jpg|css|js|ico)$"
    sessionBackupAsync="false"
    sessionBackupTimeout="100"
    transcoderFactoryClass=
    "de.javakaffee.web.msm.serializer.kryo.KryoTranscoderFactory"/>

    I got a lot of "LockingStrategyAuto- Found no validity info for
    session id " WARN, but my website seems OK.

    Is the Found no validity WARN info is something wrong, or I could just
    ignore it ?
    To give you the context of the warning: for non-sticky sessions some
    metadata is stored separately from the session. The metadata includes
    e.g. the lastAccessedTime which is used to determine session
    validity/timeout. The metadata is updated in memcached always, even if
    the session itself has not been modified.

    The warning "Found no validity info for session..." is logged at the end
    of a request that didn't load the session (there was no
    request.getSession()), when the validity info for this session could not
    be found in memcached. One reason for this might be that the memcached
    does not have enough memory assigned and therefore had to evict cache
    entries. For this you should check your memcached config and memcached
    stats (evictions particularly).

    Do you have some knowledge about the sessions for that this was logged,
    e.g. if they had just been created, how long they did already exist
    etc.? Can you reproduce this issue?

    Cheers,
    Martin
  • Huang kun at Dec 21, 2011 at 3:49 pm
    I reproduced the issue on my testing enviroment:

    When user logout I call session.invalidate(), and the "Found no
    validity..." is logged. I removed the invalidate() ,and the "Found no
    validity..." disappeared in my testing enviroment.

    Then I removed session.invalidate() on the production enviroment, the
    "Found no validity..." is logged much less than before but still has
    some.
    On Dec 21, 6:33 pm, Martin Grotzke wrote:
    Hi,

    On 12/21/2011 07:10 AM, huang kun wrote:








    This is my MSM config:
    <Manager
    className="de.javakaffee.web.msm.MemcachedBackupSessionManager"
    memcachedNodes="n1:172.16.0.7:11211"
    sticky="false"
    lockingMode="auto"
    requestUriIgnorePattern=".*\.(png|gif|jpg|css|js|ico)$"
    sessionBackupAsync="false"
    sessionBackupTimeout="100"
    transcoderFactoryClass=
    "de.javakaffee.web.msm.serializer.kryo.KryoTranscoderFactory"/>
    I got a lot of "LockingStrategyAuto- Found no validity info for
    session id "  WARN, but my website seems OK.
    Is the Found no validity WARN info is something wrong, or I could just
    ignore it ?
    To give you the context of the warning: for non-sticky sessions some
    metadata is stored separately from the session. The metadata includes
    e.g. the lastAccessedTime which is used to determine session
    validity/timeout. The metadata is updated in memcached always, even if
    the session itself has not been modified.

    The warning "Found no validity info for session..." is logged at the end
    of a request that didn't load the session (there was no
    request.getSession()), when the validity info for this session could not
    be found in memcached. One reason for this might be that the memcached
    does not have enough memory assigned and therefore had to evict cache
    entries. For this you should check your memcached config and memcached
    stats (evictions particularly).

    Do you have some knowledge about the sessions for that this was logged,
    e.g. if they had just been created, how long they did already exist
    etc.? Can you reproduce this issue?

    Cheers,
    Martin

    signature.asc
    < 1KViewDownload
  • Martin Grotzke at Dec 21, 2011 at 4:44 pm
    Thanx, I submitted this as issue 116
    (http://code.google.com/p/memcached-session-manager/issues/detail?id=116).
    I think it's not a serious problem but should definitely be fixed.

    The question remains why it's being logged for other sessions (memcached
    stats/evictions?).

    And from a security perspective you should definitely reactivate
    session.invalidate(), but you are probably aware of this.

    Cheers,
    Martin

    On 12/21/2011 04:49 PM, huang kun wrote:
    I reproduced the issue on my testing enviroment:

    When user logout I call session.invalidate(), and the "Found no
    validity..." is logged. I removed the invalidate() ,and the "Found no
    validity..." disappeared in my testing enviroment.

    Then I removed session.invalidate() on the production enviroment, the
    "Found no validity..." is logged much less than before but still has
    some.
    On Dec 21, 6:33 pm, Martin Grotzke wrote:
    Hi,

    On 12/21/2011 07:10 AM, huang kun wrote:








    This is my MSM config:
    <Manager
    className="de.javakaffee.web.msm.MemcachedBackupSessionManager"
    memcachedNodes="n1:172.16.0.7:11211"
    sticky="false"
    lockingMode="auto"
    requestUriIgnorePattern=".*\.(png|gif|jpg|css|js|ico)$"
    sessionBackupAsync="false"
    sessionBackupTimeout="100"
    transcoderFactoryClass=
    "de.javakaffee.web.msm.serializer.kryo.KryoTranscoderFactory"/>
    I got a lot of "LockingStrategyAuto- Found no validity info for
    session id " WARN, but my website seems OK.
    Is the Found no validity WARN info is something wrong, or I could just
    ignore it ?
    To give you the context of the warning: for non-sticky sessions some
    metadata is stored separately from the session. The metadata includes
    e.g. the lastAccessedTime which is used to determine session
    validity/timeout. The metadata is updated in memcached always, even if
    the session itself has not been modified.

    The warning "Found no validity info for session..." is logged at the end
    of a request that didn't load the session (there was no
    request.getSession()), when the validity info for this session could not
    be found in memcached. One reason for this might be that the memcached
    does not have enough memory assigned and therefore had to evict cache
    entries. For this you should check your memcached config and memcached
    stats (evictions particularly).

    Do you have some knowledge about the sessions for that this was logged,
    e.g. if they had just been created, how long they did already exist
    etc.? Can you reproduce this issue?

    Cheers,
    Martin

    signature.asc
    < 1KViewDownload
    --
    Dennis Brakhane, Martin Grotzke und Ole Langbehn GbR
    Breitenfelder Str. 13c, 20251 Hamburg
  • Huang kun at Dec 21, 2011 at 5:15 pm
    Memcached stats:
    STAT limit_maxbytes 2147483648
    STAT bytes 51231754
    STAT curr_items 192410
    STAT total_items 450529
    STAT evictions 0

    Memcached start with -M, No evictions.

    Thanks for your quick reply.

    Martin Grotzke wrote:
    Thanx, I submitted this as issue 116
    (http://code.google.com/p/memcached-session-manager/issues/detail?id=116).
    I think it's not a serious problem but should definitely be fixed.

    The question remains why it's being logged for other sessions (memcached
    stats/evictions?).

    And from a security perspective you should definitely reactivate
    session.invalidate(), but you are probably aware of this.

    Cheers,
    Martin

    On 12/21/2011 04:49 PM, huang kun wrote:
    I reproduced the issue on my testing enviroment:

    When user logout I call session.invalidate(), and the "Found no
    validity..." is logged. I removed the invalidate() ,and the "Found no
    validity..." disappeared in my testing enviroment.

    Then I removed session.invalidate() on the production enviroment, the
    "Found no validity..." is logged much less than before but still has
    some.

    On Dec 21, 6:33 pm, Martin Grotzke <martin.grot...@googlemail.com>
    wrote:
    Hi,

    On 12/21/2011 07:10 AM, huang kun wrote:








    This is my MSM config:
    <Manager
    className="de.javakaffee.web.msm.MemcachedBackupSessionManager"
    memcachedNodes="n1:172.16.0.7:11211"
    sticky="false"
    lockingMode="auto"
    requestUriIgnorePattern=".*\.(png|gif|jpg|css|js|ico)$"
    sessionBackupAsync="false"
    sessionBackupTimeout="100"
    transcoderFactoryClass=
    "de.javakaffee.web.msm.serializer.kryo.KryoTranscoderFactory"/>
    I got a lot of "LockingStrategyAuto- Found no validity info for
    session id " WARN, but my website seems OK.
    Is the Found no validity WARN info is something wrong, or I could just
    ignore it ?
    To give you the context of the warning: for non-sticky sessions some
    metadata is stored separately from the session. The metadata includes
    e.g. the lastAccessedTime which is used to determine session
    validity/timeout. The metadata is updated in memcached always, even if
    the session itself has not been modified.

    The warning "Found no validity info for session..." is logged at the end
    of a request that didn't load the session (there was no
    request.getSession()), when the validity info for this session could not
    be found in memcached. One reason for this might be that the memcached
    does not have enough memory assigned and therefore had to evict cache
    entries. For this you should check your memcached config and memcached
    stats (evictions particularly).

    Do you have some knowledge about the sessions for that this was logged,
    e.g. if they had just been created, how long they did already exist
    etc.? Can you reproduce this issue?

    Cheers,
    Martin

    signature.asc
    < 1KViewDownload
    --
    Dennis Brakhane, Martin Grotzke und Ole Langbehn GbR
    Breitenfelder Str. 13c, 20251 Hamburg
  • Martin Grotzke at Dec 21, 2011 at 9:12 pm
    Ok, so evictions don't seem to cause the logging.
    Without session.invalidate(), do you know more about the sessions for
    that it's still logged?

    In the meantime I'm trying to reproduce the session.invalidate->logging
    issue btw.

    Cheers,
    Martin

    On 12/21/2011 06:15 PM, huang kun wrote:
    Memcached stats:
    STAT limit_maxbytes 2147483648
    STAT bytes 51231754
    STAT curr_items 192410
    STAT total_items 450529
    STAT evictions 0

    Memcached start with -M, No evictions.

    Thanks for your quick reply.

    Martin Grotzke wrote:
    Thanx, I submitted this as issue 116
    (http://code.google.com/p/memcached-session-manager/issues/detail?id=116).
    I think it's not a serious problem but should definitely be fixed.

    The question remains why it's being logged for other sessions (memcached
    stats/evictions?).

    And from a security perspective you should definitely reactivate
    session.invalidate(), but you are probably aware of this.

    Cheers,
    Martin

    On 12/21/2011 04:49 PM, huang kun wrote:
    I reproduced the issue on my testing enviroment:

    When user logout I call session.invalidate(), and the "Found no
    validity..." is logged. I removed the invalidate() ,and the "Found no
    validity..." disappeared in my testing enviroment.

    Then I removed session.invalidate() on the production enviroment, the
    "Found no validity..." is logged much less than before but still has
    some.

    On Dec 21, 6:33 pm, Martin Grotzke <martin.grot...@googlemail.com>
    wrote:
    Hi,

    On 12/21/2011 07:10 AM, huang kun wrote:








    This is my MSM config:
    <Manager
    className="de.javakaffee.web.msm.MemcachedBackupSessionManager"
    memcachedNodes="n1:172.16.0.7:11211"
    sticky="false"
    lockingMode="auto"
    requestUriIgnorePattern=".*\.(png|gif|jpg|css|js|ico)$"
    sessionBackupAsync="false"
    sessionBackupTimeout="100"
    transcoderFactoryClass=
    "de.javakaffee.web.msm.serializer.kryo.KryoTranscoderFactory"/>
    I got a lot of "LockingStrategyAuto- Found no validity info for
    session id " WARN, but my website seems OK.
    Is the Found no validity WARN info is something wrong, or I could just
    ignore it ?
    To give you the context of the warning: for non-sticky sessions some
    metadata is stored separately from the session. The metadata includes
    e.g. the lastAccessedTime which is used to determine session
    validity/timeout. The metadata is updated in memcached always, even if
    the session itself has not been modified.

    The warning "Found no validity info for session..." is logged at the end
    of a request that didn't load the session (there was no
    request.getSession()), when the validity info for this session could not
    be found in memcached. One reason for this might be that the memcached
    does not have enough memory assigned and therefore had to evict cache
    entries. For this you should check your memcached config and memcached
    stats (evictions particularly).

    Do you have some knowledge about the sessions for that this was logged,
    e.g. if they had just been created, how long they did already exist
    etc.? Can you reproduce this issue?

    Cheers,
    Martin

    signature.asc
    < 1KViewDownload
    --
    Dennis Brakhane, Martin Grotzke und Ole Langbehn GbR
    Breitenfelder Str. 13c, 20251 Hamburg
    --
    Dennis Brakhane, Martin Grotzke und Ole Langbehn GbR
    Breitenfelder Str. 13c, 20251 Hamburg
  • Martin Grotzke at Dec 21, 2011 at 11:48 pm
    Hi,

    I've fixed this issue, so you should be able to invalidate your sessions
    without any warnings logged.

    I've attached the jars, do you want to test this version?

    Cheers,
    Martin

    On 12/21/2011 10:12 PM, Martin Grotzke wrote:
    Ok, so evictions don't seem to cause the logging.
    Without session.invalidate(), do you know more about the sessions for
    that it's still logged?

    In the meantime I'm trying to reproduce the session.invalidate->logging
    issue btw.

    Cheers,
    Martin

    On 12/21/2011 06:15 PM, huang kun wrote:
    Memcached stats:
    STAT limit_maxbytes 2147483648
    STAT bytes 51231754
    STAT curr_items 192410
    STAT total_items 450529
    STAT evictions 0

    Memcached start with -M, No evictions.

    Thanks for your quick reply.

    Martin Grotzke wrote:
    Thanx, I submitted this as issue 116
    (http://code.google.com/p/memcached-session-manager/issues/detail?id=116).
    I think it's not a serious problem but should definitely be fixed.

    The question remains why it's being logged for other sessions (memcached
    stats/evictions?).

    And from a security perspective you should definitely reactivate
    session.invalidate(), but you are probably aware of this.

    Cheers,
    Martin

    On 12/21/2011 04:49 PM, huang kun wrote:
    I reproduced the issue on my testing enviroment:

    When user logout I call session.invalidate(), and the "Found no
    validity..." is logged. I removed the invalidate() ,and the "Found no
    validity..." disappeared in my testing enviroment.

    Then I removed session.invalidate() on the production enviroment, the
    "Found no validity..." is logged much less than before but still has
    some.

    On Dec 21, 6:33 pm, Martin Grotzke <martin.grot...@googlemail.com>
    wrote:
    Hi,

    On 12/21/2011 07:10 AM, huang kun wrote:








    This is my MSM config:
    <Manager
    className="de.javakaffee.web.msm.MemcachedBackupSessionManager"
    memcachedNodes="n1:172.16.0.7:11211"
    sticky="false"
    lockingMode="auto"
    requestUriIgnorePattern=".*\.(png|gif|jpg|css|js|ico)$"
    sessionBackupAsync="false"
    sessionBackupTimeout="100"
    transcoderFactoryClass=
    "de.javakaffee.web.msm.serializer.kryo.KryoTranscoderFactory"/>
    I got a lot of "LockingStrategyAuto- Found no validity info for
    session id " WARN, but my website seems OK.
    Is the Found no validity WARN info is something wrong, or I could just
    ignore it ?
    To give you the context of the warning: for non-sticky sessions some
    metadata is stored separately from the session. The metadata includes
    e.g. the lastAccessedTime which is used to determine session
    validity/timeout. The metadata is updated in memcached always, even if
    the session itself has not been modified.

    The warning "Found no validity info for session..." is logged at the end
    of a request that didn't load the session (there was no
    request.getSession()), when the validity info for this session could not
    be found in memcached. One reason for this might be that the memcached
    does not have enough memory assigned and therefore had to evict cache
    entries. For this you should check your memcached config and memcached
    stats (evictions particularly).

    Do you have some knowledge about the sessions for that this was logged,
    e.g. if they had just been created, how long they did already exist
    etc.? Can you reproduce this issue?

    Cheers,
    Martin

    signature.asc
    < 1KViewDownload
    --
    Dennis Brakhane, Martin Grotzke und Ole Langbehn GbR
    Breitenfelder Str. 13c, 20251 Hamburg
    --
    Dennis Brakhane, Martin Grotzke und Ole Langbehn GbR
    Breitenfelder Str. 13c, 20251 Hamburg

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupmemcached-session-manager @
categoriesmemcached
postedDec 21, '11 at 6:11a
activeDec 21, '11 at 11:48p
posts9
users2
websitememcached.org

2 users in discussion

Martin Grotzke: 5 posts Huang kun: 4 posts

People

Translate

site design / logo © 2022 Grokbase