[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
Tue Sep 1 09:44:47 PDT 2015
Hi Dale,
I just tried but unfortunately I still got the same error.... I do not want
to make you loose more time if this was fixed in newer gemstone versions. I
just hope I do not get this error frequently in the future until I am able
to migrate to newer versions. If you still want me to dig or try something
else because of your convenience (like if you think there might still be a
bug even for newer versions), then let me know.
Thanks anyway for the help. Very much appreciated.
On Mon, Aug 31, 2015 at 4:14 PM, Dale Henrichs <
dale.henrichs at gemtalksystems.com> wrote:
>
>
> 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> 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:
>>
>> 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>marianopeck at gmail.com> wrote:
>>
>>>
>>>
>>> On Fri, Aug 28, 2015 at 4:56 PM, Dale Henrichs via Glass <
>>> <glass at lists.gemtalksystems.com>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>Glass at lists.gemtalksystems.com
>>>> <http://lists.gemtalksystems.com/mailman/listinfo/glass>
>>>> http://lists.gemtalksystems.com/mailman/listinfo/glass
>>>>
>>>
>>>
>>>
>>> --
>>> Mariano
>>> http://marianopeck.wordpress.com
>>>
>>
>>
>>
>> --
>> 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/20150901/3a3124fb/attachment-0001.html>
More information about the Glass
mailing list