Slow queries and unexpected results

classic Classic list List threaded Threaded
37 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Slow queries and unexpected results

Carlos Munoz
Hi,

My team is using Sling for an internal application and we've run into a
couple of unexpected scenarios:

1. When modifying the nodetypes.cnd file included with our bundle (e.g.
adding a new node type), the application queries seem to stop working. This
only happens when the queries use the following form: "select * from
[custom:type] ..." and not when using something like "select * from
[nt:base] where [jcr:primaryType] = 'custom:type'"

2. There is a specific query which runs very slowly only the first time it
is executed. Once it is executed that one time it runs considerably faster
on subsequent runs.

I was wondering if the Sling community would be able to shed some light on
some possible causes to these two scenarios.

Thanks in advance!
Reply | Threaded
Open this post in threaded view
|

Re: Slow queries and unexpected results

Robert Munteanu-2
Hi Carlos,

On Tue, 2020-01-21 at 22:31 -0500, Carlos Munoz wrote:

> Hi,
>
> My team is using Sling for an internal application and we've run into
> a
> couple of unexpected scenarios:
>
> 1. When modifying the nodetypes.cnd file included with our bundle
> (e.g.
> adding a new node type), the application queries seem to stop
> working. This
> only happens when the queries use the following form: "select * from
> [custom:type] ..." and not when using something like "select * from
> [nt:base] where [jcr:primaryType] = 'custom:type'"
>
> 2. There is a specific query which runs very slowly only the first
> time it
> is executed. Once it is executed that one time it runs considerably
> faster
> on subsequent runs.

These both look like Jackrabbit/Oak issues, so first let me ask you
which version of Jackrabbit/Jackrabbit Oak are you using?

Thanks,
Robert

>
> I was wondering if the Sling community would be able to shed some
> light on
> some possible causes to these two scenarios.
>
> Thanks in advance!

Reply | Threaded
Open this post in threaded view
|

Re: Slow queries and unexpected results

Carlos Munoz
Thanks for the reply Robert. We are using the latest Sling release (11) and
its corresponding bundle versions, so that would make it oak 1.8.8.

We could proably be using more updated bundles, but without a stable
release or tag we're not sure how to gauge whether a set of bundles is
stable enough.

Regards,

Carlos


On Wed, Jan 22, 2020 at 4:47 AM Robert Munteanu <[hidden email]> wrote:

> Hi Carlos,
>
> On Tue, 2020-01-21 at 22:31 -0500, Carlos Munoz wrote:
> > Hi,
> >
> > My team is using Sling for an internal application and we've run into
> > a
> > couple of unexpected scenarios:
> >
> > 1. When modifying the nodetypes.cnd file included with our bundle
> > (e.g.
> > adding a new node type), the application queries seem to stop
> > working. This
> > only happens when the queries use the following form: "select * from
> > [custom:type] ..." and not when using something like "select * from
> > [nt:base] where [jcr:primaryType] = 'custom:type'"
> >
> > 2. There is a specific query which runs very slowly only the first
> > time it
> > is executed. Once it is executed that one time it runs considerably
> > faster
> > on subsequent runs.
>
> These both look like Jackrabbit/Oak issues, so first let me ask you
> which version of Jackrabbit/Jackrabbit Oak are you using?
>
> Thanks,
> Robert
>
> >
> > I was wondering if the Sling community would be able to shed some
> > light on
> > some possible causes to these two scenarios.
> >
> > Thanks in advance!
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Slow queries and unexpected results

Robert Munteanu-2
Hi Carlos,

On Wed, 2020-01-22 at 07:11 -0500, Carlos Munoz wrote:
> Thanks for the reply Robert. We are using the latest Sling release
> (11) and
> its corresponding bundle versions, so that would make it oak 1.8.8.
>
> We could proably be using more updated bundles, but without a stable
> release or tag we're not sure how to gauge whether a set of bundles
> is
> stable enough.

Latest released bundles as found in the current sling starter [1]
should be stable. You could try and update to a later Oak, we have
validated that Oak 1.16.0 works fine, see commit [2] for details.

I would suggest the following:

1. Try and update to Oak 1.16.0, following commit [2] .
2. If that does not solve your problem, update to latest Oak (currently
1.22.0). If that does not work for you, let me know and we'll figure it
out.
3. If that still does not work, you probably should ask in the
Jackrabbit project.

How does that sound?

Thanks,
Robert


[1]: https://github.com/apache/sling-org-apache-sling-starter
[2]: https://github.com/apache/sling-org-apache-sling-starter/commit/c4f6e3b

>
> Regards,
>
> Carlos
>
>
> On Wed, Jan 22, 2020 at 4:47 AM Robert Munteanu <[hidden email]>
> wrote:
>
> > Hi Carlos,
> >
> > On Tue, 2020-01-21 at 22:31 -0500, Carlos Munoz wrote:
> > > Hi,
> > >
> > > My team is using Sling for an internal application and we've run
> > > into
> > > a
> > > couple of unexpected scenarios:
> > >
> > > 1. When modifying the nodetypes.cnd file included with our bundle
> > > (e.g.
> > > adding a new node type), the application queries seem to stop
> > > working. This
> > > only happens when the queries use the following form: "select *
> > > from
> > > [custom:type] ..." and not when using something like "select *
> > > from
> > > [nt:base] where [jcr:primaryType] = 'custom:type'"
> > >
> > > 2. There is a specific query which runs very slowly only the
> > > first
> > > time it
> > > is executed. Once it is executed that one time it runs
> > > considerably
> > > faster
> > > on subsequent runs.
> >
> > These both look like Jackrabbit/Oak issues, so first let me ask you
> > which version of Jackrabbit/Jackrabbit Oak are you using?
> >
> > Thanks,
> > Robert
> >
> > > I was wondering if the Sling community would be able to shed some
> > > light on
> > > some possible causes to these two scenarios.
> > >
> > > Thanks in advance!

Reply | Threaded
Open this post in threaded view
|

Re: Slow queries and unexpected results

Carlos Munoz
Thanks heaps Robert, sounds like way more than I was expecting :)

I'll try these things and let you know how it goes.



On Wed, Jan 22, 2020 at 9:31 AM Robert Munteanu <[hidden email]> wrote:

> Hi Carlos,
>
> On Wed, 2020-01-22 at 07:11 -0500, Carlos Munoz wrote:
> > Thanks for the reply Robert. We are using the latest Sling release
> > (11) and
> > its corresponding bundle versions, so that would make it oak 1.8.8.
> >
> > We could proably be using more updated bundles, but without a stable
> > release or tag we're not sure how to gauge whether a set of bundles
> > is
> > stable enough.
>
> Latest released bundles as found in the current sling starter [1]
> should be stable. You could try and update to a later Oak, we have
> validated that Oak 1.16.0 works fine, see commit [2] for details.
>
> I would suggest the following:
>
> 1. Try and update to Oak 1.16.0, following commit [2] .
> 2. If that does not solve your problem, update to latest Oak (currently
> 1.22.0). If that does not work for you, let me know and we'll figure it
> out.
> 3. If that still does not work, you probably should ask in the
> Jackrabbit project.
>
> How does that sound?
>
> Thanks,
> Robert
>
>
> [1]: https://github.com/apache/sling-org-apache-sling-starter
> [2]:
> https://github.com/apache/sling-org-apache-sling-starter/commit/c4f6e3b
> >
> > Regards,
> >
> > Carlos
> >
> >
> > On Wed, Jan 22, 2020 at 4:47 AM Robert Munteanu <[hidden email]>
> > wrote:
> >
> > > Hi Carlos,
> > >
> > > On Tue, 2020-01-21 at 22:31 -0500, Carlos Munoz wrote:
> > > > Hi,
> > > >
> > > > My team is using Sling for an internal application and we've run
> > > > into
> > > > a
> > > > couple of unexpected scenarios:
> > > >
> > > > 1. When modifying the nodetypes.cnd file included with our bundle
> > > > (e.g.
> > > > adding a new node type), the application queries seem to stop
> > > > working. This
> > > > only happens when the queries use the following form: "select *
> > > > from
> > > > [custom:type] ..." and not when using something like "select *
> > > > from
> > > > [nt:base] where [jcr:primaryType] = 'custom:type'"
> > > >
> > > > 2. There is a specific query which runs very slowly only the
> > > > first
> > > > time it
> > > > is executed. Once it is executed that one time it runs
> > > > considerably
> > > > faster
> > > > on subsequent runs.
> > >
> > > These both look like Jackrabbit/Oak issues, so first let me ask you
> > > which version of Jackrabbit/Jackrabbit Oak are you using?
> > >
> > > Thanks,
> > > Robert
> > >
> > > > I was wondering if the Sling community would be able to shed some
> > > > light on
> > > > some possible causes to these two scenarios.
> > > >
> > > > Thanks in advance!
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Slow queries and unexpected results

klcodanr
You can also try using the explain keyword to get introspection into how
the JCR repository is planning to execute the query which may identify any
traversal or index issues:
https://jackrabbit.apache.org/oak/docs/query/grammar-sql2.html#explain


On Wed, Jan 22, 2020 at 12:06 PM Carlos Munoz <[hidden email]> wrote:

> Thanks heaps Robert, sounds like way more than I was expecting :)
>
> I'll try these things and let you know how it goes.
>
>
>
> On Wed, Jan 22, 2020 at 9:31 AM Robert Munteanu <[hidden email]>
> wrote:
>
> > Hi Carlos,
> >
> > On Wed, 2020-01-22 at 07:11 -0500, Carlos Munoz wrote:
> > > Thanks for the reply Robert. We are using the latest Sling release
> > > (11) and
> > > its corresponding bundle versions, so that would make it oak 1.8.8.
> > >
> > > We could proably be using more updated bundles, but without a stable
> > > release or tag we're not sure how to gauge whether a set of bundles
> > > is
> > > stable enough.
> >
> > Latest released bundles as found in the current sling starter [1]
> > should be stable. You could try and update to a later Oak, we have
> > validated that Oak 1.16.0 works fine, see commit [2] for details.
> >
> > I would suggest the following:
> >
> > 1. Try and update to Oak 1.16.0, following commit [2] .
> > 2. If that does not solve your problem, update to latest Oak (currently
> > 1.22.0). If that does not work for you, let me know and we'll figure it
> > out.
> > 3. If that still does not work, you probably should ask in the
> > Jackrabbit project.
> >
> > How does that sound?
> >
> > Thanks,
> > Robert
> >
> >
> > [1]: https://github.com/apache/sling-org-apache-sling-starter
> > [2]:
> > https://github.com/apache/sling-org-apache-sling-starter/commit/c4f6e3b
> > >
> > > Regards,
> > >
> > > Carlos
> > >
> > >
> > > On Wed, Jan 22, 2020 at 4:47 AM Robert Munteanu <[hidden email]>
> > > wrote:
> > >
> > > > Hi Carlos,
> > > >
> > > > On Tue, 2020-01-21 at 22:31 -0500, Carlos Munoz wrote:
> > > > > Hi,
> > > > >
> > > > > My team is using Sling for an internal application and we've run
> > > > > into
> > > > > a
> > > > > couple of unexpected scenarios:
> > > > >
> > > > > 1. When modifying the nodetypes.cnd file included with our bundle
> > > > > (e.g.
> > > > > adding a new node type), the application queries seem to stop
> > > > > working. This
> > > > > only happens when the queries use the following form: "select *
> > > > > from
> > > > > [custom:type] ..." and not when using something like "select *
> > > > > from
> > > > > [nt:base] where [jcr:primaryType] = 'custom:type'"
> > > > >
> > > > > 2. There is a specific query which runs very slowly only the
> > > > > first
> > > > > time it
> > > > > is executed. Once it is executed that one time it runs
> > > > > considerably
> > > > > faster
> > > > > on subsequent runs.
> > > >
> > > > These both look like Jackrabbit/Oak issues, so first let me ask you
> > > > which version of Jackrabbit/Jackrabbit Oak are you using?
> > > >
> > > > Thanks,
> > > > Robert
> > > >
> > > > > I was wondering if the Sling community would be able to shed some
> > > > > light on
> > > > > some possible causes to these two scenarios.
> > > > >
> > > > > Thanks in advance!
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Slow queries and unexpected results

Carlos Munoz
Thanks for the tip Daniel!

Robert - we were able to successfully package the sling starter with the
latest definitions as you pointed, but when deploying on top of an existing
database we started getting a JCR error:

javax.jcr.LoginException: Can neither derive user name nor principal names
for bundle org.apache.sling.jcr.resource [152] and sub service observation

We don't get the same error when deploying on a fresh database.

Carlos

On Wed, Jan 22, 2020 at 12:22 PM Daniel Klco <[hidden email]> wrote:

