Smalltalk › Gemtalk › GLASS

Does findAllReferencePathsToObject:maxPaths: in GS 3.3.1 ever end?

‹ Previous Topic Next Topic ›
 
classic Classic list List threaded Threaded
♦
♦
 3 messages Options
GLASS mailing list
Reply | Threaded
Open this post in threaded view
♦
♦
|

Does findAllReferencePathsToObject:maxPaths: in GS 3.3.1 ever end?

GLASS mailing list
Hi -


In a 7GB GS/64 3.3.1 stone on Ubuntu 16.04 I've had a topaz session running for 7+ hours trying to find the 'printit' result of


SystemRepository  findAllReferencePathsToObject:  (MyCollection at: 13)  maxPaths: 2


After about 20 minutes it output:

RefPathScan at 01/03/2019 05:37:54 PST
  Starting scan  51.
RefPathScan at 01/03/2019 05:37:57 PST
  End of scan 51.  Current status of sub-scans:

  Search oop #  1 ( 861666305):   ***SCAN COMPLETED***
Search oop is reachable from the following 15 limit oops:
      1  oop=  32961281 (aMetaclass3)
      2  oop=  33115393 (aMetaMCMethodDefinition)
      3  oop=  80039425 (aMetaCPSystem)
      4  oop= 179477249 (aMetaWADispatcher)
      5  oop= 358600193 (aMetaCPInboundEmailServer)
      6  oop= 360980481 (aMetaCPTaskScheduler)
      7  oop= 684421377 (aMetaCPBusinessModel)
      8  oop=1422970369 (aMetaTDTopezServer)
      9  oop=1422970625 (aMetaclass3)
     10  oop=1595670785 (aMetaCPrHelpEntrySystemRepository)
     11  oop=4420608001 (aMetaCPUtilities)
     12  oop=4420608257 (aMetaclass3)
     13  oop=12594921729 (aMetaCPUserModel)
     14  oop=12594936065 (aMetaCPAdministrator)
     15  oop=19393736449 (aMetaCPTwilioHTTPInterface)


and has had one CPU pegged at 100% for the remaining 7 hours.  Scrolling back through the scans show several "scans" with more than a million parent references.  

Is this normal?   Should I expect something different from the #findAllReferencePathsToObject: method by now?  


I'm worried theres a cycle or something else I don't understand because there are roughly of the 13,000 instances of this class 12,000 shouldn't exist....

Thanks for any guidance or ideas you can provide.

Paul

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
GLASS mailing list
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Does findAllReferencePathsToObject:maxPaths: in GS 3.3.1 ever end?

GLASS mailing list
Check to see if they are instances of an older class in class history, perhaps referenced by class variable or class instance variable of older class editions. 

Add more paths if your CPU has spare threads for use, search will complete faster unless disk IO constrained.

Paul Baumann



On Thu, Jan 3, 2019, 3:54 PM PAUL DEBRUICKER via Glass <[hidden email] wrote:
Hi -


In a 7GB GS/64 3.3.1 stone on Ubuntu 16.04 I've had a topaz session running for 7+ hours trying to find the 'printit' result of


SystemRepository  findAllReferencePathsToObject:  (MyCollection at: 13)  maxPaths: 2


After about 20 minutes it output:

RefPathScan at 01/03/2019 05:37:54 PST
  Starting scan  51.
RefPathScan at 01/03/2019 05:37:57 PST
  End of scan 51.  Current status of sub-scans:

  Search oop #  1 ( 861666305):   ***SCAN COMPLETED***
Search oop is reachable from the following 15 limit oops:
      1  oop=  32961281 (aMetaclass3)
      2  oop=  33115393 (aMetaMCMethodDefinition)
      3  oop=  80039425 (aMetaCPSystem)
      4  oop= 179477249 (aMetaWADispatcher)
      5  oop= 358600193 (aMetaCPInboundEmailServer)
      6  oop= 360980481 (aMetaCPTaskScheduler)
      7  oop= 684421377 (aMetaCPBusinessModel)
      8  oop=1422970369 (aMetaTDTopezServer)
      9  oop=1422970625 (aMetaclass3)
     10  oop=1595670785 (aMetaCPrHelpEntrySystemRepository)
     11  oop=4420608001 (aMetaCPUtilities)
     12  oop=4420608257 (aMetaclass3)
     13  oop=12594921729 (aMetaCPUserModel)
     14  oop=12594936065 (aMetaCPAdministrator)
     15  oop=19393736449 (aMetaCPTwilioHTTPInterface)


and has had one CPU pegged at 100% for the remaining 7 hours.  Scrolling back through the scans show several "scans" with more than a million parent references. 

Is this normal?   Should I expect something different from the #findAllReferencePathsToObject: method by now? 


I'm worried theres a cycle or something else I don't understand because there are roughly of the 13,000 instances of this class 12,000 shouldn't exist....

Thanks for any guidance or ideas you can provide.

Paul

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
GLASS mailing list
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Does findAllReferencePathsToObject:maxPaths: in GS 3.3.1 ever end?

GLASS mailing list
In reply to this post by GLASS mailing list

Paul,

This appears to be a known bug (internal bug number 44792 "#findAllReferencePathsToObject: can require more iterations than "necessary"... in 3.4, we are deprecating this method:

In 3.4.x and 3.5 the methods contain the following:

self deprecated: 'Repository>>findAllReferencePathsToObject:maxPaths: ',
      'unsupported as of v3.4, unreliable for large operations. Use multiple single ref path queries'

Dale

On 1/3/19 12:53 PM, PAUL DEBRUICKER via Glass wrote:
Hi - 


In a 7GB GS/64 3.3.1 stone on Ubuntu 16.04 I've had a topaz session running for 7+ hours trying to find the 'printit' result of 


SystemRepository  findAllReferencePathsToObject:  (MyCollection at: 13)  maxPaths: 2


After about 20 minutes it output:

RefPathScan at 01/03/2019 05:37:54 PST
  Starting scan  51.
RefPathScan at 01/03/2019 05:37:57 PST
  End of scan 51.  Current status of sub-scans:

  Search oop #  1 ( 861666305):   ***SCAN COMPLETED***
Search oop is reachable from the following 15 limit oops:
      1  oop=  32961281 (aMetaclass3)
      2  oop=  33115393 (aMetaMCMethodDefinition)
      3  oop=  80039425 (aMetaCPSystem)
      4  oop= 179477249 (aMetaWADispatcher)
      5  oop= 358600193 (aMetaCPInboundEmailServer)
      6  oop= 360980481 (aMetaCPTaskScheduler)
      7  oop= 684421377 (aMetaCPBusinessModel)
      8  oop=1422970369 (aMetaTDTopezServer)
      9  oop=1422970625 (aMetaclass3)
     10  oop=1595670785 (aMetaCPrHelpEntrySystemRepository)
     11  oop=4420608001 (aMetaCPUtilities)
     12  oop=4420608257 (aMetaclass3)
     13  oop=12594921729 (aMetaCPUserModel)
     14  oop=12594936065 (aMetaCPAdministrator)
     15  oop=19393736449 (aMetaCPTwilioHTTPInterface)


and has had one CPU pegged at 100% for the remaining 7 hours.  Scrolling back through the scans show several "scans" with more than a million parent references.  

Is this normal?   Should I expect something different from the #findAllReferencePathsToObject: method by now?  


I'm worried theres a cycle or something else I don't understand because there are roughly of the 13,000 instances of this class 12,000 shouldn't exist....

Thanks for any guidance or ideas you can provide.

Paul

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Free forum by Nabble Edit this page