Hi > I'm starting to think that the best (easiest) approach here is to simply gracefully disallow jmx files I agree. I dont see a way out of having to change your scripts or specifying a set of guidelines everyone must follow. For e.g. it is a rule that we never use full paths for our CSV files (they are always relative)
regards deepak On Mon, Sep 17, 2012 at 9:08 AM, 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. > > > 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] > >
