Buildbot success in on tomcat-9.0.x
Build status: Build succeeded! Worker used: bb_worker2_ubuntu URL: https://ci2.apache.org/#builders/37/builds/491 Blamelist: Mark Thomas , lihan Build Text: build successful Status Detected: restored build Build Source Stamp: [branch 9.0.x] 6918c28c776c7b7d2104b26b9768b46eeb4352a0 Steps: worker_preparation: 0 git: 0 shell: 0 shell_1: 0 shell_2: 0 shell_3: 0 shell_4: 0 shell_5: 0 compile: 1 shell_6: 0 shell_7: 0 shell_8: 0 shell_9: 0 Rsync docs to nightlies.apache.org: 0 shell_10: 0 Rsync RAT to nightlies.apache.org: 0 compile_1: 1 shell_11: 0 Rsync Logs to nightlies.apache.org: 0 -- ASF Buildbot - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[GitHub] [tomcat] ChristopherSchultz commented on pull request #596: Use SELECT...FOR UPDATE to update session data in the database instead of DELETE, INSERT.
ChristopherSchultz commented on PR #596: URL: https://github.com/apache/tomcat/pull/596#issuecomment-1463902816 The problem is that there is a window of opportunity between the existing `DELETE` and `INSERT` where the `session_id` column (which is `UNIQUE` or equivalent) can be `INSERT`ed by another thread. Changing the definition of the table to include a separate PK and removing the `UNIQUE` constraint from the `session_id` column is one way to solve this issue, but it would break any existing installation which is _not_ using that kind of table definition. I would definitely *not* want to do that for a point-release, and my goal here is to back-port this all the way back to 8.5 at this point. I think some larger changes could be made separately from this current effort, and restricted to maybe Tomcat 11.0.x and later. -- 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: dev-unsubscr...@tomcat.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 66524] New: resource cache eviction is MRU not LRU
https://bz.apache.org/bugzilla/show_bug.cgi?id=66524 Bug ID: 66524 Summary: resource cache eviction is MRU not LRU Product: Tomcat 9 Version: 9.0.73 Hardware: PC OS: Mac OS X 10.1 Status: NEW Severity: normal Priority: P2 Component: Catalina Assignee: dev@tomcat.apache.org Reporter: steven.kea...@servicenow.com Target Milestone: - Cache.java evicts items using "MRU except we wont evict items last accessed within 5s". The comments indicate that LRU was intended. The fix is simple, just remove the ".reverse()" from this line. https://github.com/apache/tomcat/blob/main/java/org/apache/catalina/webresources/Cache.java#L211 -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 65770] Make keys reload automatically
https://bz.apache.org/bugzilla/show_bug.cgi?id=65770 --- Comment #7 from Christoph Anton Mitterer --- I'd also say that any form of automatic reloading (e.g. via fnotify on respectively periodic reloading of the cert/key files) is a bad idea. It may e.g just happen at the time where only one of the two has already been replaced. Instead, I've asked in bug #66526 for a way to *only* reload key/certificate files - not any other configuration. Such a feature should be easily usable with e.g. certbot and friends. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
