Re: Not-sticky sessions with Sling?

Hi Lance Ok, so being as it is — eventual consistent repo replicating the Oak login token and not able to use sticky sessions, I suggest you go with something else, which does *not* need the repository for persistence. This means you might want to investigate your own authentication handler or

Re: Not-sticky sessions with Sling?

Ok First of all - I GENUINELY appreciate the heck out of your time, and patience!! ... and THIS is really interesting: If THIS is true: chetan mehrotra wrote > If you are running a cluster with Sling on Oak/Mongo then sticky > sessions would be required due to eventual consistent nature of

Re: Not-sticky sessions with Sling?

HI Lance, 2017-01-17 19:19 GMT+01:00 lancedolan : > ... > > If "being eventual" is the reason we can't go stateless, then how is adobe > getting away with it if we know their architecture is also eventual?? What > am I missing? I understand that the documentation I linked

RE: Not-sticky sessions with Sling?

not sure if this is of any help for your usecase - but do you need the full JCR features and complexity underneath sling, or only a sling cluster + storage in mongodb? if you need only basic resource read and write features via the Sling API you might bypass JCR completely and directly use a

Re: Not-sticky sessions with Sling?

My bad: CAP = consistency, availability and partition-tolerance. Jörg 2017-01-17 19:35 GMT+01:00 Jörg Hoh : > HI Lance, > > 2017-01-17 19:19 GMT+01:00 lancedolan : > >> ... >> >> If "being eventual" is the reason we can't go stateless, then how is

Re: Not-sticky sessions with Sling?

Bertrand Delacretaz wrote > That would be a pity, as I suppose you're starting to like Sling now ;-) Ma you have no idea haha! I've got almost every dev in the office all excited about this now haha. However, it seems our hands are tied. I wrote local consistency test scripts which POST and

RE: Not-sticky sessions with Sling?

Thi is tempting, but I know in my dev-instinct that we won't have the time to solve all the unsolved in that effort. Thank you for suggesting though :) -- View this message in context: http://apache-sling.73963.n3.nabble.com/Not-sticky-sessions-with-Sling-tp4069530p4069712.html Sent from

Re: Not-sticky sessions with Sling?

lancedolan wrote > I must know what determines the duration of this revision catch-up time > ... While I don't know where to look in src code to answer this, I did run a very revealing experiment. It pretty much always takes 1 second exactly for a Sling instance to get the latest revision, and

Re: Sling Model and Request Parameters

Hi everyone, There was a discussion back on Oct 11, 2016 about an extra injector+annotation to inject request parameters into Sling models. I couldn’t find any JIRA issue about that, and I haven’t seen anything like that in the code so I don’t think this is currently in progress. I just joined