On Fri, Sep 4, 2020 at 10:42 AM Alexandre Rafalovitch <arafa...@gmail.com> wrote:
> I feel that maybe we don't treat it special mentally, but then it > actually is. At least with minimum custom locations configured. > > Consider: > 1) What is in "server", above "server/solr" > * resources/log4j2.xml (because of magic jetty classpath mechanism) > * logs > * NOT server/solr/configsets (but probably should be to avoid > confusion with recursive core searching algorithm or just people > trying to understand what those directories are) > Correct; configsets is in solr.home > 2) What is in "example/schemaless" > * logs (because of hardcoded magic in bin/solr) > * NOT log4j2.xml, because we simplified it but also lost an ability to > customize 3) What is in "example/cloud/node1" > * logs (same magic) > > From other discussions, if you try to reproduce examples outside of > the example directory, they will log to the global log directory and > mess with each other, unless you pass on an individual log directory > location for each bin/solr command. > I am wondering if the example above solr.home should be the place we > try to check for: > 1) logging configuration (or override that latest log4 seems to support) > 2) logs > 3) configsets available to that node 4) maybe solr.in.sh > Starting more than one Solr node on a machine is rather unusual, but it shows up in certain examples, and on a local dev machine, but I don't think "the real world" (prod). I think it would help a bit if logs were under solr.home. It's rare to touch logging config, but it'd be interesting to allow a log4j2.xml in solr.home to take precedence. configsets dir is already in solr.home. Again, it'd be interesting for a solr.in.sh in solr.home to take precedence if it is defined. All this would help make a solr.home a complete place for a Solr node if you want to isolate it from other nodes -- be it for "example"/tutorial reasons, or for keeping multiple side-projects together. In addition to all this, I really wish the default cores dir was not solr.home itself but one directory beneath. > This would certainly make example setups easy and less magical. > Yes; that'd be nice. > I don't know if this is the right answer. I specifically don't know if > this will mess up cloud setups. SolrCloud isn't special with regards to this discussion (I think). > But I see a pattern that is > unacknowledged and think that maybe acknowledging would allow us to > have a more general solution that magic in bin/solr. And maybe just in > time for the Solr in Docker final decisions. > Yeah; I hope you like my suggestions above. > Regards, > Alex. > P.s. To make it more interesting, I am also confused about pid files > going into bin directory. I bet docker image puts them somewhere else. > > On Fri, 4 Sep 2020 at 01:04, David Smiley <dsmi...@apache.org> wrote: > > > > The parent directory of Solr home is not special. Where Solr Home is > (as you know) configurable. It's default location is different too, since > it's in /var/solr for both the Docker & service install script. > > > > ~ David Smiley > > Apache Lucene/Solr Search Developer > > http://www.linkedin.com/in/davidwsmiley > > > > > > On Tue, Aug 25, 2020 at 8:31 PM Alexandre Rafalovitch < > arafa...@gmail.com> wrote: > >> > >> Hello, > >> > >> What do we call the directory above the solr.home? > >> E.g. > >> - "schemaless" in example/schemaless/solr/gettingstarted > >> - "node1" in example/cloud/node1/solr/gettingstarted_shard1_replica_n2 > >> - "solr" in server/solr/book/conf > >> > >> In solr.in.cmd we "may be" calling it "solr start dir" > >> In bin/solr, we call it SOLR_SERVER_DIR > >> In install_solr-service.sh, we sort-of call it SOLR_VAR_DIR "Directory > >> for live/writable Solr files", which is not quite the same because > >> apparently pid files go there, while for distribution they seem to go > >> into bin > >> > >> I guess it mostly matters when you have multiple Solr instances > >> running on the same machine and you need to separate log locations, > >> etc. > >> > >> Regards, > >> Alex. > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > >> For additional commands, e-mail: dev-h...@lucene.apache.org > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
