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