-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Mark,
On 9/14/18 05:21, Mark Thomas wrote: > On 14/09/18 10:07, Rémy Maucherat wrote: >> On Fri, Sep 14, 2018 at 10:41 AM <ma...@apache.org> wrote: >> >>> Author: markt Date: Fri Sep 14 08:41:02 2018 New Revision: >>> 1840901 >>> >>> URL: http://svn.apache.org/viewvc?rev=1840901&view=rev Log: >>> Review thread-safety Document locking strategy Fix a few >>> issues: - Iterators could throw >>> ConcurrentModificationException - Syncs on open/save didn't >>> lock roles Map Update with a view to supporting runtime >>> reloading (BZ 58590) >>> >> >> This user db stuff was introduced in 4.1 and was never really >> updated since, nor were other implementations done. It survived >> because of the manager/jmx management it had. Do you think it >> would be useful to take it somewhere now, or is this only for >> 58590 ? > > My primary motivation is 58590. I've lost track of the number of > times I've started Tomcat do test something, only to have to > restart it to pickup changes to tomcat-users.xml. Of course, fixing > that means reloading has to be enabled by default. I think that is > OK but what does everyone else think? Having to bounce the app server to adjust the authentication database is really bad IMHO. Auto-reload isn't necessary, but the fact that a reload is POSSIBLE is nice. Triggering re-loading via JMX would be sufficient for me. > While I researched the fix for BZ 58590, I could see various > thread-safety issues that I thought were worth fixing as problems > are more likely if a background thread is reloading the user > database. > > There were other issues I didn't fix. Concurrent modification may > leave the db in an inconsistent state. E.g a user with a role that > has been deleted. It is also possible to add a role to a user that > is not in the database. > > I thought about a wider clean-up but it looking like a 'proper' > solution that addressed all the various edge cases was heading > towards implementing an in memory RDBMS and that seemed like > overkill for the use case. Even Derby/Javadb/whatever-the-name is also fairly heavy-handed. We don't need full ACID for what amounts to a HashMap. > I think there are some users who maintain the database via JMX so > I think it is worth keeping. But maybe they only do that because > the file can't be reloaded. It might be worth a discussion on the > users list. Persistence via JMX is problematic. Reloading the user database from the disk is preferable if you ask me. Just like being able to trigger a reload of the TLS key store(s) and trust store(s). - -chris -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlueuxkACgkQHPApP6U8 pFj38A//T/t1pjSEvznyzAKfY5rtPEwww7a6scMQgPSG+e9DuKDjqzJczAwtPCA1 dN7Ojbt9HkC8n8lpfc8YkVJpADvhze34aJxdg+Fty8aNSr3YIWQmyONjQN/R8eSx Src7NmNGN4Gh3tfIoIAxSNRpvcH+13fkdcWDbwWvVlzO6/QSEkjTtk9EMQ7MUQfd xlyNxrChuEYDCxG6RePqusEc3BuUJktcVl6KGcRcDaoBR/K+AdU2ui7S+3osgE5Y 7+Dziy6Hr8V/abAAB4ov7m6nORXLk+qKuzvaSOpqk8Vhg5yolVrpwTNPROLF5P1J Xk7jBqe6iYR/yvU4mG6Yd3fzcbZME7F7uVk4SBWDikoxk7ZycWyvdr4VzkKe01v+ k1GivUMgLeHMCUqDQlBV1DLlJBEJKtn/VKPa+OSmP0mIJjkC/TMqFrNVWc5Rqho7 0xOloi8MtHjiuXI/tK5UbS0cJf/x8amXJbHTyKSaGNWoSV2G1eMSmuQIhUcx3wHX XjtzQBrvsCsVG9bJe3tcBZMXoa57PIw1z48NkBRQXRAOAtrYGKdOMDchfapXvSUU ugH61FDCwy9k+ZH6KgLFEpsrGIxxJ2dF5qCEt3JbgQcfisnU8QWpTekZu/0/TlJB TgrqfVgApFc+RwQhP72pX4yUCsbuDFm//HoLvslEePv9S5scg70= =8mDs -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
