Bug 38748 - JDBC DataSourceElement fails with remote testing
JDBC DataSourceElement fails with remote testing
Status: RESOLVED FIXED
Product: JMeter
Classification: Unclassified
Component: Main
2.1.1
All All
: P2 normal (vote)
: ---
Assigned To: JMeter issues mailing list
:
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2006-02-22 11:22 UTC by Joerg Holle
Modified: 2006-04-29 07:51 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Joerg Holle 2006-02-22 11:22:07 UTC
Test plans using a "JDBC Connection Configuration" element will _not start_ 
with remote testing!

The error message of the remote server is:
java.lang.NullPointerException 
        at org.apache.jmeter.protocol.jdbc.config.DataSourceElement.testStarted
(DataSourceElement.java:91) 
        at org.apache.jmeter.protocol.jdbc.config.DataSourceElement.testStarted
(DataSourceElement.java:109) 
        at 
org.apache.jmeter.engine.StandardJMeterEngine.notifyTestListenersOfStart
(StandardJMeterEngine.java:201) 
        at org.apache.jmeter.engine.StandardJMeterEngine.run(StandardJMeterEngin
e.java:315) 
        at java.lang.Thread.run(Unknown Source) 

This has nothing to do with wrong classpath or such. Having a look at the 
source code of DataSourceElement it seems that the transient property "started" 
is causing the problem. [http://www.devx.com/tips/Tip/13726]
To verify that I removed the "transient" keyword in my environment, compiled, 
re-started - and my testplan started remotely (i.e. no NullPointerException).

Since I have no idea about the internal logic of JMeter and there are even more 
transient properties in the mentioned class, I suggest to have a look at the 
class as a whole. But again: making property "started" non-transient worked for 
me.

BTW
This behaviour has been mentioned already by Benny Rogiers on the jmeter-user 
mailing list, but has been ignored there:
http://www.mail-archive.com/jmeter-user@jakarta.apache.org/msg10071.html
[Just to ensure you guys that this is no local problem with my environment ;-)]
Comment 1 Sebb 2006-02-22 13:05:17 UTC
Thanks for the report - I'll fix this shortly.
[I seem to have missed the posting; I don't remember it.]
Comment 2 Sebb 2006-02-22 20:39:40 UTC
I've fixed it in a slightly different way - by adding a readResolve() method 
to emulate what the constructor does.

Seems to me that this is a bit safer than relying on the correct value being 
passed across.

As far as I can tell, all the other transient fields are set up when running 
the test.
Comment 3 Joerg Holle 2006-03-23 10:43:49 UTC
(In reply to comment #2)
> I've fixed it in a slightly different way - by adding a readResolve() method 
> to emulate what the constructor does.
> Seems to me that this is a bit safer than relying on the correct value being 
> passed across.
> As far as I can tell, all the other transient fields are set up when running 
> the test.

Sounds like the correct way to handle this.

BTW: Does the current status NEEDINFO indicate that this fix will not be used 
yet (e.g. in the next release)?
Comment 4 Sebb 2006-03-23 12:14:22 UTC
The fix will be in the next release, 2.1.2.

NEEDINFO means that we are awaiting information from the person who created 
the bug. In this case, we need to know if the current nightly build fixes the 
problem or not.