grinder-development — Discussion list for Grinder developers.

[Grinder-development] Working Maven Grinder Project OOTB

[gradeawarrior <psa...@gm...>]

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.

Re: [Grinder-development] [Grinder-use] atExit worker state - inconsistency?

[Darren B. <bal...@gm...>]

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
>>
>>
>

Re: [Grinder-development] [Grinder-use] atExit worker state - inconsistency?

[Darren B. <bal...@gm...>]

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
>
>

[Grinder-development] atExit worker state - inconsistency?

[Darren B. <bal...@gm...>]

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-development] Java Thick Client project

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

Re: [Grinder-development] New Releases

[Philip A. <ph...@ma...>]

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

[Grinder-development] New Releases

[Marcus F. <mar...@gm...>]

Is there anyone working on updates for The Grinder? No new releases since
2012.

Re: [Grinder-development] [Grinder-use] Agent not responding after initial startup

[Darren B. <bal...@gm...>]

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
>
>

Re: [Grinder-development] tower - missing translation

[Darren B. <bal...@gm...>]

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
>>
>>
>>
>>
>>
>

Re: [Grinder-development] tower - missing translation

[Darren B. <bal...@gm...>]

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
>
>
>
>
>

Re: [Grinder-development] tower - missing translation

[Philip A. <ph...@ma...>]

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

[Grinder-development] tower - missing translation

[Darren B. <bal...@gm...>]

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

[Grinder-development] Timer-0 invalid locale?

[Darren B. <bal...@gm...>]

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}

Re: [Grinder-development] If anyone is out there - help!

[Philip A. <ph...@ma...>]

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
>>
>>
>
>

Re: [Grinder-development] Initialization of object once per thread

[Philip A. <ph...@ma...>]

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
>

Re: [Grinder-development] Initialization of object once per thread

[Darren B. <bal...@gm...>]

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
>

[Grinder-development] Initialization of object once per thread

[Darren B. <bal...@gm...>]

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

Re: [Grinder-development] If anyone is out there - help!

[Darren B. <bal...@gm...>]

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
>>
>
>
>

Re: [Grinder-development] If anyone is out there - help!

[Philip A. <ph...@ma...>]

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
>
>

Re: [Grinder-development] Maven compile - skiptests - error

[Philip A. <ph...@ma...>]

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

Re: [Grinder-development] If anyone is out there - help!

[Darren B. <bal...@gm...>]

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
>

Re: [Grinder-development] If anyone is out there - help!

[Gary M. <fly...@gm...>]

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

Re: [Grinder-development] If anyone is out there - help!

[Darren B. <bal...@gm...>]

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
>>
>
>

Re: [Grinder-development] If anyone is out there - help!

[Darren B. <bal...@gm...>]

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
>>
>
>

Re: [Grinder-development] If anyone is out there - help!

[Darren B. <bal...@gm...>]

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)