Closed obi068 closed 7 months ago
That does seem surprising. I'll investigate...
I'm connecting to a clean extent (a copy of $GEMSTONE/bin/extent0.dbf
) and don't even have #GsPackage_Current
in my SymbolList. Have you connected to this repository with anything other than Jade (even Jadeite)? Especially, have you used any of the Pharo-based tools? I think some of them might have used the name JadeServer for a class that gets installed. The way Jade works is that it compiles a class but doesn't add it to a SymbolList (or any persistent object), so it shouldn't be committed at all. Next, the whole GsPackage structure is related to Monticello and other package managers, and Jade doesn't rely on any of that. Perhaps you could get a list of methods and compare it to these.
We had a JadeServer class (without any instVarNames) at UserGlobals. But still after the Login i have this classes in the sessionMethods Dict. | aDict jadeKeys| aDict := (GsPackagePolicy current symbolList first at: #GsPackage_Current ) sessionMethods. jadeKeys := aDict keys select: [:e | (e name gemstoneMatch: 'JadeServer')].
jadeKeys anIdentitySet( JadeServer64bit34, JadeServer64bit, JadeServer64bit24, JadeServer64bit3x, JadeServer64bit33, JadeServer64bit32, JadeServer) I must do an abort right after the login to avoid that this classes become persistent.
And yes we have used Pharo as Client for GLASS. Many Years ago.
I'm able to reproduce this using the Seaside extent rather than the base extent. I suspect that a compile method is adding to SessionMethods. I'll investigate further.
We have a lot of JadeServer MethodDicts in our databases. How should we do a cleanup of this sessionMethods dicts.
((GsPackagePolicy current symbolList first at: #GsPackage_Current ) sessionMethods keys select: [:e | e name gemstoneMatch: 'JadeServer']) size 46363
This leads to memory issues at login time.