> You can also try using the explain keyword to get introspection into how
> the JCR repository is planning to execute the query which may identify any
> traversal or index issues:
> https://jackrabbit.apache.org/oak/docs/query/grammar-sql2.html#explain
>
>
> On Wed, Jan 22, 2020 at 12:06 PM Carlos Munoz <[hidden email]> wrote:
>
> > Thanks heaps Robert, sounds like way more than I was expecting :)
> >
> > I'll try these things and let you know how it goes.
> >
> >
> >
> > On Wed, Jan 22, 2020 at 9:31 AM Robert Munteanu <[hidden email]>
> > wrote:
> >
> > > Hi Carlos,
> > >
> > > On Wed, 2020-01-22 at 07:11 -0500, Carlos Munoz wrote:
> > > > Thanks for the reply Robert. We are using the latest Sling release
> > > > (11) and
> > > > its corresponding bundle versions, so that would make it oak 1.8.8.
> > > >
> > > > We could proably be using more updated bundles, but without a stable
> > > > release or tag we're not sure how to gauge whether a set of bundles
> > > > is
> > > > stable enough.
> > >
> > > Latest released bundles as found in the current sling starter [1]
> > > should be stable. You could try and update to a later Oak, we have
> > > validated that Oak 1.16.0 works fine, see commit [2] for details.
> > >
> > > I would suggest the following:
> > >
> > > 1. Try and update to Oak 1.16.0, following commit [2] .
> > > 2. If that does not solve your problem, update to latest Oak (currently
> > > 1.22.0). If that does not work for you, let me know and we'll figure it
> > > out.
> > > 3. If that still does not work, you probably should ask in the
> > > Jackrabbit project.
> > >
> > > How does that sound?
> > >
> > > Thanks,
> > > Robert
> > >
> > >
> > > [1]: https://github.com/apache/sling-org-apache-sling-starter
> > > [2]:
> > >
> https://github.com/apache/sling-org-apache-sling-starter/commit/c4f6e3b
> > > >
> > > > Regards,
> > > >
> > > > Carlos
> > > >
> > > >
> > > > On Wed, Jan 22, 2020 at 4:47 AM Robert Munteanu <[hidden email]>
> > > > wrote:
> > > >
> > > > > Hi Carlos,
> > > > >
> > > > > On Tue, 2020-01-21 at 22:31 -0500, Carlos Munoz wrote:
> > > > > > Hi,
> > > > > >
> > > > > > My team is using Sling for an internal application and we've run
> > > > > > into
> > > > > > a
> > > > > > couple of unexpected scenarios:
> > > > > >
> > > > > > 1. When modifying the nodetypes.cnd file included with our bundle
> > > > > > (e.g.
> > > > > > adding a new node type), the application queries seem to stop
> > > > > > working. This
> > > > > > only happens when the queries use the following form: "select *
> > > > > > from
> > > > > > [custom:type] ..." and not when using something like "select *
> > > > > > from
> > > > > > [nt:base] where [jcr:primaryType] = 'custom:type'"
> > > > > >
> > > > > > 2. There is a specific query which runs very slowly only the
> > > > > > first
> > > > > > time it
> > > > > > is executed. Once it is executed that one time it runs
> > > > > > considerably
> > > > > > faster
> > > > > > on subsequent runs.
> > > > >
> > > > > These both look like Jackrabbit/Oak issues, so first let me ask you
> > > > > which version of Jackrabbit/Jackrabbit Oak are you using?
> > > > >
> > > > > Thanks,
> > > > > Robert
> > > > >
> > > > > > I was wondering if the Sling community would be able to shed some
> > > > > > light on
> > > > > > some possible causes to these two scenarios.
> > > > > >
> > > > > > Thanks in advance!
> > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Slow queries and unexpected results

Robert Munteanu-2
On Wed, 2020-01-22 at 16:16 -0500, Carlos Munoz wrote:

> Thanks for the tip Daniel!
>
> Robert - we were able to successfully package the sling starter with
> the
> latest definitions as you pointed, but when deploying on top of an
> existing
> database we started getting a JCR error:
>
> javax.jcr.LoginException: Can neither derive user name nor principal
> names
> for bundle org.apache.sling.jcr.resource [152] and sub service
> observation
>
> We don't get the same error when deploying on a fresh database.

It seems that you have some missing service user mappings. Those might
be required by newer versions of the bundles that you just consumed. In
the Sling Starter the current mapping is defined at [1].

Does adding that as a configuration to your application help?

Thanks,
Robert


[1]: https://github.com/apache/sling-org-apache-sling-starter/blob/7eac121fc3f00c95ef5b8ac38133f6796a4a6c08/src/main/provisioning/sling.txt#L199-L202

Reply | Threaded
Open this post in threaded view
|

Re: Slow queries and unexpected results

Carlos Munoz
I double checked and we do have the mapping. We copied all the provisioning
files from the commit you recommended earlier [1] and deployed like that.

In fact, you can see our provisioning files here: [2] We are only adding a
single file with our own bundle and configurations.

[1] https://github.com/apache/sling-org-apache-sling-starter/commit/c4f6e3b
[2]
https://github.com/redhataccess/pantheon/tree/upgrade-sling-bundles/pantheon-slingstart/src/main/provisioning

On Wed, Jan 22, 2020 at 4:54 PM Robert Munteanu <[hidden email]> wrote:

> On Wed, 2020-01-22 at 16:16 -0500, Carlos Munoz wrote:
> > Thanks for the tip Daniel!
> >
> > Robert - we were able to successfully package the sling starter with
> > the
> > latest definitions as you pointed, but when deploying on top of an
> > existing
> > database we started getting a JCR error:
> >
> > javax.jcr.LoginException: Can neither derive user name nor principal
> > names
> > for bundle org.apache.sling.jcr.resource [152] and sub service
> > observation
> >
> > We don't get the same error when deploying on a fresh database.
>
> It seems that you have some missing service user mappings. Those might
> be required by newer versions of the bundles that you just consumed. In
> the Sling Starter the current mapping is defined at [1].
>
> Does adding that as a configuration to your application help?
>
> Thanks,
> Robert
>
>
> [1]:
> https://github.com/apache/sling-org-apache-sling-starter/blob/7eac121fc3f00c95ef5b8ac38133f6796a4a6c08/src/main/provisioning/sling.txt#L199-L202
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Slow queries and unexpected results

Robert Munteanu-2
I tried building the app from source code but did not reproduce the
problem. I guess this matches your experience - this happens only
during an 'upgrade'.

Can you please give me a set of steps to reproduce? Ideally without
MongoDB, but if that's required leave it in :-)

Thanks,
Robert

On Wed, 2020-01-22 at 22:08 -0500, Carlos Munoz wrote:

> I double checked and we do have the mapping. We copied all the
> provisioning
> files from the commit you recommended earlier [1] and deployed like
> that.
>
> In fact, you can see our provisioning files here: [2] We are only
> adding a
> single file with our own bundle and configurations.
>
> [1]
> https://github.com/apache/sling-org-apache-sling-starter/commit/c4f6e3b
> [2]
> https://github.com/redhataccess/pantheon/tree/upgrade-sling-bundles/pantheon-slingstart/src/main/provisioning
>
> On Wed, Jan 22, 2020 at 4:54 PM Robert Munteanu <[hidden email]>
> wrote:
>
> > On Wed, 2020-01-22 at 16:16 -0500, Carlos Munoz wrote:
> > > Thanks for the tip Daniel!
> > >
> > > Robert - we were able to successfully package the sling starter
> > > with
> > > the
> > > latest definitions as you pointed, but when deploying on top of
> > > an
> > > existing
> > > database we started getting a JCR error:
> > >
> > > javax.jcr.LoginException: Can neither derive user name nor
> > > principal
> > > names
> > > for bundle org.apache.sling.jcr.resource [152] and sub service
> > > observation
> > >
> > > We don't get the same error when deploying on a fresh database.
> >
> > It seems that you have some missing service user mappings. Those
> > might
> > be required by newer versions of the bundles that you just
> > consumed. In
> > the Sling Starter the current mapping is defined at [1].
> >
> > Does adding that as a configuration to your application help?
> >
> > Thanks,
> > Robert
> >
> >
> > [1]:
> > https://github.com/apache/sling-org-apache-sling-starter/blob/7eac121fc3f00c95ef5b8ac38133f6796a4a6c08/src/main/provisioning/sling.txt#L199-L202
> >
> >

Reply | Threaded
Open this post in threaded view
|

Re: Slow queries and unexpected results

Carlos Munoz
Thanks Robert. I think we actually found out what was going on: it seems we
have a poorly defined index which was being deployed as part of our bundle
and which was interfering with some of the other indexes. As soon as we
removed it everything started working once again. We are working on a
better index for the query right now.

Really appreciate your willingness to help here... ++

On Fri, Jan 24, 2020 at 5:03 AM Robert Munteanu <[hidden email]> wrote:

> I tried building the app from source code but did not reproduce the
> problem. I guess this matches your experience - this happens only
> during an 'upgrade'.
>
> Can you please give me a set of steps to reproduce? Ideally without
> MongoDB, but if that's required leave it in :-)
>
> Thanks,
> Robert
>
> On Wed, 2020-01-22 at 22:08 -0500, Carlos Munoz wrote:
> > I double checked and we do have the mapping. We copied all the
> > provisioning
> > files from the commit you recommended earlier [1] and deployed like
> > that.
> >
> > In fact, you can see our provisioning files here: [2] We are only
> > adding a
> > single file with our own bundle and configurations.
> >
> > [1]
> > https://github.com/apache/sling-org-apache-sling-starter/commit/c4f6e3b
> > [2]
> >
> https://github.com/redhataccess/pantheon/tree/upgrade-sling-bundles/pantheon-slingstart/src/main/provisioning
> >
> > On Wed, Jan 22, 2020 at 4:54 PM Robert Munteanu <[hidden email]>
> > wrote:
> >
> > > On Wed, 2020-01-22 at 16:16 -0500, Carlos Munoz wrote:
> > > > Thanks for the tip Daniel!
> > > >
> > > > Robert - we were able to successfully package the sling starter
> > > > with
> > > > the
> > > > latest definitions as you pointed, but when deploying on top of
> > > > an
> > > > existing
> > > > database we started getting a JCR error:
> > > >
> > > > javax.jcr.LoginException: Can neither derive user name nor
> > > > principal
> > > > names
> > > > for bundle org.apache.sling.jcr.resource [152] and sub service
> > > > observation
> > > >
> > > > We don't get the same error when deploying on a fresh database.
> > >
> > > It seems that you have some missing service user mappings. Those
> > > might
> > > be required by newer versions of the bundles that you just
> > > consumed. In
> > > the Sling Starter the current mapping is defined at [1].
> > >
> > > Does adding that as a configuration to your application help?
> > >
> > > Thanks,
> > > Robert
> > >
> > >
> > > [1]:
> > >
> https://github.com/apache/sling-org-apache-sling-starter/blob/7eac121fc3f00c95ef5b8ac38133f6796a4a6c08/src/main/provisioning/sling.txt#L199-L202
> > >
> > >
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Slow queries and unexpected results

Robert Munteanu-2
Happy to hear that you got it sorted out! Feel free to come back with
more questions if you have any.

Thanks,
Robert

On Fri, 2020-01-24 at 10:58 -0500, Carlos Munoz wrote:

> Thanks Robert. I think we actually found out what was going on: it
> seems we
> have a poorly defined index which was being deployed as part of our
> bundle
> and which was interfering with some of the other indexes. As soon as
> we
> removed it everything started working once again. We are working on a
> better index for the query right now.
>
> Really appreciate your willingness to help here... ++
>
> On Fri, Jan 24, 2020 at 5:03 AM Robert Munteanu <[hidden email]>
> wrote:
>
> > I tried building the app from source code but did not reproduce the
> > problem. I guess this matches your experience - this happens only
> > during an 'upgrade'.
> >
> > Can you please give me a set of steps to reproduce? Ideally without
> > MongoDB, but if that's required leave it in :-)
> >
> > Thanks,
> > Robert
> >
> > On Wed, 2020-01-22 at 22:08 -0500, Carlos Munoz wrote:
> > > I double checked and we do have the mapping. We copied all the
> > > provisioning
> > > files from the commit you recommended earlier [1] and deployed
> > > like
> > > that.
> > >
> > > In fact, you can see our provisioning files here: [2] We are only
> > > adding a
> > > single file with our own bundle and configurations.
> > >
> > > [1]
> > > https://github.com/apache/sling-org-apache-sling-starter/commit/c4f6e3b
> > > [2]
> > >
> > https://github.com/redhataccess/pantheon/tree/upgrade-sling-bundles/pantheon-slingstart/src/main/provisioning
> > > On Wed, Jan 22, 2020 at 4:54 PM Robert Munteanu <
> > > [hidden email]>
> > > wrote:
> > >
> > > > On Wed, 2020-01-22 at 16:16 -0500, Carlos Munoz wrote:
> > > > > Thanks for the tip Daniel!
> > > > >
> > > > > Robert - we were able to successfully package the sling
> > > > > starter
> > > > > with
> > > > > the
> > > > > latest definitions as you pointed, but when deploying on top
> > > > > of
> > > > > an
> > > > > existing
> > > > > database we started getting a JCR error:
> > > > >
> > > > > javax.jcr.LoginException: Can neither derive user name nor
> > > > > principal
> > > > > names
> > > > > for bundle org.apache.sling.jcr.resource [152] and sub
> > > > > service
> > > > > observation
> > > > >
> > > > > We don't get the same error when deploying on a fresh
> > > > > database.
> > > >
> > > > It seems that you have some missing service user mappings.
> > > > Those
> > > > might
> > > > be required by newer versions of the bundles that you just
> > > > consumed. In
> > > > the Sling Starter the current mapping is defined at [1].
> > > >
> > > > Does adding that as a configuration to your application help?
> > > >
> > > > Thanks,
> > > > Robert
> > > >
> > > >
> > > > [1]:
> > > >
> > https://github.com/apache/sling-org-apache-sling-starter/blob/7eac121fc3f00c95ef5b8ac38133f6796a4a6c08/src/main/provisioning/sling.txt#L199-L202
> > > >

