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 thus the latest data. When not 1 second, it takes 2 seconds exactly. If you increase load on the server, the likelihood of taking 2 seconds increases, and you also begin to see it take exactly 3 seconds in some rare cases. Increasing load increases the number of seconds before a "sync," however it's always near-exactly a second interval. It seems impossible for this to be a natural coincidence - I smell a setting somewhere (or perhaps hardcode value) which is telling Sling to check the latest JCR revision on 1 second intervals. When that window can't be hit, it checks on the next second interval, and so on. Is there a Sling dev who can tell me whether this is configurable? I have a load of questions about this discovery: - Am I wrong? (I'll be shocked) - Perhaps we can speed it up? - What event is causing it to "miss the window" and wait until the next 1 second synch interval? - If we do decrease the interval, will that just increase the likelihood of taking more intervals anyhow? - Is there a maximum number of 1 second intervals before the things just gets the latest?? progress. -- View this message in context: http://apache-sling.73963.n3.nabble.com/Not-sticky-sessions-with-Sling-tp4069530p4069711.html Sent from the Sling - Users mailing list archive at Nabble.com.
