On 17 September 2012 17:08, Oliver Lloyd <[email protected]> wrote: > The trouble is I have no control over the structure of the jmx files - they > can come from other teams / people - so the script has to adapt to what it > gets given. > > I'm starting to think that the best (easiest) approach here is to simply > gracefully disallow jmx files that do not use numeric literals where I need > them to. Trying to support a solution that allows variables in these fields > is probably just going to end up giving me grey hair and might never work > that well.
Why not produce a template JMX file for the users that they can tailor? The TestPlan can contain variables derived from properties, along with a thread group that uses the variables. Or just use a Thread Group that uses the properties directly. Or just tell the other teams that they must use specific property names for the fields you need to vary. If you are providing a service for the other users then they should be prepared to make some adjustments in order to make your job easier. > > On 17 Sep 2012, at 16:51, sebb wrote: > >> On 17 September 2012 09:54, Oliver Lloyd <[email protected]> wrote: >>> Hey, that's actually a very good idea. It might get tricky if the thread >>> count were smaller than the size of the farm but it's a much better >>> solution than my first thought. Thanks. >>> >> >> Another way is to change the test plan so that it uses properties for >> such things as loop count and ramp-up (with suitable defaults so the >> test can be run without needing any to be defined). >> >> Then the controlling script can do the calculations and pass in the >> appropriate properties - or you can create a user.properties file and >> supply that. >> >> This is likely to be more flexible long term if you parameterise the >> test appropriately. >> >>> >>> On 17 Sep 2012, at 09:00, Shmuel Krakower wrote: >>> >>>> Hi >>>> One idea is instead of parsing the value; wrap it. >>>> For example said that the thread group users is 50 and you have 5 machines >>>> in the farm you would need to divide by 5 with eval expression like >>>> ${__eval(50 / 5)} this can be the value in the thread group configuration. >>>> >>>> Now you dont care if its a fixed value or a variable. >>>> בתאריך 2012 9 17 07:35, מאת "Anthony Johnson" <[email protected]>: >>>> >>>>> I assume that you are trying to spread the load as equally as possible? >>>>> >>>>> Could you would some magic with the Beanshell Server? >>>>> >>>>> Perhaps you can block every test in a setup Thread group or a >>>>> Once-Only Controller until your test distribution is done and then >>>>> open the gates? >>>>> >>>>> Good luck, >>>>> >>>>> Anthony >>>>> >>>>> On Sun, Sep 16, 2012 at 9:48 PM, Oliver Lloyd <[email protected]> >>>>> wrote: >>>>>> No really, sadly this is the problem statement. >>>>>> >>>>>> So, what I'm working on is a program that takes the jmeter jmx file and >>>>> farms it out over a bunch of machines. Before it does this it parses the >>>>> jmx to get things like thread counts and references to csv files - you >>>>> need >>>>> these to make the process useful. >>>>>> >>>>>> It's all very easy if I could be sure that the values will always be >>>>> absolute but the use case is such that this is simply not the case - so >>>>> I'm >>>>> looking for the best approach to handle it. As far as I can see, the best >>>>> way to find out what ${myVar} equals is to fire up JMeter and see what it >>>>> get's set to but then I really don't want to do that, it's messy and >>>>> potentially not even possible. Is there an alternative? >>>>>> >>>>>> >>>>>> On 16 Sep 2012, at 22:33, Deepak Shetty wrote: >>>>>> >>>>>>>> I want to take this jmx xml file and parse it to read the location of >>>>> the >>>>>>> file so I can do stuff with it (before I actually run the >test) >>>>>>> I cant help but feel that this is a proposed solution to a problem >>>>> rather >>>>>>> than the problem itself. >>>>>>> Literally you are asking the equivalent of I have a java class , can i >>>>>>> figure out the value of a variable without running the java class. In >>>>> which >>>>>>> case the answer is no. However a variable is just initial state + >>>>> algorithm >>>>>>> so you can always figure out its value it would have if you are willing >>>>> to >>>>>>> duplicate the steps.(or in your case , how does JMeter determine >>>>>>> ${myTestRoot}) or you can specify your original problem statement and >>>>> see >>>>>>> if anyone has a different suggestion. >>>>>>> >>>>>>> regards >>>>>>> deepak >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Sun, Sep 16, 2012 at 5:27 AM, Oliver Lloyd <[email protected] >>>>>> wrote: >>>>>>> >>>>>>>> Is it possible to resolve the value of a jmeter variable from an >>>>> external >>>>>>>> program? >>>>>>>> >>>>>>>> So, if I have a jmx that has, for example, a CSV Config control that >>>>> has a >>>>>>>> literal path of: >>>>>>>> >>>>>>>> ${myTestRoot}/some/other/dir/myfile.csv >>>>>>>> >>>>>>>> Using an external program, I want to take this jmx xml file and parse >>>>> it >>>>>>>> to read the location of the file so I can do stuff with it (before I >>>>>>>> actually run the test). But because there is a variable in the literal >>>>>>>> value of the file path I obviously cannot. >>>>>>>> >>>>>>>> What I would like to do is work out a way (probably via some form of >>>>>>>> temporary plugin) to start the jmeter process in such a way that the >>>>>>>> variable is instantiated and I am able to get its value, but without >>>>>>>> actually starting the test. >>>>>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> To unsubscribe, e-mail: [email protected] >>>>>>>> For additional commands, e-mail: [email protected] >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: [email protected] >>>>>> For additional commands, e-mail: [email protected] >>>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [email protected] >>>>> For additional commands, e-mail: [email protected] >>>>> >>>>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