Reply | Threaded
Open this post in threaded view
|

Re: Slow queries and unexpected results

Carlos Munoz
Hi Robert, I'm picking up this thread again since we briefly talked about
this problem; allow me to recap:
We are attempting to migrate bundle versions for a Sling application from
their Sling 11 versions to the latest stable versions. The application is
running against an already populated mongo database and we are seeing the
following exception when deploying.

29.01.2020 02:58:59.571 *ERROR* [Apache Sling Repository Startup Thread #4]
ERROR: Bundle '160' EventDispatcher: Error during dispatch.
(org.apache.sling.api.SlingException: Can't create the JCR event listener.)
org.apache.sling.api.SlingException: Can't create the JCR event listener.
at
org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.registerListeners(JcrResourceProvider.java:227)

at
org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.start(JcrResourceProvider.java:182)

at
org.apache.sling.resourceresolver.impl.providers.ResourceProviderHandler.activate(ResourceProviderHandler.java:74)

at
org.apache.sling.resourceresolver.impl.providers.ResourceProviderTracker.activate(ResourceProviderTracker.java:360)

at
org.apache.sling.resourceresolver.impl.providers.ResourceProviderTracker.register(ResourceProviderTracker.java:192)

at
org.apache.sling.resourceresolver.impl.providers.ResourceProviderTracker.access$200(ResourceProviderTracker.java:59)

at
org.apache.sling.resourceresolver.impl.providers.ResourceProviderTracker$1.addingService(ResourceProviderTracker.java:130)

at
org.apache.sling.resourceresolver.impl.providers.ResourceProviderTracker$1.addingService(ResourceProviderTracker.java:106)

at
org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:943)

at
org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:871)

at
org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)
at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229)
at
org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:903)

at
org.apache.felix.framework.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:990)

at
org.apache.felix.framework.EventDispatcher.fireEventImmediately(EventDispatcher.java:838)

at
org.apache.felix.framework.EventDispatcher.fireServiceEvent(EventDispatcher.java:545)

at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4833)
at org.apache.felix.framework.Felix.registerService(Felix.java:3804)
at
org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:328)

at
org.apache.felix.scr.impl.manager.AbstractComponentManager$3.register(AbstractComponentManager.java:906)

at
org.apache.felix.scr.impl.manager.AbstractComponentManager$3.register(AbstractComponentManager.java:892)

at
org.apache.felix.scr.impl.manager.RegistrationManager.changeRegistration(RegistrationManager.java:128)

at
org.apache.felix.scr.impl.manager.AbstractComponentManager.registerService(AbstractComponentManager.java:959)

at
org.apache.felix.scr.impl.manager.AbstractComponentManager.activateInternal(AbstractComponentManager.java:732)

at
org.apache.felix.scr.impl.manager.DependencyManager$SingleStaticCustomizer.addedService(DependencyManager.java:1045)

at
org.apache.felix.scr.impl.manager.DependencyManager$SingleStaticCustomizer.addedService(DependencyManager.java:999)

at
org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.customizerAdded(ServiceTracker.java:1216)

at
org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.customizerAdded(ServiceTracker.java:1137)

at
org.apache.felix.scr.impl.manager.ServiceTracker$AbstractTracked.trackAdding(ServiceTracker.java:944)

at
org.apache.felix.scr.impl.manager.ServiceTracker$AbstractTracked.track(ServiceTracker.java:880)

at
org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:1168)

at
org.apache.felix.scr.impl.BundleComponentActivator$ListenerInfo.serviceChanged(BundleComponentActivator.java:125)

at
org.apache.felix.framework.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:990)

at
org.apache.felix.framework.EventDispatcher.fireEventImmediately(EventDispatcher.java:838)

at
org.apache.felix.framework.EventDispatcher.fireServiceEvent(EventDispatcher.java:545)

at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4833)
at org.apache.felix.framework.Felix.registerService(Felix.java:3804)
at
org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:328)

at
org.apache.sling.jcr.base.AbstractSlingRepositoryManager.registerService(AbstractSlingRepositoryManager.java:218)

at
org.apache.sling.jcr.base.AbstractSlingRepositoryManager.initializeAndRegisterRepositoryService(AbstractSlingRepositoryManager.java:541)

at
org.apache.sling.jcr.base.AbstractSlingRepositoryManager.access$300(AbstractSlingRepositoryManager.java:92)

at
org.apache.sling.jcr.base.AbstractSlingRepositoryManager$4.run(AbstractSlingRepositoryManager.java:496)

Caused by: javax.jcr.LoginException: Can neither derive user name nor
principal names for bundle org.apache.sling.jcr.resource [154] and sub
service observation
at
org.apache.sling.jcr.base.AbstractSlingRepository2.loginService(AbstractSlingRepository2.java:387)

at
org.apache.sling.jcr.resource.internal.JcrListenerBaseConfig.<init>(JcrListenerBaseConfig.java:62)

at
org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.registerListeners(JcrResourceProvider.java:218)

... 41 more


The application deploys fine when not running against mongo, or when
running against a clean mongo instance.

The changes are located here for reference:
https://github.com/redhataccess/pantheon/pull/219/files#diff-e93a9e4b7b62ab20d546f78f9ac775c8L33

Any ideas on what could be going wrong?

Regards,

Carlos



On Mon, Jan 27, 2020 at 4:57 AM Robert Munteanu <[hidden email]> wrote:

> Happy to hear that you got it sorted out! Feel free to come back with
> more questions if you have any.
>
> Thanks,
> Robert
>
> On Fri, 2020-01-24 at 10:58 -0500, Carlos Munoz wrote:
> > Thanks Robert. I think we actually found out what was going on: it
> > seems we
> > have a poorly defined index which was being deployed as part of our
> > bundle
> > and which was interfering with some of the other indexes. As soon as
> > we
> > removed it everything started working once again. We are working on a
> > better index for the query right now.
> >
> > Really appreciate your willingness to help here... ++
> >
> > On Fri, Jan 24, 2020 at 5:03 AM Robert Munteanu <[hidden email]>
> > wrote:
> >
> > > I tried building the app from source code but did not reproduce the
> > > problem. I guess this matches your experience - this happens only
> > > during an 'upgrade'.
> > >
> > > Can you please give me a set of steps to reproduce? Ideally without
> > > MongoDB, but if that's required leave it in :-)
> > >
> > > Thanks,
> > > Robert
> > >
> > > On Wed, 2020-01-22 at 22:08 -0500, Carlos Munoz wrote:
> > > > I double checked and we do have the mapping. We copied all the
> > > > provisioning
> > > > files from the commit you recommended earlier [1] and deployed
> > > > like
> > > > that.
> > > >
> > > > In fact, you can see our provisioning files here: [2] We are only
> > > > adding a
> > > > single file with our own bundle and configurations.
> > > >
> > > > [1]
> > > >
> https://github.com/apache/sling-org-apache-sling-starter/commit/c4f6e3b
> > > > [2]
> > > >
> > >
> https://github.com/redhataccess/pantheon/tree/upgrade-sling-bundles/pantheon-slingstart/src/main/provisioning
> > > > On Wed, Jan 22, 2020 at 4:54 PM Robert Munteanu <
> > > > [hidden email]>
> > > > wrote:
> > > >
> > > > > On Wed, 2020-01-22 at 16:16 -0500, Carlos Munoz wrote:
> > > > > > Thanks for the tip Daniel!
> > > > > >
> > > > > > Robert - we were able to successfully package the sling
> > > > > > starter
> > > > > > with
> > > > > > the
> > > > > > latest definitions as you pointed, but when deploying on top
> > > > > > of
> > > > > > an
> > > > > > existing
> > > > > > database we started getting a JCR error:
> > > > > >
> > > > > > javax.jcr.LoginException: Can neither derive user name nor
> > > > > > principal
> > > > > > names
> > > > > > for bundle org.apache.sling.jcr.resource [152] and sub
> > > > > > service
> > > > > > observation
> > > > > >
> > > > > > We don't get the same error when deploying on a fresh
> > > > > > database.
> > > > >
> > > > > It seems that you have some missing service user mappings.
> > > > > Those
> > > > > might
> > > > > be required by newer versions of the bundles that you just
> > > > > consumed. In
> > > > > the Sling Starter the current mapping is defined at [1].
> > > > >
> > > > > Does adding that as a configuration to your application help?
> > > > >
> > > > > Thanks,
> > > > > Robert
> > > > >
> > > > >
> > > > > [1]:
> > > > >
> > >
> https://github.com/apache/sling-org-apache-sling-starter/blob/7eac121fc3f00c95ef5b8ac38133f6796a4a6c08/src/main/provisioning/sling.txt#L199-L202
> > > > >
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Slow queries and unexpected results

Carlos Munoz
Robert, I wonder if this is a timing issue. I’m not sure I understand how
Sling is loading bundles and configurations, but is it possible that it
could load up a bundle which needs a specific configuration before said
configuration has finished loading?

I mention this because we are seeing the error now on a containerized
environment where resources may be more virtualized than in a local
environment, where the application seems to run without any issues.

Regards,

Carlos

On Tue, Jan 28, 2020 at 10:11 PM Carlos Munoz <[hidden email]> wrote:

