[Glass] Grrrr cannot migrate (class rename with subclasses and with a name of a deleted class)
Dale Henrichs via Glass
glass at lists.gemtalksystems.com
Mon Aug 31 12:14:09 PDT 2015
On 8/31/15 11:49 AM, Mariano Martinez Peck wrote:
>
>
> On Mon, Aug 31, 2015 at 3:38 PM, Dale Henrichs
> <dale.henrichs at gemtalksystems.com
> <mailto:dale.henrichs at gemtalksystems.com>> wrote:
>
> Mariano,
>
> Here's a better patch (from engineering) ... there are bugs in the
> handling of temps and blocks (in 3.1.x) that appears to be the
> culprit (the code i.v. value was not correctly picked up ... do
> the calculation in the context of the block ... this is the
> preferred patch because the nil return value dod not imply an
> empty result set as my patch implied ... this one should give you
> correct results ... let me know if there are further problems):
>
>
>
> Thanks Dale and the rest of the engineers for the effort. I will test
> it soon (I must restore from backup first and do a few things in order
> to reproduce it again). In the meanwhile let me ask:
>
> 1) was this "temps and blocks" bugs solved in 3.2 or 3.3?
I don't know the exact details ... the engineer I talked to was pretty
confident that this bug wasn't present in 3.2.x or 3.3.x.
> 2) Is there anything I should take care of for when I am using temps
> and closures? I mean, were you able to fin the exact issue so that I
> can know and not have those problems in my own code? I do remember the
> known problem of seaside callbacks and temps and the usage of
> ValueHolder, but I don't know if this is related or not.
Since you are using 3.1.0.6, your best course of action might be to read
through the release notes for each of the 3.2.x releases[1] and see if
block/temp bugs were fixed or mentioned and then cross reference with
bugnotes[2] using the site-search[3].
IIRC the particular bug in this case had to do with assigning the temp
that was only referenced in a block created before the temp assignment
was made - moving the temp assignment before the block was created could
be a workaround (I don't recall any additional details) ...
Dale
[1] https://gemtalksystems.com/products/gs64/versions32x/
[2] https://gemtalksystems.com/techsupport/bugnotes/
[3] https://cse.google.com/cse/home?cx=014580976650604809618:1cdoq5jo3te
>
> Thanks in advance,
>
> listInstances: anArray limit: aSmallInt toDirectory:
> directoryString withMaxThreads: maxThreads maxCpuUsage:
> aPercentage memoryOnly: memOnlyBool
> "If directoryString == nil, result includes in-memory objects.
>
> If memBool == true, result contains only the in-memory objects,
> and maxThreads and aPercentage are ignored."
>
> | inputSet resultInSetOrder result scanBlk |
> memOnlyBool
> ifFalse: [
> System needsCommit
> ifTrue: [ self _error: #'rtErrAbortWouldLoseData' ] ].
> inputSet := self _arrayOfClassesAsSet: anArray.
> inputSet size < 1
> ifTrue: [ ^ {} ].
> memOnlyBool
> ifFalse: [
> scanBlk := [ :scanSetThisTime |
> self
> _scanPomWithMaxThreads: maxThreads
> waitForLock: 60
> pageBufSize: 8
> percentCpuActiveLimit: aPercentage
> https://gemtalksystems.com/techsupport/bugnotes/ identSet:
> scanSetThisTime
> limit: aSmallInt
> scanKind: (directoryString ifNotNil:[ 2 ] ifNil:[ 0 ])
> toDirectory: directoryString ] ].
> inputSet := IdentitySet withAll: anArray.
> resultInSetOrder := self
> _doListInstancesFrom: inputSet
> with: scanBlk
> includeMemory: directoryString == nil.
> directoryString
> ifNotNil: [ result := resultInSetOrder "primitive wrote the
> files, so we are done" ]
> ifNil: [
> | inputArraySize |
> inputArraySize := anArray size.
> result := Array new: inputArraySize * 2.
> 1 to: inputArraySize do: [ :j |
> | soIdx resIdx anObj |
> anObj := anArray at: j.
> soIdx := (inputSet _offsetOf: anObj) * 2.
> resIdx := j * 2.
> result at: resIdx - 1 put: (resultInSetOrder at: soIdx -
> 1). "totalCount"
> result at: resIdx put: (resultInSetOrder at: soIdx)
> "array of instances" ] ].
> ^ result
>
>
> On 08/28/2015 03:09 PM, Dale Henrichs wrote:
>> Here's an untested patch for
>> Repository>>listInstances:limit:toDirectory:withMaxThreads:maxCpuUsage:memoryOnly:
>> that you can try (Probably have to use topaz logged in as
>> SystemUser to install this patch) based on 3.1.0.6 <http://3.1.0.6>:
>>
>> listInstances: anArray limit: aSmallInt toDirectory:
>> directoryString withMaxThreads: maxThreads maxCpuUsage:
>> aPercentage memoryOnly: memOnlyBool
>> "If directoryString == nil, result includes in-memory objects.
>>
>> If memBool == true, result contains only the in-memory objects,
>> and maxThreads and aPercentage are ignored."
>>
>> | inputSet resultInSetOrder result code scanBlk |
>> memOnlyBool
>> ifFalse: [
>> System needsCommit
>> ifTrue: [ self _error: #'rtErrAbortWouldLoseData' ] ].
>> inputSet := self _arrayOfClassesAsSet: anArray.
>> inputSet size < 1
>> ifTrue: [ ^ {} ].
>> memOnlyBool
>> ifFalse: [
>> scanBlk := [ :scanSetThisTime |
>> (self
>> _scanPomWithMaxThreads: maxThreads
>> waitForLock: 60
>> pageBufSize: 8
>> percentCpuActiveLimit: aPercentage
>> identSet: scanSetThisTime
>> limit: aSmallInt
>> scanKind: code
>> toDirectory: directoryString) ifNil: [ #() ] ] ].
>> code := directoryString ifNotNil: [ 2 ] ifNil: [ 0 ].
>> inputSet := IdentitySet withAll: anArray.
>> resultInSetOrder := self
>> _doListInstancesFrom: inputSet
>> with: scanBlk
>> includeMemory: directoryString == nil.
>> directoryString
>> ifNotNil: [ result := resultInSetOrder "primitive wrote the
>> files, so we are done" ]
>> ifNil: [
>> | inputArraySize |
>> inputArraySize := anArray size.
>> result := Array new: inputArraySize * 2.
>> 1 to: inputArraySize do: [ :j |
>> | soIdx resIdx anObj |
>> anObj := anArray at: j.
>> soIdx := (inputSet _offsetOf: anObj) * 2.
>> resIdx := j * 2.
>> result at: resIdx - 1 put: (resultInSetOrder at: soIdx -
>> 1). "totalCount"
>> result at: resIdx put: (resultInSetOrder at: soIdx)
>> "array of instances" ] ].
>> ^ result
>>
>>
>> On 8/28/15 3:04 PM, Dale Henrichs wrote:
>>> Mariano,
>>>
>>> Does the following return nil consistently when run in your image:
>>>
>>> System abortTransaction.
>>> SystemRepository
>>> listInstances: {FaSecurityAdjustedClosingPriceRecord}
>>> limit: 0
>>> toDirectory: nil
>>> withMaxThreads: 1
>>> maxCpuUsage: 95
>>> memoryOnly: false
>>>
>>> I think this is the equivalent call that is causing a nil return
>>> value. I've looked at the code and there is no obvious code path
>>> for returning nill instead of an Array .... I've submitted an
>>> internal bug.
>>>
>>> Dale
>>>
>>> On 8/28/15 1:20 PM, Dale Henrichs wrote:
>>>> Nonetheless, this looks like a bug in GemStone and now I need
>>>> to understand why so I can provide a test case to the server
>>>> guys ... I don't think that 2 metaclasses and 2 classes is a
>>>> good reason for nil, since GemStone is supposed to survive this
>>>> kind of situation ... likely it is something else ... this is a
>>>> multi-thread operation and it is possible that something
>>>> related to that is the root cause could you check in the stone
>>>> log and the gem log to see if any error information is written
>>>> there ...
>>>>
>>>> Thanks for pushing on this like you did ... I was an email
>>>> behind and you were way ahead of me ... but ... I have an
>>>> "expectation" that certain class loading scenarios could result
>>>> in an error, but this kind of error is not part of my
>>>> expectation and the monticello loading scheme does hide these
>>>> kinds of problems ....
>>>>
>>>> Need to make the error more visible at the very least ... and
>>>> fix the GemStone bug ... it's possible that the bug is already
>>>> fixed and it is not likely that we will ship a 3.1.0.7 with a
>>>> bugfix -
>>>>
>>>> Let's get a simplified test case and move forward from there ...
>>>>
>>>> Is it possible that you're in a limited memory situation in
>>>> your development environment?
>>>>
>>>> Dale
>>>>
>>>> On 8/28/15 1:04 PM, Mariano Martinez Peck wrote:
>>>>>
>>>>>
>>>>> On Fri, Aug 28, 2015 at 5:00 PM, Mariano Martinez Peck
>>>>> <marianopeck at gmail.com <mailto:marianopeck at gmail.com>> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Aug 28, 2015 at 4:56 PM, Dale Henrichs via Glass
>>>>> <glass at lists.gemtalksystems.com
>>>>> <mailto:glass at lists.gemtalksystems.com>> wrote:
>>>>>
>>>>> Definitely a GemStone bug, since
>>>>> Repository>>_scanPomWithMaxThreads:waitForLock:pageBufSize:percentCpuActiveLimit:identSet:limit:scanKind:toDirectory:
>>>>> is a primitive call and is not documented to return
>>>>> nil ... unless I misread the stack and calls?
>>>>>
>>>>>
>>>>> No, I got exactly until that point too. I read the comment
>>>>> of the method, it said anywhere why it would answer nil,
>>>>> so I kind of give up.
>>>>>
>>>>>
>>>>> BTW..I will try to see if I can get there again. But I suspect
>>>>> this is related to the fact that I end up having 2 metaclasses
>>>>> and 2 classes (as I show some emails up) for the same "class"
>>>>> after loading.
>>>>>
>>>>>
>>>>> Dale
>>>>>
>>>>>
>>>>> On 8/28/15 12:50 PM, Dale Henrichs wrote:
>>>>>
>>>>> This looks like a GemStone bug (at first blush),
>>>>> since the error is originating in
>>>>>
>>>>> [13] Repository >>
>>>>> _doListInstancesFrom:with:includeMemory: (envId 0)
>>>>>
>>>>> so if you could extract some detail from that
>>>>> frame about where the source of the nil, we might
>>>>> be able to work our way back to the root cause ...
>>>>>
>>>>> Dale
>>>>>
>>>>> On 8/28/15 7:58 AM, Mariano Martinez Peck via
>>>>> Glass wrote:
>>>>>
>>>>> [13] Repository >>
>>>>> _doListInstancesFrom:with:includeMemory: (envId 0)
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Glass mailing list
>>>>> Glass at lists.gemtalksystems.com
>>>>> <mailto:Glass at lists.gemtalksystems.com>
>>>>> http://lists.gemtalksystems.com/mailman/listinfo/glass
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Mariano
>>>>> http://marianopeck.wordpress.com
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Mariano
>>>>> http://marianopeck.wordpress.com
>>>>
>>>
>>
>
>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20150831/aef2258f/attachment-0001.html>
More information about the Glass
mailing list