Hi Martin,
However, in our test image, the server has after running 100 tests inserting and deleting data, around 31000 instances of MaHashIndexRecord (found with your provided script). Does that give any hint to you?
That's possibly high, but it depends on how many MagmaCollections and indexes you have and, in particular, if you are using a large key like 256 bits. And also whether a garbage collection has occurred (or am I to assume that number is *post* "Smalltalk garbageCollect"?). Instances of this class are managed solely by MaHashIndex, they cache a path of MaHashIndexRecords from the last access through the tree of records. There is a very detailed detailed description of MaHashIndex, and even a detailed PDF of its format and operation workings on the Swiki pages. This code has been rock-solid for years, I am doubtful there is a memory leak here..
We'll have to further dig into some code tomorrow, to provide you with a modified version of your scripts so you can test it... :)
Great, if I can see it, I can probably find the cause very quickly..
Another question: Is it possible to limit the answers of a MagmaCollectionReader just like with "limit" in sql?
myReader pageSize: 10
But I would do at least 50..
The problem is, that I want to have only the first 10 results of a query, but it would return about 1500.
Yeah, I wish I knew a way to co-integrate where clauses with terms that are not part of the available indices. It requires faulting the object to the client anyway, so I leave it to the Magma user.
but if i use MagmaCollectionReader>>asArray: .. it will call lastKnownSize which in turn executes the query on the server side (if i am right).
Yes, if the query uses "or" it will require a full enumeration of the result-set to determine the size. You just want the first 10 and don't care about the size. Yeah, that would be nice, I'll add that to my list to investigate.
I hope r39 is a little better for you, you can now have MagmaSessions referenced in your domain..
Regards, Chris