CSV Data Set Config parameters cannot be used in some Config elements

[asfimport]

Michal Kaczmarzyk (Bug 40934): Connection to Oracle database. All necessary info (host, port, SID) are stored in *.txt file. CSV Data Set Config gets them from file and assigns to variables. ,Variable Names (comma-delimited), field in CSV Data Set Config is: host,port,sid In JDBC Connection Configuration in 'Database URL' field there is: jdbc:oracle:thin:@${host}:${port}:${sid}

After running the test plan HTTP Response Message is: 'java.sql.SQLException: Invalid number format for port number', although all the values from file were read correctly (checked with Java request). When 'Database URL' field is: jdbc:oracle:thin:@nemo:1523:MY_SID (fixed values), everything is OK.

CSVRead function instead of CSV Data Set Config, makes it also working just fine.

It looks like, after getting the values from file by CSV Data Set Config, the values are not replaced in ${variable_name} reference, in JDBC Connection Configuration element.

Votes in Bugzilla: 2 Severity: normal OS: Windows XP Resolution: WORKSFORME

[asfimport]

Sebb (migrated from Bugzilla): User Defined Variables also work OK.

The CSV Dataset does not work with JDBC Config because it processes the file read after the other Config elements have been processed.

Not sure how to fix this yet.

[asfimport]

Sebb (migrated from Bugzilla): Now at least documented in known bugs and component_reference...

[asfimport]

Sebb (migrated from Bugzilla): In fact CSV Dataset works OK in Configuration elements that process their data at run time - for example HTTP Auth Manager, Header Manager and Cookie Manager (which now handles variables).

The problem with JDBC Config is that its data items are processed during test initialisation, which is too early for the CSV variables to be defined.

[asfimport]

Nikolai Prokoschenko (migrated from Bugzilla): So this bug is actually about JDBC sampler, right? Judging from mailing list traffic and own experience, it's the only sampler that doesn't support user-defined variables. Considering this bug didn't exist in the "old" JDBC sampler (e.g. in 2.0.1) it is introduced in 2.3 and is making life difficult for people like myself who have to migrate from 2.0.1

I'm having the same problems: variables in JDBC configuration field are not used, i.e. replaced with blanks. Using verbatim configuration in these fields works, using properties on the command line works too, but not variables with values calculated at run-time.

If this is really a problem with initialization order (which it seems it is), could some developers please take a look the JDBC sampler and make it use the runtime configuration? I tried to, but my experience is limited and JMeter code is foreign to me.

[asfimport]

Sebb (migrated from Bugzilla): (In reply to comment 4)

So this bug is actually about JDBC sampler, right? Judging from mailing list traffic and own experience, it's the only sampler that doesn't support user-defined variables.

Not strictly true, there was another case recently not involving JDBC. See: http://www.nabble.com/User-and-Password-Variable-Problem-td15598236.html#a15598236

Considering this bug didn't exist in the "old" JDBC sampler (e.g. in 2.0.1) it is introduced in 2.3 and is making life difficult for people like myself who have to migrate from 2.0.1

CSV Dataset did not exist in 2.0.1.

I'm having the same problems: variables in JDBC configuration field are not used, i.e. replaced with blanks. Using verbatim configuration in these fields works, using properties on the command line works too, but not variables with values calculated at run-time.

Exactly what used to work in 2.0.1 and does not work now?

If this is really a problem with initialization order (which it seems it is), could some developers please take a look the JDBC sampler and make it use the runtime configuration? I tried to, but my experience is limited and JMeter code is foreign to me.

It would help if you could attach a simple test case that works in 2.0.1 and fails in the later version of JMeter.

[asfimport]

Nikolai Prokoschenko (migrated from Bugzilla): (In reply to comment 5)

(In reply to comment 4) > Considering this bug didn't exist in the "old" JDBC > sampler (e.g. in 2.0.1) it is introduced in 2.3 and is making life difficult > for people like myself who have to migrate from 2.0.1 CSV Dataset did not exist in 2.0.1.

My problematic case doesn't involve CSV Dataset, but generated variables instead.

> I'm having the same problems: variables in JDBC configuration field are not > used, i.e. replaced with blanks. Using verbatim configuration in these fields > works, using properties on the command line works too, but not variables with > values calculated at run-time. Exactly what used to work in 2.0.1 and does not work now?

