Re: Massive concurrency problems under high server load

[Armin Waibel]

I run some massive multithreaded tests against the 1.0_RELEASE branch in 
CVS (against hsql in-memory mode, single CPU) without failures (with 
tweaked OJB settings). In this test each thread work on separate 
objects, maybe the problems occur only when different threads work on 
the same objects.

So could you post some of the exceptions you got when run your tests and 
some info about the test (concurrent threads, OJB configuration, ...)?

regards,
Armin
[ojb] ========================================================
[ojb]         OJB PERFORMANCE TEST SUMMARY
[ojb] 100 concurrent threads, handle 500 objects per thread
[ojb]         - performance mode
[ojb] ========================================================
[ojb]      API  Period   Total  Insert   Fetch  Update  Delete
[ojb]            [sec]   [sec]  [msec]  [msec]  [msec]  [msec]
[ojb] --------------------------------------------------------
[ojb]     ODMG  63.833  59.424   19117   17445   13850    9011
[ojb] ========================================================
[ojb] PerfTest takes 194 [sec]
[ojb] ========================================================
[ojb]         OJB PERFORMANCE TEST SUMMARY
[ojb] 40 concurrent threads, handle 2000 objects per thread
[ojb]         - performance mode
[ojb] ========================================================
[ojb]      API  Period   Total  Insert   Fetch  Update  Delete
[ojb]            [sec]   [sec]  [msec]  [msec]  [msec]  [msec]
[ojb] --------------------------------------------------------
[ojb]     ODMG  90.255  80.836   40198   10361   20026   10250
[ojb] ========================================================
[ojb] PerfTest takes 274 [sec]
Armin Waibel wrote:
Hi Gerhard,
this sounds alarming :-(
Gerhard Grosse wrote:
So my main questions are:
- Have substantial things changed between RC5 and 1.0 that might have
improved OJB's behavior under high concurrent load.

we made serveral improvements between rc5 and 1.0. The performance 
improvement of the odmg-api should be about 10-15%. The handling of 
nested objects was improved significantly (~ 250% better performance).
But I think this will not solve the described problems of transactions 
take minutes to complete.
OJB was shipped with a simple multi-threaded performance test. This test 
pass on all releases (but only on my single cpu PC).


- Does anyone have experience with OJB in a servlet environment under
high load? Any hints how to get it to work and perform?
One finding that discourages us from upgrading to 1.0 is a concurrency
bug we discovered in RC5 which does not seem to have been fixed in
1.0:
In class org.apache.ojb.broker.core.QueryReferenceBroker:
private void performRetrievalTasks()
{
  while (m_retrievalTasks.size() > 0)
  {
      HashMap tmp = m_retrievalTasks; // *
      m_retrievalTasks = new HashMap(); // *
      // during execution of these tasks new tasks may be added
      for (Iterator it = tmp.entrySet().iterator(); it.hasNext(); )
      ...
the two lines marked with // * must be put in a block that
synchronizes (e.g.) on m_retrievalTasks. If not, a thread switch may
occur after the first line and two instances of tmp may point to the
same hash table. Seems unlikely, but under high load it does occur
often enough (a java.util.ConcurrentModification exception is the
consequence):
synchronized (m_retrievalTasks) {
  tmp = m_retrievalTasks;
  m_retrievalTasks = new HashMap();
}
solves the problem.
hmm, the PB-api is not threadsafe by design, so if this happens the 
problem will be occured by the odmg-api (missing synchronized block ...) 
or does it happen when lazy loading of objects was used?

regards,
Armin

Any hints and help are greatly appreciated.
Gerhard Grosse



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]