> Hi Robert, I'm picking up this thread again since we briefly talked about
> this problem; allow me to recap:
> We are attempting to migrate bundle versions for a Sling application from
> their Sling 11 versions to the latest stable versions. The application is
> running against an already populated mongo database and we are seeing the
> following exception when deploying.
>
> 29.01.2020 02:58:59.571 *ERROR* [Apache Sling Repository Startup Thread
> #4] ERROR: Bundle '160' EventDispatcher: Error during dispatch.
> (org.apache.sling.api.SlingException: Can't create the JCR event listener.)
> org.apache.sling.api.SlingException: Can't create the JCR event listener.
> at
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.registerListeners(JcrResourceProvider.java:227)
>
> at
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.start(JcrResourceProvider.java:182)
>
> at
> org.apache.sling.resourceresolver.impl.providers.ResourceProviderHandler.activate(ResourceProviderHandler.java:74)
>
> at
> org.apache.sling.resourceresolver.impl.providers.ResourceProviderTracker.activate(ResourceProviderTracker.java:360)
>
> at
> org.apache.sling.resourceresolver.impl.providers.ResourceProviderTracker.register(ResourceProviderTracker.java:192)
>
> at
> org.apache.sling.resourceresolver.impl.providers.ResourceProviderTracker.access$200(ResourceProviderTracker.java:59)
>
> at
> org.apache.sling.resourceresolver.impl.providers.ResourceProviderTracker$1.addingService(ResourceProviderTracker.java:130)
>
> at
> org.apache.sling.resourceresolver.impl.providers.ResourceProviderTracker$1.addingService(ResourceProviderTracker.java:106)
>
> at
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:943)
>
> at
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:871)
>
> at
> org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)
> at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229)
> at
> org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:903)
>
> at
> org.apache.felix.framework.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:990)
>
> at
> org.apache.felix.framework.EventDispatcher.fireEventImmediately(EventDispatcher.java:838)
>
> at
> org.apache.felix.framework.EventDispatcher.fireServiceEvent(EventDispatcher.java:545)
>
> at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4833)
> at org.apache.felix.framework.Felix.registerService(Felix.java:3804)
> at
> org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:328)
>
> at
> org.apache.felix.scr.impl.manager.AbstractComponentManager$3.register(AbstractComponentManager.java:906)
>
> at
> org.apache.felix.scr.impl.manager.AbstractComponentManager$3.register(AbstractComponentManager.java:892)
>
> at
> org.apache.felix.scr.impl.manager.RegistrationManager.changeRegistration(RegistrationManager.java:128)
>
> at
> org.apache.felix.scr.impl.manager.AbstractComponentManager.registerService(AbstractComponentManager.java:959)
>
> at
> org.apache.felix.scr.impl.manager.AbstractComponentManager.activateInternal(AbstractComponentManager.java:732)
>
> at
> org.apache.felix.scr.impl.manager.DependencyManager$SingleStaticCustomizer.addedService(DependencyManager.java:1045)
>
> at
> org.apache.felix.scr.impl.manager.DependencyManager$SingleStaticCustomizer.addedService(DependencyManager.java:999)
>
> at
> org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.customizerAdded(ServiceTracker.java:1216)
>
> at
> org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.customizerAdded(ServiceTracker.java:1137)
>
> at
> org.apache.felix.scr.impl.manager.ServiceTracker$AbstractTracked.trackAdding(ServiceTracker.java:944)
>
> at
> org.apache.felix.scr.impl.manager.ServiceTracker$AbstractTracked.track(ServiceTracker.java:880)
>
> at
> org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:1168)
>
> at
> org.apache.felix.scr.impl.BundleComponentActivator$ListenerInfo.serviceChanged(BundleComponentActivator.java:125)
>
> at
> org.apache.felix.framework.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:990)
>
> at
> org.apache.felix.framework.EventDispatcher.fireEventImmediately(EventDispatcher.java:838)
>
> at
> org.apache.felix.framework.EventDispatcher.fireServiceEvent(EventDispatcher.java:545)
>
> at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4833)
> at org.apache.felix.framework.Felix.registerService(Felix.java:3804)
> at
> org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:328)
>
> at
> org.apache.sling.jcr.base.AbstractSlingRepositoryManager.registerService(AbstractSlingRepositoryManager.java:218)
>
> at
> org.apache.sling.jcr.base.AbstractSlingRepositoryManager.initializeAndRegisterRepositoryService(AbstractSlingRepositoryManager.java:541)
>
> at
> org.apache.sling.jcr.base.AbstractSlingRepositoryManager.access$300(AbstractSlingRepositoryManager.java:92)
>
> at
> org.apache.sling.jcr.base.AbstractSlingRepositoryManager$4.run(AbstractSlingRepositoryManager.java:496)
>
> Caused by: javax.jcr.LoginException: Can neither derive user name nor
> principal names for bundle org.apache.sling.jcr.resource [154] and sub
> service observation
> at
> org.apache.sling.jcr.base.AbstractSlingRepository2.loginService(AbstractSlingRepository2.java:387)
>
> at
> org.apache.sling.jcr.resource.internal.JcrListenerBaseConfig.<init>(JcrListenerBaseConfig.java:62)
>
> at
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.registerListeners(JcrResourceProvider.java:218)
>
> ... 41 more
>
>
> The application deploys fine when not running against mongo, or when
> running against a clean mongo instance.
>
> The changes are located here for reference:
>
> https://github.com/redhataccess/pantheon/pull/219/files#diff-e93a9e4b7b62ab20d546f78f9ac775c8L33
>
> Any ideas on what could be going wrong?
>
> Regards,
>
> Carlos
>
>
>
> On Mon, Jan 27, 2020 at 4:57 AM Robert Munteanu <[hidden email]>
> wrote:
>
>> Happy to hear that you got it sorted out! Feel free to come back with
>> more questions if you have any.
>>
>> Thanks,
>> Robert
>>
>> On Fri, 2020-01-24 at 10:58 -0500, Carlos Munoz wrote:
>> > Thanks Robert. I think we actually found out what was going on: it
>> > seems we
>> > have a poorly defined index which was being deployed as part of our
>> > bundle
>> > and which was interfering with some of the other indexes. As soon as
>> > we
>> > removed it everything started working once again. We are working on a
>> > better index for the query right now.
>> >
>> > Really appreciate your willingness to help here... ++
>> >
>> > On Fri, Jan 24, 2020 at 5:03 AM Robert Munteanu <[hidden email]>
>> > wrote:
>> >
>> > > I tried building the app from source code but did not reproduce the
>> > > problem. I guess this matches your experience - this happens only
>> > > during an 'upgrade'.
>> > >
>> > > Can you please give me a set of steps to reproduce? Ideally without
>> > > MongoDB, but if that's required leave it in :-)
>> > >
>> > > Thanks,
>> > > Robert
>> > >
>> > > On Wed, 2020-01-22 at 22:08 -0500, Carlos Munoz wrote:
>> > > > I double checked and we do have the mapping. We copied all the
>> > > > provisioning
>> > > > files from the commit you recommended earlier [1] and deployed
>> > > > like
>> > > > that.
>> > > >
>> > > > In fact, you can see our provisioning files here: [2] We are only
>> > > > adding a
>> > > > single file with our own bundle and configurations.
>> > > >
>> > > > [1]
>> > > >
>> https://github.com/apache/sling-org-apache-sling-starter/commit/c4f6e3b
>> > > > [2]
>> > > >
>> > >
>> https://github.com/redhataccess/pantheon/tree/upgrade-sling-bundles/pantheon-slingstart/src/main/provisioning
>> > > > On Wed, Jan 22, 2020 at 4:54 PM Robert Munteanu <
>> > > > [hidden email]>
>> > > > wrote:
>> > > >
>> > > > > On Wed, 2020-01-22 at 16:16 -0500, Carlos Munoz wrote:
>> > > > > > Thanks for the tip Daniel!
>> > > > > >
>> > > > > > Robert - we were able to successfully package the sling
>> > > > > > starter
>> > > > > > with
>> > > > > > the
>> > > > > > latest definitions as you pointed, but when deploying on top
>> > > > > > of
>> > > > > > an
>> > > > > > existing
>> > > > > > database we started getting a JCR error:
>> > > > > >
>> > > > > > javax.jcr.LoginException: Can neither derive user name nor
>> > > > > > principal
>> > > > > > names
>> > > > > > for bundle org.apache.sling.jcr.resource [152] and sub
>> > > > > > service
>> > > > > > observation
>> > > > > >
>> > > > > > We don't get the same error when deploying on a fresh
>> > > > > > database.
>> > > > >
>> > > > > It seems that you have some missing service user mappings.
>> > > > > Those
>> > > > > might
>> > > > > be required by newer versions of the bundles that you just
>> > > > > consumed. In
>> > > > > the Sling Starter the current mapping is defined at [1].
>> > > > >
>> > > > > Does adding that as a configuration to your application help?
>> > > > >
>> > > > > Thanks,
>> > > > > Robert
>> > > > >
>> > > > >
>> > > > > [1]:
>> > > > >
>> > >
>> https://github.com/apache/sling-org-apache-sling-starter/blob/7eac121fc3f00c95ef5b8ac38133f6796a4a6c08/src/main/provisioning/sling.txt#L199-L202
>> > > > >
>>
>> --

Carlos A. Muñoz

Manager, Software Engineering - Customer Platform

Red Hat <https://www.redhat.com>
<https://red.ht/sig>
Reply | Threaded
Open this post in threaded view
|

Re: Slow queries and unexpected results

Carlos Munoz
Robert, I checked the latest (master) pipeline build logs for the starter
project:

https://builds.apache.org/blue/organizations/jenkins/Sling%2Fsling-org-apache-sling-starter/detail/master/104/pipeline/24

and found that there is a very similar error being reported (different
principal and bundle), but same type of exception nonetheless.

Carlos


On Wed, Jan 29, 2020 at 7:47 PM Carlos Munoz <[hidden email]> wrote:

> Robert, I wonder if this is a timing issue. I’m not sure I understand how
> Sling is loading bundles and configurations, but is it possible that it
> could load up a bundle which needs a specific configuration before said
> configuration has finished loading?
>
> I mention this because we are seeing the error now on a containerized
> environment where resources may be more virtualized than in a local
> environment, where the application seems to run without any issues.
>
> Regards,
>
> Carlos
>
> On Tue, Jan 28, 2020 at 10:11 PM Carlos Munoz <[hidden email]> wrote:
>
>> Hi Robert, I'm picking up this thread again since we briefly talked about
>> this problem; allow me to recap:
>> We are attempting to migrate bundle versions for a Sling application from
>> their Sling 11 versions to the latest stable versions. The application is
>> running against an already populated mongo database and we are seeing the
>> following exception when deploying.
>>
>> 29.01.2020 02:58:59.571 *ERROR* [Apache Sling Repository Startup Thread
>> #4] ERROR: Bundle '160' EventDispatcher: Error during dispatch.
>> (org.apache.sling.api.SlingException: Can't create the JCR event listener.)
>> org.apache.sling.api.SlingException: Can't create the JCR event listener.
>> at
>> org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.registerListeners(JcrResourceProvider.java:227)
>>
>> at
>> org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.start(JcrResourceProvider.java:182)
>>
>> at
>> org.apache.sling.resourceresolver.impl.providers.ResourceProviderHandler.activate(ResourceProviderHandler.java:74)
>>
>> at
>> org.apache.sling.resourceresolver.impl.providers.ResourceProviderTracker.activate(ResourceProviderTracker.java:360)
>>
>> at
>> org.apache.sling.resourceresolver.impl.providers.ResourceProviderTracker.register(ResourceProviderTracker.java:192)
>>
>> at
>> org.apache.sling.resourceresolver.impl.providers.ResourceProviderTracker.access$200(ResourceProviderTracker.java:59)
>>
>> at
>> org.apache.sling.resourceresolver.impl.providers.ResourceProviderTracker$1.addingService(ResourceProviderTracker.java:130)
>>
>> at
>> org.apache.sling.resourceresolver.impl.providers.ResourceProviderTracker$1.addingService(ResourceProviderTracker.java:106)
>>
>> at
>> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:943)
>>
>> at
>> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:871)
>>
>> at
>> org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)
>> at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229)
>> at
>> org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:903)
>>
>> at
>> org.apache.felix.framework.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:990)
>>
>> at
>> org.apache.felix.framework.EventDispatcher.fireEventImmediately(EventDispatcher.java:838)
>>
>> at
>> org.apache.felix.framework.EventDispatcher.fireServiceEvent(EventDispatcher.java:545)
>>
>> at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4833)
>> at org.apache.felix.framework.Felix.registerService(Felix.java:3804)
>> at
>> org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:328)
>>
>> at
>> org.apache.felix.scr.impl.manager.AbstractComponentManager$3.register(AbstractComponentManager.java:906)
>>
>> at
>> org.apache.felix.scr.impl.manager.AbstractComponentManager$3.register(AbstractComponentManager.java:892)
>>
>> at
>> org.apache.felix.scr.impl.manager.RegistrationManager.changeRegistration(RegistrationManager.java:128)
>>
>> at
>> org.apache.felix.scr.impl.manager.AbstractComponentManager.registerService(AbstractComponentManager.java:959)
>>
>> at
>> org.apache.felix.scr.impl.manager.AbstractComponentManager.activateInternal(AbstractComponentManager.java:732)
>>
>> at
>> org.apache.felix.scr.impl.manager.DependencyManager$SingleStaticCustomizer.addedService(DependencyManager.java:1045)
>>
>> at
>> org.apache.felix.scr.impl.manager.DependencyManager$SingleStaticCustomizer.addedService(DependencyManager.java:999)
>>
>> at
>> org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.customizerAdded(ServiceTracker.java:1216)
>>
>> at
>> org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.customizerAdded(ServiceTracker.java:1137)
>>
>> at
>> org.apache.felix.scr.impl.manager.ServiceTracker$AbstractTracked.trackAdding(ServiceTracker.java:944)
>>
>> at
>> org.apache.felix.scr.impl.manager.ServiceTracker$AbstractTracked.track(ServiceTracker.java:880)
>>
>> at
>> org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:1168)
>>
>> at
>> org.apache.felix.scr.impl.BundleComponentActivator$ListenerInfo.serviceChanged(BundleComponentActivator.java:125)
>>
>> at
>> org.apache.felix.framework.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:990)
>>
>> at
>> org.apache.felix.framework.EventDispatcher.fireEventImmediately(EventDispatcher.java:838)
>>
>> at
>> org.apache.felix.framework.EventDispatcher.fireServiceEvent(EventDispatcher.java:545)
>>
>> at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4833)
>> at org.apache.felix.framework.Felix.registerService(Felix.java:3804)
>> at
>> org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:328)
>>
>> at
>> org.apache.sling.jcr.base.AbstractSlingRepositoryManager.registerService(AbstractSlingRepositoryManager.java:218)
>>
>> at
>> org.apache.sling.jcr.base.AbstractSlingRepositoryManager.initializeAndRegisterRepositoryService(AbstractSlingRepositoryManager.java:541)
>>
>> at
>> org.apache.sling.jcr.base.AbstractSlingRepositoryManager.access$300(AbstractSlingRepositoryManager.java:92)
>>
>> at
>> org.apache.sling.jcr.base.AbstractSlingRepositoryManager$4.run(AbstractSlingRepositoryManager.java:496)
>>
>> Caused by: javax.jcr.LoginException: Can neither derive user name nor
>> principal names for bundle org.apache.sling.jcr.resource [154] and sub
>> service observation
>> at
>> org.apache.sling.jcr.base.AbstractSlingRepository2.loginService(AbstractSlingRepository2.java:387)
>>
>> at
>> org.apache.sling.jcr.resource.internal.JcrListenerBaseConfig.<init>(JcrListenerBaseConfig.java:62)
>>
>> at
>> org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.registerListeners(JcrResourceProvider.java:218)
>>
>> ... 41 more
>>
>>
>> The application deploys fine when not running against mongo, or when
>> running against a clean mongo instance.
>>
>> The changes are located here for reference:
>>
>> https://github.com/redhataccess/pantheon/pull/219/files#diff-e93a9e4b7b62ab20d546f78f9ac775c8L33
>>
>> Any ideas on what could be going wrong?
>>
>> Regards,
>>
>> Carlos
>>
>>
>>
>> On Mon, Jan 27, 2020 at 4:57 AM Robert Munteanu <[hidden email]>
>> wrote:
>>
>>> Happy to hear that you got it sorted out! Feel free to come back with
>>> more questions if you have any.
>>>
>>> Thanks,
>>> Robert
>>>
>>> On Fri, 2020-01-24 at 10:58 -0500, Carlos Munoz wrote:
>>> > Thanks Robert. I think we actually found out what was going on: it
>>> > seems we
>>> > have a poorly defined index which was being deployed as part of our
>>> > bundle
>>> > and which was interfering with some of the other indexes. As soon as
>>> > we
>>> > removed it everything started working once again. We are working on a
>>> > better index for the query right now.
>>> >
>>> > Really appreciate your willingness to help here... ++
>>> >
>>> > On Fri, Jan 24, 2020 at 5:03 AM Robert Munteanu <[hidden email]>
>>> > wrote:
>>> >
>>> > > I tried building the app from source code but did not reproduce the
>>> > > problem. I guess this matches your experience - this happens only
>>> > > during an 'upgrade'.
>>> > >
>>> > > Can you please give me a set of steps to reproduce? Ideally without
>>> > > MongoDB, but if that's required leave it in :-)
>>> > >
>>> > > Thanks,
>>> > > Robert
>>> > >
>>> > > On Wed, 2020-01-22 at 22:08 -0500, Carlos Munoz wrote:
>>> > > > I double checked and we do have the mapping. We copied all the
>>> > > > provisioning
>>> > > > files from the commit you recommended earlier [1] and deployed
>>> > > > like
>>> > > > that.
>>> > > >
>>> > > > In fact, you can see our provisioning files here: [2] We are only
>>> > > > adding a
>>> > > > single file with our own bundle and configurations.
>>> > > >
>>> > > > [1]
>>> > > >
>>> https://github.com/apache/sling-org-apache-sling-starter/commit/c4f6e3b
>>> > > > [2]
>>> > > >
>>> > >
>>> https://github.com/redhataccess/pantheon/tree/upgrade-sling-bundles/pantheon-slingstart/src/main/provisioning
>>> > > > On Wed, Jan 22, 2020 at 4:54 PM Robert Munteanu <
>>> > > > [hidden email]>
>>> > > > wrote:
>>> > > >
>>> > > > > On Wed, 2020-01-22 at 16:16 -0500, Carlos Munoz wrote:
>>> > > > > > Thanks for the tip Daniel!
>>> > > > > >
>>> > > > > > Robert - we were able to successfully package the sling
>>> > > > > > starter
>>> > > > > > with
>>> > > > > > the
>>> > > > > > latest definitions as you pointed, but when deploying on top
>>> > > > > > of
>>> > > > > > an
>>> > > > > > existing
>>> > > > > > database we started getting a JCR error:
>>> > > > > >
>>> > > > > > javax.jcr.LoginException: Can neither derive user name nor
>>> > > > > > principal
>>> > > > > > names
>>> > > > > > for bundle org.apache.sling.jcr.resource [152] and sub
>>> > > > > > service
>>> > > > > > observation
>>> > > > > >
>>> > > > > > We don't get the same error when deploying on a fresh
>>> > > > > > database.
>>> > > > >
>>> > > > > It seems that you have some missing service user mappings.
>>> > > > > Those
>>> > > > > might
>>> > > > > be required by newer versions of the bundles that you just
>>> > > > > consumed. In
>>> > > > > the Sling Starter the current mapping is defined at [1].
>>> > > > >
>>> > > > > Does adding that as a configuration to your application help?
>>> > > > >
>>> > > > > Thanks,
>>> > > > > Robert
>>> > > > >
>>> > > > >
>>> > > > > [1]:
>>> > > > >
>>> > >
>>> https://github.com/apache/sling-org-apache-sling-starter/blob/7eac121fc3f00c95ef5b8ac38133f6796a4a6c08/src/main/provisioning/sling.txt#L199-L202
>>> > > > >
>>>
>>> --
>
> Carlos A. Muñoz
>
> Manager, Software Engineering - Customer Platform
>
> Red Hat <https://www.redhat.com>
> <https://red.ht/sig>
>
Reply | Threaded
Open this post in threaded view
|

