|
|
|
|
| Index | Recent Threads | Unanswered Threads | Who's Online | User List | Help |
DataNucleus Forum
DataNucleus Support
Queries : JDOQL
Thread: Synchronization issues
|
| No member browsing this thread |
|
Thread Status: Active Total posts in this thread: 7
|
|
| Author |
|
oblivious_1978
Newbie Joined: Jan 4, 2006 Post Count: 15 Status: Offline |
Has anyone come across threading problems when executing JPOX queries in a high volume env ? I am using JPOX using the connector module in a J2EE env on WebLogic. Consider the following thread dump .... at weblogic.utils.classloaders.ChangeAwareClassLoader.loadClass(ChangeAwareClassLoader.java:41) - waiting to lock <0x9f027208> (a weblogic.utils.classloaders.ChangeAwareClassLoader) at org.jpox.JDOClassLoaderResolver.classOrNull(JDOClassLoaderResolver.java:477) at org.jpox.JDOClassLoaderResolver.classForName(JDOClassLoaderResolver.java:172) at org.jpox.util.Imports.resolveClassDeclaration(Imports.java:163) at org.jpox.store.query.Query.resolveClassDeclaration(Query.java:1000) at org.jpox.store.query.Query.compile(Query.java:936) at org.jpox.store.query.JDOQLQuery.performExecute(JDOQLQuery.java:453) at org.jpox.store.query.Query.executeWithMap(Query.java:1122) at org.jpox.store.query.Query.executeWithArray(Query.java:1095) at org.jpox.store.query.Query.execute(Query.java:1031) WE are having performance issues due to the classloader being fought over. Any way around this or any ideas ? thanks in advance |
||
|
|
oblivious_1978
Newbie Joined: Jan 4, 2006 Post Count: 15 Status: Offline |
What i'm meaning to say, is does JPOX unload any of the classes that it explicitly loads ? Unless it did, i am baffled at what would hold it up at the classloader. Not only would it have to get slammed with volume (that is the case), but it (the weblogic Classloader) would have to be really slow. We verfied there is plenty of perm space left. ---------------------------------------- [Edit 1 times, last edit by oblivious_1978 at May 24, 2006 2:59:46 AM] |
||
|
|
ganzuoni
Expert Joined: Nov 16, 2005 Post Count: 804 Status: Offline |
What was the query ? Maybe classloader execution is triggered by the access to the class discriminator in the table. It this is the pb, you could try to "preload" (i.e. issue a Class.forName) for all your leaf classes in you .jdo files. Guido ---------------------------------------- Guido Anzuoni http://www.objectmagic.org |
||
|
|
erik
Expert Belgium Joined: Mar 12, 2004 Post Count: 3105 Status: Offline |
Can you take about 5 thread dumps waiting 2 seconds between each take and post them here? what is high volume for you? - number of concurrent requests - query result size etc ---------------------------------------- Erik Bengtson  |
||
|
|
oblivious_1978
Newbie Joined: Jan 4, 2006 Post Count: 15 Status: Offline |
Just an FYI guys ... i found a lot more modules than just JPOX fighting over the class loaders. Some of them are our custom webservice apis, which use classloaders way more heaviliy than they should. I still need to look at the JPOX though, as i use it to build a cache and get a lot of this behavior at that time. Thats done before we allow anyone on the system, so the webservices aren't being called at that time. WE don't load the cached tables entirely, as a lot of that data is old and no longer used. So,if i get a "miss" and call JPOX during application running with users the webservice competition for the Loader would contribute to this problem then though. I will put out any further details that might help with the tuning of htis, if you guys would be so inclined. thanks again !! ---------------------------------------- [Edit 2 times, last edit by oblivious_1978 at May 24, 2006 12:06:19 PM] |
||
|
|
oblivious_1978
Newbie Joined: Jan 4, 2006 Post Count: 15 Status: Offline |
Eric, I did some looking in the code, namely the file JDOClassLoaderResolver.java. Consider the two definitions. /** * Cache for loaded classes */ protected Map loadedClasses = new WeakHashMap(); /** * Cache for loaded classes */ protected Map unloadedClasses = new WeakHashMap(); I am assuming you did not make these static to prevent a perm memory leak ? Would there be any other side effects of me hacking this and making them static other than draining my perm space a little ... i have plenty. I would like to reduce resource contention for the loadClass function, as the thread dump goes on and on for this in slightly different variations. There are not a huge number of different classes, but massive amounts of the same query .... considering its used in the context of caching as little data as possible. |
||
|
|
oblivious_1978
Newbie Joined: Jan 4, 2006 Post Count: 15 Status: Offline |
Post mortem ... we have solved the issue we have had with the JPOX thread locking that i saw. It appears we probably weren't appropriately declaring the imports. This was EVERYWHERE in the code, so as a hack to get the system up and running we hacked the Imports class to kick out of hte loop when it found the first matching package/class combo. We don't intend that to be permanent. WE are going to fix the application code to call the appropriate import method. One word of warning i've learned out of this, if you fail to use the import statements, performance will degrade outrageously in a high volume env. ---------------------------------------- [Edit 1 times, last edit by oblivious_1978 at May 25, 2006 1:15:06 PM] |
||
|
|
|
|
Current timezone is GMT Mar 15, 2010 6:32:16 PM |
