[Glass] [3.3.1]: Waiting for a connection is blocked ... no timeout at all is considered

[Dale Henrichs via Glass]

If these are changes that deserve to be shared (including the bugfix) a 
pull request with the relevant fixes would be much appreciated ... there 
are only so many hours in the day for me to work and the whole point of 
using GitHub is to make it much easier for users to contribute ...

Personally I would rather spend the time teaching you guys how to submit 
pull requests than have to fix all of the outsanding bugs all by myself:)

Dale


On 10/26/16 10:50 AM, Marten Feldtmann via Glass wrote:
>
> Ok, I notice, that seconds are not enough ... timeout has to be 
> calculated on ms time - but ok not that difficult.
>
> Thanks, I'll implement this ..
>
> Marten
>
>> Marten Feldtmann via Glass <glass at lists.gemtalksystems.com> hat am 
>> 26. Oktober 2016 um 19:39 geschrieben:
>>
>> That means something like:
>>
>>
>> ZnServer>>acceptWaitTimeout
>>
>> acceptWaitTimeout
>>     "How many seconds to wait for a server socket listening for an 
>> accept ?"
>>
>>         | utcSeconds2001 wishedIntervallInSeconds |
>>
>>         wishedIntervallInSeconds := 30.
>>         utcSeconds2001 := DateAndTime now asSeconds asInteger.
>>         ^(utcSeconds2001 / wishedIntervallInSeconds) truncated * 
>> wishedIntervallInSeconds + wishedIntervallInSeconds - utcSeconds2001
>>
>>
>>> Paul Baumann <plbaumann at gmail.com> hat am 26. Oktober 2016 um 17:42 
>>> geschrieben:
>>>
>>> The fix you made would reduce the accumulation of transactions that 
>>> gs needs to resolve views and potential conflicts through. The 
>>> accumulation would have been high when some gems are very active 
>>> with commits while others are mostly waiting (and holding an old 
>>> view). It was the mostly-idle gems causing accumulation.
>>>
>>> You may notice:
>>> - Quicker continueTransaction
>>> - shorter login time
>>> - far fewer gems receive SigAbort
>>> - cr backlogs resolve quicker
>>> - fewer transactions since last checkpoint
>>> - extents updated more frequently
>>> - backups are more reliable
>>> - restores require fewer tranlog files
>>>
>>> I'm big on performance tuning, here is another hint. Gs is also 
>>> aided by having many gems starting with the same view point rather 
>>> than each having separate views. Change your timeout time so that it 
>>> expires at a time interval that the others would also target. Rather 
>>> than a fixed 15 second timeout, compute a timeout from current 
>>> system time that other gems might also compute to timeout on. A 15 
>>> second target interval might be a bit aggressive depending on your 
>>> commit rates. Perhaps target expiry at a 30 second interval to 
>>> further improve odds that gems will timeout-abort at the same moment.
>>>
>>> Paul Baumann
>>>
>
>> _______________________________________________ Glass mailing list 
>> Glass at lists.gemtalksystems.com 
>> http://lists.gemtalksystems.com/mailman/listinfo/glass
>
>
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20161026/7968cd0c/attachment.html>