Error migrating to latest version of the bundles - Can neither derive user name nor principal names (was: Slow queries and unexpected results)

Robert Munteanu-2
Hi Carlos,

Yes, this may be a timing issue.

I could not follow the link you sent me for some reason. I think the
build log is the one from [1]. If that is the case, the error is
visible at shutdown, and probably does not have the same root cause.

I'd still like to get some steps to reproduce - even if it's a change
of 1 in 3, even if it depends on containers.

Thanks,
Robert


[1]: https://builds.apache.org/job/Sling/job/sling-org-apache-sling-starter/job/master/104/console

On Wed, 2020-01-29 at 21:27 -0500, Carlos Munoz wrote:

> Robert, I checked the latest (master) pipeline build logs for the
> starter
> project:
>
> https://builds.apache.org/blue/organizations/jenkins/Sling%2Fsling-org-apache-sling-starter/detail/master/104/pipeline/24
>
> and found that there is a very similar error being reported
> (different
> principal and bundle), but same type of exception nonetheless.
>
> Carlos
>
>
> On Wed, Jan 29, 2020 at 7:47 PM Carlos Munoz <[hidden email]>
> wrote:
>
> > Robert, I wonder if this is a timing issue. I’m not sure I
> > understand how
> > Sling is loading bundles and configurations, but is it possible
> > that it
> > could load up a bundle which needs a specific configuration before
> > said
> > configuration has finished loading?
> >
> > I mention this because we are seeing the error now on a
> > containerized
> > environment where resources may be more virtualized than in a local
> > environment, where the application seems to run without any issues.
> >
> > Regards,
> >
> > Carlos
> >
> > On Tue, Jan 28, 2020 at 10:11 PM Carlos Munoz <[hidden email]>
> > wrote:
> >
> > > Hi Robert, I'm picking up this thread again since we briefly
> > > talked about
> > > this problem; allow me to recap:
> > > We are attempting to migrate bundle versions for a Sling
> > > application from
> > > their Sling 11 versions to the latest stable versions. The
> > > application is
> > > running against an already populated mongo database and we are
> > > seeing the
> > > following exception when deploying.
> > >
> > > 29.01.2020 02:58:59.571 *ERROR* [Apache Sling Repository Startup
> > > Thread
> > > #4] ERROR: Bundle '160' EventDispatcher: Error during dispatch.
> > > (org.apache.sling.api.SlingException: Can't create the JCR event
> > > listener.)
> > > org.apache.sling.api.SlingException: Can't create the JCR event
> > > listener.
> > > at
> > > org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProv
> > > ider.registerListeners(JcrResourceProvider.java:227)
> > >
> > > at
> > > org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProv
> > > ider.start(JcrResourceProvider.java:182)
> > >
> > > at
> > > org.apache.sling.resourceresolver.impl.providers.ResourceProvider
> > > Handler.activate(ResourceProviderHandler.java:74)
> > >
> > > at
> > > org.apache.sling.resourceresolver.impl.providers.ResourceProvider
> > > Tracker.activate(ResourceProviderTracker.java:360)
> > >
> > > at
> > > org.apache.sling.resourceresolver.impl.providers.ResourceProvider
> > > Tracker.register(ResourceProviderTracker.java:192)
> > >
> > > at
> > > org.apache.sling.resourceresolver.impl.providers.ResourceProvider
> > > Tracker.access$200(ResourceProviderTracker.java:59)
> > >
> > > at
> > > org.apache.sling.resourceresolver.impl.providers.ResourceProvider
> > > Tracker$1.addingService(ResourceProviderTracker.java:130)
> > >
> > > at
> > > org.apache.sling.resourceresolver.impl.providers.ResourceProvider
> > > Tracker$1.addingService(ResourceProviderTracker.java:106)
> > >
> > > at
> > > org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(Ser
> > > viceTracker.java:943)
> > >
> > > at
> > > org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(Ser
> > > viceTracker.java:871)
> > >
> > > at
> > > org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked
> > > .java:256)
> > > at
> > > org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:
> > > 229)
> > > at
> > > org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(Servi
> > > ceTracker.java:903)
> > >
> > > at
> > > org.apache.felix.framework.EventDispatcher.invokeServiceListenerC
> > > allback(EventDispatcher.java:990)
> > >
> > > at
> > > org.apache.felix.framework.EventDispatcher.fireEventImmediately(E
> > > ventDispatcher.java:838)
> > >
> > > at
> > > org.apache.felix.framework.EventDispatcher.fireServiceEvent(Event
> > > Dispatcher.java:545)
> > >
> > > at
> > > org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4833
> > > )
> > > at
> > > org.apache.felix.framework.Felix.registerService(Felix.java:3804)
> > > at
> > > org.apache.felix.framework.BundleContextImpl.registerService(Bund
> > > leContextImpl.java:328)
> > >
> > > at
> > > org.apache.felix.scr.impl.manager.AbstractComponentManager$3.regi
> > > ster(AbstractComponentManager.java:906)
> > >
> > > at
> > > org.apache.felix.scr.impl.manager.AbstractComponentManager$3.regi
> > > ster(AbstractComponentManager.java:892)
> > >
> > > at
> > > org.apache.felix.scr.impl.manager.RegistrationManager.changeRegis
> > > tration(RegistrationManager.java:128)
> > >
> > > at
> > > org.apache.felix.scr.impl.manager.AbstractComponentManager.regist
> > > erService(AbstractComponentManager.java:959)
> > >
> > > at
> > > org.apache.felix.scr.impl.manager.AbstractComponentManager.activa
> > > teInternal(AbstractComponentManager.java:732)
> > >
> > > at
> > > org.apache.felix.scr.impl.manager.DependencyManager$SingleStaticC
> > > ustomizer.addedService(DependencyManager.java:1045)
> > >
> > > at
> > > org.apache.felix.scr.impl.manager.DependencyManager$SingleStaticC
> > > ustomizer.addedService(DependencyManager.java:999)
> > >
> > > at
> > > org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.customiz
> > > erAdded(ServiceTracker.java:1216)
> > >
> > > at
> > > org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.customiz
> > > erAdded(ServiceTracker.java:1137)
> > >
> > > at
> > > org.apache.felix.scr.impl.manager.ServiceTracker$AbstractTracked.
> > > trackAdding(ServiceTracker.java:944)
> > >
> > > at
> > > org.apache.felix.scr.impl.manager.ServiceTracker$AbstractTracked.
> > > track(ServiceTracker.java:880)
> > >
> > > at
> > > org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.serviceC
> > > hanged(ServiceTracker.java:1168)
> > >
> > > at
> > > org.apache.felix.scr.impl.BundleComponentActivator$ListenerInfo.s
> > > erviceChanged(BundleComponentActivator.java:125)
> > >
> > > at
> > > org.apache.felix.framework.EventDispatcher.invokeServiceListenerC
> > > allback(EventDispatcher.java:990)
> > >
> > > at
> > > org.apache.felix.framework.EventDispatcher.fireEventImmediately(E
> > > ventDispatcher.java:838)
> > >
> > > at
> > > org.apache.felix.framework.EventDispatcher.fireServiceEvent(Event
> > > Dispatcher.java:545)
> > >
> > > at
> > > org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4833
> > > )
> > > at
> > > org.apache.felix.framework.Felix.registerService(Felix.java:3804)
> > > at
> > > org.apache.felix.framework.BundleContextImpl.registerService(Bund
> > > leContextImpl.java:328)
> > >
> > > at
> > > org.apache.sling.jcr.base.AbstractSlingRepositoryManager.register
> > > Service(AbstractSlingRepositoryManager.java:218)
> > >
> > > at
> > > org.apache.sling.jcr.base.AbstractSlingRepositoryManager.initiali
> > > zeAndRegisterRepositoryService(AbstractSlingRepositoryManager.jav
> > > a:541)
> > >
> > > at
> > > org.apache.sling.jcr.base.AbstractSlingRepositoryManager.access$3
> > > 00(AbstractSlingRepositoryManager.java:92)
> > >
> > > at
> > > org.apache.sling.jcr.base.AbstractSlingRepositoryManager$4.run(Ab
> > > stractSlingRepositoryManager.java:496)
> > >
> > > Caused by: javax.jcr.LoginException: Can neither derive user name
> > > nor
> > > principal names for bundle org.apache.sling.jcr.resource [154]
> > > and sub
> > > service observation
> > > at
> > > org.apache.sling.jcr.base.AbstractSlingRepository2.loginService(A
> > > bstractSlingRepository2.java:387)
> > >
> > > at
> > > org.apache.sling.jcr.resource.internal.JcrListenerBaseConfig.<ini
> > > t>(JcrListenerBaseConfig.java:62)
> > >
> > > at
> > > org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProv
> > > ider.registerListeners(JcrResourceProvider.java:218)
> > >
> > > ... 41 more
> > >
> > >
> > > The application deploys fine when not running against mongo, or
> > > when
> > > running against a clean mongo instance.
> > >
> > > The changes are located here for reference:
> > >
> > > https://github.com/redhataccess/pantheon/pull/219/files#diff-e93a9e4b7b62ab20d546f78f9ac775c8L33
> > >
> > > Any ideas on what could be going wrong?
> > >
> > > Regards,
> > >
> > > Carlos
> > >
> > >
> > >
> > > On Mon, Jan 27, 2020 at 4:57 AM Robert Munteanu <
> > > [hidden email]>
> > > wrote:
> > >
> > > > Happy to hear that you got it sorted out! Feel free to come
> > > > back with
> > > > more questions if you have any.
> > > >
> > > > Thanks,
> > > > Robert
> > > >
> > > > On Fri, 2020-01-24 at 10:58 -0500, Carlos Munoz wrote:
> > > > > Thanks Robert. I think we actually found out what was going
> > > > > on: it
> > > > > seems we
> > > > > have a poorly defined index which was being deployed as part
> > > > > of our
> > > > > bundle
> > > > > and which was interfering with some of the other indexes. As
> > > > > soon as
> > > > > we
> > > > > removed it everything started working once again. We are
> > > > > working on a
> > > > > better index for the query right now.
> > > > >
> > > > > Really appreciate your willingness to help here... ++
> > > > >
> > > > > On Fri, Jan 24, 2020 at 5:03 AM Robert Munteanu <
> > > > > [hidden email]>
> > > > > wrote:
> > > > >
> > > > > > I tried building the app from source code but did not
> > > > > > reproduce the
> > > > > > problem. I guess this matches your experience - this
> > > > > > happens only
> > > > > > during an 'upgrade'.
> > > > > >
> > > > > > Can you please give me a set of steps to reproduce? Ideally
> > > > > > without
> > > > > > MongoDB, but if that's required leave it in :-)
> > > > > >
> > > > > > Thanks,
> > > > > > Robert
> > > > > >
> > > > > > On Wed, 2020-01-22 at 22:08 -0500, Carlos Munoz wrote:
> > > > > > > I double checked and we do have the mapping. We copied
> > > > > > > all the
> > > > > > > provisioning
> > > > > > > files from the commit you recommended earlier [1] and
> > > > > > > deployed
> > > > > > > like
> > > > > > > that.
> > > > > > >
> > > > > > > In fact, you can see our provisioning files here: [2] We
> > > > > > > are only
> > > > > > > adding a
> > > > > > > single file with our own bundle and configurations.
> > > > > > >
> > > > > > > [1]
> > > > > > >
> > > > https://github.com/apache/sling-org-apache-sling-starter/commit/c4f6e3b
> > > > > > > [2]
> > > > > > >
> > > > https://github.com/redhataccess/pantheon/tree/upgrade-sling-bundles/pantheon-slingstart/src/main/provisioning
> > > > > > > On Wed, Jan 22, 2020 at 4:54 PM Robert Munteanu <
> > > > > > > [hidden email]>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > On Wed, 2020-01-22 at 16:16 -0500, Carlos Munoz wrote:
> > > > > > > > > Thanks for the tip Daniel!
> > > > > > > > >
> > > > > > > > > Robert - we were able to successfully package the
> > > > > > > > > sling
> > > > > > > > > starter
> > > > > > > > > with
> > > > > > > > > the
> > > > > > > > > latest definitions as you pointed, but when deploying
> > > > > > > > > on top
> > > > > > > > > of
> > > > > > > > > an
> > > > > > > > > existing
> > > > > > > > > database we started getting a JCR error:
> > > > > > > > >
> > > > > > > > > javax.jcr.LoginException: Can neither derive user
> > > > > > > > > name nor
> > > > > > > > > principal
> > > > > > > > > names
> > > > > > > > > for bundle org.apache.sling.jcr.resource [152] and
> > > > > > > > > sub
> > > > > > > > > service
> > > > > > > > > observation
> > > > > > > > >
> > > > > > > > > We don't get the same error when deploying on a fresh
> > > > > > > > > database.
> > > > > > > >
> > > > > > > > It seems that you have some missing service user
> > > > > > > > mappings.
> > > > > > > > Those
> > > > > > > > might
> > > > > > > > be required by newer versions of the bundles that you
> > > > > > > > just
> > > > > > > > consumed. In
> > > > > > > > the Sling Starter the current mapping is defined at
> > > > > > > > [1].
> > > > > > > >
> > > > > > > > Does adding that as a configuration to your application
> > > > > > > > help?
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > Robert
> > > > > > > >
> > > > > > > >
> > > > > > > > [1]:
> > > > > > > >
> > > > https://github.com/apache/sling-org-apache-sling-starter/blob/7eac121fc3f00c95ef5b8ac38133f6796a4a6c08/src/main/provisioning/sling.txt#L199-L202
> > > >
> > > > --
> >
> > Carlos A. Muñoz
> >
> > Manager, Software Engineering - Customer Platform
> >
> > Red Hat <https://www.redhat.com>
> > <https://red.ht/sig>
> >

