On 16/09/18 21:20, Christopher Schultz wrote: > 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.
We can probably add something to do that too (if it isn't already there - I need to check which methods are exposed). >> 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). Ack. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
