sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carlos Munoz <camu...@redhat.com>
Subject Re: Error migrating to latest version of the bundles - Can neither derive user name nor principal names (was: Slow queries and unexpected results)
Date Fri, 14 Feb 2020 20:41:16 GMT
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 also wonder if once persisted, multiple containers could share this
directory.

Regards,

Carlos


On Fri, Feb 14, 2020 at 3:17 PM Carlos Munoz <camunoz@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 <rombert@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 <
>> > bdelacretaz@apache.org>
>> > wrote:
>> >
>> > > Hi,
>> > >
>> > > On Thu, Feb 13, 2020 at 8:47 PM Carlos Munoz <camunoz@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
>> > >
>> > >
>>
>>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message