Reply | Threaded
Open this post in threaded view
|

Re: Error migrating to latest version of the bundles - Can neither derive user name nor principal names (was: Slow queries and unexpected results)

Carlos Munoz
Sure thing.

Steps to reproduce are fairly simple, we actually saw the same result when
building a vanilla sling starter from master [1]. But if you want to be
closer to our specific problem you can build from our application's starter
module [2].

We containerize the application using the Dockerfile in the same repo [3],
and we run in a Kubernetes orchestrated server against a Mongo DB cluster
with 3 nodes (note that there is some latency due to the database).

We run the application from the resulting container image and we see the
error as sling is coming up.

Let me know if this is enough to go by.

As a side question, I was wondering if the order of the provisioning files
makes any difference to the sequence in which bundles and configurations
are installed. I was thinking if this is the case we might be able to
reorganize those files to ensure all configurations are loaded before the
bundles using them.

Regards,

Carlos

[1] https://github.com/apache/sling-org-apache-sling-starter
[2] https://github.com/redhataccess/pantheon/pull/221
[3]
https://github.com/redhataccess/pantheon/blob/master/container/Dockerfile

On Thu, Jan 30, 2020 at 4:47 AM Robert Munteanu <[hidden email]> wrote:

> Hi Carlos,
>
> Yes, this may be a timing issue.
>
> I could not follow the link you sent me for some reason. I think the
> build log is the one from [1]. If that is the case, the error is
> visible at shutdown, and probably does not have the same root cause.
>
> I'd still like to get some steps to reproduce - even if it's a change
> of 1 in 3, even if it depends on containers.
>
> Thanks,
> Robert
>
>
> [1]:
> https://builds.apache.org/job/Sling/job/sling-org-apache-sling-starter/job/master/104/console
>
> On Wed, 2020-01-29 at 21:27 -0500, Carlos Munoz wrote:
> > Robert, I checked the latest (master) pipeline build logs for the
> > starter
> > project:
> >
> >
> https://builds.apache.org/blue/organizations/jenkins/Sling%2Fsling-org-apache-sling-starter/detail/master/104/pipeline/24
> >
> > and found that there is a very similar error being reported
> > (different
> > principal and bundle), but same type of exception nonetheless.
> >
> > Carlos
> >
> >
> > On Wed, Jan 29, 2020 at 7:47 PM Carlos Munoz <[hidden email]>
> > wrote:
> >
> > > Robert, I wonder if this is a timing issue. I’m not sure I
> > > understand how
> > > Sling is loading bundles and configurations, but is it possible
> > > that it
> > > could load up a bundle which needs a specific configuration before
> > > said
> > > configuration has finished loading?
> > >
> > > I mention this because we are seeing the error now on a
> > > containerized
> > > environment where resources may be more virtualized than in a local
> > > environment, where the application seems to run without any issues.
> > >
> > > Regards,
> > >
> > > Carlos
> > >
> > > On Tue, Jan 28, 2020 at 10:11 PM Carlos Munoz <[hidden email]>
> > > wrote:
> > >
> > > > Hi Robert, I'm picking up this thread again since we briefly
> > > > talked about
> > > > this problem; allow me to recap:
> > > > We are attempting to migrate bundle versions for a Sling
> > > > application from
> > > > their Sling 11 versions to the latest stable versions. The
> > > > application is
> > > > running against an already populated mongo database and we are
> > > > seeing the
> > > > following exception when deploying.
> > > >
> > > > 29.01.2020 02:58:59.571 *ERROR* [Apache Sling Repository Startup
> > > > Thread
> > > > #4] ERROR: Bundle '160' EventDispatcher: Error during dispatch.
> > > > (org.apache.sling.api.SlingException: Can't create the JCR event
> > > > listener.)
> > > > org.apache.sling.api.SlingException: Can't create the JCR event
> > > > listener.
> > > > at
> > > > org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProv
> > > > ider.registerListeners(JcrResourceProvider.java:227)
> > > >
> > > > at
> > > > org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProv
> > > > ider.start(JcrResourceProvider.java:182)
> > > >
> > > > at
> > > > org.apache.sling.resourceresolver.impl.providers.ResourceProvider
> > > > Handler.activate(ResourceProviderHandler.java:74)
> > > >
> > > > at
> > > > org.apache.sling.resourceresolver.impl.providers.ResourceProvider
> > > > Tracker.activate(ResourceProviderTracker.java:360)
> > > >
> > > > at
> > > > org.apache.sling.resourceresolver.impl.providers.ResourceProvider
> > > > Tracker.register(ResourceProviderTracker.java:192)
> > > >
> > > > at
> > > > org.apache.sling.resourceresolver.impl.providers.ResourceProvider
> > > > Tracker.access$200(ResourceProviderTracker.java:59)
> > > >
> > > > at
> > > > org.apache.sling.resourceresolver.impl.providers.ResourceProvider
> > > > Tracker$1.addingService(ResourceProviderTracker.java:130)
> > > >
> > > > at
> > > > org.apache.sling.resourceresolver.impl.providers.ResourceProvider
> > > > Tracker$1.addingService(ResourceProviderTracker.java:106)
> > > >
> > > > at
> > > > org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(Ser
> > > > viceTracker.java:943)
> > > >
> > > > at
> > > > org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(Ser
> > > > viceTracker.java:871)
> > > >
> > > > at
> > > > org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked
> > > > .java:256)
> > > > at
> > > > org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:
> > > > 229)
> > > > at
> > > > org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(Servi
> > > > ceTracker.java:903)
> > > >
> > > > at
> > > > org.apache.felix.framework.EventDispatcher.invokeServiceListenerC
> > > > allback(EventDispatcher.java:990)
> > > >
> > > > at
> > > > org.apache.felix.framework.EventDispatcher.fireEventImmediately(E
> > > > ventDispatcher.java:838)
> > > >
> > > > at
> > > > org.apache.felix.framework.EventDispatcher.fireServiceEvent(Event
> > > > Dispatcher.java:545)
> > > >
> > > > at
> > > > org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4833
> > > > )
> > > > at
> > > > org.apache.felix.framework.Felix.registerService(Felix.java:3804)
> > > > at
> > > > org.apache.felix.framework.BundleContextImpl.registerService(Bund
> > > > leContextImpl.java:328)
> > > >
> > > > at
> > > > org.apache.felix.scr.impl.manager.AbstractComponentManager$3.regi
> > > > ster(AbstractComponentManager.java:906)
> > > >
> > > > at
> > > > org.apache.felix.scr.impl.manager.AbstractComponentManager$3.regi
> > > > ster(AbstractComponentManager.java:892)
> > > >
> > > > at
> > > > org.apache.felix.scr.impl.manager.RegistrationManager.changeRegis
> > > > tration(RegistrationManager.java:128)
> > > >
> > > > at
> > > > org.apache.felix.scr.impl.manager.AbstractComponentManager.regist
> > > > erService(AbstractComponentManager.java:959)
> > > >
> > > > at
> > > > org.apache.felix.scr.impl.manager.AbstractComponentManager.activa
> > > > teInternal(AbstractComponentManager.java:732)
> > > >
> > > > at
> > > > org.apache.felix.scr.impl.manager.DependencyManager$SingleStaticC
> > > > ustomizer.addedService(DependencyManager.java:1045)
> > > >
> > > > at
> > > > org.apache.felix.scr.impl.manager.DependencyManager$SingleStaticC
> > > > ustomizer.addedService(DependencyManager.java:999)
> > > >
> > > > at
> > > > org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.customiz
> > > > erAdded(ServiceTracker.java:1216)
> > > >
> > > > at
> > > > org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.customiz
> > > > erAdded(ServiceTracker.java:1137)
> > > >
> > > > at
> > > > org.apache.felix.scr.impl.manager.ServiceTracker$AbstractTracked.
> > > > trackAdding(ServiceTracker.java:944)
> > > >
> > > > at
> > > > org.apache.felix.scr.impl.manager.ServiceTracker$AbstractTracked.
> > > > track(ServiceTracker.java:880)
> > > >
> > > > at
> > > > org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.serviceC
> > > > hanged(ServiceTracker.java:1168)
> > > >
> > > > at
> > > > org.apache.felix.scr.impl.BundleComponentActivator$ListenerInfo.s
> > > > erviceChanged(BundleComponentActivator.java:125)
> > > >
> > > > at
> > > > org.apache.felix.framework.EventDispatcher.invokeServiceListenerC
> > > > allback(EventDispatcher.java:990)
> > > >
> > > > at
> > > > org.apache.felix.framework.EventDispatcher.fireEventImmediately(E
> > > > ventDispatcher.java:838)
> > > >
> > > > at
> > > > org.apache.felix.framework.EventDispatcher.fireServiceEvent(Event
> > > > Dispatcher.java:545)
> > > >
> > > > at
> > > > org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4833
> > > > )
> > > > at
> > > > org.apache.felix.framework.Felix.registerService(Felix.java:3804)
> > > > at
> > > > org.apache.felix.framework.BundleContextImpl.registerService(Bund
> > > > leContextImpl.java:328)
> > > >
> > > > at
> > > > org.apache.sling.jcr.base.AbstractSlingRepositoryManager.register
> > > > Service(AbstractSlingRepositoryManager.java:218)
> > > >
> > > > at
> > > > org.apache.sling.jcr.base.AbstractSlingRepositoryManager.initiali
> > > > zeAndRegisterRepositoryService(AbstractSlingRepositoryManager.jav
> > > > a:541)
> > > >
> > > > at
> > > > org.apache.sling.jcr.base.AbstractSlingRepositoryManager.access$3
> > > > 00(AbstractSlingRepositoryManager.java:92)
> > > >
> > > > at
> > > > org.apache.sling.jcr.base.AbstractSlingRepositoryManager$4.run(Ab
> > > > stractSlingRepositoryManager.java:496)
> > > >
> > > > Caused by: javax.jcr.LoginException: Can neither derive user name
> > > > nor
> > > > principal names for bundle org.apache.sling.jcr.resource [154]
> > > > and sub
> > > > service observation
> > > > at
> > > > org.apache.sling.jcr.base.AbstractSlingRepository2.loginService(A
> > > > bstractSlingRepository2.java:387)
> > > >
> > > > at
> > > > org.apache.sling.jcr.resource.internal.JcrListenerBaseConfig.<ini
> > > > t>(JcrListenerBaseConfig.java:62)
> > > >
> > > > at
> > > > org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProv
> > > > ider.registerListeners(JcrResourceProvider.java:218)
> > > >
> > > > ... 41 more
> > > >
> > > >
> > > > The application deploys fine when not running against mongo, or
> > > > when
> > > > running against a clean mongo instance.
> > > >
> > > > The changes are located here for reference:
> > > >
> > > >
> https://github.com/redhataccess/pantheon/pull/219/files#diff-e93a9e4b7b62ab20d546f78f9ac775c8L33
> > > >
> > > > Any ideas on what could be going wrong?
> > > >
> > > > Regards,
> > > >
> > > > Carlos
> > > >
> > > >
> > > >
> > > > On Mon, Jan 27, 2020 at 4:57 AM Robert Munteanu <
> > > > [hidden email]>
> > > > wrote:
> > > >
> > > > > Happy to hear that you got it sorted out! Feel free to come
> > > > > back with
> > > > > more questions if you have any.
> > > > >
> > > > > Thanks,
> > > > > Robert
> > > > >
> > > > > On Fri, 2020-01-24 at 10:58 -0500, Carlos Munoz wrote:
> > > > > > Thanks Robert. I think we actually found out what was going
> > > > > > on: it
> > > > > > seems we
> > > > > > have a poorly defined index which was being deployed as part
> > > > > > of our
> > > > > > bundle
> > > > > > and which was interfering with some of the other indexes. As
> > > > > > soon as
> > > > > > we
> > > > > > removed it everything started working once again. We are
> > > > > > working on a
> > > > > > better index for the query right now.
> > > > > >
> > > > > > Really appreciate your willingness to help here... ++
> > > > > >
> > > > > > On Fri, Jan 24, 2020 at 5:03 AM Robert Munteanu <
> > > > > > [hidden email]>
> > > > > > wrote:
> > > > > >
> > > > > > > I tried building the app from source code but did not
> > > > > > > reproduce the
> > > > > > > problem. I guess this matches your experience - this
> > > > > > > happens only
> > > > > > > during an 'upgrade'.
> > > > > > >
> > > > > > > Can you please give me a set of steps to reproduce? Ideally
> > > > > > > without
> > > > > > > MongoDB, but if that's required leave it in :-)
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Robert
> > > > > > >
> > > > > > > On Wed, 2020-01-22 at 22:08 -0500, Carlos Munoz wrote:
> > > > > > > > I double checked and we do have the mapping. We copied
> > > > > > > > all the
> > > > > > > > provisioning
> > > > > > > > files from the commit you recommended earlier [1] and
> > > > > > > > deployed
> > > > > > > > like
> > > > > > > > that.
> > > > > > > >
> > > > > > > > In fact, you can see our provisioning files here: [2] We
> > > > > > > > are only
> > > > > > > > adding a
> > > > > > > > single file with our own bundle and configurations.
> > > > > > > >
> > > > > > > > [1]
> > > > > > > >
> > > > >
> https://github.com/apache/sling-org-apache-sling-starter/commit/c4f6e3b
> > > > > > > > [2]
> > > > > > > >
> > > > >
> https://github.com/redhataccess/pantheon/tree/upgrade-sling-bundles/pantheon-slingstart/src/main/provisioning
> > > > > > > > On Wed, Jan 22, 2020 at 4:54 PM Robert Munteanu <
> > > > > > > > [hidden email]>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > On Wed, 2020-01-22 at 16:16 -0500, Carlos Munoz wrote:
> > > > > > > > > > Thanks for the tip Daniel!
> > > > > > > > > >
> > > > > > > > > > Robert - we were able to successfully package the
> > > > > > > > > > sling
> > > > > > > > > > starter
> > > > > > > > > > with
> > > > > > > > > > the
> > > > > > > > > > latest definitions as you pointed, but when deploying
> > > > > > > > > > on top
> > > > > > > > > > of
> > > > > > > > > > an
> > > > > > > > > > existing
> > > > > > > > > > database we started getting a JCR error:
> > > > > > > > > >
> > > > > > > > > > javax.jcr.LoginException: Can neither derive user
> > > > > > > > > > name nor
> > > > > > > > > > principal
> > > > > > > > > > names
> > > > > > > > > > for bundle org.apache.sling.jcr.resource [152] and
> > > > > > > > > > sub
> > > > > > > > > > service
> > > > > > > > > > observation
> > > > > > > > > >
> > > > > > > > > > We don't get the same error when deploying on a fresh
> > > > > > > > > > database.
> > > > > > > > >
> > > > > > > > > It seems that you have some missing service user
> > > > > > > > > mappings.
> > > > > > > > > Those
> > > > > > > > > might
> > > > > > > > > be required by newer versions of the bundles that you
> > > > > > > > > just
> > > > > > > > > consumed. In
> > > > > > > > > the Sling Starter the current mapping is defined at
> > > > > > > > > [1].
> > > > > > > > >
> > > > > > > > > Does adding that as a configuration to your application
> > > > > > > > > help?
> > > > > > > > >
> > > > > > > > > Thanks,
> > > > > > > > > Robert
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > [1]:
> > > > > > > > >
> > > > >
> https://github.com/apache/sling-org-apache-sling-starter/blob/7eac121fc3f00c95ef5b8ac38133f6796a4a6c08/src/main/provisioning/sling.txt#L199-L202
> > > > >
> > > > > --
> > >
> > > Carlos A. Muñoz
> > >
> > > Manager, Software Engineering - Customer Platform
> > >
> > > Red Hat <https://www.redhat.com>
> > > <https://red.ht/sig>
> > >
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Error migrating to latest version of the bundles - Can neither derive user name nor principal names (was: Slow queries and unexpected results)

