grinder-development Mailing List for The Grinder
Distributed load testing framework - Java, Jython, or Clojure scripts.
Brought to you by:
philipa
You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(5) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(2) |
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
(4) |
Nov
(3) |
Dec
(4) |
2003 |
Jan
(4) |
Feb
(10) |
Mar
(13) |
Apr
(8) |
May
(15) |
Jun
(12) |
Jul
(8) |
Aug
(8) |
Sep
(25) |
Oct
(10) |
Nov
(39) |
Dec
(27) |
2004 |
Jan
(40) |
Feb
(25) |
Mar
(28) |
Apr
(19) |
May
(29) |
Jun
(19) |
Jul
(26) |
Aug
(17) |
Sep
(14) |
Oct
(5) |
Nov
(1) |
Dec
(4) |
2005 |
Jan
(15) |
Feb
(13) |
Mar
(64) |
Apr
(15) |
May
(18) |
Jun
(18) |
Jul
(33) |
Aug
(5) |
Sep
(19) |
Oct
(9) |
Nov
(16) |
Dec
(26) |
2006 |
Jan
(9) |
Feb
|
Mar
(11) |
Apr
(9) |
May
(38) |
Jun
(8) |
Jul
(24) |
Aug
(4) |
Sep
(1) |
Oct
(26) |
Nov
(30) |
Dec
(22) |
2007 |
Jan
(19) |
Feb
(12) |
Mar
(15) |
Apr
(14) |
May
(6) |
Jun
(4) |
Jul
(5) |
Aug
(11) |
Sep
(4) |
Oct
(8) |
Nov
(11) |
Dec
(14) |
2008 |
Jan
(13) |
Feb
(33) |
Mar
(32) |
Apr
(23) |
May
(20) |
Jun
(6) |
Jul
(4) |
Aug
(2) |
Sep
(15) |
Oct
(19) |
Nov
(41) |
Dec
(34) |
2009 |
Jan
(17) |
Feb
(9) |
Mar
(28) |
Apr
(6) |
May
(2) |
Jun
(3) |
Jul
(4) |
Aug
(4) |
Sep
(4) |
Oct
(3) |
Nov
(7) |
Dec
(48) |
2010 |
Jan
(16) |
Feb
(27) |
Mar
(13) |
Apr
(15) |
May
(15) |
Jun
(5) |
Jul
(5) |
Aug
(29) |
Sep
(8) |
Oct
(3) |
Nov
(4) |
Dec
(21) |
2011 |
Jan
(4) |
Feb
(9) |
Mar
(12) |
Apr
(5) |
May
(3) |
Jun
(6) |
Jul
(11) |
Aug
(12) |
Sep
(9) |
Oct
(12) |
Nov
(11) |
Dec
(21) |
2012 |
Jan
(23) |
Feb
(27) |
Mar
(61) |
Apr
(23) |
May
(36) |
Jun
(6) |
Jul
(11) |
Aug
(6) |
Sep
(44) |
Oct
(2) |
Nov
(2) |
Dec
|
2013 |
Jan
(1) |
Feb
(7) |
Mar
(2) |
Apr
|
May
(4) |
Jun
(4) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
(2) |
2014 |
Jan
(2) |
Feb
(3) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(3) |
Oct
(1) |
Nov
|
Dec
|
2015 |
Jan
|
Feb
|
Mar
(1) |
Apr
(24) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2016 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
(2) |
Oct
(1) |
Nov
|
Dec
|
2017 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: gradeawarrior <psa...@gm...> - 2017-01-03 22:32:02
|
I've been an avid Grinder user for nearly 11 years, using it on several WebApp projects (both backend and frontend) and at different companies. What I've enjoyed over many other frameworks is its flexibility to handle virtually any type of performance/load test because at its core is Java! It still holds up today and I frequently use Grinder as a baseline for evaluating other performance tools. However, one thing that has vexed me over the years is the lack of a "simple" documentation for getting started. Granted, I've always figured it out eventually when I've had to re-invest time and energy seeing which sample script works with the latest version of Grinder, and deciphering which libraries have been deprecated. To counter this, I've published a "mavenized-grinder" project: https://github.com/gradeawarrior/mavenized-grinder This is a sample working Grinder project that simply works OOTB. Basic requirements is Java 6+ (tested with Java 8) and Maven installed. Also take note that I primarily run from command-line and I've tested working on *nix based operating systems including OSX. NOTE: This of course is a sample project that I intend to improve upon. Feedback is welcomed! -- View this message in context: http://grinder.996249.n3.nabble.com/Working-Maven-Grinder-Project-OOTB-tp9265.html Sent from the Grinder - Dev mailing list archive at Nabble.com. |
From: Darren B. <bal...@gm...> - 2016-10-06 14:50:11
|
Anyone else have any insight/ideas on this? Development? On Fri, Sep 30, 2016 at 10:43 AM, Darren Ball <bal...@gm...> wrote: > Hi Joel, > > Thanks for your feedback. > This is actually during the stopping process or the tear down. > > My polling is every 5 seconds, but displayed in the original was a test > that was showing the inconsistent state of worker tracking during atexit. > > Update on this as well: > > If I use __del__, the state of the workers remains 'running', but if > atexit is used, and registered outside of ThreadRunner, this state seems to > be 'lost'. During shutdown this is a problem. By adding the atexit > outside of TestRunner, the total time of the test is only that of > TestRunner. > Adding __del__, extends the execution time of TestRunner, calculations are > off then. My cleanup can take several (> 10) seconds... > > > > > > On Fri, Sep 30, 2016 at 9:53 AM, Joel Lucuik <joe...@gm...> > wrote: > >> This is likely the scenario where the agent is just starting. To avoid >> this, consider polling the running status every 60 seconds. With that you >> can skip those 30 seconds scenario where grinder is trying to start worker >> processes. >> >> >> >> Maybe increase the sleeptime between polling status. >> >> >> On Thu, Sep 29, 2016 at 1:23 PM, Darren Ball <bal...@gm...> >> wrote: >> >>> Hi All, >>> >>> I've come across a pretty unusual situation in my polling logic for >>> workers (use to tell if they are 'done'). I have test logic that runs many >>> scenarios, and I typically poll for workers like this: >>> >>> workerstate=$(curl --noproxy localhost -s -X GET http://localhost:6373/agents/status | /usr/local/bin/jq -r '.[].workers[].state' | wc -l) >>> >>> >>> I have an atExit function registered, that cleans up data that was created/generated during the run. >>> >>> The odd behaviour can be seen below, captured with a simply loop outside the run for observation (1 sec interval) to check the state of workers while a test was running. It seams that once test runner exits, the state of status of t >>> >>> the agents's workers are 'cleared' (which was my indication that things were really done). Grinder also issues a termination at 10 seconds as well, regrettably. >>> >>> As can been seen, the agent workers look like their state went from running to nothing and then back to finished. Time between this is 30 seconds. Threads are still up during this period, as the cleanup is still being processed. >>> >>> Is there any efficient way to determine successfully that the workers have passed the 'finished' state? I can't really rely on polling for a state of finished, as there is a chance that it will be missed (it is cleared). >>> >>> >>> Thanks. >>> >>> >>> [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566:0 >>> ","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running", >>> "workers":[{"maximum-threads":20,"running-threads":20,"id":" >>> i-0a98f94c8d82cb1fd-24:371439501|1475085007713|1565583566:25 >>> ","name":"i-0a98f94c8d82cb1fd-24","number":24,"state":"running"}]}] >>> [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566:0 >>> ","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running", >>> "workers":[{"maximum-threads":20,"running-threads":20,"id":" >>> i-0a98f94c8d82cb1fd-24:371439501|1475085007713|1565583566:25 >>> ","name":"i-0a98f94c8d82cb1fd-24","number":24,"state":"running"}]}] >>> [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566:0 >>> ","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running", >>> "workers":[{"maximum-threads":20,"running-threads":20,"id":" >>> i-0a98f94c8d82cb1fd-24:371439501|1475085007713|1565583566:25 >>> ","name":"i-0a98f94c8d82cb1fd-24","number":24,"state":"running"}]}] >>> [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566:0 >>> ","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running", >>> "workers":[]}] >>> [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566:0 >>> ","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running", >>> "workers":[]}] >>> [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566:0 >>> ","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running", >>> "workers":[]}] >>> [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566:0 >>> ","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running", >>> "workers":[]}] >>> [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566:0 >>> ","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running", >>> "workers":[]}] >>> [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566:0 >>> ","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running", >>> "workers":[]}] >>> [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566:0 >>> ","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running", >>> "workers":[]}] >>> [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566:0 >>> ","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running", >>> "workers":[]}] >>> [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566:0 >>> ","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running", >>> "workers":[]}] >>> [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566:0 >>> ","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running", >>> "workers":[]}] >>> [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566:0 >>> ","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running", >>> "workers":[]}] >>> [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566:0 >>> ","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running", >>> "workers":[]}] >>> [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566:0 >>> ","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running", >>> "workers":[]}] >>> [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566:0 >>> ","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running", >>> "workers":[]}] >>> [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566:0 >>> ","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running", >>> "workers":[]}] >>> [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566:0 >>> ","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running", >>> "workers":[]}] >>> [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566:0 >>> ","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running", >>> "workers":[]}] >>> [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566:0 >>> ","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running", >>> "workers":[]}] >>> [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566:0 >>> ","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running", >>> "workers":[]}] >>> [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566:0 >>> ","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running", >>> "workers":[]}] >>> [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566:0 >>> ","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running", >>> "workers":[]}] >>> [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566:0 >>> ","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running", >>> "workers":[]}] >>> [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566:0 >>> ","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running", >>> "workers":[]}] >>> [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566:0 >>> ","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running", >>> "workers":[]}] >>> [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566:0 >>> ","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running", >>> "workers":[]}] >>> [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566:0 >>> ","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running", >>> "workers":[]}] >>> [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566:0 >>> ","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running", >>> "workers":[]}] >>> [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566:0 >>> ","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running", >>> "workers":[]}] >>> [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566:0 >>> ","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running", >>> "workers":[]}] >>> [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566:0 >>> ","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running", >>> "workers":[]}] >>> [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566:0 >>> ","name":"i-0a98f94c8d82cb1fd","number":0,"state":"finished" >>> ,"workers":[{"maximum-threads":0,"running-threads":0,"id":" >>> i-0a98f94c8d82cb1fd-24:371439501|1475085007713|1565583566:25","name":"i- >>> 0a98f94c8d82cb1fd-24","number":24,"state":"finished"}]}] >>> [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566:0 >>> ","name":"i-0a98f94c8d82cb1fd","number":0,"state":"finished" >>> ,"workers":[{"maximum-threads":0,"running-threads":0,"id":" >>> i-0a98f94c8d82cb1fd-24:371439501|1475085007713|1565583566:25","name":"i- >>> 0a98f94c8d82cb1fd-24","number":24,"state":"finished"}]}] >>> [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566:0 >>> ","name":"i-0a98f94c8d82cb1fd","number":0,"state":"started", >>> "workers":[]}] >>> [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566:0 >>> ","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running", >>> "workers":[]}] >>> [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566:0 >>> ","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running", >>> "workers":[]}] >>> >>> >>> ------------------------------------------------------------ >>> ------------------ >>> >>> _______________________________________________ >>> grinder-use mailing list >>> gri...@li... >>> https://lists.sourceforge.net/lists/listinfo/grinder-use >>> >>> >> >> ------------------------------------------------------------ >> ------------------ >> >> _______________________________________________ >> grinder-use mailing list >> gri...@li... >> https://lists.sourceforge.net/lists/listinfo/grinder-use >> >> > |
From: Darren B. <bal...@gm...> - 2016-09-30 14:44:26
|
Hi Joel, Thanks for your feedback. This is actually during the stopping process or the tear down. My polling is every 5 seconds, but displayed in the original was a test that was showing the inconsistent state of worker tracking during atexit. Update on this as well: If I use __del__, the state of the workers remains 'running', but if atexit is used, and registered outside of ThreadRunner, this state seems to be 'lost'. During shutdown this is a problem. By adding the atexit outside of TestRunner, the total time of the test is only that of TestRunner. Adding __del__, extends the execution time of TestRunner, calculations are off then. My cleanup can take several (> 10) seconds... On Fri, Sep 30, 2016 at 9:53 AM, Joel Lucuik <joe...@gm...> wrote: > This is likely the scenario where the agent is just starting. To avoid > this, consider polling the running status every 60 seconds. With that you > can skip those 30 seconds scenario where grinder is trying to start worker > processes. > > > > Maybe increase the sleeptime between polling status. > > > On Thu, Sep 29, 2016 at 1:23 PM, Darren Ball <bal...@gm...> > wrote: > >> Hi All, >> >> I've come across a pretty unusual situation in my polling logic for >> workers (use to tell if they are 'done'). I have test logic that runs many >> scenarios, and I typically poll for workers like this: >> >> workerstate=$(curl --noproxy localhost -s -X GET http://localhost:6373/agents/status | /usr/local/bin/jq -r '.[].workers[].state' | wc -l) >> >> >> I have an atExit function registered, that cleans up data that was created/generated during the run. >> >> The odd behaviour can be seen below, captured with a simply loop outside the run for observation (1 sec interval) to check the state of workers while a test was running. It seams that once test runner exits, the state of status of t >> >> the agents's workers are 'cleared' (which was my indication that things were really done). Grinder also issues a termination at 10 seconds as well, regrettably. >> >> As can been seen, the agent workers look like their state went from running to nothing and then back to finished. Time between this is 30 seconds. Threads are still up during this period, as the cleanup is still being processed. >> >> Is there any efficient way to determine successfully that the workers have passed the 'finished' state? I can't really rely on polling for a state of finished, as there is a chance that it will be missed (it is cleared). >> >> >> Thanks. >> >> >> [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566: >> 0","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running" >> ,"workers":[{"maximum-threads":20,"running-threads":20,"id": >> "i-0a98f94c8d82cb1fd-24:371439501|1475085007713|1565583566: >> 25","name":"i-0a98f94c8d82cb1fd-24","number":24,"state":"running"}]}] >> [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566: >> 0","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running" >> ,"workers":[{"maximum-threads":20,"running-threads":20,"id": >> "i-0a98f94c8d82cb1fd-24:371439501|1475085007713|1565583566: >> 25","name":"i-0a98f94c8d82cb1fd-24","number":24,"state":"running"}]}] >> [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566: >> 0","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running" >> ,"workers":[{"maximum-threads":20,"running-threads":20,"id": >> "i-0a98f94c8d82cb1fd-24:371439501|1475085007713|1565583566: >> 25","name":"i-0a98f94c8d82cb1fd-24","number":24,"state":"running"}]}] >> [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566: >> 0","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running" >> ,"workers":[]}] >> [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566: >> 0","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running" >> ,"workers":[]}] >> [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566: >> 0","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running" >> ,"workers":[]}] >> [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566: >> 0","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running" >> ,"workers":[]}] >> [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566: >> 0","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running" >> ,"workers":[]}] >> [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566: >> 0","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running" >> ,"workers":[]}] >> [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566: >> 0","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running" >> ,"workers":[]}] >> [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566: >> 0","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running" >> ,"workers":[]}] >> [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566: >> 0","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running" >> ,"workers":[]}] >> [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566: >> 0","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running" >> ,"workers":[]}] >> [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566: >> 0","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running" >> ,"workers":[]}] >> [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566: >> 0","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running" >> ,"workers":[]}] >> [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566: >> 0","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running" >> ,"workers":[]}] >> [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566: >> 0","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running" >> ,"workers":[]}] >> [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566: >> 0","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running" >> ,"workers":[]}] >> [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566: >> 0","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running" >> ,"workers":[]}] >> [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566: >> 0","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running" >> ,"workers":[]}] >> [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566: >> 0","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running" >> ,"workers":[]}] >> [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566: >> 0","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running" >> ,"workers":[]}] >> [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566: >> 0","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running" >> ,"workers":[]}] >> [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566: >> 0","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running" >> ,"workers":[]}] >> [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566: >> 0","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running" >> ,"workers":[]}] >> [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566: >> 0","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running" >> ,"workers":[]}] >> [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566: >> 0","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running" >> ,"workers":[]}] >> [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566: >> 0","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running" >> ,"workers":[]}] >> [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566: >> 0","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running" >> ,"workers":[]}] >> [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566: >> 0","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running" >> ,"workers":[]}] >> [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566: >> 0","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running" >> ,"workers":[]}] >> [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566: >> 0","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running" >> ,"workers":[]}] >> [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566: >> 0","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running" >> ,"workers":[]}] >> [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566: >> 0","name":"i-0a98f94c8d82cb1fd","number":0,"state":" >> finished","workers":[{"maximum-threads":0,"running-th >> reads":0,"id":"i-0a98f94c8d82cb1fd-24:371439501| >> 1475085007713|1565583566:25","name":"i-0a98f94c8d82cb1fd-24" >> ,"number":24,"state":"finished"}]}] >> [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566: >> 0","name":"i-0a98f94c8d82cb1fd","number":0,"state":" >> finished","workers":[{"maximum-threads":0,"running-th >> reads":0,"id":"i-0a98f94c8d82cb1fd-24:371439501| >> 1475085007713|1565583566:25","name":"i-0a98f94c8d82cb1fd-24" >> ,"number":24,"state":"finished"}]}] >> [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566: >> 0","name":"i-0a98f94c8d82cb1fd","number":0,"state":"started" >> ,"workers":[]}] >> [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566: >> 0","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running" >> ,"workers":[]}] >> [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566: >> 0","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running" >> ,"workers":[]}] >> >> >> ------------------------------------------------------------ >> ------------------ >> >> _______________________________________________ >> grinder-use mailing list >> gri...@li... >> https://lists.sourceforge.net/lists/listinfo/grinder-use >> >> > > ------------------------------------------------------------ > ------------------ > > _______________________________________________ > grinder-use mailing list > gri...@li... > https://lists.sourceforge.net/lists/listinfo/grinder-use > > |
From: Darren B. <bal...@gm...> - 2016-09-29 17:24:27
|
Hi All, I've come across a pretty unusual situation in my polling logic for workers (use to tell if they are 'done'). I have test logic that runs many scenarios, and I typically poll for workers like this: workerstate=$(curl --noproxy localhost -s -X GET http://localhost:6373/agents/status | /usr/local/bin/jq -r '.[].workers[].state' | wc -l) I have an atExit function registered, that cleans up data that was created/generated during the run. The odd behaviour can be seen below, captured with a simply loop outside the run for observation (1 sec interval) to check the state of workers while a test was running. It seams that once test runner exits, the state of status of t the agents's workers are 'cleared' (which was my indication that things were really done). Grinder also issues a termination at 10 seconds as well, regrettably. As can been seen, the agent workers look like their state went from running to nothing and then back to finished. Time between this is 30 seconds. Threads are still up during this period, as the cleanup is still being processed. Is there any efficient way to determine successfully that the workers have passed the 'finished' state? I can't really rely on polling for a state of finished, as there is a chance that it will be missed (it is cleared). Thanks. [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566:0","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running","workers":[{"maximum-threads":20,"running-threads":20,"id":"i-0a98f94c8d82cb1fd-24:371439501|1475085007713|1565583566:25","name":"i-0a98f94c8d82cb1fd-24","number":24,"state":"running"}]}] [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566:0","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running","workers":[{"maximum-threads":20,"running-threads":20,"id":"i-0a98f94c8d82cb1fd-24:371439501|1475085007713|1565583566:25","name":"i-0a98f94c8d82cb1fd-24","number":24,"state":"running"}]}] [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566:0","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running","workers":[{"maximum-threads":20,"running-threads":20,"id":"i-0a98f94c8d82cb1fd-24:371439501|1475085007713|1565583566:25","name":"i-0a98f94c8d82cb1fd-24","number":24,"state":"running"}]}] [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566:0","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running","workers":[]}] [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566:0","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running","workers":[]}] [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566:0","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running","workers":[]}] [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566:0","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running","workers":[]}] [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566:0","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running","workers":[]}] [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566:0","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running","workers":[]}] [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566:0","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running","workers":[]}] [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566:0","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running","workers":[]}] [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566:0","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running","workers":[]}] [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566:0","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running","workers":[]}] [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566:0","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running","workers":[]}] [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566:0","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running","workers":[]}] [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566:0","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running","workers":[]}] [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566:0","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running","workers":[]}] [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566:0","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running","workers":[]}] [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566:0","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running","workers":[]}] [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566:0","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running","workers":[]}] [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566:0","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running","workers":[]}] [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566:0","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running","workers":[]}] [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566:0","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running","workers":[]}] [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566:0","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running","workers":[]}] [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566:0","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running","workers":[]}] [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566:0","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running","workers":[]}] [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566:0","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running","workers":[]}] [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566:0","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running","workers":[]}] [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566:0","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running","workers":[]}] [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566:0","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running","workers":[]}] [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566:0","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running","workers":[]}] [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566:0","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running","workers":[]}] [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566:0","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running","workers":[]}] [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566:0","name":"i-0a98f94c8d82cb1fd","number":0,"state":"finished","workers":[{"maximum-threads":0,"running-threads":0,"id":"i-0a98f94c8d82cb1fd-24:371439501|1475085007713|1565583566:25","name":"i-0a98f94c8d82cb1fd-24","number":24,"state":"finished"}]}] [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566:0","name":"i-0a98f94c8d82cb1fd","number":0,"state":"finished","workers":[{"maximum-threads":0,"running-threads":0,"id":"i-0a98f94c8d82cb1fd-24:371439501|1475085007713|1565583566:25","name":"i-0a98f94c8d82cb1fd-24","number":24,"state":"finished"}]}] [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566:0","name":"i-0a98f94c8d82cb1fd","number":0,"state":"started","workers":[]}] [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566:0","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running","workers":[]}] [{"id":"ip-10-82-147-72:371439501|1475085007713|1565583566:0","name":"i-0a98f94c8d82cb1fd","number":0,"state":"running","workers":[]}] |
From: - 2016-07-31 12:45:30
|
I am looking for a tool that will permit me to load test a Java Thick Client application running on Window 7. I had seen a comment on a write-up on tools available that said that Grinder was being used successfully for this purpose. Can you provide assistance with this please. Any examples or help would be great. Thanks Sent from Mail for Windows 10 |
From: Philip A. <ph...@ma...> - 2016-03-16 14:36:13
|
The short answer is "no". I've afraid I've not found time for The Grinder over the last 3 years, and I don't see that changing soon. - Phil On 10/03/16 20:48, Marcus French wrote: > Is there anyone working on updates for The Grinder? No new releases > since 2012. > > > ------------------------------------------------------------------------------ > Transform Data into Opportunity. > Accelerate data analysis in your applications with > Intel Data Analytics Acceleration Library. > Click to learn more. > http://pubads.g.doubleclick.net/gampad/clk?id=278785111&iu=/4140 > > > _______________________________________________ > Grinder-development mailing list > Gri...@li... > https://lists.sourceforge.net/lists/listinfo/grinder-development |
From: Marcus F. <mar...@gm...> - 2016-03-10 20:48:59
|
Is there anyone working on updates for The Grinder? No new releases since 2012. |
From: Darren B. <bal...@gm...> - 2015-04-22 22:48:10
|
No sure how that helps, as I need the console. I can send any number of other commands that affect agents like agent/stop-workers and agents/stop. These all seem to get through. Requesting files/distribute is a complete no go.vvI brought down the console and brought it back up, agent reconnected immediately. Dev: any insight on how to get this files/distribute to work? Here is the agent log as these other command are coming in. File distribute fails to come through. {"timestamp":"2015-04-22T22:37:16.781+00:00","logger":"agent","thread":"Message pump-1","level":"INFO","HOSTNAME":"ip-10-82-151-49.localdomain","message":"received a reset message"} {"timestamp":"2015-04-22T22:37:16.782+00:00","logger":"agent","thread":"main","level":"INFO","HOSTNAME":"ip-10-82-151-49.localdomain","message":"The Grinder 3.12-SNAPSHOT"} {"timestamp":"2015-04-22T22:37:16.782+00:00","logger":"agent","thread":"main","level":"INFO","HOSTNAME":"ip-10-82-151-49.localdomain","message":"waiting for console signal"} {"timestamp":"2015-04-22T22:39:05.609+00:00","logger":"agent","thread":"Message pump-1","level":"INFO","HOSTNAME":"ip-10-82-151-49.localdomain","message":"console connection shut down"} {"timestamp":"2015-04-22T22:39:05.609+00:00","logger":"agent","thread":"main","level":"INFO","HOSTNAME":"ip-10-82-151-49.localdomain","message":"agent finished"} {"timestamp":"2015-04-22T22:39:05.610+00:00","logger":"agent","thread":"main","level":"INFO","HOSTNAME":"ip-10-82-151-49.localdomain","message":"sleeping for 30000 ms"} {"timestamp":"2015-04-22T22:39:35.610+00:00","logger":"agent","thread":"main","level":"INFO","HOSTNAME":"ip-10-82-151-49.localdomain","message":"The Grinder 3.12-SNAPSHOT"} {"timestamp":"2015-04-22T22:39:35.613+00:00","logger":"agent","thread":"main","level":"ERROR","HOSTNAME":"ip-10-82-151-49.localdomain","message":"Failed to connect to 'grinderconsole1/10.82.151.32:6372'"} {"timestamp":"2015-04-22T22:39:35.613+00:00","logger":"agent","thread":"main","level":"INFO","HOSTNAME":"ip-10-82-151-49.localdomain","message":"agent finished"} {"timestamp":"2015-04-22T22:39:35.613+00:00","logger":"agent","thread":"main","level":"INFO","HOSTNAME":"ip-10-82-151-49.localdomain","message":"sleeping for 30000 ms"} {"timestamp":"2015-04-22T22:40:05.616+00:00","logger":"agent","thread":"main","level":"INFO","HOSTNAME":"ip-10-82-151-49.localdomain","message":"The Grinder 3.12-SNAPSHOT"} {"timestamp":"2015-04-22T22:40:05.623+00:00","logger":"agent","thread":"main","level":"ERROR","HOSTNAME":"ip-10-82-151-49.localdomain","message":"Failed to connect to 'grinderconsole1/10.82.151.32:6372'"} {"timestamp":"2015-04-22T22:40:05.623+00:00","logger":"agent","thread":"main","level":"INFO","HOSTNAME":"ip-10-82-151-49.localdomain","message":"agent finished"} {"timestamp":"2015-04-22T22:40:05.623+00:00","logger":"agent","thread":"main","level":"INFO","HOSTNAME":"ip-10-82-151-49.localdomain","message":"sleeping for 30000 ms"} {"timestamp":"2015-04-22T22:40:35.624+00:00","logger":"agent","thread":"main","level":"INFO","HOSTNAME":"ip-10-82-151-49.localdomain","message":"The Grinder 3.12-SNAPSHOT"} {"timestamp":"2015-04-22T22:40:35.628+00:00","logger":"agent","thread":"main","level":"INFO","HOSTNAME":"ip-10-82-151-49.localdomain","message":"connected to console at grinderconsole1/10.82.151.32:6372"} {"timestamp":"2015-04-22T22:40:35.629+00:00","logger":"agent","thread":"main","level":"INFO","HOSTNAME":"ip-10-82-151-49.localdomain","message":"waiting for console signal"} {"timestamp":"2015-04-22T22:41:36.219+00:00","logger":"agent","thread":"Message pump-1","level":"INFO","HOSTNAME":"ip-10-82-151-49.localdomain","message":"received a reset message"} {"timestamp":"2015-04-22T22:41:36.220+00:00","logger":"agent","thread":"main","level":"INFO","HOSTNAME":"ip-10-82-151-49.localdomain","message":"The Grinder 3.12-SNAPSHOT"} {"timestamp":"2015-04-22T22:41:36.221+00:00","logger":"agent","thread":"main","level":"INFO","HOSTNAME":"ip-10-82-151-49.localdomain","message":"waiting for console signal"} {"timestamp":"2015-04-22T22:41:41.317+00:00","logger":"agent","thread":"Message pump-1","level":"INFO","HOSTNAME":"ip-10-82-151-49.localdomain","message":"received a stop message"} {"timestamp":"2015-04-22T22:41:41.318+00:00","logger":"agent","thread":"main","level":"INFO","HOSTNAME":"ip-10-82-151-49.localdomain","message":"console connection shut down"} {"timestamp":"2015-04-22T22:41:41.318+00:00","logger":"agent","thread":"main","level":"INFO","HOSTNAME":"ip-10-82-151-49.localdomain","message":"agent finished"} {"timestamp":"2015-04-22T22:41:41.318+00:00","logger":"agent","thread":"main","level":"INFO","HOSTNAME":"ip-10-82-151-49.localdomain","message":"sleeping for 30000 ms"} {"timestamp":"2015-04-22T22:42:11.319+00:00","logger":"agent","thread":"main","level":"INFO","HOSTNAME":"ip-10-82-151-49.localdomain","message":"The Grinder 3.12-SNAPSHOT"} {"timestamp":"2015-04-22T22:42:11.321+00:00","logger":"agent","thread":"main","level":"INFO","HOSTNAME":"ip-10-82-151-49.localdomain","message":"connected to console at grinderconsole1/10.82.151.32:6372"} {"timestamp":"2015-04-22T22:42:11.322+00:00","logger":"agent","thread":"main","level":"INFO","HOSTNAME":"ip-10-82-151-49.localdomain","message":"waiting for console signal"} {"timestamp":"2015-04-22T22:42:27.402+00:00","logger":"agent","thread":"Message pump-1","level":"INFO","HOSTNAME":"ip-10-82-151-49.localdomain","message":"received a start message"} {"timestamp":"2015-04-22T22:42:27.405+00:00","logger":"agent","thread":"main","level":"ERROR","HOSTNAME":"ip-10-82-151-49.localdomain","message":"The script file 'CreateApp.py' does not exist or is not readable."} {"timestamp":"2015-04-22T22:42:27.405+00:00","logger":"agent","thread":"main","level":"INFO","HOSTNAME":"ip-10-82-151-49.localdomain","message":"finished, waiting for console signal"} On Wed, Apr 22, 2015 at 5:42 PM, Adil qureshi <ad...@gm...> wrote: > Great now don't start the console and do everything same..., give it a try > .,,, > On 22 Apr 2015 22:38, "Darren Ball" <bal...@gm...> wrote: > >> Adil, >> >> The console is started and up. I wait for the ports to be up and >> listening prior to starting the agents. The agents all connect (to the >> console) and seem to wait for console signal. I can see all agents connect >> in the console log and via netstat (both sides). Using tcpdump I can see >> communication from the console to all agents (with ack's). Commands like >> file/distribute on the console suggest started but never 'work' as the >> agents are never accepting any files etc...). >> >> -Darren >> >> On Wed, Apr 22, 2015 at 5:29 PM, Adil qureshi <ad...@gm...> wrote: >> >>> agents will not run on their own if they get connected to console ....if >>> the console is not started agents will start running and won't wait for the >>> console signal ... u may just get cant connect to console warning in >>> agent log .... >>> >>> u can just stop the console and run the agents ..... >>> >>> On Wed, Apr 22, 2015 at 10:19 PM, Darren Ball <bal...@gm...> >>> wrote: >>> >>>> Hi Adil, >>>> What do you mean by that? >>>> -Darren >>>> >>>> On Wed, Apr 22, 2015 at 4:43 PM, Adil qureshi <ad...@gm...> >>>> wrote: >>>> >>>>> one more suggestion can you NOT connect to console and run the agents >>>>> directly .... i think it may work then ,,, >>>>> >>>>> On Wed, Apr 22, 2015 at 9:17 PM, Gary Mulder <fly...@gm...> >>>>> wrote: >>>>> >>>>>> >>>>>> On 22 April 2015 at 20:45, Darren Ball <bal...@gm...> wrote: >>>>>> >>>>>>> Here is an update on this; >>>>>>> >>>>>>> I have five agents actively connected >>>>>>> >>>>>>> On one of the agents - the log is just sitting waiting for console >>>>>>> signal - no files have been distributed: >>>>>>> >>>>>> >>>>>> As a temporary work-around, why not use Jenkins to distribute your >>>>>> Grinder code? >>>>>> >>>>>> Gary >>>>>> >>>>>> >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT >>>>>> Develop your own process in accordance with the BPMN 2 standard >>>>>> Learn Process modeling best practices with Bonita BPM through live >>>>>> exercises >>>>>> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- >>>>>> event?utm_ >>>>>> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF >>>>>> _______________________________________________ >>>>>> grinder-use mailing list >>>>>> gri...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/grinder-use >>>>>> >>>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT >>>>> Develop your own process in accordance with the BPMN 2 standard >>>>> Learn Process modeling best practices with Bonita BPM through live >>>>> exercises >>>>> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- >>>>> event?utm_ >>>>> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF >>>>> _______________________________________________ >>>>> grinder-use mailing list >>>>> gri...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/grinder-use >>>>> >>>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT >>>> Develop your own process in accordance with the BPMN 2 standard >>>> Learn Process modeling best practices with Bonita BPM through live >>>> exercises >>>> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- >>>> event?utm_ >>>> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF >>>> _______________________________________________ >>>> grinder-use mailing list >>>> gri...@li... >>>> https://lists.sourceforge.net/lists/listinfo/grinder-use >>>> >>>> >>> >>> >>> ------------------------------------------------------------------------------ >>> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT >>> Develop your own process in accordance with the BPMN 2 standard >>> Learn Process modeling best practices with Bonita BPM through live >>> exercises >>> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- >>> event?utm_ >>> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF >>> _______________________________________________ >>> grinder-use mailing list >>> gri...@li... >>> https://lists.sourceforge.net/lists/listinfo/grinder-use >>> >>> >> >> >> ------------------------------------------------------------------------------ >> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT >> Develop your own process in accordance with the BPMN 2 standard >> Learn Process modeling best practices with Bonita BPM through live >> exercises >> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- >> event?utm_ >> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF >> _______________________________________________ >> grinder-use mailing list >> gri...@li... >> https://lists.sourceforge.net/lists/listinfo/grinder-use >> >> > > ------------------------------------------------------------------------------ > BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT > Develop your own process in accordance with the BPMN 2 standard > Learn Process modeling best practices with Bonita BPM through live > exercises > http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- > event?utm_ > source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF > _______________________________________________ > grinder-use mailing list > gri...@li... > https://lists.sourceforge.net/lists/listinfo/grinder-use > > |
From: Darren B. <bal...@gm...> - 2015-04-20 19:26:37
|
Looks like it might have solved it. FYI. Running an extended series to see. Thanks for the fix. On Mon, Apr 20, 2015 at 3:05 PM, Darren Ball <bal...@gm...> wrote: > Hi Philip, > I think this is also a problem (below). It seems that locale is set to > nothing in this case and this is causing a translation in tower to throw an > exception. > It only happens when the agents are connecting for statistical reporting? > Rebuilding to see if your changes fix this, but I think this is slightly > different. > > -Darren > > Stack trace: > 2015-04-18 03:12:04,104 INFO console: The Grinder 3.12-SNAPSHOT > 2015-04-18 03:12:08,092 DEBUG net.grinder.console.web.livedata: (push > :process-state) 0 > 2015-04-18 03:12:08,105 DEBUG net.grinder.console.web.livedata: (push > :threads) 0 > 2015-04-18 03:12:08,288 DEBUG net.grinder.console.web.livedata: (push > :statistics) 0 > 2015-04-18 03:12:08,290 DEBUG net.grinder.console.web.livedata: (push > :sample) 0 > 2015-04-18 03:12:08,313 DEBUG net.grinder.console.service.bootstrap_impl: > Starting HTTP server at 0.0.0.0:6373 > 2015-04-18 03:12:23,532 DEBUG net.grinder.console.service.app: request > :put /properties -> 200 (53.28 ms) > 2015-04-18 03:12:29,923 INFO console: Agent i-70cc4286 [Connected] > 2015-04-18 03:12:30,007 DEBUG net.grinder.console.web.livedata: (push > :process-state) 1 > 2015-04-18 03:12:30,010 DEBUG net.grinder.console.web.livedata: (push > :threads) 1 > 2015-04-18 03:12:30,986 DEBUG net.grinder.console.web.livedata: (push > :process-state) 2 > 2015-04-18 03:12:30,988 DEBUG net.grinder.console.web.livedata: (push > :threads) 2 > 2015-04-18 03:12:37,953 DEBUG net.grinder.console.service.app: request > :post /files/distribute -> 200 (10.33 ms) > 2015-04-18 03:12:38,974 DEBUG net.grinder.console.web.livedata: (push > :process-state) 3 > 2015-04-18 03:12:38,975 DEBUG net.grinder.console.web.livedata: (push > :threads) 3 > 2015-04-18 03:12:51,746 DEBUG net.grinder.console.service.app: request > :post /agents/start-workers -> 200 (21.76 ms) > 2015-04-18 03:13:01,427 INFO console: Agent i-70cc4286 [Connected] { > Worker i-70cc4286-0 [Ready] } > 2015-04-18 03:13:01,502 DEBUG net.grinder.console.web.livedata: (push > :process-state) 4 > 2015-04-18 03:13:01,503 DEBUG net.grinder.console.web.livedata: (push > :threads) 4 > 2015-04-18 03:13:03,926 INFO console: Agent i-70cc4286 [Connected] > 2015-04-18 03:13:04,002 DEBUG net.grinder.console.web.livedata: (push > :process-state) 5 > 2015-04-18 03:13:04,003 DEBUG net.grinder.console.web.livedata: (push > :threads) 5 > 2015-04-18 03:13:12,606 DEBUG net.grinder.console.web.livedata: (push > :statistics) 1 > 2015-04-18 03:13:12,608 DEBUG net.grinder.console.web.livedata: (push > :sample) 1 > 2015-04-18 03:13:12,945 INFO console: Agent i-70cc4286 [Connected] { > Worker i-70cc4286-0 [Running (1/1 thread)] } > 2015-04-18 03:13:12,983 INFO console: Collecting samples: 1 > Exception in thread "Timer-0" java.lang.Exception: Invalid locale: > at taoensso.tower$fn__1103.invoke(tower.clj:38) > at clojure.lang.AFn.applyToHelper(AFn.java:161) > at clojure.lang.AFn.applyTo(AFn.java:151) > at clojure.core$apply.invoke(core.clj:617) > at clojure.core$memoize$fn__5049.doInvoke(core.clj:5735) > at clojure.lang.RestFn.invoke(RestFn.java:408) > at taoensso.tower$fmt_msg.doInvoke(tower.clj:177) > at clojure.lang.RestFn.applyTo(RestFn.java:142) > at clojure.core$apply.invoke(core.clj:619) > at taoensso.tower$format_msg.doInvoke(tower.clj:542) > at clojure.lang.RestFn.applyTo(RestFn.java:137) > at clojure.core$apply.invoke(core.clj:619) > at net.grinder.translation.translate$t.doInvoke(translate.clj:52) > at clojure.lang.RestFn.invoke(RestFn.java:439) > at net.grinder.console.service.web$eval4444$fn__4445.invoke(web.clj:69) > at clojure.lang.MultiFn.invoke(MultiFn.java:231) > at > net.grinder.console.service.web$render_process_table$iter__4482__4486$fn__4487$iter__4504__4508$fn__4509.invoke(web.clj:109) > at clojure.lang.LazySeq.sval(LazySeq.java:42) > at clojure.lang.LazySeq.seq(LazySeq.java:60) > at clojure.lang.RT.seq(RT.java:484) > at clojure.core$seq.invoke(core.clj:133) > at clojure.core$apply.invoke(core.clj:617) > at > net.grinder.console.service.web$render_process_table$iter__4482__4486$fn__4487.invoke(web.clj:105) > at clojure.lang.LazySeq.sval(LazySeq.java:42) > at clojure.lang.LazySeq.seq(LazySeq.java:60) > at clojure.lang.RT.seq(RT.java:484) > at clojure.core$seq.invoke(core.clj:133) > at clojure.core$apply.invoke(core.clj:617) > at net.grinder.console.service.web$render_process_table.invoke(web.clj:90) > at > net.grinder.console.service.web$create_app$push_process_data__4912.invoke(web.clj:352) > at > net.grinder.console.model.processes$add_listener$fn__2111.invoke(processes.clj:116) > at clojure.lang.ARef.notifyWatches(ARef.java:98) > at clojure.lang.Atom.reset(Atom.java:101) > at clojure.core$reset_BANG_.invoke(core.clj:2178) > at > net.grinder.console.model.processes$initialise$reify__2016.update(processes.clj:48) > at > net.grinder.console.communication.ProcessStatusImplementation$3.inform(ProcessStatusImplementation.java:157) > at > net.grinder.console.communication.ProcessStatusImplementation$3.inform(ProcessStatusImplementation.java:155) > at net.grinder.util.ListenerSupport.apply(ListenerSupport.java:104) > at > net.grinder.console.communication.ProcessStatusImplementation.update(ProcessStatusImplementation.java:154) > at > net.grinder.console.communication.ProcessStatusImplementation.access$000(ProcessStatusImplementation.java:51) > at > net.grinder.console.communication.ProcessStatusImplementation$1.run(ProcessStatusImplementation.java:103) > at java.util.TimerThread.mainLoop(Timer.java:555) > at java.util.TimerThread.run(Timer.java:505) > 2015-04-18 03:13:13,107 DEBUG net.grinder.console.web.livedata: (push > :statistics) 2 > 2015-04-18 03:13:13,108 DEBUG net.grinder.console.web.livedata: (push > :sample) 2 > ^C2015-04-18 03:13:41,966 INFO console: missing translation: {0} > > > There are other times this works for a period and then croaks, as in this, > where it does not happen until 90+ samples in. > > 2015-04-18 02:46:11,878 DEBUG net.grinder.console.web.livedata: (push > :statistics) 86 > 2015-04-18 02:46:11,879 DEBUG net.grinder.console.web.livedata: (push > :sample) 86 > 2015-04-18 02:46:12,880 INFO console: Collecting samples: 86 > 2015-04-18 02:46:12,995 DEBUG net.grinder.console.web.livedata: (push > :statistics) 87 > 2015-04-18 02:46:12,996 DEBUG net.grinder.console.web.livedata: (push > :sample) 87 > 2015-04-18 02:46:13,996 INFO console: Collecting samples: 87 > 2015-04-18 02:46:14,114 DEBUG net.grinder.console.web.livedata: (push > :statistics) 88 > 2015-04-18 02:46:14,116 DEBUG net.grinder.console.web.livedata: (push > :sample) 88 > 2015-04-18 02:46:15,118 INFO console: Collecting samples: 88 > 2015-04-18 02:46:15,238 DEBUG net.grinder.console.web.livedata: (push > :statistics) 89 > 2015-04-18 02:46:15,239 DEBUG net.grinder.console.web.livedata: (push > :sample) 89 > 2015-04-18 02:46:16,240 INFO console: Collecting samples: 89 > 2015-04-18 02:46:16,357 DEBUG net.grinder.console.web.livedata: (push > :statistics) 90 > 2015-04-18 02:46:16,358 DEBUG net.grinder.console.web.livedata: (push > :sample) 90 > 2015-04-18 02:46:17,358 INFO console: Collecting samples: 90 > 2015-04-18 02:46:17,475 DEBUG net.grinder.console.web.livedata: (push > :statistics) 91 > 2015-04-18 02:46:17,476 DEBUG net.grinder.console.web.livedata: (push > :sample) 91 > 2015-04-18 02:46:18,477 INFO console: Collecting samples: 91 > 2015-04-18 02:46:18,598 DEBUG net.grinder.console.web.livedata: (push > :statistics) 92 > 2015-04-18 02:46:18,599 DEBUG net.grinder.console.web.livedata: (push > :sample) 92 > 2015-04-18 02:46:18,638 INFO console: Agent i-70cc4286 [Connected] { > Worker i-70cc4286-1 [Running (1/1 thread)] } > Exception in thread "Timer-0" java.lang.Exception: Invalid locale: > at taoensso.tower$fn__1103.invoke(tower.clj:38) > at clojure.lang.AFn.applyToHelper(AFn.java:161) > at clojure.lang.AFn.applyTo(AFn.java:151) > at clojure.core$apply.invoke(core.clj:617) > at clojure.core$memoize$fn__5049.doInvoke(core.clj:5735) > at clojure.lang.RestFn.invoke(RestFn.java:408) > > > Environment (both nodes) > [grinder@grinderconsole ~]$ env | grep UTF > LC_ALL=en_US.UTF-8 > LANG=en_US.UTF-8 > LANGUAGE=en_US.UTF-8 > [grinder@grinderconsole ~]$ locale > LANG=en_US.UTF-8 > LC_CTYPE="en_US.UTF-8" > LC_NUMERIC="en_US.UTF-8" > LC_TIME="en_US.UTF-8" > LC_COLLATE="en_US.UTF-8" > LC_MONETARY="en_US.UTF-8" > LC_MESSAGES="en_US.UTF-8" > LC_PAPER="en_US.UTF-8" > LC_NAME="en_US.UTF-8" > LC_ADDRESS="en_US.UTF-8" > LC_TELEPHONE="en_US.UTF-8" > LC_MEASUREMENT="en_US.UTF-8" > LC_IDENTIFICATION="en_US.UTF-8" > LC_ALL=en_US.UTF-8 > > > [grinder@grinderagent1 ~]$ env | grep UTF > LC_ALL=en_US.UTF-8 > LANG=en_US.UTF-8 > LANGUAGE=en_US.UTF-8 > [grinder@grinderagent1 ~]$ locale > LANG=en_US.UTF-8 > LC_CTYPE="en_US.UTF-8" > LC_NUMERIC="en_US.UTF-8" > LC_TIME="en_US.UTF-8" > LC_COLLATE="en_US.UTF-8" > LC_MONETARY="en_US.UTF-8" > LC_MESSAGES="en_US.UTF-8" > LC_PAPER="en_US.UTF-8" > LC_NAME="en_US.UTF-8" > LC_ADDRESS="en_US.UTF-8" > LC_TELEPHONE="en_US.UTF-8" > LC_MEASUREMENT="en_US.UTF-8" > LC_IDENTIFICATION="en_US.UTF-8" > LC_ALL=en_US.UTF-8 > > > > On Mon, Apr 20, 2015 at 2:18 PM, Philip Aston <ph...@ma...> wrote: > >> Thanks for the report. >> >> I've pushed a fix - let me know whether this works. >> >> Building a SNAPSHOT from the tip of the source tree is always going to be >> adventurous. But I understand you are doing so to use the later version of >> Jython. >> >> - Phil >> >> >> On 20/04/15 16:15, Darren Ball wrote: >> >> I am getting this error, and after talking to the owner of Tower, he is >> suggesting that this is something broken in grinder: >> >> [grinder@ip-10-82-151-23 ~]$ ./console_headless_start2.sh >> >> 2015-04-20 14:46:26,607 INFO console: The Grinder 3.12-SNAPSHOT >> >> 2015-Apr-20 14:46:26 +0000 ip-10-82-151-23.localdomain DEBUG >> [taoensso.tower] - Missing translation {:locales [#<Locale en_US>], :scope >> nil, :ks [:console.term/finished], :dev-mode? true, :ns clojure.core} >> >> >> Anyone know why tower is reacting this way or how to fix this? >> >> Darren >> >> >> ------------------------------------------------------------------------------ >> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT >> Develop your own process in accordance with the BPMN 2 standard >> Learn Process modeling best practices with Bonita BPM through live exerciseshttp://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ >> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF >> >> >> >> _______________________________________________ >> Grinder-development mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/grinder-development >> >> >> >> >> > |
From: Darren B. <bal...@gm...> - 2015-04-20 19:06:00
|
Hi Philip, I think this is also a problem (below). It seems that locale is set to nothing in this case and this is causing a translation in tower to throw an exception. It only happens when the agents are connecting for statistical reporting? Rebuilding to see if your changes fix this, but I think this is slightly different. -Darren Stack trace: 2015-04-18 03:12:04,104 INFO console: The Grinder 3.12-SNAPSHOT 2015-04-18 03:12:08,092 DEBUG net.grinder.console.web.livedata: (push :process-state) 0 2015-04-18 03:12:08,105 DEBUG net.grinder.console.web.livedata: (push :threads) 0 2015-04-18 03:12:08,288 DEBUG net.grinder.console.web.livedata: (push :statistics) 0 2015-04-18 03:12:08,290 DEBUG net.grinder.console.web.livedata: (push :sample) 0 2015-04-18 03:12:08,313 DEBUG net.grinder.console.service.bootstrap_impl: Starting HTTP server at 0.0.0.0:6373 2015-04-18 03:12:23,532 DEBUG net.grinder.console.service.app: request :put /properties -> 200 (53.28 ms) 2015-04-18 03:12:29,923 INFO console: Agent i-70cc4286 [Connected] 2015-04-18 03:12:30,007 DEBUG net.grinder.console.web.livedata: (push :process-state) 1 2015-04-18 03:12:30,010 DEBUG net.grinder.console.web.livedata: (push :threads) 1 2015-04-18 03:12:30,986 DEBUG net.grinder.console.web.livedata: (push :process-state) 2 2015-04-18 03:12:30,988 DEBUG net.grinder.console.web.livedata: (push :threads) 2 2015-04-18 03:12:37,953 DEBUG net.grinder.console.service.app: request :post /files/distribute -> 200 (10.33 ms) 2015-04-18 03:12:38,974 DEBUG net.grinder.console.web.livedata: (push :process-state) 3 2015-04-18 03:12:38,975 DEBUG net.grinder.console.web.livedata: (push :threads) 3 2015-04-18 03:12:51,746 DEBUG net.grinder.console.service.app: request :post /agents/start-workers -> 200 (21.76 ms) 2015-04-18 03:13:01,427 INFO console: Agent i-70cc4286 [Connected] { Worker i-70cc4286-0 [Ready] } 2015-04-18 03:13:01,502 DEBUG net.grinder.console.web.livedata: (push :process-state) 4 2015-04-18 03:13:01,503 DEBUG net.grinder.console.web.livedata: (push :threads) 4 2015-04-18 03:13:03,926 INFO console: Agent i-70cc4286 [Connected] 2015-04-18 03:13:04,002 DEBUG net.grinder.console.web.livedata: (push :process-state) 5 2015-04-18 03:13:04,003 DEBUG net.grinder.console.web.livedata: (push :threads) 5 2015-04-18 03:13:12,606 DEBUG net.grinder.console.web.livedata: (push :statistics) 1 2015-04-18 03:13:12,608 DEBUG net.grinder.console.web.livedata: (push :sample) 1 2015-04-18 03:13:12,945 INFO console: Agent i-70cc4286 [Connected] { Worker i-70cc4286-0 [Running (1/1 thread)] } 2015-04-18 03:13:12,983 INFO console: Collecting samples: 1 Exception in thread "Timer-0" java.lang.Exception: Invalid locale: at taoensso.tower$fn__1103.invoke(tower.clj:38) at clojure.lang.AFn.applyToHelper(AFn.java:161) at clojure.lang.AFn.applyTo(AFn.java:151) at clojure.core$apply.invoke(core.clj:617) at clojure.core$memoize$fn__5049.doInvoke(core.clj:5735) at clojure.lang.RestFn.invoke(RestFn.java:408) at taoensso.tower$fmt_msg.doInvoke(tower.clj:177) at clojure.lang.RestFn.applyTo(RestFn.java:142) at clojure.core$apply.invoke(core.clj:619) at taoensso.tower$format_msg.doInvoke(tower.clj:542) at clojure.lang.RestFn.applyTo(RestFn.java:137) at clojure.core$apply.invoke(core.clj:619) at net.grinder.translation.translate$t.doInvoke(translate.clj:52) at clojure.lang.RestFn.invoke(RestFn.java:439) at net.grinder.console.service.web$eval4444$fn__4445.invoke(web.clj:69) at clojure.lang.MultiFn.invoke(MultiFn.java:231) at net.grinder.console.service.web$render_process_table$iter__4482__4486$fn__4487$iter__4504__4508$fn__4509.invoke(web.clj:109) at clojure.lang.LazySeq.sval(LazySeq.java:42) at clojure.lang.LazySeq.seq(LazySeq.java:60) at clojure.lang.RT.seq(RT.java:484) at clojure.core$seq.invoke(core.clj:133) at clojure.core$apply.invoke(core.clj:617) at net.grinder.console.service.web$render_process_table$iter__4482__4486$fn__4487.invoke(web.clj:105) at clojure.lang.LazySeq.sval(LazySeq.java:42) at clojure.lang.LazySeq.seq(LazySeq.java:60) at clojure.lang.RT.seq(RT.java:484) at clojure.core$seq.invoke(core.clj:133) at clojure.core$apply.invoke(core.clj:617) at net.grinder.console.service.web$render_process_table.invoke(web.clj:90) at net.grinder.console.service.web$create_app$push_process_data__4912.invoke(web.clj:352) at net.grinder.console.model.processes$add_listener$fn__2111.invoke(processes.clj:116) at clojure.lang.ARef.notifyWatches(ARef.java:98) at clojure.lang.Atom.reset(Atom.java:101) at clojure.core$reset_BANG_.invoke(core.clj:2178) at net.grinder.console.model.processes$initialise$reify__2016.update(processes.clj:48) at net.grinder.console.communication.ProcessStatusImplementation$3.inform(ProcessStatusImplementation.java:157) at net.grinder.console.communication.ProcessStatusImplementation$3.inform(ProcessStatusImplementation.java:155) at net.grinder.util.ListenerSupport.apply(ListenerSupport.java:104) at net.grinder.console.communication.ProcessStatusImplementation.update(ProcessStatusImplementation.java:154) at net.grinder.console.communication.ProcessStatusImplementation.access$000(ProcessStatusImplementation.java:51) at net.grinder.console.communication.ProcessStatusImplementation$1.run(ProcessStatusImplementation.java:103) at java.util.TimerThread.mainLoop(Timer.java:555) at java.util.TimerThread.run(Timer.java:505) 2015-04-18 03:13:13,107 DEBUG net.grinder.console.web.livedata: (push :statistics) 2 2015-04-18 03:13:13,108 DEBUG net.grinder.console.web.livedata: (push :sample) 2 ^C2015-04-18 03:13:41,966 INFO console: missing translation: {0} There are other times this works for a period and then croaks, as in this, where it does not happen until 90+ samples in. 2015-04-18 02:46:11,878 DEBUG net.grinder.console.web.livedata: (push :statistics) 86 2015-04-18 02:46:11,879 DEBUG net.grinder.console.web.livedata: (push :sample) 86 2015-04-18 02:46:12,880 INFO console: Collecting samples: 86 2015-04-18 02:46:12,995 DEBUG net.grinder.console.web.livedata: (push :statistics) 87 2015-04-18 02:46:12,996 DEBUG net.grinder.console.web.livedata: (push :sample) 87 2015-04-18 02:46:13,996 INFO console: Collecting samples: 87 2015-04-18 02:46:14,114 DEBUG net.grinder.console.web.livedata: (push :statistics) 88 2015-04-18 02:46:14,116 DEBUG net.grinder.console.web.livedata: (push :sample) 88 2015-04-18 02:46:15,118 INFO console: Collecting samples: 88 2015-04-18 02:46:15,238 DEBUG net.grinder.console.web.livedata: (push :statistics) 89 2015-04-18 02:46:15,239 DEBUG net.grinder.console.web.livedata: (push :sample) 89 2015-04-18 02:46:16,240 INFO console: Collecting samples: 89 2015-04-18 02:46:16,357 DEBUG net.grinder.console.web.livedata: (push :statistics) 90 2015-04-18 02:46:16,358 DEBUG net.grinder.console.web.livedata: (push :sample) 90 2015-04-18 02:46:17,358 INFO console: Collecting samples: 90 2015-04-18 02:46:17,475 DEBUG net.grinder.console.web.livedata: (push :statistics) 91 2015-04-18 02:46:17,476 DEBUG net.grinder.console.web.livedata: (push :sample) 91 2015-04-18 02:46:18,477 INFO console: Collecting samples: 91 2015-04-18 02:46:18,598 DEBUG net.grinder.console.web.livedata: (push :statistics) 92 2015-04-18 02:46:18,599 DEBUG net.grinder.console.web.livedata: (push :sample) 92 2015-04-18 02:46:18,638 INFO console: Agent i-70cc4286 [Connected] { Worker i-70cc4286-1 [Running (1/1 thread)] } Exception in thread "Timer-0" java.lang.Exception: Invalid locale: at taoensso.tower$fn__1103.invoke(tower.clj:38) at clojure.lang.AFn.applyToHelper(AFn.java:161) at clojure.lang.AFn.applyTo(AFn.java:151) at clojure.core$apply.invoke(core.clj:617) at clojure.core$memoize$fn__5049.doInvoke(core.clj:5735) at clojure.lang.RestFn.invoke(RestFn.java:408) Environment (both nodes) [grinder@grinderconsole ~]$ env | grep UTF LC_ALL=en_US.UTF-8 LANG=en_US.UTF-8 LANGUAGE=en_US.UTF-8 [grinder@grinderconsole ~]$ locale LANG=en_US.UTF-8 LC_CTYPE="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" LC_PAPER="en_US.UTF-8" LC_NAME="en_US.UTF-8" LC_ADDRESS="en_US.UTF-8" LC_TELEPHONE="en_US.UTF-8" LC_MEASUREMENT="en_US.UTF-8" LC_IDENTIFICATION="en_US.UTF-8" LC_ALL=en_US.UTF-8 [grinder@grinderagent1 ~]$ env | grep UTF LC_ALL=en_US.UTF-8 LANG=en_US.UTF-8 LANGUAGE=en_US.UTF-8 [grinder@grinderagent1 ~]$ locale LANG=en_US.UTF-8 LC_CTYPE="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" LC_PAPER="en_US.UTF-8" LC_NAME="en_US.UTF-8" LC_ADDRESS="en_US.UTF-8" LC_TELEPHONE="en_US.UTF-8" LC_MEASUREMENT="en_US.UTF-8" LC_IDENTIFICATION="en_US.UTF-8" LC_ALL=en_US.UTF-8 On Mon, Apr 20, 2015 at 2:18 PM, Philip Aston <ph...@ma...> wrote: > Thanks for the report. > > I've pushed a fix - let me know whether this works. > > Building a SNAPSHOT from the tip of the source tree is always going to be > adventurous. But I understand you are doing so to use the later version of > Jython. > > - Phil > > > On 20/04/15 16:15, Darren Ball wrote: > > I am getting this error, and after talking to the owner of Tower, he is > suggesting that this is something broken in grinder: > > [grinder@ip-10-82-151-23 ~]$ ./console_headless_start2.sh > > 2015-04-20 14:46:26,607 INFO console: The Grinder 3.12-SNAPSHOT > > 2015-Apr-20 14:46:26 +0000 ip-10-82-151-23.localdomain DEBUG > [taoensso.tower] - Missing translation {:locales [#<Locale en_US>], :scope > nil, :ks [:console.term/finished], :dev-mode? true, :ns clojure.core} > > > Anyone know why tower is reacting this way or how to fix this? > > Darren > > > ------------------------------------------------------------------------------ > BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT > Develop your own process in accordance with the BPMN 2 standard > Learn Process modeling best practices with Bonita BPM through live exerciseshttp://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ > source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF > > > > _______________________________________________ > Grinder-development mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/grinder-development > > > > > |
From: Philip A. <ph...@ma...> - 2015-04-20 18:18:20
|
Thanks for the report. I've pushed a fix - let me know whether this works. Building a SNAPSHOT from the tip of the source tree is always going to be adventurous. But I understand you are doing so to use the later version of Jython. - Phil On 20/04/15 16:15, Darren Ball wrote: > I am getting this error, and after talking to the owner of Tower, he > is suggesting that this is something broken in grinder: > > [grinder@ip-10-82-151-23 ~]$ ./console_headless_start2.sh > > 2015-04-20 14:46:26,607 INFO console: The Grinder 3.12-SNAPSHOT > > 2015-Apr-20 14:46:26 +0000 ip-10-82-151-23.localdomain DEBUG > [taoensso.tower] - Missing translation {:locales [#<Locale en_US>], > :scope nil, :ks [:console.term/finished], :dev-mode? true, :ns > clojure.core} > > > > Anyone know why tower is reacting this way or how to fix this? > > Darren > > > ------------------------------------------------------------------------------ > BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT > Develop your own process in accordance with the BPMN 2 standard > Learn Process modeling best practices with Bonita BPM through live exercises > http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ > source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF > > > _______________________________________________ > Grinder-development mailing list > Gri...@li... > https://lists.sourceforge.net/lists/listinfo/grinder-development |
From: Darren B. <bal...@gm...> - 2015-04-20 15:16:15
|
I am getting this error, and after talking to the owner of Tower, he is suggesting that this is something broken in grinder: [grinder@ip-10-82-151-23 ~]$ ./console_headless_start2.sh 2015-04-20 14:46:26,607 INFO console: The Grinder 3.12-SNAPSHOT 2015-Apr-20 14:46:26 +0000 ip-10-82-151-23.localdomain DEBUG [taoensso.tower] - Missing translation {:locales [#<Locale en_US>], :scope nil, :ks [:console.term/finished], :dev-mode? true, :ns clojure.core} Anyone know why tower is reacting this way or how to fix this? Darren |
From: Darren B. <bal...@gm...> - 2015-04-17 21:05:05
|
Hi (again) all, I am experiencing the following after compiling and deploying 3.12, any insight would be great. 2015-04-17 20:59:32,967 INFO console: Agent i-70cc4286 [Connected] { Worker i-70cc4286-0 [Running (1/1 thread)] } Exception in thread "Timer-0" java.lang.Exception: Invalid locale: at taoensso.tower$fn__1103.invoke(tower.clj:38) at clojure.lang.AFn.applyToHelper(AFn.java:154) at clojure.lang.AFn.applyTo(AFn.java:144) at clojure.core$apply.invoke(core.clj:628) at clojure.core$memoize$fn__5458.doInvoke(core.clj:6078) at clojure.lang.RestFn.invoke(RestFn.java:408) at taoensso.tower$fmt_msg.doInvoke(tower.clj:177) at clojure.lang.RestFn.applyTo(RestFn.java:142) at clojure.core$apply.invoke(core.clj:630) at taoensso.tower$format_msg.doInvoke(tower.clj:542) at clojure.lang.RestFn.applyTo(RestFn.java:137) at clojure.core$apply.invoke(core.clj:630) at net.grinder.translation.translate$t.doInvoke(translate.clj:52) at clojure.lang.RestFn.invoke(RestFn.java:439) at net.grinder.console.service.web$eval4444$fn__4445.invoke(web.clj:69) at clojure.lang.MultiFn.invoke(MultiFn.java:233) at net.grinder.console.service.web$render_process_table$iter__4482__4486$fn__4487$iter__4504__4508$fn__4509.invoke(web.clj:109) at clojure.lang.LazySeq.sval(LazySeq.java:40) at clojure.lang.LazySeq.seq(LazySeq.java:49) at clojure.lang.RT.seq(RT.java:507) at clojure.core$seq__4107.invoke(core.clj:135) at clojure.core$apply.invoke(core.clj:628) at net.grinder.console.service.web$render_process_table$iter__4482__4486$fn__4487.invoke(web.clj:90) at clojure.lang.LazySeq.sval(LazySeq.java:40) at clojure.lang.LazySeq.seq(LazySeq.java:49) at clojure.lang.RT.seq(RT.java:507) at clojure.core$seq__4107.invoke(core.clj:135) at clojure.core$apply.invoke(core.clj:628) at net.grinder.console.service.web$render_process_table.invoke(web.clj:90) at net.grinder.console.service.web$create_app$push_process_data__4912.invoke(web.clj:352) at net.grinder.console.model.processes$add_listener$fn__2111.invoke(processes.clj:116) at clojure.lang.ARef.notifyWatches(ARef.java:81) at clojure.lang.Atom.reset(Atom.java:101) at clojure.core$reset_BANG_.invoke(core.clj:2254) at net.grinder.console.model.processes$initialise$reify__2016.update(processes.clj:48) at net.grinder.console.communication.ProcessStatusImplementation$3.inform(ProcessStatusImplementation.java:157) at net.grinder.console.communication.ProcessStatusImplementation$3.inform(ProcessStatusImplementation.java:155) at net.grinder.util.ListenerSupport.apply(ListenerSupport.java:104) at net.grinder.console.communication.ProcessStatusImplementation.update(ProcessStatusImplementation.java:154) at net.grinder.console.communication.ProcessStatusImplementation.access$000(ProcessStatusImplementation.java:51) at net.grinder.console.communication.ProcessStatusImplementation$1.run(ProcessStatusImplementation.java:103) at java.util.TimerThread.mainLoop(Timer.java:555) at java.util.TimerThread.run(Timer.java:505) 2015-04-17 20:59:33,112 ERROR console: Exiting java.lang.IllegalStateException: Timer already cancelled. at java.util.Timer.sched(Timer.java:397) ~[na:1.8.0_40] at java.util.Timer.schedule(Timer.java:193) ~[na:1.8.0_40] at net.grinder.console.model.SampleModelImplementation$SamplingState.schedule(SampleModelImplementation.java:491) ~[grinder-core-3.12-SNAPSHOT.jar:na] at net.grinder.console.model.SampleModelImplementation$CapturingState.<init>(SampleModelImplementation.java:589) ~[grinder-core-3.12-SNAPSHOT.jar:na] at net.grinder.console.model.SampleModelImplementation$WaitingForTriggerState.newTestReport(SampleModelImplementation.java:410) ~[grinder-core-3.12-SNAPSHOT.jar:na] at net.grinder.console.model.SampleModelImplementation.addTestReport(SampleModelImplementation.java:321) ~[grinder-core-3.12-SNAPSHOT.jar:na] at net.grinder.console.ConsoleFoundation$WireMessageDispatch$2.handle(ConsoleFoundation.java:321) ~[grinder-core-3.12-SNAPSHOT.jar:na] at net.grinder.console.ConsoleFoundation$WireMessageDispatch$2.handle(ConsoleFoundation.java:318) ~[grinder-core-3.12-SNAPSHOT.jar:na] at net.grinder.communication.MessageDispatchSender.send(MessageDispatchSender.java:116) ~[grinder-core-3.12-SNAPSHOT.jar:na] at net.grinder.console.communication.ConsoleCommunicationImplementation.processOneMessage(ConsoleCommunicationImplementation.java:299) ~[grinder-core-3.12-SNAPSHOT.jar:na] at net.grinder.console.ConsoleFoundation.run(ConsoleFoundation.java:245) ~[grinder-core-3.12-SNAPSHOT.jar:na] at net.grinder.Console.run(Console.java:77) [grinder-core-3.12-SNAPSHOT.jar:na] at net.grinder.Console.main(Console.java:98) [grinder-core-3.12-SNAPSHOT.jar:na] 2015-04-17 20:59:33,114 INFO console: missing translation: {0} |
From: Philip A. <ph...@ma...> - 2015-04-15 18:30:23
|
The Jython 2.5 instrumenter works fine with Jython 2.7. It would be interesting to know what libraries clashed. - Phil On 14/04/15 03:55, Darren Ball wrote: > I finally got this to run. > > I figured this was a classpath clash. I synced the libraries in use > by grinder with the libraries in my application (some updated, some > downgraded) and finally this all works. That wasn't easy to solve to > say the least. I can finally move forward with Grinder - as I've been > wanting to. > > One thing is odd - the instrumenter log statement suggests Jython 2.5 > but as you can see Grinder was compiled with and pulled in Jython > 2.7rc2. Not sure what that means - maybe just a package that has not > caught up inside of Jython? > > If anyone is interested, I can send along the top level pom with > changes to make this work. > > Thanks for all the help as well - it is very much appreciated. > Hopefully as I get further acquainted with Grinder, I will be able to > help someone else out as well. > > -Darren > > > > 2015-04-14 02:46:14,895 INFO i-ccfd793a-0 : The Grinder version > 3.12-SNAPSHOT > 2015-04-14 02:46:14,903 INFO i-ccfd793a-0 : Java(TM) SE Runtime > Environment 1.8.0_40-b25: Java HotSpot(TM) 64-Bit Server VM > (25.40-b25, mixed mode) on Linux amd64 2.6.32-504.8.1.el6.x86_64 > 2015-04-14 02:46:14,909 INFO i-ccfd793a-0 : time zone is UTC (+0000) > 2015-04-14 02:46:15,062 INFO i-ccfd793a-0 : registered plug-in > net.grinder.plugin.http.HTTPPlugin > 2015-04-14 02:46:15,154 INFO i-ccfd793a-0 : worker process 0 of agent > number 0 > 2015-04-14 02:46:15,218 INFO i-ccfd793a-0 : instrumentation agents: > byte code transforming instrumenter for Jython 2.5; byte code > transforming instrumenter for Java > 2015-04-14 02:46:21,293 INFO i-ccfd793a-0 : running "dbhttp2.py" > using Jython 2.7rc2 (default:913eec7f2e60, Apr 3 2015, 17:13:45) > [Java HotSpot(TM) 64-Bit Server VM (Oracle Corporation)] > 2015-04-14 02:46:21,308 INFO i-ccfd793a-0 : starting threads > 2015-04-14 02:46:29,787 INFO i-ccfd793a-0 thread-0: starting, will do > 1 run > 2015-04-14 02:46:29,787 INFO i-ccfd793a-0 : start time is > 1428979589787 ms since Epoch > 2015-04-14 02:46:32,017 INFO i-ccfd793a-0 thread-0: finished 1 run > 2015-04-14 02:46:32,028 INFO i-ccfd793a-0 : elapsed time is 2240 ms > 2015-04-14 02:46:32,028 INFO i-ccfd793a-0 : Final statistics for this > process: > 2015-04-14 02:46:32,046 INFO i-ccfd793a-0 : > Tests Errors Mean Test Test Time TPS > > Time (ms) Standard > > Deviation > > (ms) > > > Test 1 2 0 5297.50 3085.50 0.89 > "Create APP 1 Table 100 Fields" > > Totals 2 0 5297.50 3085.50 0.89 > > > On Mon, Apr 13, 2015 at 5:34 PM, Philip Aston <ph...@ma... > <mailto:ph...@ma...>> wrote: > > > I've just run the standard unit tests against Java 8u40, and they > worked fine. The tests heavily exercise the instrumentation, but > don't do anything Java 8 specific. Its possible they are getting > tripped up by lambdas, default methods etc. > > Looking at the original test case, it appears to me that you > simply might be running the worker process under an earlier > version of Java. Please check the worker process log file - it > will tell you in the first few lines. > > Otherwise, could you produce a minimal test case? I.e. some code > you can share that demonstrates the problem? > > - Phil > > > On 13/04/15 20:59, Darren Ball wrote: >> Are any contributors/developers attempting to move this up for >> use in jdk8? >> >> On Mon, Apr 13, 2015 at 3:37 PM, Gary Mulder >> <fly...@gm... <mailto:fly...@gm...>> wrote: >> >> On 13 April 2015 at 20:35, Darren Ball <bal...@gm... >> <mailto:bal...@gm...>> wrote: >> >> I am starting to think this is due to the following: >> >> at >> net.grinder.util.weave.j2se6.ASMTransformerFactory.create(ASMTransformerFactory.java:146) >> >> at >> net.grinder.util.weave.j2se6.DCRWeaver.<init>(DCRWeaver.java:73) >> >> >> There were issues with DCR moving from JRE 6 to 7. Looks like >> something similar has resurfaced. >> >> Gary >> >> > > |
From: Philip A. <ph...@ma...> - 2015-04-15 18:24:10
|
Hi Darren, This really belongs on grinder-use - grinder-development is for the development of the grinder and has fewer subscribers. Anyway, its hard to say exactly because I don't know what CreateAppPerf does. The full stack trace from the output log would help. The difference between code executed at the top level and that executed from TestRunner.__init__() or __call__() is that the former is not executed in a worker thread, so can't itself call instrumented code. I suspect that's the problem. You could try moving the "createAppTest.record(createAppPerf.createApp)" line to TestRunner.__init__(). Calling record multiple times for the same Test and target is essentially a no-op. - Phil On 15/04/15 16:28, Darren Ball wrote: > This is exactly what I am getting along with the script, any insight > as to why the object is not available inside of the __call__ method > would be great. > > > 2015-04-15 15:25:14,768 INFO i-ccfd793a-1 thread-0: starting, will do > 1 run > 2015-04-15 15:25:14,768 INFO i-ccfd793a-1 : start time is > 1429111514767 ms since Epoch > 2015-04-15 15:25:14,851 ERROR i-ccfd793a-1 thread-0 [ run-0 ]: aborted > run - Java exception calling TestRunner > net.grinder.scriptengine.jython.JythonScriptExecutionException: Java > exception calling TestRunner > createAppPerf.createApp(1,100) > File "/home/grinder/./i-ccfd793a-file-store/current/createapp.py", > line 13, in __call__ > java.lang.NullPointerException: null > > The script: > > from net.grinder.script import Test > from net.grinder.script.Grinder import grinder > from com.myapp.api.controllers.perf.app import CreateAppPerf > > createAppTest = Test(1, "Create APP 1 Table 100 Fields") > createAppPerf = CreateAppPerf() > createAppPerf.initialize() > createAppTest.record(createAppPerf.createApp) > > > class TestRunner: > def __call__(self): > createAppPerf.createApp(1,100) > > > On Wed, Apr 15, 2015 at 11:05 AM, Darren Ball <bal...@gm... > <mailto:bal...@gm...>> wrote: > > Hi All, > > I recently found the following example online: > > If you want one instance for all worker threads in a process, > call it > from the top level of your script. > > > from mypackage import MyTest > > myTest = MyTest() > myTest.init() > > class TestRunner: > def __call__(self): > # use myTest > > I have this exact code with onle the MyTest object being the > differentiator, and in the call I get a null pointer exception. > > > from net.grinder.script import Test > from net.grinder.script.Grinder import grinder > from com.myapp.api.controllers.perf.app import CreateAppPerf > > createAppPerf = CreateAppPerf() > createAppPerf.initialize() > > createAppTest = Test(1, "Create APP 1 Table 100 Fields") > createAppTest.record(createAppPerf.createApp) > > class TestRunner: > def __call__(self): > createAppPerf.createApp(1,100) > > > > Moving the createAppPerf.initialize() to the __init__ method > works, but this is not what I would like. I would to initialize > only once. > > Any suggestions as how to do this so that createAppPerf is not > null in __call__? > > > Thanks, > Darren > |
From: Darren B. <bal...@gm...> - 2015-04-15 15:28:46
|
This is exactly what I am getting along with the script, any insight as to why the object is not available inside of the __call__ method would be great. 2015-04-15 15:25:14,768 INFO i-ccfd793a-1 thread-0: starting, will do 1 run 2015-04-15 15:25:14,768 INFO i-ccfd793a-1 : start time is 1429111514767 ms since Epoch 2015-04-15 15:25:14,851 ERROR i-ccfd793a-1 thread-0 [ run-0 ]: aborted run - Java exception calling TestRunner net.grinder.scriptengine.jython.JythonScriptExecutionException: Java exception calling TestRunner createAppPerf.createApp(1,100) File "/home/grinder/./i-ccfd793a-file-store/current/createapp.py", line 13, in __call__ java.lang.NullPointerException: null The script: from net.grinder.script import Test from net.grinder.script.Grinder import grinder from com.myapp.api.controllers.perf.app import CreateAppPerf createAppTest = Test(1, "Create APP 1 Table 100 Fields") createAppPerf = CreateAppPerf() createAppPerf.initialize() createAppTest.record(createAppPerf.createApp) class TestRunner: def __call__(self): createAppPerf.createApp(1,100) On Wed, Apr 15, 2015 at 11:05 AM, Darren Ball <bal...@gm...> wrote: > Hi All, > > I recently found the following example online: > > If you want one instance for all worker threads in a process, call it > from the top level of your script. > > > from mypackage import MyTest > > myTest = MyTest() > myTest.init() > > class TestRunner: > def __call__(self): > # use myTest > > I have this exact code with onle the MyTest object being the > differentiator, and in the call I get a null pointer exception. > > > from net.grinder.script import Test > from net.grinder.script.Grinder import grinder > from com.myapp.api.controllers.perf.app import CreateAppPerf > > createAppPerf = CreateAppPerf() > createAppPerf.initialize() > > createAppTest = Test(1, "Create APP 1 Table 100 Fields") > createAppTest.record(createAppPerf.createApp) > > class TestRunner: > def __call__(self): > createAppPerf.createApp(1,100) > > > > Moving the createAppPerf.initialize() to the __init__ method works, but > this is not what I would like. I would to initialize only once. > > Any suggestions as how to do this so that createAppPerf is not null in > __call__? > > > Thanks, > Darren > |
From: Darren B. <bal...@gm...> - 2015-04-15 15:06:22
|
Hi All, I recently found the following example online: If you want one instance for all worker threads in a process, call it from the top level of your script. from mypackage import MyTest myTest = MyTest() myTest.init() class TestRunner: def __call__(self): # use myTest I have this exact code with onle the MyTest object being the differentiator, and in the call I get a null pointer exception. from net.grinder.script import Test from net.grinder.script.Grinder import grinder from com.myapp.api.controllers.perf.app import CreateAppPerf createAppPerf = CreateAppPerf() createAppPerf.initialize() createAppTest = Test(1, "Create APP 1 Table 100 Fields") createAppTest.record(createAppPerf.createApp) class TestRunner: def __call__(self): createAppPerf.createApp(1,100) Moving the createAppPerf.initialize() to the __init__ method works, but this is not what I would like. I would to initialize only once. Any suggestions as how to do this so that createAppPerf is not null in __call__? Thanks, Darren |
From: Darren B. <bal...@gm...> - 2015-04-14 02:55:54
|
I finally got this to run. I figured this was a classpath clash. I synced the libraries in use by grinder with the libraries in my application (some updated, some downgraded) and finally this all works. That wasn't easy to solve to say the least. I can finally move forward with Grinder - as I've been wanting to. One thing is odd - the instrumenter log statement suggests Jython 2.5 but as you can see Grinder was compiled with and pulled in Jython 2.7rc2. Not sure what that means - maybe just a package that has not caught up inside of Jython? If anyone is interested, I can send along the top level pom with changes to make this work. Thanks for all the help as well - it is very much appreciated. Hopefully as I get further acquainted with Grinder, I will be able to help someone else out as well. -Darren 2015-04-14 02:46:14,895 INFO i-ccfd793a-0 : The Grinder version 3.12-SNAPSHOT 2015-04-14 02:46:14,903 INFO i-ccfd793a-0 : Java(TM) SE Runtime Environment 1.8.0_40-b25: Java HotSpot(TM) 64-Bit Server VM (25.40-b25, mixed mode) on Linux amd64 2.6.32-504.8.1.el6.x86_64 2015-04-14 02:46:14,909 INFO i-ccfd793a-0 : time zone is UTC (+0000) 2015-04-14 02:46:15,062 INFO i-ccfd793a-0 : registered plug-in net.grinder.plugin.http.HTTPPlugin 2015-04-14 02:46:15,154 INFO i-ccfd793a-0 : worker process 0 of agent number 0 2015-04-14 02:46:15,218 INFO i-ccfd793a-0 : instrumentation agents: byte code transforming instrumenter for Jython 2.5; byte code transforming instrumenter for Java 2015-04-14 02:46:21,293 INFO i-ccfd793a-0 : running "dbhttp2.py" using Jython 2.7rc2 (default:913eec7f2e60, Apr 3 2015, 17:13:45) [Java HotSpot(TM) 64-Bit Server VM (Oracle Corporation)] 2015-04-14 02:46:21,308 INFO i-ccfd793a-0 : starting threads 2015-04-14 02:46:29,787 INFO i-ccfd793a-0 thread-0: starting, will do 1 run 2015-04-14 02:46:29,787 INFO i-ccfd793a-0 : start time is 1428979589787 ms since Epoch 2015-04-14 02:46:32,017 INFO i-ccfd793a-0 thread-0: finished 1 run 2015-04-14 02:46:32,028 INFO i-ccfd793a-0 : elapsed time is 2240 ms 2015-04-14 02:46:32,028 INFO i-ccfd793a-0 : Final statistics for this process: 2015-04-14 02:46:32,046 INFO i-ccfd793a-0 : Tests Errors Mean Test Test Time TPS Time (ms) Standard Deviation (ms) Test 1 2 0 5297.50 3085.50 0.89 "Create APP 1 Table 100 Fields" Totals 2 0 5297.50 3085.50 0.89 On Mon, Apr 13, 2015 at 5:34 PM, Philip Aston <ph...@ma...> wrote: > > I've just run the standard unit tests against Java 8u40, and they worked > fine. The tests heavily exercise the instrumentation, but don't do anything > Java 8 specific. Its possible they are getting tripped up by lambdas, > default methods etc. > > Looking at the original test case, it appears to me that you simply might > be running the worker process under an earlier version of Java. Please > check the worker process log file - it will tell you in the first few lines. > > Otherwise, could you produce a minimal test case? I.e. some code you can > share that demonstrates the problem? > > - Phil > > > On 13/04/15 20:59, Darren Ball wrote: > > Are any contributors/developers attempting to move this up for use in jdk8? > > On Mon, Apr 13, 2015 at 3:37 PM, Gary Mulder <fly...@gm...> > wrote: > >> On 13 April 2015 at 20:35, Darren Ball <bal...@gm...> wrote: >> >>> I am starting to think this is due to the following: >>> >>> at >>> net.grinder.util.weave.j2se6.ASMTransformerFactory.create(ASMTransformerFactory.java:146) >>> >>> at net.grinder.util.weave.j2se6.DCRWeaver.<init>(DCRWeaver.java:73) >>> >> >> There were issues with DCR moving from JRE 6 to 7. Looks like something >> similar has resurfaced. >> >> Gary >> > > > |
From: Philip A. <ph...@ma...> - 2015-04-13 21:34:51
|
I've just run the standard unit tests against Java 8u40, and they worked fine. The tests heavily exercise the instrumentation, but don't do anything Java 8 specific. Its possible they are getting tripped up by lambdas, default methods etc. Looking at the original test case, it appears to me that you simply might be running the worker process under an earlier version of Java. Please check the worker process log file - it will tell you in the first few lines. Otherwise, could you produce a minimal test case? I.e. some code you can share that demonstrates the problem? - Phil On 13/04/15 20:59, Darren Ball wrote: > Are any contributors/developers attempting to move this up for use in > jdk8? > > On Mon, Apr 13, 2015 at 3:37 PM, Gary Mulder <fly...@gm... > <mailto:fly...@gm...>> wrote: > > On 13 April 2015 at 20:35, Darren Ball <bal...@gm... > <mailto:bal...@gm...>> wrote: > > I am starting to think this is due to the following: > > at > net.grinder.util.weave.j2se6.ASMTransformerFactory.create(ASMTransformerFactory.java:146) > > at > net.grinder.util.weave.j2se6.DCRWeaver.<init>(DCRWeaver.java:73) > > > There were issues with DCR moving from JRE 6 to 7. Looks like > something similar has resurfaced. > > Gary > > |
From: Philip A. <ph...@ma...> - 2015-04-13 21:29:49
|
Yeah - you want -DskipTests=true. -Dmaven.test.skip disable compilation of tests as well as execution, hence the issue. - Phil On 13/04/15 17:37, Darren Ball wrote: > This seems to solve the problem: > > mvn -e -Dverbose=true -Dskipit -DskipTests=true clean install > > On Mon, Apr 13, 2015 at 12:30 PM, Darren Ball <bal...@gm...> wrote: >> Hi All, >> >> As I am attempting to resolve a compatibility issue potentially, I >> decided to compile this project locally, but I am encountering the >> following error: >> >> I am using the following command to build: >> >> mvn -e -Dverbose=true -Dmaven.test.skip=true -Dskipit -DskipTests clean install >> >> The following (test dependency resolution) is encountered: >> >> [INFO] >> [INFO] ------------------------------------------------------------------------ >> [INFO] Building grinder-http 3.12-SNAPSHOT >> [INFO] ------------------------------------------------------------------------ >> [INFO] ------------------------------------------------------------------------ >> [INFO] Reactor Summary: >> [INFO] >> [INFO] grinder-parent .................................... SUCCESS [0.237s] >> [INFO] grinder-dcr-agent ................................. SUCCESS [0.662s] >> [INFO] grinder-translation ............................... SUCCESS [1.691s] >> [INFO] grinder-test-support .............................. SUCCESS [0.546s] >> [INFO] grinder-core ...................................... SUCCESS [2.403s] >> [INFO] grinder-httpclient ................................ SUCCESS [0.657s] >> [INFO] grinder-xmlbeans .................................. SUCCESS [2.601s] >> [INFO] grinder-http ...................................... FAILURE [0.021s] >> [INFO] grinder-console-service ........................... SKIPPED >> [INFO] grinder-swing-console ............................. SKIPPED >> [INFO] grinder ........................................... SKIPPED >> [INFO] ------------------------------------------------------------------------ >> [INFO] BUILD FAILURE >> [INFO] ------------------------------------------------------------------------ >> [INFO] Total time: 9.226s >> [INFO] Finished at: Mon Apr 13 12:29:19 EDT 2015 >> [INFO] Final Memory: 43M/383M >> [INFO] ------------------------------------------------------------------------ >> [ERROR] Failed to execute goal on project grinder-http: Could not >> resolve dependencies for project >> net.sf.grinder:grinder-http:jar:3.12-SNAPSHOT: Failure to find >> net.sf.grinder:grinder-core:jar:tests:3.12-SNAPSHOT in >> https://oss.sonatype.org/content/repositories/snapshots was cached in >> the local repository, resolution will not be reattempted until the >> update interval of sonatype-nexus-snapshots has elapsed or updates are >> forced -> [Help 1] >> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to >> execute goal on project grinder-http: Could not resolve dependencies >> for project net.sf.grinder:grinder-http:jar:3.12-SNAPSHOT: Failure to >> find net.sf.grinder:grinder-core:jar:tests:3.12-SNAPSHOT in >> https://oss.sonatype.org/content/repositories/snapshots was cached in >> the local repository, resolution will not be reattempted until the >> update interval of sonatype-nexus-snapshots has elapsed or updates are >> forced > ------------------------------------------------------------------------------ > BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT > Develop your own process in accordance with the BPMN 2 standard > Learn Process modeling best practices with Bonita BPM through live exercises > http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ > source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF > _______________________________________________ > Grinder-development mailing list > Gri...@li... > https://lists.sourceforge.net/lists/listinfo/grinder-development |
From: Darren B. <bal...@gm...> - 2015-04-13 19:59:27
|
Are any contributors/developers attempting to move this up for use in jdk8? On Mon, Apr 13, 2015 at 3:37 PM, Gary Mulder <fly...@gm...> wrote: > On 13 April 2015 at 20:35, Darren Ball <bal...@gm...> wrote: > >> I am starting to think this is due to the following: >> >> at >> net.grinder.util.weave.j2se6.ASMTransformerFactory.create(ASMTransformerFactory.java:146) >> >> at net.grinder.util.weave.j2se6.DCRWeaver.<init>(DCRWeaver.java:73) >> > > There were issues with DCR moving from JRE 6 to 7. Looks like something > similar has resurfaced. > > Gary > |
From: Gary M. <fly...@gm...> - 2015-04-13 19:38:13
|
On 13 April 2015 at 20:35, Darren Ball <bal...@gm...> wrote: > I am starting to think this is due to the following: > > at > net.grinder.util.weave.j2se6.ASMTransformerFactory.create(ASMTransformerFactory.java:146) > > at net.grinder.util.weave.j2se6.DCRWeaver.<init>(DCRWeaver.java:73) > There were issues with DCR moving from JRE 6 to 7. Looks like something similar has resurfaced. Gary |
From: Darren B. <bal...@gm...> - 2015-04-13 19:35:52
|
I am starting to think this is due to the following: at net.grinder.util.weave.j2se6.ASMTransformerFactory.create(ASMTransformerFactory.java:146) at net.grinder.util.weave.j2se6.DCRWeaver.<init>(DCRWeaver.java:73) Anyway to move this into modern times? -Darren On Mon, Apr 13, 2015 at 2:07 PM, Darren Ball <bal...@gm...> wrote: > I can not use JRE 7. The libraries I am pulling in require jdk8. > I have tried with the standalone jython (2.5.3) that exists in the lib > directory. > > Running jython using the following: > > java -classpath > "/home/grinder/uber/*":/home/grinder/myapp-uber.jar:/opt/grinder/lib/grinder.jar:/opt/grinder/lib/jython-standalone-2.5.3.jar > org.python.util.jython -v > > I can run my code fine. > > When using the agent, this all falls apart. I believe this is specific to > grinder's libraries given that I can easily launch my code form the jython > console. > > Recompiling with the correct jdk does not help at the moment. > > > On Mon, Apr 13, 2015 at 1:37 PM, Gary Mulder <fly...@gm...> > wrote: > >> >> On 13 April 2015 at 18:10, Darren Ball <bal...@gm...> wrote: >> >>> Well, >>> Even after building locally with jdk8, I still have this issue: >>> >> >> Just to confirm you have tried JRE 7 and Jython as provided in ./lib in >> Grinder? >> >> Can you include another library or is it specific to your library? >> >> Gary >> > > |
From: Darren B. <bal...@gm...> - 2015-04-13 18:21:27
|
I've tried this with even the most basic of scripts as well, and it still fails. The classpath I am introducing contains jars built on jdk8, and this is likely the issue. Having built grinder with jdk8, the issue still persists though. The basic script attempted as well: from net.grinder.script import Test from net.grinder.script.Grinder import grinder test1 = Test(1, "Log method") # Instrument the info() method with our Test. test1.record(grinder.logger.info) class TestRunner: def __call__(self): log("Hello World") On Mon, Apr 13, 2015 at 2:07 PM, Darren Ball <bal...@gm...> wrote: > I can not use JRE 7. The libraries I am pulling in require jdk8. > I have tried with the standalone jython (2.5.3) that exists in the lib > directory. > > Running jython using the following: > > java -classpath > "/home/grinder/uber/*":/home/grinder/myapp-uber.jar:/opt/grinder/lib/grinder.jar:/opt/grinder/lib/jython-standalone-2.5.3.jar > org.python.util.jython -v > > I can run my code fine. > > When using the agent, this all falls apart. I believe this is specific to > grinder's libraries given that I can easily launch my code form the jython > console. > > Recompiling with the correct jdk does not help at the moment. > > > On Mon, Apr 13, 2015 at 1:37 PM, Gary Mulder <fly...@gm...> > wrote: > >> >> On 13 April 2015 at 18:10, Darren Ball <bal...@gm...> wrote: >> >>> Well, >>> Even after building locally with jdk8, I still have this issue: >>> >> >> Just to confirm you have tried JRE 7 and Jython as provided in ./lib in >> Grinder? >> >> Can you include another library or is it specific to your library? >> >> Gary >> > > |
From: Darren B. <bal...@gm...> - 2015-04-13 17:11:13
|
Well, Even after building locally with jdk8, I still have this issue: Exception in thread "main" java.lang.IncompatibleClassChangeError: Implementing class at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:760) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) at java.net.URLClassLoader.defineClass(URLClassLoader.java:467) at java.net.URLClassLoader.access$100(URLClassLoader.java:73) at java.net.URLClassLoader$1.run(URLClassLoader.java:368) at java.net.URLClassLoader$1.run(URLClassLoader.java:362) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:361) at java.lang.ClassLoader.loadClass(ClassLoader.java:424) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:760) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) at java.net.URLClassLoader.defineClass(URLClassLoader.java:467) at java.net.URLClassLoader.access$100(URLClassLoader.java:73) at java.net.URLClassLoader$1.run(URLClassLoader.java:368) at java.net.URLClassLoader$1.run(URLClassLoader.java:362) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:361) at java.lang.ClassLoader.loadClass(ClassLoader.java:424) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) at net.grinder.util.weave.j2se6.ASMTransformerFactory.create(ASMTransformerFactory.java:146) at net.grinder.util.weave.j2se6.DCRWeaver.<init>(DCRWeaver.java:73) at net.grinder.engine.process.dcr.DCRContextImplementation.<init>(DCRContextImplementation.java:112) at net.grinder.engine.process.dcr.DCRContextImplementation.create(DCRContextImplementation.java:91) at net.grinder.engine.process.GrinderProcess.run(GrinderProcess.java:328) at net.grinder.engine.process.WorkerProcessEntryPoint.run(WorkerProcessEntryPoint.java:88) at net.grinder.engine.process.WorkerProcessEntryPoint.main(WorkerProcessEntryPoint.java:60) Any help would be greatly appreciated. Thanks, Darren On Mon, Apr 13, 2015 at 10:43 AM, Darren Ball <bal...@gm...> wrote: > Hi All, I really need to solve the problem below and I am in need of > a little assistance if possible. > > It looks like this might be a jdk mismatch issue? > > I've tried building with the src code on github with jdk8 but I am > getting several errors. > > I have been experiencing the following error while attempting to > execute a simple grinder jython test. Any help or insight as to a > solution would be greatly appreciated. > > The test is structured as follows: > > from net.grinder.Grinder import grinder > from net.grinder.script import Test > from com.mywebapp.api.controllers.perf.app import CreateAppPerf > > test1 = Test(1, "Create APP 1 Table 100 Fields") > createAppPerf = CreateAppPerf() > test1.record(createAppPerf.createApp) > > class TestRunner: > def __init__(self): > createAppPerf.initialize() > > def __call__(self): > createAppPerf.createApp(1,100) > > > The error I am receiving is as follows: > > Exception in thread "main" java.lang.IncompatibleClassChangeError: > Implementing class > at java.lang.ClassLoader.defineClass1(Native Method) > at java.lang.ClassLoader.defineClass(ClassLoader.java:760) > at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) > at java.net.URLClassLoader.defineClass(URLClassLoader.java:467) > at java.net.URLClassLoader.access$100(URLClassLoader.java:73) > at java.net.URLClassLoader$1.run(URLClassLoader.java:368) > at java.net.URLClassLoader$1.run(URLClassLoader.java:362) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:361) > at java.lang.ClassLoader.loadClass(ClassLoader.java:424) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331) > at java.lang.ClassLoader.loadClass(ClassLoader.java:357) > at java.lang.ClassLoader.defineClass1(Native Method) > at java.lang.ClassLoader.defineClass(ClassLoader.java:760) > at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) > at java.net.URLClassLoader.defineClass(URLClassLoader.java:467) > at java.net.URLClassLoader.access$100(URLClassLoader.java:73) > at java.net.URLClassLoader$1.run(URLClassLoader.java:368) > at java.net.URLClassLoader$1.run(URLClassLoader.java:362) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:361) > at java.lang.ClassLoader.loadClass(ClassLoader.java:424) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331) > at java.lang.ClassLoader.loadClass(ClassLoader.java:357) > at net.grinder.util.weave.j2se6.ASMTransformerFactory.create(ASMTransformerFactory.java:119) > at net.grinder.util.weave.j2se6.DCRWeaver.<init>(DCRWeaver.java:70) > at net.grinder.engine.process.dcr.DCRContextImplementation.<init>(DCRContextImplementation.java:112) > at net.grinder.engine.process.dcr.DCRContextImplementation.create(DCRContextImplementation.java:89) > at net.grinder.engine.process.GrinderProcess.run(GrinderProcess.java:361) > at net.grinder.engine.process.WorkerProcessEntryPoint.run(WorkerProcessEntryPoint.java:86) > at net.grinder.engine.process.WorkerProcessEntryPoint.main(WorkerProcessEntryPoint.java:59) |