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
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
Hello, fellow Apache enthusiast. Thanks for your participation, and
interest in, the projects of the Apache Software Foundation.
I wanted to remind you that the Call For Papers (CFP) for ApacheCon
North America, and Apache: Big Data North America, closes in less than a
month. If you've been
Couldn't this be simplified to simply stating that the sticky session cookie
only lasts for x amount of seconds?
I like this idea, but I'm not sure this is really a sling solution rather than
an API management or proxy solution. When you take an instance out of the pool,
you would need to
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
> 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
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