Carlos Munoz
In reply to this post by Robert Munteanu-2
You are right Robert, the error is seen at shutdown, even if it's similar.
I continued doing a bit of debugging to understand how sling is loading up
the different resources and had a quesiton: do configurations from the
repoinit files get installed in a specific order with relation to the
artifacts? do they get installed in different threads?
This might idicate if we are seeing a slow thread in there.
Thanks again for all the help.
Carlos


On Thu, Jan 30, 2020 at 4:47 AM Robert Munteanu <[hidden email]> wrote:

> Hi Carlos,
>
> Yes, this may be a timing issue.
>
> I could not follow the link you sent me for some reason. I think the
> build log is the one from [1]. If that is the case, the error is
> visible at shutdown, and probably does not have the same root cause.
>
> I'd still like to get some steps to reproduce - even if it's a change
> of 1 in 3, even if it depends on containers.
>
> Thanks,
> Robert
>
>
> [1]:
> https://builds.apache.org/job/Sling/job/sling-org-apache-sling-starter/job/master/104/console
>
> On Wed, 2020-01-29 at 21:27 -0500, Carlos Munoz wrote:
> > Robert, I checked the latest (master) pipeline build logs for the
> > starter
> > project:
> >
> >
> https://builds.apache.org/blue/organizations/jenkins/Sling%2Fsling-org-apache-sling-starter/detail/master/104/pipeline/24
> >
> > and found that there is a very similar error being reported
> > (different
> > principal and bundle), but same type of exception nonetheless.
> >
> > Carlos
> >
> >
> > On Wed, Jan 29, 2020 at 7:47 PM Carlos Munoz <[hidden email]>
> > wrote:
> >
> > > Robert, I wonder if this is a timing issue. I’m not sure I
> > > understand how
> > > Sling is loading bundles and configurations, but is it possible
> > > that it
> > > could load up a bundle which needs a specific configuration before
> > > said
> > > configuration has finished loading?
> > >
> > > I mention this because we are seeing the error now on a
> > > containerized
> > > environment where resources may be more virtualized than in a local
> > > environment, where the application seems to run without any issues.
> > >
> > > Regards,
> > >
> > > Carlos
> > >
> > > On Tue, Jan 28, 2020 at 10:11 PM Carlos Munoz <[hidden email]>
> > > wrote:
> > >
> > > > Hi Robert, I'm picking up this thread again since we briefly
> > > > talked about
> > > > this problem; allow me to recap:
> > > > We are attempting to migrate bundle versions for a Sling
> > > > application from
> > > > their Sling 11 versions to the latest stable versions. The
> > > > application is
> > > > running against an already populated mongo database and we are
> > > > seeing the
> > > > following exception when deploying.
> > > >
> > > > 29.01.2020 02:58:59.571 *ERROR* [Apache Sling Repository Startup
> > > > Thread
> > > > #4] ERROR: Bundle '160' EventDispatcher: Error during dispatch.
> > > > (org.apache.sling.api.SlingException: Can't create the JCR event
> > > > listener.)
> > > > org.apache.sling.api.SlingException: Can't create the JCR event
> > > > listener.
> > > > at
> > > > org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProv
> > > > ider.registerListeners(JcrResourceProvider.java:227)
> > > >
> > > > at
> > > > org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProv
> > > > ider.start(JcrResourceProvider.java:182)
> > > >
> > > > at
> > > > org.apache.sling.resourceresolver.impl.providers.ResourceProvider
> > > > Handler.activate(ResourceProviderHandler.java:74)
> > > >
> > > > at
> > > > org.apache.sling.resourceresolver.impl.providers.ResourceProvider
> > > > Tracker.activate(ResourceProviderTracker.java:360)
> > > >
> > > > at
> > > > org.apache.sling.resourceresolver.impl.providers.ResourceProvider
> > > > Tracker.register(ResourceProviderTracker.java:192)
> > > >
> > > > at
> > > > org.apache.sling.resourceresolver.impl.providers.ResourceProvider
> > > > Tracker.access$200(ResourceProviderTracker.java:59)
> > > >
> > > > at
> > > > org.apache.sling.resourceresolver.impl.providers.ResourceProvider
> > > > Tracker$1.addingService(ResourceProviderTracker.java:130)
> > > >
> > > > at
> > > > org.apache.sling.resourceresolver.impl.providers.ResourceProvider
> > > > Tracker$1.addingService(ResourceProviderTracker.java:106)
> > > >
> > > > at
> > > > org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(Ser
> > > > viceTracker.java:943)
> > > >
> > > > at
> > > > org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(Ser
> > > > viceTracker.java:871)
> > > >
> > > > at
> > > > org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked
> > > > .java:256)
> > > > at
> > > > org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:
> > > > 229)
> > > > at
> > > > org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(Servi
> > > > ceTracker.java:903)
> > > >
> > > > at
> > > > org.apache.felix.framework.EventDispatcher.invokeServiceListenerC
> > > > allback(EventDispatcher.java:990)
> > > >
> > > > at
> > > > org.apache.felix.framework.EventDispatcher.fireEventImmediately(E
> > > > ventDispatcher.java:838)
> > > >
> > > > at
> > > > org.apache.felix.framework.EventDispatcher.fireServiceEvent(Event
> > > > Dispatcher.java:545)
> > > >
> > > > at
> > > > org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4833
> > > > )
> > > > at
> > > > org.apache.felix.framework.Felix.registerService(Felix.java:3804)
> > > > at
> > > > org.apache.felix.framework.BundleContextImpl.registerService(Bund
> > > > leContextImpl.java:328)
> > > >
> > > > at
> > > > org.apache.felix.scr.impl.manager.AbstractComponentManager$3.regi
> > > > ster(AbstractComponentManager.java:906)
> > > >
> > > > at
> > > > org.apache.felix.scr.impl.manager.AbstractComponentManager$3.regi
> > > > ster(AbstractComponentManager.java:892)
> > > >
> > > > at
> > > > org.apache.felix.scr.impl.manager.RegistrationManager.changeRegis
> > > > tration(RegistrationManager.java:128)
> > > >
> > > > at
> > > > org.apache.felix.scr.impl.manager.AbstractComponentManager.regist
> > > > erService(AbstractComponentManager.java:959)
> > > >
> > > > at
> > > > org.apache.felix.scr.impl.manager.AbstractComponentManager.activa
> > > > teInternal(AbstractComponentManager.java:732)
> > > >
> > > > at
> > > > org.apache.felix.scr.impl.manager.DependencyManager$SingleStaticC
> > > > ustomizer.addedService(DependencyManager.java:1045)
> > > >
> > > > at
> > > > org.apache.felix.scr.impl.manager.DependencyManager$SingleStaticC
> > > > ustomizer.addedService(DependencyManager.java:999)
> > > >
> > > > at
> > > > org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.customiz
> > > > erAdded(ServiceTracker.java:1216)
> > > >
> > > > at
> > > > org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.customiz
> > > > erAdded(ServiceTracker.java:1137)
> > > >
> > > > at
> > > > org.apache.felix.scr.impl.manager.ServiceTracker$AbstractTracked.
> > > > trackAdding(ServiceTracker.java:944)
> > > >
> > > > at
> > > > org.apache.felix.scr.impl.manager.ServiceTracker$AbstractTracked.
> > > > track(ServiceTracker.java:880)
> > > >
> > > > at
> > > > org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.serviceC
> > > > hanged(ServiceTracker.java:1168)
> > > >
> > > > at
> > > > org.apache.felix.scr.impl.BundleComponentActivator$ListenerInfo.s
> > > > erviceChanged(BundleComponentActivator.java:125)
> > > >
> > > > at
> > > > org.apache.felix.framework.EventDispatcher.invokeServiceListenerC
> > > > allback(EventDispatcher.java:990)
> > > >
> > > > at
> > > > org.apache.felix.framework.EventDispatcher.fireEventImmediately(E
> > > > ventDispatcher.java:838)
> > > >
> > > > at
> > > > org.apache.felix.framework.EventDispatcher.fireServiceEvent(Event
> > > > Dispatcher.java:545)
> > > >
> > > > at
> > > > org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4833
> > > > )
> > > > at
> > > > org.apache.felix.framework.Felix.registerService(Felix.java:3804)
> > > > at
> > > > org.apache.felix.framework.BundleContextImpl.registerService(Bund
> > > > leContextImpl.java:328)
> > > >
> > > > at
> > > > org.apache.sling.jcr.base.AbstractSlingRepositoryManager.register
> > > > Service(AbstractSlingRepositoryManager.java:218)
> > > >
> > > > at
> > > > org.apache.sling.jcr.base.AbstractSlingRepositoryManager.initiali
> > > > zeAndRegisterRepositoryService(AbstractSlingRepositoryManager.jav
> > > > a:541)
> > > >
> > > > at
> > > > org.apache.sling.jcr.base.AbstractSlingRepositoryManager.access$3
> > > > 00(AbstractSlingRepositoryManager.java:92)
> > > >
> > > > at
> > > > org.apache.sling.jcr.base.AbstractSlingRepositoryManager$4.run(Ab
> > > > stractSlingRepositoryManager.java:496)
> > > >
> > > > Caused by: javax.jcr.LoginException: Can neither derive user name
> > > > nor
> > > > principal names for bundle org.apache.sling.jcr.resource [154]
> > > > and sub
> > > > service observation
> > > > at
> > > > org.apache.sling.jcr.base.AbstractSlingRepository2.loginService(A
> > > > bstractSlingRepository2.java:387)
> > > >
> > > > at
> > > > org.apache.sling.jcr.resource.internal.JcrListenerBaseConfig.<ini
> > > > t>(JcrListenerBaseConfig.java:62)
> > > >
> > > > at
> > > > org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProv
> > > > ider.registerListeners(JcrResourceProvider.java:218)
> > > >
> > > > ... 41 more
> > > >
> > > >
> > > > The application deploys fine when not running against mongo, or
> > > > when
> > > > running against a clean mongo instance.
> > > >
> > > > The changes are located here for reference:
> > > >
> > > >
> https://github.com/redhataccess/pantheon/pull/219/files#diff-e93a9e4b7b62ab20d546f78f9ac775c8L33
> > > >
> > > > Any ideas on what could be going wrong?
> > > >
> > > > Regards,
> > > >
> > > > Carlos
> > > >
> > > >
> > > >
> > > > On Mon, Jan 27, 2020 at 4:57 AM Robert Munteanu <
> > > > [hidden email]>
> > > > wrote:
> > > >
> > > > > Happy to hear that you got it sorted out! Feel free to come
> > > > > back with
> > > > > more questions if you have any.
> > > > >
> > > > > Thanks,
> > > > > Robert
> > > > >
> > > > > On Fri, 2020-01-24 at 10:58 -0500, Carlos Munoz wrote:
> > > > > > Thanks Robert. I think we actually found out what was going
> > > > > > on: it
> > > > > > seems we
> > > > > > have a poorly defined index which was being deployed as part
> > > > > > of our
> > > > > > bundle
> > > > > > and which was interfering with some of the other indexes. As
> > > > > > soon as
> > > > > > we
> > > > > > removed it everything started working once again. We are
> > > > > > working on a
> > > > > > better index for the query right now.
> > > > > >
> > > > > > Really appreciate your willingness to help here... ++
> > > > > >
> > > > > > On Fri, Jan 24, 2020 at 5:03 AM Robert Munteanu <
> > > > > > [hidden email]>
> > > > > > wrote:
> > > > > >
> > > > > > > I tried building the app from source code but did not
> > > > > > > reproduce the
> > > > > > > problem. I guess this matches your experience - this
> > > > > > > happens only
> > > > > > > during an 'upgrade'.
> > > > > > >
> > > > > > > Can you please give me a set of steps to reproduce? Ideally
> > > > > > > without
> > > > > > > MongoDB, but if that's required leave it in :-)
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Robert
> > > > > > >
> > > > > > > On Wed, 2020-01-22 at 22:08 -0500, Carlos Munoz wrote:
> > > > > > > > I double checked and we do have the mapping. We copied
> > > > > > > > all the
> > > > > > > > provisioning
> > > > > > > > files from the commit you recommended earlier [1] and
> > > > > > > > deployed
> > > > > > > > like
> > > > > > > > that.
> > > > > > > >
> > > > > > > > In fact, you can see our provisioning files here: [2] We
> > > > > > > > are only
> > > > > > > > adding a
> > > > > > > > single file with our own bundle and configurations.
> > > > > > > >
> > > > > > > > [1]
> > > > > > > >
> > > > >
> https://github.com/apache/sling-org-apache-sling-starter/commit/c4f6e3b
> > > > > > > > [2]
> > > > > > > >
> > > > >
> https://github.com/redhataccess/pantheon/tree/upgrade-sling-bundles/pantheon-slingstart/src/main/provisioning
> > > > > > > > On Wed, Jan 22, 2020 at 4:54 PM Robert Munteanu <
> > > > > > > > [hidden email]>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > On Wed, 2020-01-22 at 16:16 -0500, Carlos Munoz wrote:
> > > > > > > > > > Thanks for the tip Daniel!
> > > > > > > > > >
> > > > > > > > > > Robert - we were able to successfully package the
> > > > > > > > > > sling
> > > > > > > > > > starter
> > > > > > > > > > with
> > > > > > > > > > the
> > > > > > > > > > latest definitions as you pointed, but when deploying
> > > > > > > > > > on top
> > > > > > > > > > of
> > > > > > > > > > an
> > > > > > > > > > existing
> > > > > > > > > > database we started getting a JCR error:
> > > > > > > > > >
> > > > > > > > > > javax.jcr.LoginException: Can neither derive user
> > > > > > > > > > name nor
> > > > > > > > > > principal
> > > > > > > > > > names
> > > > > > > > > > for bundle org.apache.sling.jcr.resource [152] and
> > > > > > > > > > sub
> > > > > > > > > > service
> > > > > > > > > > observation
> > > > > > > > > >
> > > > > > > > > > We don't get the same error when deploying on a fresh
> > > > > > > > > > database.
> > > > > > > > >
> > > > > > > > > It seems that you have some missing service user
> > > > > > > > > mappings.
> > > > > > > > > Those
> > > > > > > > > might
> > > > > > > > > be required by newer versions of the bundles that you
> > > > > > > > > just
> > > > > > > > > consumed. In
> > > > > > > > > the Sling Starter the current mapping is defined at
> > > > > > > > > [1].
> > > > > > > > >
> > > > > > > > > Does adding that as a configuration to your application
> > > > > > > > > help?
> > > > > > > > >
> > > > > > > > > Thanks,
> > > > > > > > > Robert
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > [1]:
> > > > > > > > >
> > > > >
> https://github.com/apache/sling-org-apache-sling-starter/blob/7eac121fc3f00c95ef5b8ac38133f6796a4a6c08/src/main/provisioning/sling.txt#L199-L202
> > > > >
> > > > > --
> > >
> > > Carlos A. Muñoz
> > >
> > > Manager, Software Engineering - Customer Platform
> > >
> > > Red Hat <https://www.redhat.com>
> > > <https://red.ht/sig>
> > >
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Error migrating to latest version of the bundles - Can neither derive user name nor principal names (was: Slow queries and unexpected results)

