Re: Grinder Feature Enhancements for Worker Notifications and Console Reporting

  Apologies for the tardy response. I'm very busy with work at the 
moment, and I don't see this changing for the next few months.

Anyway, if this is still an open question, I would recommend not using a 
blocking sender to wait for the console response. Instead I would have 
some per-worker lock registry. When a blocking point is reached, the 
worker can place the fact its waiting for a response in the registry 
then synchronously call the console to register the lock (removing it 
from the registry if the call fails). The worker can then sleep until a 
different message is broadcast from the console, through the normal 
channels, which comes in through the main worker listener and updates 
the lock registry, so waking the appropriate thread(s).

- Phil

On 03/06/10 18:22, David Smith wrote:
> Hi Phil,
>
> Thanks for the feedback.  I am starting to prototype the synchronisation API
> to create the sync handles, wait for all handles across all agents to close
> or reach the waiting point, and close the handles.  For this type of
> blocking communication from the agent to the console it looks like I will
> need to create a new blocking sender instance for the workers to use for
> these sync handle operations, since they need a response from the console to
> continue.  Would having a blocking sender instantiated at a high level in
> the worker's code base (such as in the GrinderProcess class) be beneficial
> for future coding projects, or do you think it would be best to retain the
> blocking sender privately in my new synchronization classes?
>
>
> David Smith
> Information Sciences Institute
> [email protected]
> +1 (310)-448-9113
>
>
> -----Original Message-----
> From: Philip Aston [mailto:[email protected]]
> Sent: Saturday, May 29, 2010 8:39 AM
> To: grinder-development-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> Subject: Re: [Grinder-development] Grinder Feature Enhancements for Worker
> Notifications and Console Reporting
>
> Hi David,
>
> On 28/05/10 02:34, David Smith wrote:
>> Good evening,
>>
>> Our organization is interested in using The Grinder for some
>> performance test measurements we will record.  There are a few
>> enhancements we would like to discuss and are willing to contribute
>> the code back to the community if there is interest in any of them.
>>
>> 1. *Ability to wait for a test to finish on all agent workers prior to
>> starting the next test.*  This would allow us to batch run a large
>> number of concurrent tests and help ensure that the same test is
>> actually running on all agents at any given time.  It seems like the
>> easiest way for us to do this is to run the console in headless mode
>> and enhance the Console API so that it allows listeners to be notified
>> when agents have started and finished processing a test.  We could
>> utilize this enhancement, along with the startWorkerProcesses()
>> method, to control when the next test starts on all agents.  I saw
>> that having a listener in the Console API was on the to-do list.
>>
> Yes, I've thought about doing something like this. I wouldn't base it on
> Test()'s though, but instead create a separate synchronisation API which
> the scripts would use. I don't think it would involve the console API,
> but would use the console for coordination.
>
> I'd imagine an API that looks something like this:
>
>       sync = grinder.synchronisation.register("my sync point") # create a
> sync handle
>
>       ##
>
>       sync.waitForAll()    # Blocks until all handles for "my sync point"
> have reached this point or have been closed
>
>       ##
>
>       sync.close()    # In case a script no longer wants to participate
> in a sync point. Will also happen automatically if the worker
> disconnects from the console.
>
>
>
>> 2. *An option to publish detailed test results to the console.*  In
>> many cases the individual test results would contain too much data to
>> maintain in the console, making the summarized results the better
>> information to present.  However in our testing it would be more
>> useful to have all of the data collected from all the agents into a
>> single location by the console.
>>
> There may be a data volume issue here. Not sure.
>
>> 3. *Collect statistics in a headless console.*  If our solution needs
>> to involve running the console in headless mode and sending all the
>> data collected to it, we will need to enhance the Console so that it
>> is able to record the data somehow.  I also saw that this is a To-do
>> list item.
>>
>> 4. *Push files from the console to the agents when running in headless
>> mode.*  We foresee ourselves having many agents deployed, so manually
>> transferring script changes to all of these files will be problematic
>> for us.
>>
> Yes, definitely both "to do"s
>
>> Let me know if any of these enhancements are already underway by
>> someone else.  We would like our efforts to benefit the project as a
>> whole as well as our own needs, so feel free to discuss any additional
>> requirements or ideas regarding these enhancements with us and the list.
>>
> I won't be working on any of these in the near future, and I'd welcome
> such contributions. Please go ahead and prototype
>
> Be aware that I'm a benevolent dictator and can be fussy about accepting
> patches, and will want to review things carefully before merging them
> back into the source tree, there's some hints at
> http://grinder.sourceforge.net/development/contributing.html. Start with
> some small things, and we'll proceed from there.
>
> - Phil
>
>
> ----------------------------------------------------------------------------
> --
>
> _______________________________________________
> Grinder-development mailing list
> Grinder-development-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/grinder-development
>
>


------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first