Wang Lei wrote:
At first ,thank you for your reply. I tried it as you wrote. The result keeps the same.
Are you still running multithreaded test runner from the initial post? If so, it's just a fact that you are asking for 500 brokers at approximately the same time in your test runner (as Steve Clark pointed out). Also, you have no way of getting reproducable results using an inherit multithreaded race-condition where the number of threads active in parallell is dependent on execution speed of the JVM and your hardware. (If you monitor Oracle sessions with your multithreaded test runner, you might see only 2 active in parallell beacuse all other threads had time to finish, or you might see 500 active in parallell because the for-loop with Thread start was fast enough to start them all, but no thread is yet finished with RBDMS-ops.) If you want to try the semantics "acquire a broker, perform op, close broker" sequentially 500 times to check for Connection leaks you just use a single- threaded test runner with a for-loop instead of 500 threads. I can't really tell which code you are running and what you still consider to be a problem. (I realise this is a language problem, so plead bear with me while I try to read you correctly - I am also not a native English speaker so we have some "filtering" in both ends.) :-) Please supply more details so we can follow up on the SequenceManager configuration changes you posted. Most important is: exactly which test runner code are you using at the moment and exactly what are the semantics you are trying to test (ie how do you define your "connection leak" and what do you think is the expected result). Regards, Martin --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
