Then I think your question revolves around the JMS element - not UDVs :) -----Original Message----- From: Noel O'Brien [mailto:[email protected]] Sent: Thursday, February 26, 2009 12:00 PM To: [email protected] Cc: Steve Kapinos Subject: Re: When are paramerters/variables resolved?
On Thursday 26 February 2009 16:51:28 Steve Kapinos wrote: > Where are the UDVs compared to your samplers? They are not valid until > that element has been processed by the test plan. They are defined at the very top of my test plan > You can use properties which would be available from the start. I don't even get to start my test plan, the value in the Timeout field of overridden once you select a different GUI element It's easily reproducible: Create new test plan Add thread group Add JMS Point-to-Point Sampler Add non-numberic value to Timeout field Save, or Select a different GUI element (e.g. thread group) then go back to the JMS Sampler you will see the value has changed to "2000" Regards, Noel > -----Original Message----- > From: Noel O'Brien [mailto:[email protected]] > Sent: Thursday, February 26, 2009 10:30 AM > To: [email protected] > Subject: When are paramerters/variables resolved? > > Hi, > > I'm wondering at what point does JMeter resolve all variables (or > parameters? :) ) stored in a User Defined Variables element? > > I'm using serveral JMS samplers (point-to-point) and I'm using the same > timeout value for each one, so for convenience I would like to define it > in a > User Defined Variables element and reference it in the Timeout field of > the > JMS Sampler as ${timeout}. > > The problem is that when the GUI stores the data to the test element, or > it is > reloaded (i.e. once transfer() or configure() is called) the default > timeout > value (2000) is stored in the test element and displayed in the GUI > > I've debugged through it and the cause is that the getTimeout() method > in > JMSSampler.java is trying to return the value as an int, but as in my > case > timeout is ${timeout}, it is not resolved and the default value is > returned > instead. > > Is this a bug? > > What can I do in the meantime to work around it? I see two approaches: > 1. Modify getTimout() to return a string > 2. Somehow resolve ${timeout} to its value > > What are the ramifications of either of these approaches? > > Thanks, > Noel > > --------------------------------------------------------------------- > 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]
