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

[Dale Henrichs via Glass]

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 ...

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/7b0e22e7/attachment-0001.html>