View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0000812 | LDMud 3.5 | Runtime | public | 2012-11-11 22:00 | 2012-12-04 16:01 |
Reporter | zesstra | Assigned To | zesstra | ||
Priority | normal | Severity | major | Reproducibility | N/A |
Status | resolved | Resolution | fixed | ||
Product Version | 3.5.0 | ||||
Target Version | 3.5.0 | Fixed in Version | 3.5.0 | ||
Summary | 0000812: Data cleanup behaviour should be improved | ||||
Description | Currently the data cleanup behaviour is somehow flawed. 1) The number of objects cleaned per backend cycle is dependent on the TIME_TO_CLEANUP (i.e. the time before calling cleanup()). This dependency does not make much sense. If you want to have calls to cleanup() only for objects which were not used for a long time, you choose a large TIME_TO_CLEANUP. But because the number of objects data-cleaned is 2*number_of_objects / time_to_cleanup, this leads to a very low number of objects cleaned per cycle. 2) The first X objects of the processed objects in a given backend cycle are data-cleaned. If all objects are processed in a cycle, always the same X objects are data-cleaned and the other never. (Unless the object list changes.) | ||||
Tags | No tags attached. | ||||
|
I changed the default for the data cleanup time to 3600 s and made it configurable with configure_driver(). Additionally a bug was fixed during object creation (the time was initialized with the genereal cleanup time). In 3.3 the default was changed to 10800 s (longer, because not configurable at run-time) and the mentioned bug during object creation was fixed. |
Date Modified | Username | Field | Change |
---|---|---|---|
2012-11-11 22:00 | zesstra | New Issue | |
2012-12-04 13:11 | zesstra | Assigned To | => zesstra |
2012-12-04 13:11 | zesstra | Status | new => assigned |
2012-12-04 16:01 | zesstra | Note Added: 0002155 | |
2012-12-04 16:01 | zesstra | Status | assigned => resolved |
2012-12-04 16:01 | zesstra | Fixed in Version | => 3.5.0 |
2012-12-04 16:01 | zesstra | Resolution | open => fixed |