On Wed, Feb 26, 2020 at 10:21:48PM +0200, Alan Orth wrote: > After having exported a slice of my 2019 statistics from production I've > just done two experiments in my development environment: manually create a > `statistics-2019` core and load the 2019 hits into it, and load data into > the main `statistics` core and initiate the `dspace stats-util -s` yearly > sharding process. In both cases the core's data is online and available > immediately after it is loaded. In the first case the manually created core > does not get loaded the next time I restart Tomcat, while in the second > case the DSpace-created core does.
Clearly you and DSpace are doing something different, but I don't know what it could be. > Regarding DSpace doing something "hacky" in using multiple data-only cores > that share an instanceDir, I'm also wondering how that fits into the > official use cases of Solr! I want to add some debug logging to > SolrLoggerServiceImpl.java (DSpace 6.x) to try to understand why my > manually-created core doesn't get loaded. Possibly related, about half the > time we start Tomcat on our production server one of the cores fails to > load anyways! To be honest it's making me a bit nervous about running with > all these shards (we have ten, back to 2010!) and I am debating whether I > should just put everything back in the main statistics core. I think you need more information from the Solr service itself, to debug core startup issues. Stock Solr logs quite a bit at startup by default, and can log a lot more. Finer-grained settings in config/log4j-solr.properties may help, without overwhelming you with normal-operation chit-chat. I would set log4j.rootLogger up to WARN or ERROR, log4j.logger.org.apache.solr.client to ERROR, and log4j.logger.org.apache.solr to INFO or even DEBUG, and see what you get at startup. You could even send org.apache.solr.client off to a separate file via a separate appender (and setting its 'additivity' to false), to completely separate client and server logging. I have no more-precise suggestions here. > How does the migration process to a more modern Solr with DSpace 7 > look with our "hacky" sharding? I haven't tried it yet, because we don't do sharding here so I have no experience with how it *ought to* look. There are no changes to DSpace's sharding code, so I would expect it to act much the same as in previous versions. -- Mark H. Wood Lead Technology Analyst University Library Indiana University - Purdue University Indianapolis 755 W. Michigan Street Indianapolis, IN 46202 317-274-0749 www.ulib.iupui.edu -- All messages to this mailing list should adhere to the DuraSpace Code of Conduct: https://duraspace.org/about/policies/code-of-conduct/ --- You received this message because you are subscribed to the Google Groups "DSpace Technical Support" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/dspace-tech/20200228151217.GC4591%40IUPUI.Edu.
signature.asc
Description: PGP signature
