[kepler-users] Asynchronous source Model of Computation

[Chris Weed]

Add CC to mailing list

It doesn't look like it ever calls the wrapup function, but that isn't
really critical.
I can just close and reopen the workflow, although, that's not
particularly ideal.
My bigger concern is the performance problems I was having where the
workflow would bog-down. That sleep call took care of that.

Now, that I think more about it, maybe a FSM model would make more sense
with two states, on (streaming data) and off (no connection).

Chris


On Fri, Aug 7, 2009 at 2:26 PM, Timothy McPhillips<tmcphillips at mac.com> wrote:
> Hi Chris,
>
> Ok, then your workflow is meant to stop when you hit the "Stop" button.  I'm
> curious to know if that works with your actor written the way it is?
>
> Tim
>
> On Aug 7, 2009, at 11:19 AM, Chris Weed wrote:
>
>> Hi Tim,
>>
>> The data is just streaming in from a port, and there really is no end.
>> My workflow is really creating a long running system that will receive
>> tokens forever as long as the server on the UDP port is working.
>>
>> I suspect my use case is very different from what you describe where
>> you process a fixed set of data. In my case, the data is streaming in from
>> a real-time sensor that is always running. By connecting to the
>> server port, I can analyze the data. I generally end the workflow
>> by hitting the "stop" button since the data doesn't end.
>> This should call the wrapup function of my actor to close the port,
>> I presume, but I have never tested that.
>>
>> Chris
>>
>> On Fri, Aug 7, 2009 at 2:06 PM, Timothy McPhillips<tmcphillips at mac.com>
>> wrote:
>>>
>>> Hi Chris,
>>>
>>> How does your workflow knows when to stop?  One advantage of using the
>>> prefire/fire/postfire pattern in designing an actor is that it  provides
>>> the
>>> actor a way of telling the workflow system that it isn't going to do any
>>> more work or produce more tokens.  I tend to write PN workflows that
>>> depend
>>> on the first actor in the workflow declaring when it has produced all the
>>> tokens that is going to produce (by returning false from postfire); the
>>> system can then see to it that downstream actors wrap up nicely and don't
>>> wait forever for data which is never going to arrive.
>>>
>>> Perhaps in your actors, the fire and postfire methods could interact with
>>> the other thread such that, say, the fire method returns each time a
>>> token
>>> is emitted, and postfire returns false when there are no more tokens to
>>> output?  Or does that make no sense in your case?
>>>
>>> Cheers,
>>>
>>> Tim
>>>
>>> On Aug 7, 2009, at 8:17 AM, Chris Weed wrote:
>>>
>>>> I have several actors that are token sources that generate tokens
>>>> asynchronously.
>>>> An example is an actor that connects to a UDP port and produces tokens
>>>> from
>>>> packets it receives.
>>>> The actors essentially initialize a separate thread, which
>>>> asynchronously outputs tokens
>>>> to an output port. My prefire, fire, and postfire functions are empty,
>>>> and when used
>>>> with the PN director seem to bog down the system. It looks like these
>>>> empty
>>>> functions just get called over and over. To overcome this, I put a
>>>> non-ending while-loop
>>>> in the fire method to just sleep the actors main thread. I am curious
>>>> if this is the correct
>>>> way to do this, or am I missing something.
>>>> Chris
>>>> _______________________________________________
>>>> Kepler-users mailing list
>>>> Kepler-users at kepler-project.org
>>>> http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-users
>>>
>>>
>
>