search

crs4 / notredam

Automatically exported from code.google.com/p/notredam
http://www.notredam.org
17 stars 4 forks source link

Class changes do not appear consistently #88

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
*What steps will reproduce the problem?*
1. Setup NotreDAM using a production setup (Apache + mod_wsgi) 
https://docs.djangoproject.com/en/dev/topics/install/#install-apache-and-mod-wsg
i
2. Create multiple workspaces
3. Create a class in the Vocabulary
4. Share the class with other workspaces
5. Click Save
6. Select the Class from the tree (may need to repeat this last step multiple 
times to reproduce)

*What is the expected output? What do you see instead?*
Occassionally the last saved workspaces (and possibly other changes) do not 
show up properly. IE: If you checked another workspace it will not be checked.

*What version of the product are you using? On what operating system?*
Latest checkout of notredam-replacement branch
OS: CentOS 6

*Please provide any additional information below.*
I do not have any Django CACHES setup, so I had a hunch that the reason it 
would sometimes return the correct result and sometimes return the old list of 
workspaces was related to multiple Apache processes. I tested this by adding 
the PID to the HTTP response headers, and indeed it only varied when the PID 
was different.

What I came up with is that in src/dam/kb/tinykb/session.py the class_ method 
caches objects. Commenting that out resolves that issue; I now get the same 
response from all Apache processes. (See 
https://code.google.com/r/jonathan-notredam/source/detail?r=ec84d42ef69f015f8bc6
986cd837df89c35537f5)

Original issue reported on code.google.com by jonat...@metaltoad.com on 17 Apr 2013 at 11:40

GoogleCodeExporter commented 9 years ago 
The caching system for classes is intended to run in a multi-threaded, rather 
than multi-process, WSGI setup.  It was introduced because we observed 
uncontrolled memory growth on previous versions of Python and SQLAlchemy, due 
to object reference cycles which apparently were not detected by the Python 
garbage collector.

However, after a quick testing of your patch, this memory problem does not seem 
to arise on Python 2.7 (or at least, it is not as bad as in Python 2.6).

I will leave this issue open.  While we perform some more tests, I would ask 
you to observe how the NotreDAM memory usage varies over time in your setup.  
Please report any anomaly.  Thank you!

Original comment by alce...@crs4.it on 18 Apr 2013 at 2:08