sebb wrote: > Here is the output from > http://vmbuild.apache.org/continuum/buildResult.action?buildId=268733&projectId=22 > > I've rearranged it so the threads are in ConnectionStart order. > I moved ConnectionStart to the beginning, added the Thread number at > the end (dropping irrelevant stuff), and deleted the prefix > "ConnectStart: 355958" > > 7635. StartupDelay: 13. ConnectTime: 2. Runtime: 218. 1 > 7637. StartupDelay: 0. ConnectTime: 280. Runtime: 481. 2 > 7724. StartupDelay: 0. ConnectTime: 193. Runtime: 394. 4 > 7737. StartupDelay: 13. ConnectTime: 180. Runtime: 381. 5 > 7750. StartupDelay: 112. ConnectTime: 167. Runtime: 368. 3 > 7775. StartupDelay: 38. ConnectTime: 142. Runtime: 343. 6 > 7785. StartupDelay: 10. ConnectTime: 132. Runtime: 333. 7 > 7816. StartupDelay: 31. ConnectTime: 101. Runtime: 302. 8 > 7853. StartupDelay: 38. ConnectTime: 1. Runtime: 202. 9 > 7865. StartupDelay: 11. ConnectTime: 52. Runtime: 252. 10 > 7874. StartupDelay: 9. ConnectTime: 43. Runtime: 243. 11 > 7918. StartupDelay: 44. ConnectTime: -. Runtime: 109. 12 > 7927. StartupDelay: 9. ConnectTime: -. Runtime: 113. 13 > 7941. StartupDelay: 14. ConnectTime: -. Runtime: 104. 14 > 7944. StartupDelay: 3. ConnectTime: -. Runtime: 101. 15 > 7953. StartupDelay: 0. ConnectTime: -. Runtime: 100. 17 > 7953. StartupDelay: 0. ConnectTime: -. Runtime: 100. 18 > 7953. StartupDelay: 0. ConnectTime: -. Runtime: 101. 19 > 7954. StartupDelay: 1. ConnectTime: -. Runtime: 100. 20 > 7954. StartupDelay: 10. ConnectTime: -. Runtime: 100. 16 > > It can be seen that thread 2 reaches the getConnection() method some > while before the next thread (7724-7637=87ms) yet takes longer than > any of the other threads to return from the method. > > This could mean that there is a window somewhere in the code that > causes this thread to pause whilst others progress. There does seem to > be a problem here. > > I need to do a bit more analysis on the numbers (and perhaps update > the debug) to see how the connected threads overlap.
Interesting and consistent with the last failed run. Neither of these really explains anything, but two things to note: 1) The one obvious difference between to consider is the thread that registers the pool. Should not stall because of that and synch in registerPool will halt all others while it is completing. 2) Look at borrowObject in GKOP. When maxWait is positive and when exhausted action is block, the client thread will wait for maxWait ms and before exiting with a failure when the wait has ended it will look to see if an instance has been allocated to it. If so, it will happily grab that instance and succeed. This makes it possible to exceed maxWait by timing accuracy of wait + a time it takes to acquire a lock on the pool to check for an allocated object. It could be that what is going on is that while thread 2 is waiting to acquire the pool lock in this section, another thread comes in and returns an instance. Timing computations do not work; however, as there should not be enough elapsed time for the other thread to release its instance. Phil > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
