Re: Custom statistics: Syntax error when function wrapper is invoked

Hate to say this... it was an issue with indentation.

Otherwise the code works fine.

-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl

Re: Installation problems

Adam,

I think that there is no
net\grinder\console\swingui\resources\Console.properties file in the
classpath. Check it!

Best Regards,
KArol Muszynski

Sosnowski, Adam wrote:
> Hi,
> 
> This is my first time installing anything like grinder, I have come
accross
> a small problem when trying to run "java net.grinder.Console" I keep
getting
> the following exception:
> 
> How do I go about getting this base class: I downloaded the
grinder.src.zip
> and build it from scratch..
> 
> java.util.MissingResourceException: Can't find bundle for base name
> net.grinder.console.swing
> ui.resources.Console, locale en_CA
>         at
>
java.util.ResourceBundle.throwMissingResourceException(ResourceBundle.ja
va:8
> 04)

-Dgrinder.duration on command line working OK...

Philip,
          Switched across to beta27 and the issue no longer
exits....many thanks

                                           Sc0tt...

NB.  Was using beta23.    I will endevour to use the latest one from
now on.....

>>> "Philip Aston" <paston@...> 09/30/05 12:29pm >>>

Scott Russell writes on 28 September 2005 10:26:
 > 
 > I have a grinder script running with the following command line
 > option:-
 > 
 > -Dgrinder.duration=180000
 > 
 > ie quit grinder after 3 minutes....
 > 
 > However, each time grinder complains that:-
 > 
 >  warning, property, grinder.duration, does not specify an integer
 >  value
 > 
 > 
 > Does anyone have any ideas?
 > 
 > Also, the command

Capturing Errors

Hello all, newbie to The Grinder. Using G3 Beta 27...

While running my scripts I occasionally get an error (stems from database 
issues we are having). Due to the amount of data we would like to capture, 
I'll need to leave my script running for long periods of time, simply 
pounding the server.

When these errors are encountered they will created an error for each 
subsequent test on that thread. Data from one test is used to seed the next 
test, thus creating a snowball of errors when one fails.

Is there any way to acknowledge the fact that the script has encountered an 
error and kill the Grinder instance, or better yet swipe that thread's data 
from the data log (rather than logging it and showing an error in the 
console's "errors" column).

I just hate to collect data all night if the tests fail half way through. 
Probably less brutal to the server to just end the tests than keeping 
spitting out null parameter errors.

Thanks!

- Skylar

_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar – get it now! 
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/

-------------------------------------------------------
This SF.Net email is sponsored by:

RE: Basic

cnguyen writes on 30 September 2005 22:58: 
 > I am only trying to see if I could use a java class in grinder: 
 > 
 > Zoom.py: 
 > 
 > from net.grinder.script import Test; 
 > from net.grinder.script.Grinder import grinder; 
 > import zoom; 
 > test = Test(1, "c"); 
 > z=zoom() 
 > class TestRunner: 
 >   def __call__(self): 
 >     zz=test.wrap(z); 
 >     zz.p("s"); 
 > 
 > I am getting: 
 > 
 > 9/30/05 2:50:56 PM (process zeus-5): Error running worker process 
 > (Jython error encountered initialising test script) 
 > 
 > net.grinder.engine.process.JythonScriptExecutionException: Jython 
 > error encountered initialising test script 
 >  at
net.grinder.engine.process.JythonScript.<init>(JythonScript.java:81) 
 > 
 > <snip> 
 > 
 >  at
net.grinder.engine.process.GrinderProcess.main(GrinderProcess.java:109) 

RE: Basic

I have tried your suggestion but it didn't work. I ended up putting my class
inside net.grinder.script package inside grinder.jar, and it works. All
these were before I got familiar with python class structure and I wanted to
keep the connection to the database open while repeatedly hitting it. Soon,
I discovered that python is simple and I no longer need to use a java class
Def __init__
	Open connection to DB
Def __call__
	Hitting it
Def __del__
	Close connection
Well, now I know something about python.
And the grinder works great!!
For some reasons, when I stress test an Oracle db using OCI OS
authentication, I have to press Play button twice to get the SQL executions
going. (I have the script below.)
Thanks Philip.

from java.sql import DriverManager
from net.grinder.script.Grinder import grinder
from net.grinder.script import Test
from oracle.jdbc import OracleDriver

test1 = Test(1, "Database insert")
test2 = Test(2, "Database query")

def getConnection():
	try:
		DriverManager.registerDriver(OracleDriver())	
		return DriverManager.getConnection("jdbc:oracle:oci8:/ <at> mo")

Grinder Distribution Problem

RE: Cached files not out of date but reported so

Dominic Binks writes on 29 September 2005 16:31:
 > I'm using grinder (3.0) across a number of machines which have some
 > clock drift between them. When I distribute my files out to the
 > agents, it distributes them and then when I try to start the test
 > run I get a message telling me that the agent's files are out of
 > date (which they aren't 'cause I just pushed them out). I would
 > like to understand the processing here so that I work around this
 > problem. Can anyone help me understand what's going on here?

This shouldn't have anything to do with clock drift. The file
times on the remote machines are not currently used.

With the current implementation, you need to redistribute if any of
the following occurs after you last pressed the update button:
	- A new agent process connects to the console
	- You save a file in the console
	- The distribution directory or file filter pattern changes

This will change slightly in a future implementation
	- Connecting agents with an up to date cache will not
	  trigger the need to redistribute.
	- Changes made to files in the distribution directory
	  by tools other than the console will be detected.

Of course, this isn't helpful in working out what your problem is.

First, please check you are using at least 3.0b26. Secondly, can
you prove that its not down to clock drift by just starting agent
process on the same machine as the console.

- Phil

-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl

RE: Capturing Errors

Skylar Sutton writes on 04 October 2005 14:26:
 > Hello all, newbie to The Grinder. Using G3 Beta 27...
 > 
 > While running my scripts I occasionally get an error (stems from
 > database issues we are having). Due to the amount of data we would
 > like to capture, I'll need to leave my script running for long
 > periods of time, simply pounding the server.
 > 
 > When these errors are encountered they will created an error for
 > each subsequent test on that thread. Data from one test is used to
 > seed the next test, thus creating a snowball of errors when one
 > fails.
 > 
 > Is there any way to acknowledge the fact that the script has
 > encountered an error and kill the Grinder instance, or better yet
 > swipe that thread's data from the data log (rather than logging it
 > and showing an error in the console's "errors" column).
 > 
 > I just hate to collect data all night if the tests fail half way
 > through. Probably less brutal to the server to just end the tests
 > than keeping spitting out null parameter errors.

There's currently no API to terminate an entire process, or even
a whole thread.

If you raise an exception from __call__, the current worker thread's
run will terminate, and the engine will use the thread to start the
next run. This is what most people want, and may be right for you.
(Presumably the next run would start at the beginning of your
scenario).

Other than that, I can think of 2 hacks:

	1. System.exit(). This is likely to lose the last buffer
	   of data from your data file.

	2. Have your TestRunner have a "disable" flag. When you
	   decide your thread/process is no longer good, set the
	   flag and raise an exception. Check the flag at the
	   beginining of __call__(). If its set, sleep for a
	   second and return.

Regards,

- Phil

-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl

(no subject)

confirm 249794 
 --
 Email.it, the professional e-mail, gratis per te: http://www.email.it/f

 Sponsor:
 Erbe e tisane di primissima qualità.
Inoltre 1800 articoli erboristici. Tutti a portata di un click !

 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=1309&d=20051010

-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl