[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
Fri Aug 28 15:09:05 PDT 2015
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
>>> <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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20150828/2fbb2c59/attachment-0001.html>
More information about the Glass
mailing list