Re: Not-sticky sessions with Sling?

Hi Lance, On Wed, Jan 18, 2017 at 11:21 PM, lancedolan wrote: > ...Bertrand, I'd feel selfish taking you up on your offer to build this for > me. > Yet I'd be a fool to not at least partner with you to get it done. Should we > correspond outside this mail list?... I

RE: Not-sticky sessions with Sling?

Jason Bailey wrote > Couldn't this be simplified to simply stating that the sticky session > cookie only lasts for x amount of seconds? WHOAAA!! Bertrand, probably hold the phone on everything else I suggested in my last post - this solution is insanely simple, embarrassingly obvious in

Re: Not-sticky sessions with Sling?

Chetan is making things crystal clear for us. Our next steps are: 1) Learn what the MAXIMUM "inconsistency window" could be. Is it possible to delay past 5 seconds? 10 Seconds? 60? What determines this? Only server load? I'll ask on the JCR forum and also experiment. 2) Design and test a

RE: Not-sticky sessions with Sling?

To: users@sling.apache.org Subject: Re: Not-sticky sessions with Sling? > Each time we remove an > instance, those users will go to a new Sling instance, and experience > the inconsistency. Each time we add an instance, we will invalidate > all stickiness and users will get re-assig

Re: Not-sticky sessions with Sling?

On Wed, Jan 18, 2017 at 12:48 PM, Chetan Mehrotra wrote: > ...there is a "asyncDelay" setting in DocumentNodeStore which > defaults to 1 sec. Currently its not possible to modify it via OSGi > config though But Lance could patch [1] to experiment with different

Re: Not-sticky sessions with Sling?

> Each time we remove an > instance, those users will go to a new Sling instance, and experience the > inconsistency. Each time we add an instance, we will invalidate all > stickiness and users will get re-assigned to a new Sling instance, and > experience the inconsistency. I can understand

Re: Not-sticky sessions with Sling?

Hi Lance, On Wed, Jan 18, 2017 at 2:43 AM, lancedolan wrote: > ...It pretty much always takes 1 second exactly for a Sling instance to get > the > latest revision, and thus the latest data. When not 1 second, it takes 2 > seconds exactly I don't know enough about Oak

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?

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: 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?

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?

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?

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?

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, On Mon, Jan 16, 2017 at 9:16 PM, lancedolan wrote: > ...this probably shoots down our entire Sling > proof of concept project... That would be a pity, as I suppose you're starting to like Sling now ;-) > ...Is there any way > to force all reads to read the most

Re: Not-sticky sessions with Sling?

On Tue, Jan 17, 2017 at 1:46 AM, lancedolan wrote: > It's ironic that the cluster which involves multiple datastores (tar), and > thus should have a harder time being consistent, is the one that can > accomplish consistency.. Thats not how it is. Cluster which involves

Re: Not-sticky sessions with Sling?

This is really disappointing for us. Through this revisioning, Oak has turned a datastore that is consistent by default into a datastore that is not :p It's ironic that the cluster which involves multiple datastores (tar), and thus should have a harder time being consistent, is the one that can

Re: Not-sticky sessions with Sling?

On Sat, Jan 14, 2017 at 2:08 AM, lancedolan wrote: > To be honest, however, I don't understand fully > what you said in your last post and I also know that AEM 6.1 can do what I'd > like, which is really just Sling+Oak. If they can do it, I don't understand > why we can't.

Re: Not-sticky sessions with Sling?

Alright, this is a deal breaker for our business (if sling absolutely requires sticky sessions). I hope you're not offended that I'm not 100% convinced yet. I understand you do development on the sling project and are well qualified on the topic. To be honest, however, I don't understand fully

Re: Not-sticky sessions with Sling?

On Fri, Jan 13, 2017 at 12:20 AM, lancedolan wrote: > In an architecture with > only one Mongo instance, the moment one instance writes to the JCR, another > instance will read the same data and agree consistently. It seems to me that > the JCR state is strongly consistent.

Re: Not-sticky sessions with Sling?

Chetan, I'd like to confirm to what degree that is true for our proposed architecture. It seems that only the OSGI configurations and bundles would be "eventually consistent." It seems the only "state" that is stored in Sling instances are OSGI configurations and OSGI bundles. Everything else is

Re: Not-sticky sessions with Sling?

If you are running a cluster with Sling on Oak/Mongo then sticky sessions would be required due to eventual consistent nature of repository. Changes done on one cluster node would not be immediately visible on other cluster node. Hence to provide a consistent user experience sticky sessions would