On Fri, 2020-02-14 at 15:41 -0500, Carlos Munoz wrote: > Robert I managed to replicate the issue in a local, non-containerized > environment (!!!). > > The problem seems to be when the database is kept but the 'sling' > directory > is cleared out across restarts (as it is for us when the container > goes > away). As I said before this doesn't seem to be a problem with the > Sling 11 > bundles. > > The first basic solution will be to persist the 'sling' directory > across > restarts, and I was wondering if this is a bug, or as designed.
I think this should work. > > I also wonder if once persisted, multiple containers could share this > directory. This directory can't be shared, as it holds runtime data related to Sling. For instance, a bundle that is started in instance A could be starting on instance B. There is at least one file ( sling.id ) that holds data that must not be the same between instances. So I would advise as marking the directory as container-private as a first step. Robert > > Regards, > > Carlos > > > On Fri, Feb 14, 2020 at 3:17 PM Carlos Munoz <camu...@redhat.com> > wrote: > > > Thanks Robert (and once again I can't stress enough how grateful I > > am for > > all your help). > > > > Right now we deploy our container with the expectation that the > > mongo db > > is the only necessary state we need to keep; everything else is > > throwaway. > > This means that a totally new container connected to the mongodb > > should > > pick up the state and run the same as the first time it was fired > > up. Do > > you think this is an incorrect assumption? If so, what are other > > pieces of > > state we should be keeping for subsequent restarts? > > > > This assumption has worked well for us with the current sling 11 > > release, > > but it seems to break with the more up-to-date bundles. Perhaps > > running > > Sling in a container is just not meant to be. > > > > Regards, > > > > Carlos > > > > > > On Fri, Feb 14, 2020 at 2:21 PM Robert Munteanu <romb...@apache.org > > > > > wrote: > > > > > Hi Carlos, > > > > > > On Fri, 2020-02-14 at 11:50 -0500, Carlos Munoz wrote: > > > > Thanks Bertrand. How can I run Sling with DEBUG-level logs for > > > > every > > > > bundle? I tried passing a few configuration arguments from the > > > > command line > > > > but nothing seemed to work. > > > > > > Try configuring the LogManager to debug at > > > > > > > > > https://github.com/apache/sling-org-apache-sling-starter/blob/8ba34e28fbea2feb4c61767dde510aa94d86fa0a/src/main/provisioning/sling.txt#L138 > > > > > > Thanks, > > > Robert > > > > > > > Carlos > > > > > > > > On Fri, Feb 14, 2020 at 4:32 AM Bertrand Delacretaz < > > > > bdelacre...@apache.org> > > > > wrote: > > > > > > > > > Hi, > > > > > > > > > > On Thu, Feb 13, 2020 at 8:47 PM Carlos Munoz < > > > > > camu...@redhat.com> > > > > > wrote: > > > > > > ...Is there a reason why the Jcr repository could be > > > > > > restarting? > > > > > > And what > > > > > > class could we start looking into to debug if this is the > > > > > > case?... > > > > > > > > > > It's not uncommon to see extra restarts of OSGi components at > > > > > startup, > > > > > for various reasons. > > > > > > > > > > The simplest way to detect and log multiple repository > > > > > startups > > > > > might > > > > > be to implement a SlingRepositoryInitializer service [1] > > > > > that's > > > > > called > > > > > at every startup, or use the logs of an existing one like the > > > > > JCR > > > > > RepositoryInitializer [2] if that has anything to process in > > > > > your > > > > > system. > > > > > > > > > > -Bertrand > > > > > > > > > > [1] > > > > > > > > https://sling.apache.org/documentation/bundles/repository-initialization.html#slingrepositoryinitializer > > > > > [2] > > > > > > > > https://github.com/apache/sling-org-apache-sling-jcr-repoinit/blob/41dfe606f99ca71baee8d9054d3ec6e9b896b12e/src/main/java/org/apache/sling/jcr/repoinit/impl/RepositoryInitializer.java#L98 > > > > >
