I took a quick look at the relevant code. I haven't been able to figure out what exactly is going wrong, but it appears that JMeter's connection manager isn't working quite right. My best guess right now is that there is a thread safety issue somewhere -- the code looks okay (from what I've seen of it), but it could be a case where the JVM is reordering code or delaying memory stores in a way allowed by Java, but that JMeter isn't expecting.
When you are running inside a JSP you wouldn't hit this because you would be using the container's (Tomcat's) connection pool code instead of JMeter's.
I'll try to look into this some more this week. Some additional information from you would be helpful:
1) What JDK/JRE are you using? (Version number and vendor -- try "java -version".)
2) What hardware are you running JMeter on? (I don't care about the database system -- just where JMeter itself is running.) x86 or something else? Single processor? Any fancy hardware multi-threading features?
3) Could you try running the latest JMeter 1.9 RC3 code (http://jakarta.apache.org/builds/jakarta-jmeter/unstable/v1.9/)? I don't see any changes since 1.8.1 that would make a difference, but it would be good to verify this.
4) I assume that the error messages you sent are all that is in the logs...or at least the first thing in the logs. If you get any additional warnings before this occurs, they could be important, so please send them.
Jeremy
serge van Thiel wrote:
A week ago, I dropped this message related to a failing JDBC request. I would appreciate some feedback in order to clarify the use of JDBC requests : are there any specific rules that apply only to JDBC requests ?. The same query runs successfully in a HTTP request and the exception seems to contain some failing jmeter classes. Am I wrong ?.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
