New post
Question
· Feb 21, 2019

Compilation error on %ExtentMgr.GlobalRegistry.LockUse

#ObjectScript #Caché

I'm getting this compilation error:

Kompilieren der Klasse digi.packet
FEHLER #5002: Caché-Fehler: <FUNCTION>zLockUse+5^%ExtentMgr.GlobalRegistry.1
  > FEHLER #5030: Während der Kompilierung von Klasse 'digi.packet' ist ein Fehler aufgetreten

when importing one of my classes on the production server into one particular namespace:

  • the class compiles just fine on dev pc.
  • the class compiles just fine also in any other namespace of the same cache instance. So, looks as a problem of this particular namespace.
  • the project contains many other classes, all are compiled in all namespaces without any problems.
  • Cache for Windows (x86-64) 2017.2.1

Google gives me one similar issue but seems it is not my case: https://groups.google.com/forum/#!topic/intersystems-public-cache/kGRj3L...

Can someone shed some light on this?

Discussion (8)2
Log in or sign up to continue
Kyle Baxter · Feb 22, 2019

This typically happens when you have some corruption of the Extent information for your namespace.  You'll want to delete the nodes for digi.packet in ^oddEXT and ^rINDEXEXT (in the "G" and "U" nodes, I believe).  You can try running ##class(%ExtentMgr.Util).DeleteExtentDefinition("digi.packet") but I'm not sure if that will get it all the way done.


The easiest thing to do might be to export all your classes and import them into a fresh namespace (as you noted this works in many other places).  If you want more step-by-step guidance or any root cause analysis, I recommend contacting InterSystems Support (support@intersystems.com)

2 0
Dan Pasco · Feb 22, 2019

We should never report an error in this way. The Extent Manager can hold stale extent definitions that, over time, can become a bit unwieldy but <FUNCTION> errors are certainly never normal. All registered extents can be rebuilt from compiled class information. I agree with Kyle in that this should be brought to the attention of support so we can do a proper analysis of why this is happening.

As for the "unwieldy" comment, look into the /deleteextent qualifier. This can be optionally specified when deleting a class definition. It causes the Extent Manager information (the registered extent) to be deleted along with the class definition. It helps keep the Extent Manager a bit cleaner. It also causes the compiled class's extent (the data!!) to be deleted so be careful.

1 0
Kyle Baxter · Feb 22, 2019

So I spent 10 years working in Caché product support and this has popped up before. But I've only ever seen it on development systems when folks are creating, deleting, and updating classes at a much higher rate than would be acceptable on a production machine.  And I'm relatively sure it was all new development.  I think it ends up being an artifact of new development and the first creation of your class structures, though I've never been able to find what caused it in the past. 

0 0
Arto Alatalo · Feb 23, 2019

Thanks, I'm aware of deleteexten qualifier.

Regarding to "should never": to me, reasonable way to solve unexpected issue is:

  • spend fair amount of time trying to solve the problem alone bothering no one except Google.
  • ask your colleagues who knows your context and can look on your monitor.
  • approach Community with a clear question hoping some one seen this problem before.
  • start composing materials the support needs for the investigations and prepared for waiting for the answer.
0 0
Dan Pasco · Feb 23, 2019

Sorry! I didn't mean "we should never" comment to refer to how you reported the problem!! Not at all!

I wrote the code that is reporting the <FUNCTION> error. What I meant was that my code is wrong, there is a bug in my code and this is a problem that I need to address! ( I think that I have already in a later version.)

I am sorry that I wasn't more clear about this. I do recommend that you open an issue through the WRC however. That way you can be updated as to the resolution of the issue and we can use it internally to track the resolution.

1 0