Session expire on graphd will end up floating session being released

[wey-gu]

This is an issue talked about in WeChat Group:Earth, synced msg was pasted in the end of the issue.

It seems in current idle-release session mechanism was monitored and triggered in each graphD, that is, when a session(session-id:foo) was floated from graphd0 to graphd1, and will be actively used in graphd1 and not caming back to graphd0, after idle session timer expires in graphd0, foo will be released from graphd0.

I am on GitHub mobile(don't have access to the code to verify this)due to Covid leave, so just quickly track the issue here.

Plz forgive my unchecking of the code before raising this.

cc @Aiee

ref:

• https://github.com/vesoft-inc/nebula-community/discussions/152#discussioncomment-4473597
• https://github.com/vesoft-inc/nebula-community/discussions/152#discussioncomment-4473690
• https://github.com/vesoft-inc/nebula-community/discussions/152#discussioncomment-4474626

[HarrisChu]

steps:

1. create a session in graphA.
2. the session connection is broke, then create the connection with graphB.
3. graphB find the session in meta, and it exists, so could query with this session.
4. but session in graphA local would never be updated, and then would be expired by graphA.
5. after delete the session, use cannot use this session in graphB. (as session has been delete in metad)

more info

1. create in graph2 (port 10010)

2. connect with graph1 (port 10005)

3. session is delete by graph2

[HarrisChu]

we can simply compare the latest graphAddr in meta, if not in the same, could not delete the session.

not sure if there's any other problem.

[Aiee]

This is a rare case and it won't be fixed in 3.4. cc @xtcyclist

[xtcyclist]

we can simply compare the latest graphAddr in meta, if not in the same, could not delete the session.

not sure if there's any other problem.

Need to make sure the timeout mechanism still works, if we do this.

[xtcyclist]

Session is not advised to be kept for a long time. And, it is always recommended to check the aliveness of sessions and recreate sessions if needed. Since this is a low-priority issue and we are freezing the code for 3.4, close this issue for now.

If any developer wants to optimize this part, please feel free to reopen this issue.

[wey-gu]

we can simply compare the latest graphAddr in meta, if not in the same, could not delete the session.

not sure if there's any other problem.

I think this is the way to go, I'll fix this in this approach later when I have some bandwidth in my free time

[wey-gu]

@HarrisChu @xtcyclist @Sophie-Xie will this be tagged wont fix intended or we could save it from "won't fix" actually :-P?

[Sophie-Xie]

Session is not advised to be kept for a long time. And, it is always recommended to check the aliveness of sessions and recreate sessions if needed. Since this is a low-priority issue and we are freezing the code for 3.4, close this issue for now.

If any developer wants to optimize this part, please feel free to reopen this issue.

Just a label, I'll change it to avoid confusion.

[wey-gu]

@xtcyclist @yixinglu do we consider to fix this?

[xtcyclist]

We need to consider fixing this issue due to potential requirements from customers.