[Glass] [GLASS] Seaside - growing extent - normal?

[Lawrence Kellogg via Glass]

> On Apr 6, 2015, at 8:25 PM, Dale Henrichs <dale.henrichs at gemtalksystems.com> wrote:
> 
> Okay,
> 
> It looks like I assumed that you were using Seaside 3.1 and you must be using Seaside3.0 ... I don't think that things have actually changed in this area since Seaside 3.0, but it _is_ something to be aware of ... now...
> 
> Given that the code (in Seaside-GemStone-Core-dkh.70) in WARcLastAccessEntry>>isExpired:updating: (could you verify that your version is the same?):
> 
> isExpired: timeout updating: updating
>   | value |
>   ^ (value := self counter value) > lastCount
>     ifTrue: [ 
>       "accessed since last scan"
>       updating
>         ifTrue: [ 
>           lastCount := value.
>           time := Time totalSeconds ].
>       false ]
>     ifFalse: [ Time totalSeconds - time > timeout ]
> 
> it appears that we have only done a expiration scan (updating = true) only once and I have been under the impression that we've done at least two full scans (the scan before the backup and the scan after we discovered that we had not recovered any data) ... oh well ...
> 
> I think that the `time` in this entry corresponds to the date: `2014-11-11T22:42:08+00:00` (Time totalSeconds returns seconds since January 1, 1901) and that implies that the last scan was done a year ago? Unless the code is very different or ...  What does `date` return from the linux shell?
> 
> The next step is to see if the code is working like I expect it to. The code below simulates and expiration scan, and then see how the entry has changed along with couple of other things:
> 
>   | app cache objectsByKey assoc expired1 expired2 timeout lastAccessTable entry |
>   app := WADispatcher default handlers at: 'UserInformationInterface'.
>   cache := app cache.
>   objectsByKey := cache instVarAt: 3.
>   assoc := objectsByKey associationAt: '5jTYOuLPzkOYLv4d'.
>   lastAccessTable := cache expiryPolicy instVarNamed: #'lastAccessTable'.
>   entry := lastAccessTable at: '5jTYOuLPzkOYLv4d'.
>   timeout := cache expiryPolicy.
>   expired1 := entry isExpiredUpdating: timeout.
>   expired2 := entry isExpiredUpdating: -1.
>   ^ {timeout.
>   Time totalSeconds.
>   expired1.
>   entry.
>   entry time.
>   entry lastCount.
>   (entry counter value).
>   expired2}
> 
> I've got to head home, but I'll check in again this evening when I get the chance ...
> 

Thanks, the above code returns:

anArray( aWARcLastAccessExpiryPolicy, 3605819381, false, aWARcLastAccessEntry, 3605819381, 1, 1, true)




> Dale
> 
> 
> 
> On 04/06/2015 04:57 PM, Lawrence Kellogg wrote:
>> 
>>> On Apr 6, 2015, at 7:37 PM, Dale Henrichs <dale.henrichs at gemtalksystems.com <mailto:dale.henrichs at gemtalksystems.com>> wrote:
>>> 
>>> 
>>> On 04/06/2015 04:29 PM, Lawrence Kellogg wrote:
>>>> 
>>>>> On Apr 6, 2015, at 7:26 PM, Dale Henrichs <dale.henrichs at gemtalksystems.com <mailto:dale.henrichs at gemtalksystems.com>> wrote:
>>>>> 
>>>>> No problem ... no disappointment since I found some logic errors already:) ... So what are the values of the instance variables in the WARcLastAccessEntry ... in other words "why is it answering false?" ...
>>>>> 
>>>> 
>>>> time - 3593198528
>>>> counter - an RcCounter with a whopping 1001 aRcCounterElements
>>>> lastCount = 0 
>>>> 
>>>> Does that shed any light on the situation?
>>>> 
>>> 
>>> the value of lastCount is suspicious ... what is the result of `counter value`
>> 
>> 
>> 
>> the value is 1.
>> 
>> For Seaside Gemstone Core: 
>> 
>> MODIFIED
>> Ancestors: Seaside-GemStone-Core-dkh.63
>> ===========================
>> 
>> Name: Seaside-GemStone-Core-dkh.63
>> Author: dkh
>> Time: 09/27/2011, 14:59:38
>> UUID: 81e7cc84-552b-4806-bf52-2d93f25be69c
>> Ancestors: Seaside-GemStone-Core-dkh.62
>> 
>> 3.0.6.1 (dkh.334):
>> - remove the GemStone method seasideNextLine and add a test for Issue 289
>> —————————————
>> 
>> 
>>> 
>>> Dale
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20150406/12618e6b/attachment.html>