Bertrand Delacretaz
Hi,

On Sun, Feb 2, 2020 at 4:50 AM Carlos Munoz <[hidden email]> wrote:
> ...do configurations from the
> repoinit files get installed in a specific order with relation to the
> artifacts?...

The repoinit configs are applied by a single
SlingRepositoryInitializer [1] service which is implemented by
org.apache.sling.jcr.repoinit.impl.RepositoryInitializer [2].

The execution order of the SlingRepositoryInitializer services is
based on their service rankings [4] and the RepositoryInitializer
processes its configurations in the order in which they are provided
by the OSGi framework, sequentially.

All this happens before the SlingRepository service is made available [3]

The logs should help understand what's going on but IIRC it all
happens in a single thread.

-Bertrand

[1] https://sling.apache.org/documentation/bundles/repository-initialization.html
[2] https://github.com/apache/sling-org-apache-sling-jcr-repoinit/blob/master/src/main/java/org/apache/sling/jcr/repoinit/impl/RepositoryInitializer.java
[3] https://github.com/apache/sling-org-apache-sling-jcr-base/blob/e8fe5e004b5af1802bb2a76dbbb583a437f848ee/src/main/java/org/apache/sling/jcr/base/AbstractSlingRepositoryManager.java#L511
[4] https://github.com/apache/sling-org-apache-sling-jcr-base/blob/e8fe5e004b5af1802bb2a76dbbb583a437f848ee/src/main/java/org/apache/sling/jcr/base/AbstractSlingRepositoryManager.java#L581
Reply | Threaded
Open this post in threaded view
|

Re: Error migrating to latest version of the bundles - Can neither derive user name nor principal names (was: Slow queries and unexpected results)

Carlos Munoz
Thanks Bertrand! I will continue my fact finding mission here :)

Regards,

Carlos

On Tue, Feb 4, 2020 at 4:31 AM Bertrand Delacretaz <[hidden email]>
wrote:

> Hi,
>
> On Sun, Feb 2, 2020 at 4:50 AM Carlos Munoz <[hidden email]> wrote:
> > ...do configurations from the
> > repoinit files get installed in a specific order with relation to the
> > artifacts?...
>
> The repoinit configs are applied by a single
> SlingRepositoryInitializer [1] service which is implemented by
> org.apache.sling.jcr.repoinit.impl.RepositoryInitializer [2].
>
> The execution order of the SlingRepositoryInitializer services is
> based on their service rankings [4] and the RepositoryInitializer
> processes its configurations in the order in which they are provided
> by the OSGi framework, sequentially.
>
> All this happens before the SlingRepository service is made available [3]
>
> The logs should help understand what's going on but IIRC it all
> happens in a single thread.
>
> -Bertrand
>
> [1]
> https://sling.apache.org/documentation/bundles/repository-initialization.html
> [2]
> https://github.com/apache/sling-org-apache-sling-jcr-repoinit/blob/master/src/main/java/org/apache/sling/jcr/repoinit/impl/RepositoryInitializer.java
> [3]
> https://github.com/apache/sling-org-apache-sling-jcr-base/blob/e8fe5e004b5af1802bb2a76dbbb583a437f848ee/src/main/java/org/apache/sling/jcr/base/AbstractSlingRepositoryManager.java#L511
> [4]
> https://github.com/apache/sling-org-apache-sling-jcr-base/blob/e8fe5e004b5af1802bb2a76dbbb583a437f848ee/src/main/java/org/apache/sling/jcr/base/AbstractSlingRepositoryManager.java#L581
>
>
12