Chaho12 opened a new pull request, #7760:
URL: https://github.com/apache/kyuubi/pull/7760

   <!--
   Thanks for sending a pull request!
   
   Here are some tips for you:
     1. If this is your first time, please read our contributor guidelines: 
https://kyuubi.readthedocs.io/en/master/contributing/code/index.html
     2. If the PR is related to an issue in 
https://github.com/apache/kyuubi/issues, add '[KYUUBI #XXXX]' in your PR title, 
e.g., '[KYUUBI #XXXX] Your PR title ...'.
     3. If the PR is unfinished, add '[WIP]' in your PR title, e.g., 
'[WIP][KYUUBI #XXXX] Your PR title ...'.
   -->
   
   ### Why are the changes needed?
   <!--
   Please clarify why the changes are needed. For instance,
     1. If you propose a new feature, clarify the use cases.
     2. If you fix a bug, you can clarify why it is a bug, and what versions 
are affected.
   -->
   
   `KyuubiSessionManager.openSession` takes a count from the session limiter 
before the session is
   opened, and `closeSession` is the only place that gives one back.
   
   `SessionManager.openSession` calls `createSession` outside the `try` whose 
`catch` calls
   `closeSession`, and `AbstractSession.normalizedConf` is a `val`, so a 
session whose conf fails
   validation dies in the constructor and is never registered in 
`handleToSession`. `closeSession`
   never runs for it, and the count is kept for good.
   
   Once as many opens have failed as `kyuubi.server.limit.connections.per.user` 
allows, every further
   open from that user is rejected by the limiter although the user holds no 
session, until the
   server restarts. `kyuubi.server.limit.connections.per.ipaddress` leaks the 
same way.
   
   Ordinary client configuration reaches this on a server that follows the 
documented
   `kyuubi.session.conf.restrict.list` guidance: `spark.sql.extensions` is in 
the example restrict
   list in the [session configuration 
docs](https://kyuubi.readthedocs.io/en/master/security/session_configuration.html),
   and a client that keeps sending it locks its own account out. We hit this in 
production - three
   server nodes each rejected 20 opens for the restricted key, after which 
every open from that user
   failed with the connection-limit message while `kyuubi_connection_opened` 
stayed 0, and a rolling
   restart was the only way to recover.
   
   Affects master and 1.11.1. Batch sessions are not affected: 
`openBatchSession` takes its count
   after the session is built and inside the `try` that closes it.
   
   close #7759 
   
   
   ### How was this patch tested?
   <!--
   If tests were added, say they were added here. Please make sure to add some 
test cases that check the changes thoroughly including negative and positive 
cases if possible.
   If it was tested in a way different from regular unit tests, please clarify 
how you tested step by step, ideally copy and paste-able, so that other 
reviewers can test and check, and descendants can verify in the future.
   If tests were not added, please describe why they were not added and/or why 
it was difficult to add.
   -->
   
   Added `KyuubiSessionManagerLimiterSuite`, which sets 
`kyuubi.server.limit.connections.per.user=2`
   and a restrict list, then opens `limit + 2` sessions carrying the restricted 
key and asserts every
   attempt is still rejected by the restrict list rather than by the limiter.
   
       build/mvn test -pl kyuubi-server -am -Dtest=none \
           
-DwildcardSuites=org.apache.kyuubi.session.KyuubiSessionManagerLimiterSuite
   
   Negative check: with the change reverted, the suite fails on the third 
attempt with
   `"Connection limit per user reached (user: user limit: 2)" did not contain
   "spark.sql.extensions is a restrict key"`, which is the production symptom.
   
   ### Was this patch assisted by generative AI tooling?
   <!--
   If generative AI tooling has assisted in authoring or reviewing this patch, 
please include
   an 'Assisted-by: ' trailer that identifies the agent and/or model.
   For example: 'Assisted-by: Claude Opus 4.7' or 'Assisted-by: 
Claude:claude-opus-4-7'.
   If no, write 'No'.
   Please refer to the [ASF Generative Tooling 
Guidance](https://www.apache.org/legal/generative-tooling.html) for details.
   -->
   
   Assisted-by: Claude Opus 5


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to