[kepler-dev] Some questions on KEM monitoring

[Carlos Rueda]

Hello Faraaz,

Please see below.

On Mon, Jun 30, 2008 at 7:35 PM, Faraaz Sareshwala <fsaresh at ucdavis.edu>
wrote:

> Hello Mr. Rueda,
> Hope you are doing well. Professor Ludaescher and I met June 20, 2008 and I
> had some questions about the KEM monitoring system you implemented that I
> was hoping you could answer.
>
> First and foremost, in your implementation of the traffic lights and
> progress bars in KEM, what are the "observables" which KEM uses.
>

The MonitorManager associates a MonitoredStatus object to each entity in the
workflow [1]. A MonitoredStatus instance is basically a set of properties
[2] that are "observable." PropertyChangeListener's can be registered with a
monitored status object to get notified whenever changes occur. Note that
FigureUpdater [3] is one such listener.


> While experimenting with the system, I was able to determine that it used
> token read/write to select the color for the traffic light. Professor
> Ludaescher and I hypothesized that there must be some form of timestamp also
> with the token read/write since the traffic light will turn yellow when
> there hasn't been token flow for some user set amount of time. Is this
> correct?
>

Basically, yes. KEM does not use any explicit timestamp, but rather keeps
track of the time when the last token was either generated or received. The
inner class PropertyTimer in MonitoredStatus [2] handles an internal timer
that calls setProperty(propName, propValue) on the enclosing MonitoredStatus
if, whenever the timer is triggered, the current time minus the time when
the setProperty method was last called is greater than a given delay.


>
> I was also looking into your progress bars. I personally was only able to
> see the indeterminate progress bar but some screenshots on your
> documentation on the wiki show that determinate progress bars are also a
> possibility. My question here is that in the case of a determinate progress
> bar, how does the MonitorManager know the progress only by token count?
> There has to be some sort of denominator of total tokens to be generated
> known beforehand in order to make an accurate judgment on the progress of a
> given actor. I was a bit confused as to how this worked and if you could
> expand on it, I would greatly appreciate it!
>

Yes, you need to know the total size corresponding to a 100% filled
determinate progress bar.  As you can see in the test actor
ActorWithProgressBar [4], it includes a parameter maxParam that the user
will need to specify (> 0) to obtain a determinate progress bar. This test
actor demonstrates how a developer would directly use the KEM API. In this
sense, the determinate progress bar is more intended for internal,
presumably long-running tasks upon a single firing of the actor. By
"internal" I mean tasks that are performed inside the actor (perhaps using
remote resources) and thus not necessarily reflected in the token
consumption/generation rate of the actor in the workflow.  Of course, along
the lines of ActorWithProgressBar, one can as well get the maxParam from
some workflow parameter or port using any of the Ptolemy/Kepler mechanisms.
So, it will be up to the particular case how to determine the 100% size.


>
> Furthermore, I didn't receive any errors which would have caused my traffic
> lights to go red but I was wondering how these errors are reported. On the
> documentation, you mention that it is simply some error which stops the
> actor from continuing normally. At this point, is the error and/or possible
> cause reported to the user or does the user have to do further investigation
> in order to learn the reason.
>

In this simple version of the use case [1], it is only mentioned that some
error occurred in the actor, so the user will probably need to go to the
logs or use other Ptolemy/Kepler mechanism to learn more about the
exception. But note that, besides an ERROR state definition [2] and a
corresponding color scheme association in the traffic lights [5], the error
handling in KEM is not yet properly designed or implemented.

refs:
[1] http://www.kepler-project.org/Wiki.jsp?page=KeplerExecutionMonitoring
[2]
https://code.kepler-project.org/code/kepler/trunk/src/org/kepler/monitor/MonitoredStatus.java
[3]
https://code.kepler-project.org/code/kepler/trunk/src/org/kepler/monitor/FigureUpdater.java
[4]
https://code.kepler-project.org/code/kepler/trunk/src/org/kepler/monitor/test/ActorWithProgressBar.java
[5]
https://code.kepler-project.org/code/kepler/trunk/src/org/kepler/monitor/figure/TrafficLightFigure.java



> If you could shed some light on these issues, I would greatly appreciate it
> :)!
>
> Thanks,
> Faraaz
>


Sure. Hope it helps.

Good luck,

Carlos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/kepler-dev/attachments/20080701/6f3212b5/attachment.htm