[kepler-dev] best practices for minimizing process start-up latency?

[Daniel Crawl]

Hi Rich,

The Kepler provenance framework captures all the data
transferred between actors. By default, this is written
to an SQL database, but you could send it elsewhere. For
more information about the provenance framework, see:

https://code.kepler-project.org/code/kepler/trunk/modules/provenance
/docs/provenance.pdf

Also, the Reporting suite creates reports of workflow
results including the data transferred between actors. See:

https://code.kepler-project.org/code/kepler/trunk/modules/reporting/docs/reporting.pdf


   --dan


On 1/10/14 9:44 AM, Rich Morin wrote:
> On Jan 10, 2014, at 09:20, Christopher Brooks wrote:
>> My responses are below.
>
> Thanks!
>
>>> The following questions have to do with the inter-actor "piping"
>>> and best practices for command debugging and optimization.
>>>
>>> Q:  Can I add recording and/or archiving as attributes to a pipe?
>>>
>>>      So, for example, could I tell Kepler to turn on recording for
>>>      particular pipes, without needing to explicitly add an actor?
>>>      (This could be used for "tracing" key paths in an app.)
>>
>> I don't know of an actor that has access to pipes.  ...
>
> Perhaps I should have said "plumbing".  I'm referring to the usual
> communication channels used by Kepler/Ptolemy actors, not to Unix
> named pipes, etc.
>
> There was a talk at the PII meeting about hanging attributes on
> connections.  I was wondering if something like this could be used
> to enable archiving or analysis of the transmitted data, etc.
>
> -r
>
>   --
> http://www.cfcl.com/rdm           Rich Morin           rdm at cfcl.com
> http://www.cfcl.com/rdm/resume    San Bruno, CA, USA   +1 650-873-7841
>
> Software system design, development, and documentation
>
>
> _______________________________________________
> Kepler-dev mailing list
> Kepler-dev at kepler-project.org
> http://lists.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev
>