Hi Carlos,
I think I found a solution, can you please check my latest comment on
SLING-9118 [1] ?
Thanks!
Robert
[1]:
https://issues.apache.org/jira/browse/SLING-9118?focusedCommentId=17073183&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17073183
On Thu, 2020-0
Hi Robert,
I've found that it's not as simple. There is still some factor of
randomness attached to this issue. After doing the bisect more times, I've
found that commit 0a13d3467aa78b46ec33ae5687418685f90a9e12 seems to work
*most* of the time. There are still times where I get the error, but it i
That's good info, thank you! I've added some details to the Jira issue.
I tried reverting the commits I suspect are at fault
- https://github.com/apache/sling-org-apache-sling-jcr-base/commit/6f5771a
- https://github.com/apache/sling-org-apache-sling-jcr-base/commit/3de2b9f
But that failed due to
I went through the bisect process and I got the first bad commit:
commit bb1e10d97f3c163fb87917ea782afff674050891
Author: Eric Norman
Date: Sun Dec 16 12:33:08 2018 -0800
switch to released JCR Base 3.0.6
(I tried it a couple of times just to be sure)
I tried running our app with the com
Hi Carlos,
Apologies for the delay ...
What I was thinking of doing myself, but did not have the time is the
following
1. Find a version of Sling for which the scenario in SLING-9118 works.
Perhaps Sling Starter 11 is a good start.
2. Run a `git bisect` check between sling starter 11 and the cur
Hi Robert,
Just a friendly ping about this issue :)
We could try to submit a fix with some potential guidance from you. For
example, which of the many Sling bundles should we start looking at?
Regards,
Carlos
On Wed, Feb 26, 2020 at 7:24 AM Carlos Munoz wrote:
> Thanks Robert. As always you
Thanks Robert. As always your help is appreciated.
On Fri, Feb 21, 2020 at 6:28 PM Robert Munteanu wrote:
> Thanks, Ben,
>
> I added a bit more detail, based on our mailing list conversations.
> I'll have limited access in the next two weeks, but if no one picks it
> up I'll look into it when I
Thanks, Ben,
I added a bit more detail, based on our mailing list conversations.
I'll have limited access in the next two weeks, but if no one picks it
up I'll look into it when I get back.
Thanks,
Robert
On Fri, 2020-02-21 at 11:01 -0500, Ben Radey wrote:
> I went ahead and created
> https://i
I went ahead and created https://issues.apache.org/jira/browse/SLING-9118
for this. Although the ultimate goal here is containerization, I neglected
to include any details to that effect in the ticket, since the behavior is
reproducible without that being a complicating factor.
On Thu, Feb 20, 202
On Mon, 2020-02-17 at 13:45 -0500, Ben Radey wrote:
> I am following along conceptually - I want to make sure I understand
> what's
> being described.
>
> Let's say Sling Instance A starts successfully the first time. If we
> restart Sling Instance A, we expect subsequent restarts to also
> succee
Yes, I confirm that these steps reproduce the problem for me. Can you
please file an issue under https://issues.apache.org/jira/browse/SLING
so we can better track this?
On Mon, 2020-02-17 at 11:24 -0500, Carlos Munoz wrote:
> Thanks for the information Robert.
>
> To replicate the issue all I ne
I am following along conceptually - I want to make sure I understand what's
being described.
Let's say Sling Instance A starts successfully the first time. If we
restart Sling Instance A, we expect subsequent restarts to also succeed,
without removing the sling directory.
Now let's say Sling Insta
Thanks for the information Robert.
To replicate the issue all I needed was a mongodb (I used a full replica
set, see my instructions in a previous email about how to get one going
using podman) and a single process running sling.
The problem does happen when I do the following:
2. Start Sling in
On Fri, 2020-02-14 at 15:41 -0500, Carlos Munoz wrote:
> Robert I managed to replicate the issue in a local, non-containerized
> environment (!!!).
>
> The problem seems to be when the database is kept but the 'sling'
> directory
> is cleared out across restarts (as it is for us when the container
Hi Carlos,
On Fri, 2020-02-14 at 15:17 -0500, Carlos Munoz wrote:
> Thanks Robert (and once again I can't stress enough how grateful I am
> for
> all your help).
>
> Right now we deploy our container with the expectation that the mongo
> db is
> the only necessary state we need to keep; everythin
Robert I managed to replicate the issue in a local, non-containerized
environment (!!!).
The problem seems to be when the database is kept but the 'sling' directory
is cleared out across restarts (as it is for us when the container goes
away). As I said before this doesn't seem to be a problem wit
Thanks Robert (and once again I can't stress enough how grateful I am for
all your help).
Right now we deploy our container with the expectation that the mongo db is
the only necessary state we need to keep; everything else is throwaway.
This means that a totally new container connected to the mon
Hi Carlos,
On Fri, 2020-02-14 at 11:50 -0500, Carlos Munoz wrote:
> Thanks Bertrand. How can I run Sling with DEBUG-level logs for every
> bundle? I tried passing a few configuration arguments from the
> command line
> but nothing seemed to work.
Try configuring the LogManager to debug at
ht
Thanks Bertrand. How can I run Sling with DEBUG-level logs for every
bundle? I tried passing a few configuration arguments from the command line
but nothing seemed to work.
Carlos
On Fri, Feb 14, 2020 at 4:32 AM Bertrand Delacretaz
wrote:
> Hi,
>
> On Thu, Feb 13, 2020 at 8:47 PM Carlos Munoz
Hi,
On Thu, Feb 13, 2020 at 8:47 PM Carlos Munoz wrote:
> ...Is there a reason why the Jcr repository could be restarting? And what
> class could we start looking into to debug if this is the case?...
It's not uncommon to see extra restarts of OSGi components at startup,
for various reasons.
Th
Here are the steps we follow to create a replica set in podman. We use a
pod to hold all the mongo instances, which is a concept not likely present
in docker:
1. Create a pod
podman pod create --name mongo-replica-set -p 30001 -p 30002 -p 30003
2. Create 3 mongo containers in the pod (the mi
On Mon, 2020-02-10 at 17:16 -0500, Carlos Munoz wrote:
> Thanks Sergiu, I will give that a shot (removing that configuration
> item I
> mean).
>
> I actually managed to replicate some of the weird symptoms locally.
> It
> required me to set up a local mongo replica set. (I used podman, so
> let me
Thanks Sergiu, I will give that a shot (removing that configuration item I
mean).
I actually managed to replicate some of the weird symptoms locally. It
required me to set up a local mongo replica set. (I used podman, so let me
know if you need the steps I followed to do this). The first time I ra
This provisioning snippet triggered it for me, but in a more customized
instance, so I'm not sure if it is enough by itself to cause issues:
[configurations]
org.apache.sling.auth.form.FormAuthenticationHandler
form.login.form="/login"
On 2/10/20 4:48 AM, Robert Munteanu wrote:
> I t
I tried to reproduce this but I could not, unfortunately. What I did
was
1. Build the latest Sling Starter locally
2. Started up MongoDB
$ docker run --name mongo-sling -p 27017:27017 -d mongo:3.6
3. Started up Sling
$ java -jar target/org.apache.sling.starter-12-SNAPSHOT.jar
-Dsling.run.modes=
Thanks Robert. We tried ensuring only a single Sling pod was hitting the
database at one time with some strange results:
The first time it runs (against an empty database) everything goes well:
the database is populated and the pod comes up with no issues.
We then bring this pod down, and then tr
On Wed, 2020-02-05 at 21:17 -0500, Carlos Munoz wrote:
> Hi all,
>
> I think I have a theory for our issues here, and it may have to do
> with the
> fact that we are running on a heavily containerized environment
> (kubernetes). I wanted to consult with the community experts to see
> what
> you th
Hi all,
I think I have a theory for our issues here, and it may have to do with the
fact that we are running on a heavily containerized environment
(kubernetes). I wanted to consult with the community experts to see what
you thought.
The way our container platform works on an update is that it wi
Thanks Bertrand! I will continue my fact finding mission here :)
Regards,
Carlos
On Tue, Feb 4, 2020 at 4:31 AM Bertrand Delacretaz
wrote:
> Hi,
>
> On Sun, Feb 2, 2020 at 4:50 AM Carlos Munoz wrote:
> > ...do configurations from the
> > repoinit files get installed in a specific order with r
Hi,
On Sun, Feb 2, 2020 at 4:50 AM Carlos Munoz 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.sl
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
artifact
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 Dockerfi
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 - e
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)
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 err
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 d
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
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
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, 20
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.c
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.j
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 b
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 wrot
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 wrote:
> Hi Carlos,
>
> On Wed, 2020-01-22 at 07:11 -0500, Carlos Munoz wrote:
> > Thanks for the reply Robert. We are using th
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
> releas
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.
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 app
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 fol
48 matches
Mail list logo
