Hi -
I am trying to use the jdbcFeeder but not having much luck.
No matter what I try, I end up with the exception below…
Simulation samples.MySimulation started…
Exception in thread “main” java.sql.SQLException: Invalid operation for forward only resultset : isLast
at oracle.jdbc.driver.OracleResultSetImpl.isLast(OracleResultSetImpl.java:458)
at com.excilys.ebi.gatling.jdbc.feeder.database.JdbcFeederSource$$anonfun$apply$1$$anon$1.hasNext(JdbcFeederSource.scala:36)
at scala.collection.Iterator$class.foreach(Iterator.scala:772)
at com.excilys.ebi.gatling.jdbc.feeder.database.JdbcFeederSource$$anonfun$apply$1$$anon$1.foreach(JdbcFeederSource.scala:34)
at scala.collection.generic.Growable$class.$plus$plus$eq(Growable.scala:48)
…
Here is a snippet of my simulation
val data = jdbcFeeder(URL, user, pass, “select 1 from dual”)
which I later pass into a .feed() somewhere in my scenario.
You’re probably not doing anything wrong, that’s just that ResultSet.isLast doesn’t seem to be supported by your Oracle driver.
JDBC, such a thing of beauty…
Is there any way I can grab this when updates like this if I am not using the bundle?? (i.e. working with from a generated maven-archetype within the IDE)
Also, can you advice me on my other question above?
and change the Gatling’s version you’re depending on with <gatling.version>1.X.X</gatling.version> in the properties section.
In this case, if you want to depend from latest snapshot from the 1.4.X branch (recommanded, as it’s a maintenance branch), you would to have to replace the <gatling.version> line by : <gatling.version>1.4.2-SNAPSHOT</gatling.version>
2/ You can clone Gatling’s git repos, build the snapshots whenever you need a feature not yet released, and change the Gatling’s version you’re depending on to match latest snapshot from git.
About your other question, it’s not currently possible to use “dynamic queries”.
I may be wrong, but feeders’ data is fetched before simulation starts and therefore can hardly depend on what’s going on in your simulation
Ok. Thanks Pierre. I’ll wait for the commit and try the 2 approaches you suggested to get updates without waiting on bundles.
As for the feeders, that seems quite limiting :(. Those values would be available on the http session on the server, but I can’t get to those either, so this was the next best thing to try.
How can we vote up or make feature requests. I can imagine a lot of people will find this useful.
I have the feeling you’re not trying to get the data from the right place. Gatling is supposed to emulate real users, and real users dont get the data directly from the database, but from the pages. Are you sure that you shouldn’t be using checks with saveAs?
Stephane - Thanks! I explored the saveAs path and it does get me there for about 90% of the things I need, which I am quite happy about.
The other 10% is not achievable at this point except the application is rewritten in some fashion. These values I need to get to are embedded in the http session on the server and not returned as part of any response data (html or json).
Our application performs search which could vary based on which user is logged in. When a user logs in, we either execute the last search they executed at the time they last logged in, or execute a default search if they don’t have any (say the just logged into the system for the first time).
The logic that determines what search to run happens behind the scene, i.e. (should i run a default search or execute the last search for a given user), and only returns the end results of the search to the user. Since that part is done on the server, the user actually never gets a response of which search was run. They only see the end results of the search.
When recording our scenarios, we need to know which search to run based on the current logged in user.
A request like this is formed, based on which search needs to be executed…
Since we never returned search_id to a user in any of their response data, we don’t know which id to pass in for this request. Also, this are dynamic in nature for a user, so they same search id is not always guaranteed to be tied to a user.
Can't you build 2 similar, yet different scenarios? Can't you make a
JdbcFeeder for users with default search and one for regular ones?
If you can do that, you can run both populations in the same Simulation.
Stephane - I wish it was that simple. As I mentioned before, the logic to determine what search to run is completely housed and transparent to the logged in user and that these values are dynamic in nature.
A jdbcFeeder will create the values up front from my understanding, which doesn’t leave any room for dynamic nature of this. More pressing is the fact the logic that encapsulates which search to run. I don’t see a way (or can’t think of one right now) to encapsulate that in DB, without doing some much unwarranted fire fighting.
Your problem is not really related to Gatling, you would face it whatever
the tool.
I'm afraid you don't have a choice and have to build a feature dedicated to
exposing some HTTP session values (would be best over HTTP). Of course,
this feature doesn't have to be enabled on your live system.