[Glass] Grrrr cannot migrate (class rename with subclasses and with a name of a deleted class)
Mariano Martinez Peck via Glass
glass at lists.gemtalksystems.com
Mon Aug 31 11:49:38 PDT 2015
On Mon, Aug 31, 2015 at 3:38 PM, Dale Henrichs <
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?
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.
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
> 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:
>
> 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> wrote:
>
>>
>>
>> On Fri, Aug 28, 2015 at 4:56 PM, Dale Henrichs via Glass <
>> 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
>>> 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/cd76dfac/attachment-0001.html>
More information about the Glass
mailing list