(Sorry, I just joined the list, so I've used the archives to pull the relevant email I'd like to quote)
Just as a bit of background, I'm having a similar issue as the original poster, where I have a proliferation of transient index files that aren't being deleted. Now...
Look on the documentation page: http://wiki.squeak.org/squeak/5859 under the heading "Sorting" for your answer.
Looking at that page, it says:
"These files are automatically cleaned up when the session disconnects."
The trouble is, what if you have, say, a long running MagmaSession driving a Seaside application? In my case, I'm just using the MagmaSoloAuto helper, since it's a fairly simple, low-traffic application, but because (as I understand it) the underlying MagmaSession object *isn't* disconnected across Seaside session boundaries, I get a huge number of .hdx files that never get deleted.
Or, at least, that's my speculation. Does this sound likely?
Ultimately, my particular problem is that this behaviour, combined with the open-file limits on seasidehosting.st, makes my application impossible to deploy there, as it rapidly exceeds the maximum number of open files allowed.
Of course, for all that griping, the question is what to do about it. At minimum, I'd like to be able to instruct Magma to throw away transient indexes at some time of my own choosing (in particular, when a Seaside session expires). Is this at all possible? Heck, even the stopgap solution of having these files *not* held open would be useful, though I have no idea if that's doable, either.
Thanks in advance for any help!
Brett.
Looking at that page, it says:
"These files are automatically cleaned up when the session disconnects."
The trouble is, what if you have, say, a long running MagmaSession driving a Seaside application? In my case, I'm just using the MagmaSoloAuto helper, since it's a fairly simple, low-traffic application, but because (as I understand it) the underlying MagmaSession object *isn't* disconnected across Seaside session boundaries, I get a huge number of .hdx files that never get deleted.
Or, at least, that's my speculation. Does this sound likely?
Ultimately, my particular problem is that this behaviour, combined with the open-file limits on seasidehosting.st, makes my application impossible to deploy there, as it rapidly exceeds the maximum number of open files allowed.
No, the number of open files has nothing to do with the number of "transient" subcollections you've created. Please see the method:
MagmaRepositoryController>>filePoolSize: anInteger "Set the maximum number of simultaneously-open files that Magma will have." repository filePoolSize: anInteger
Of course, for all that griping, the question is what to do about it.
Some options:
- stop using the "luxury" features that create subcollections - Have you considered using #select: instead of #where:?
I'll try to think of other ideas, but it's hard without knowing more about your app..
At minimum, I'd like to be able to instruct Magma to throw away transient indexes at some time of my own choosing (in particular, when a Seaside session expires). Is this at all possible?
There is no support for that, but it might be possible to do. The trouble is you could still have a reference to the sub-MagmaCollection in your image and try to access it. That would cause a "object not found" error..
Have you considered
Heck, even the stopgap solution of having these files *not* held open would be useful, though I have no idea if that's doable, either.
If you are exceeding your hosting requirements you need to set down your maxFilePoolSize:.
Regards, Chris
magma@lists.squeakfoundation.org