@obi068 were you waiting for me to merge/review the pull request? I read the code and it seems to be a fair change. If you want me to press the merge button, I will:)

I have some doubts about this change. This means the gem will only retry for a maximum of 550ms before failing the request entirely. I think that is really too short if the reason for the retry was a 'session lock denied'. In those cases, this request will fail really quickly. If the concurrent request takes longer than 500ms, we will quickly end up in a 'too many retries' for this request.

Now, I agree that once a retry delay of 1s is reached, we should stick to retrying every second. The code right now started to wait for 10s and more, which indeed was never really useful.

@jbrichau and @obi068, I am queuing up 3.1.3.2-gs for release, but there seems to be controversy with this particular change, I will hold off until we have a resolution/consensus ... If the 3.1.3.2-gs link goes nowhere for you, this release is basically pushing out support for GemServers: Issue #54 and Issue #62 ... @jbrichau if you have a slightly better algorithm to suggest I can include I can do the pushes and pulls ...

At the moment i am using count := count + 10 ,
which gives me a delay of

10 + 110 +210 +310 +410 +510 +610 +710 +810 +910 = 4600 ms

• (10 * response time approx. 100ms) = 5600 ms max wait time

Best option would be config parameters for retryCount and retryDelay.

Gerhard

On Fri, Apr 3, 2015 at 2:02 AM, Dale Henrichs [email protected]
wrote:

@jbrichau https://github.com/jbrichau and @obi068
https://github.com/obi068, I am queuing up 3.1.3.2-gs
https://github.com/GsDevKit/Seaside31/releases/edit/untagged-edb4ceda33cf7ee8b1a0
for release, but there seems to be controversy with this particular change,
I will hold off until we have a resolution/consensus ... If the 3.1.3.2-gs
link goes nowhere for you, this release is basically pushing out support
for GemServers: Issue #54
#54 and Issue #62
#62 ... @jbrichau
https://github.com/jbrichau if you have a slightly better algorithm to
suggest I can include I can do the pushes and pulls ...

—
Reply to this email directly or view it on GitHub
#60 (comment).

That's "count + 100", which seems more reasonable to me.

The best option would indeed be to provide parameters, though there's no logical place to put them in Seaside at the moment (they only make sense in GS).

I would vote to set it to +100 (instead of +1) for now. The multiplication was a bit over the top.

We might see some users getting 'too many retries', so we should specify this for the version.

No this would mean:

On Fri, Apr 3, 2015 at 10:33 AM, Johan Brichau [email protected]
wrote:

That's "count + 100", which seems more reasonable to me.

The best option would indeed be to provide parameters, though there's no
logical place to put them in Seaside at the moment (they only make sense in
GS).

I would vote to set it to +100 (instead of +1) for now. The multiplication
was a bit over the top.

We might see some users getting 'too many retries', so we should specify
this for the version.

—
Reply to this email directly or view it on GitHub
#60 (comment).

count + 100 would mean:
100 + 1010 + 2010 + 3010 + 4010 + 5010 + 6010 + 7010 +8010 + 9010 = 45190 ms

Gerhard

On Fri, Apr 3, 2015 at 4:53 PM, Gerhard Obermann [email protected] wrote:

No this would mean:

On Fri, Apr 3, 2015 at 10:33 AM, Johan Brichau [email protected]
wrote:

That's "count + 100", which seems more reasonable to me.

The best option would indeed be to provide parameters, though there's no
logical place to put them in Seaside at the moment (they only make sense in
GS).

I would vote to set it to +100 (instead of +1) for now. The
multiplication was a bit over the top.

We might see some users getting 'too many retries', so we should specify
this for the version.

—
Reply to this email directly or view it on GitHub
#60 (comment).

Turns out that there are more bugfixes queued up for 3.1.3.2-gs than I originally thought ...

Yes, you are right. I got confused between the delay and the count there.
Though I still think this can be too short for applications that sometimes have longer requests. The advantage of *10 was that it's not linear but the disadvantage is that it's indeed too long too fast.

I propose a different strategy where the timings are specified manually in pull request #67