> On Tuesday 17 December 2002 03:32 pm, [EMAIL PROTECTED] wrote: >> Hello everyone, >> >> I am testing now the mmbase 1.6 rc3 for VPRO digitiaal and getting the >> ConcurrentModificationException for almost every scan editor I use. >> The scan editors create long running queries. After the errror the connections >> and driver of informix are throwing wierd errors. >> >> Bug #3469 says that it fixed the issue, but that is not the case. >> The source code of MultiPool version 1.20 is not threadsafe at all if you >> ask me. >> >> Threads can just freely get a connection and put it back even when the >> JDBCProbe >> checks the connections with checktime. >> >> Scenario >> thread 1 calls getFree and passes the semaphore.acquire() >> thread JDBCProbe . calls checktime >> >> at this point the JDBCProbe is iterating over the busypool collection and >> thread 1 can add a connection to the busy pool.
> isn't the semaphore locked by the JDBCProbe? > free also cals the semarphore btw At this time in the scenario, yes >>The semaphore is locked by the JDBCProbe, but should still be locked by > thread 1. never lock the semaphore (it calls a wait) That is just the problem. The JDBCProbe locks the semaphore in checkTime to let other threads wait for him to unlock the semaphore. This is required because the JDBCProbe needs full control over the busypool. The checkTime method iterates over the busypool and will freak out if the connections in the busypool change. This behaviour of the JDBCProbe is not solved with a semaphore, but needs a mutex. Only one thread can have the mutex. The checkTime method uses the semaphore as the mutex lock object. The getFree and putBack should use that too. A semaphore only locks when a defined number of threads already acquired it. The semaphore is very nice and fast for the getFree and putBack flow, but fails for the requiements of the JDBCProbe. >> The scenario continues.. >> thread JDBCprobe is still running checktime. >> thread 1 executes the query >> thread 1 calls putback and waits for the JDBCProbe at the statement >> semaphore.release(); >> In this simple scenario (can happen always when JDBCProbe runs) >> the ConcurrentModificationException can be thrown at 2 points in time. >> when getFree adds a connection to the busypool or when putback removes a >> connection. > The "Whole" problem exists because we use an iterator over the pools > and in the probe we need to modify the pools if we want to control them... right, only the JDBCProbe thread is allowed to change the pool (collection) when it is iterating over it. > IMHO we should only make a getConnection() wait "if and ony if" all the > connections are used (this is currently the case). That is what the semaphore is doing right now in getFree and putBack. And it would have worked great if the JDBCProbe didn't have the requirement to have full control of the busypool. >> The system becomes instable when a connection is running longer then >> 2 minutes and this exception is thrown. >> I think this is a big issue in 1.6rc3. >> I will write a fix this afternoon to get my project back on track. > fine :) I made a fix with synchronized blocks and testing it now. It will kill the performance and it is not THE solution for the Multipool. It creates issues which the semaphore solvea with the acqyire release flow (starvation of threads), but I don't see a different option right now. A mutex without the starvation issue could be written, but I don't think it is smart to throw it in the next release. Okay, mmbase is more stable now, but I found another problem with the scan editors. Searching on something always returns the full table. I guess the queries of mine take too long, because mmbase is retrieving always a full table. Going to trace that.... Nico Klasens
