dapeng From you comment at https://github.com/mariadb-corporation/MaxScale/pull/160

our proposal is:

divide session id into two part,

 |31 - 24| 23 - 0|

|-------|------|

|nodeid | session id|

set this session id back to server

so if worker thread has a session id pool, another bits will be consumed

I don't fully understand the proposal. What would nodeid denote?

the scenario is deploy multi mxs nodes behind a load balancer, client use single vip,
there are big chance of encountering session id conflicts;

so we can add a prefix to session id, nodeid is proxy node (mxs)'s id, with it , we can divide session id into different space,there will be no confilcts;

but there still have another problem, `kill connection` may issued from different connection which may different from the node of to be killed connection, so there is no mapping data for that to be killed connection;
So we need a way to set the sessionid generated by mxs back to server, then we not need do mapping anymore;

maybe we can divid it into three part

8 bits nodeid: max 255 nodes per cluster;

10 bits threads: max 1024 threads per node

14 bit sessionid :max 16384 per thread;

Ok, so nodeid would then have to be provided via some configuration item in the MaxScale configuration file?

10 bits for the threadid might be a bit excessive as it makes no sense to use more worker threads than there are real cores in the computer. Perhaps 8 bits would be enough.

With the MaxScale worker thread id in the connection id, it is easy to move the handling of kill connection to the right thread.

If the nodeid is different, then it doesn't work.

Sorry , my english is not so well, let me explain with this diagram:

by this way we can make session id global unique, so we don't need translate client session id to backend session id;

Currently in our internal version mysql, we have implicated a way to set "thread id" to server, maybe mariadb can do the same thing

Even if MaxScale were to reuse ids to ensure that the thread id cannot be overflow, that's not that useful unless the server does the same. So indeed, if MaxScale were able to specify the thread id to be used, it would be good.

Changing to a new feature as this is expected behavior.

An interesting approach to this would be for MaxScale to inject some connection attributes to the outbound connections that could be used to identify which session in MaxScale the connection relates to. This could also include the hostname from which the connection is created.