Existing scripts which use the JDBC Sampler with a properties file and user-defined variables. Pool variable has been set manually for the config element and the sampler.

It would help if you could attach a simple test case that works in 2.0.1 and fails in the later version of JMeter.

I'll try to do so tomorrow.

[asfimport]

Nikolai Prokoschenko (migrated from Bugzilla): This testcase fires two simple JDBC queries, one query uses variables in the connection definition, the other does not. The variables are defined in the test case and are apparently set according to the Debug sampler. In the first case, the connection cannot be established, in the second the query succeeds. Debug log also spots the following lines, which prove that variable replacement doesn't take place, which is bad for any kind of dynamic testing.

DEBUG - jmeter.protocol.jdbc.config.DataSourceElement: Driver: oracle.jdbc.driver.OracleDriver DbUrl: jdbc:oracle:thin:@${firstDbHost}:1521:DB User: ${firstDbUser}

DEBUG - jmeter.protocol.jdbc.config.DataSourceElement: Driver: oracle.jdbc.driver.OracleDriver DbUrl: jdbc:oracle:thin:@192.168.1.151:1521:DB User: DB_USER

Created attachment 40934.jmx: Simplified testcase

[asfimport]

Sebb (migrated from Bugzilla): (In reply to comment 7)

Created an attachment (id=21600) [details] Simplified testcase

This testcase fires two simple JDBC queries, one query uses variables in the connection definition, the other does not. The variables are defined in the test case and are apparently set according to the Debug sampler. In the first case, the connection cannot be established, in the second the query succeeds. Debug log also spots the following lines, which prove that variable replacement doesn't take place, which is bad for any kind of dynamic testing.

DEBUG - jmeter.protocol.jdbc.config.DataSourceElement: Driver: oracle.jdbc.driver.OracleDriver DbUrl: jdbc:oracle:thin:@${firstDbHost}:1521:DB User: ${firstDbUser}

DEBUG - jmeter.protocol.jdbc.config.DataSourceElement: Driver: oracle.jdbc.driver.OracleDriver DbUrl: jdbc:oracle:thin:@192.168.1.151:1521:DB User: DB_USER

Yes, I see those errors.

However the test case does not work in JMeter 2.0.1.

[asfimport]

Nikolai Prokoschenko (migrated from Bugzilla): (In reply to comment 8)

Yes, I see those errors. However the test case does not work in JMeter 2.0.1.

Yes, but there is almost nothing I can do about it -- my test cases included some custom functions which read properties from a file and besides that the JDBC sampler wouldn't work without an association with a config element.

However, this test case shows that either the JDBC sampler or the config element doesn't properly expand properties/variables and thus it's a regression from 2.0.1, since expansion worked back then. This is why I don't think that CSV data set is the buggy one in this case, but I might as well be wrong.

Should I open a separate bug for this particular case or maybe the title of this bug should be changed?

[asfimport]

Sebb (migrated from Bugzilla): (In reply to comment 9)

(In reply to comment 8)

> Yes, I see those errors. > However the test case does not work in JMeter 2.0.1.

Yes, but there is almost nothing I can do about it -- my test cases included some custom functions which read properties from a file and besides that the JDBC sampler wouldn't work without an association with a config element.

It does not have to be an existing test case.

However, this test case shows that either the JDBC sampler or the config element doesn't properly expand properties/variables and thus it's a regression from 2.0.1, since expansion worked back then. This is why I don't think that CSV data set is the buggy one in this case, but I might as well be wrong.

Should I open a separate bug for this particular case or maybe the title of this bug should be changed?

Good idea.

But we still need a test case that works on 2.0.1 and does not work on 2.3/2.3.1

[asfimport]

Nikolai Prokoschenko (migrated from Bugzilla): Sebb, I've tried to create an appropriate test-case, but failed, since 2.3.1 requires an additional element which is not created automatically (maybe there is room for some "migration support" for the samplers?). I've opened issue #44519 for my actual problem, could you please take a look at that? It might also fix a half of this bug too...

[asfimport]

@pmouawad (migrated from Bugzilla): Shouldn't this one be closed ? Attached test case is not readable in JMeter 2.5.

Regards Philippe

[asfimport]

Sebb (migrated from Bugzilla): Need proof that something is not working as intended