[SERVER-39646] endSessions does not end syntactically valid session ids and does not report this as a failure Created: 18/Feb/19  Updated: 04/Mar/19  Resolved: 04/Mar/19

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: 4.1.6
Fix Version/s: None

Type: Bug Priority: Minor - P4
Reporter: Oleg Pudeyev (Inactive) Assignee: Blake Oler
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to DOCS-12522 Reference killAllSessions from endSes... Closed
Operating System: ALL
Sprint: Sharding 2019-03-11
Participants:

 Description   

I am attempting to end outstanding sessions, using https://docs.mongodb.com/manual/reference/operator/aggregation/listLocalSessions/ and https://docs.mongodb.com/v3.6/reference/command/endSessions/. To this end I have the following code:

    sessions = client.database.command(
      aggregate: 1,
      pipeline: [{'$listLocalSessions' => {}}],
      cursor: {}
    ).first['cursor']['firstBatch']
    # https://docs.mongodb.com/v3.6/reference/command/endSessions/
    session_ids = sessions.map do |session|
      session['_id']
    end
    session_ids.each do |session_id|
      rv = client.database.command(endSessions: [session_id])
    end

The result of endSessions is as follows:

(byebug) p rv.first
{"ok"=>1.0, "$clusterTime"=>{"clusterTime"=>#<BSON::Timestamp:0x00005619179b1708 @seconds=1550452237, @increment=1>, "signature"=>{"hash"=><BSON::Binary:0x47332885105140 type=generic data=0x0000000000000000...>, "keyId"=>0}}, "operationTime"=>#<BSON::Timestamp:0x00005619179b12d0 @seconds=1550452237, @increment=1>}

There's an

{ok:1}

in there, OK. Now if I kill the same session again I still get the same result:

(byebug) rv = client.database.command(endSessions: [session_id])
#<Mongo::Operation::Result:0x47332885140160 documents=[{"ok"=>1.0, "$clusterTime"=>{"clusterTime"=>#<BSON::Timestamp:0x00005619179b1708 @seconds=1550452237, @increment=1>, "signature"=>{"hash"=><BSON::Binary:0x47332885105140 type=generic data=0x0000000000000000...>, "keyId"=>0}}, "operationTime"=>#<BSON::Timestamp:0x00005619179b12d0 @seconds=1550452237, @increment=1>}]>
(byebug) p rv.first
{"ok"=>1.0, "$clusterTime"=>{"clusterTime"=>#<BSON::Timestamp:0x00005619179b1708 @seconds=1550452237, @increment=1>, "signature"=>{"hash"=><BSON::Binary:0x47332885105140 type=generic data=0x0000000000000000...>, "keyId"=>0}}, "operationTime"=>#<BSON::Timestamp:0x00005619179b12d0 @seconds=1550452237, @increment=1>}

If I execute listlocalsessions after running the code to end the sessions, I still get the same number of sessions outstanding. At this point I cannot tell if I am passing the session ids wrong or the server chooses to ignore my session ending requests.

https://docs.mongodb.com/v3.6/reference/command/endSessions/ says:

> MongoDB concatenates each of the specified UUIDs with the hash of the authenticated user credentials to identify the user's sessions to end. If the user has no session that match, the endSessions has no effect.

How do I figure out if this applies? I am querying the sessions with the same client and credentials and database as the ones I am using for endSessions. If I need to query them in a different manner how do I do that?

To summarize:

1. endSessions should report when it is unable to end one or more of the passed sessions, and ideally with a reason why.
2. Ending nonexistent (or already ended) sessions should be indicated in some fashion, OR there should be a way to tell whether a session is ended when querying it.



 Comments   
Comment by Oleg Pudeyev (Inactive) [ 04/Mar/19 ]

OK I see, it looks like https://docs.mongodb.com/manual/reference/command/killAllSessionsByPattern/#dbcmd.killAllSessionsByPattern takes lsids and will terminate sessions upon request.

Comment by Blake Oler [ 04/Mar/19 ]

endSessions is not aptly named. It should rather be called queueSessionsForReaping – what endSessions actually does is queue a session to be reaped by the Logical Session Cache refresh thread. This thread runs by default once every five minutes (but you can change that setting with the logicalSessionRefreshMillis parameter here). That means that during the time before the reaper thread has run, the session will still be accessible. Keep in mind that the session is still in an undefined state, and that you should consider it closed even though it is still visible.

If you would like to immediately flush the session, you can run run the admin command refreshLogicalSessionCacheNow, which will manually trigger the refresh thread. Keep in mind that doing this will flush all sessions that are expired or have been marked to end with endSessions.

You can read further on the contract for endSessions as defined in the Logical Sessions design document.

Additionally, once a session is gone, it will cease to exist completely. The server has no notion of when a session has ended; it only has a notion of when the session exists, then when it no longer exists (read: has been reaped).

oleg.pudeyev if this resolves your question, we should close this ticket as Won't Fix. Let me know if you have any other questions.

Generated at Thu Feb 08 04:52:40 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.