<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div apple-content-edited="true"><div><br></div></div><div><div>On 03 Apr 2014, at 12:49, Kirill Izotov <<a href="mailto:enykeev@stackstorm.com">enykeev@stackstorm.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<div style="font-family: Helvetica; font-size: 13px;"><div>Actually, the idea to make the concept more expandable is exactly my point =) Mistral's Workbook is roughly the same as TaskFlow Flow and have nothing to do with TaskFlow LogBook. The only major difference in case of Workbook is that we have to store it after it was created using API or DSL. I very much like the idea to inherit form basic Flow and add serialization and additional metadata on top of it, but the concept of retrying within a Workbook\Flow is not exactly what we have in mind. Instead of repeating the Flow, we are repeating the Task (which has the same differences between Mistral and TaskFlow as Workbook has) and to use the trick you have proposed we would have to translate the Task into a Flow. How much sense does it make in respect to expandability and generality?</div></div></blockquote><div><br></div><div>Just one clarification. Workbook is a wider abstraction. Along with workflow itself it includes action definitions, triggers (even though it’s still controversial even within the team itself). Potentially it may include something else. So having a workbook in TaskFlow with strictly defined behaviour is not a good decision.</div><br><blockquote type="cite"><div><div><blockquote type="cite"><div>Ya, I think u are hitting this issue, if a worker acks a message saying its 'working on it' then the worker dies, this is where a message queue ack model won't really help in solving, the engine will believe that the worker is working on it (since hey the worker acked it) but the engine will really have no idea that the worker is actually dead. Of course timeouts can be used to get around this but imho that’s really un-elegant when something like zookeeper (or similar) can be used to be notified of this worker death <i>immediately</i>; which means no timeouts are needed at all, and this separate process or engine can be notified of this death (and resolve it immediately). I don't believe this kind of '<i>liveness</i>' connection is possible with rabbit (we also must think of other things besides rabbit, like qpid and such) but I might be wrong, I thought once a worker acks a message then whoever receives that ack will believe the work has started and will be finished someday in the future (aka, no connection that the work is actually in progress). Anyways, we can discuss this more since I think its a common confusion point :-)</div></blockquote><div>As far as i understand, what Renat is proposing here is not to acknowledge the message until it was successfully executed. I'm not sure how exactly RabbitMQ will react in that case, though you are right in the idea that we must investigate the other solutions more carefully.</div></div></div></blockquote></div><br><div>Joshua, I think your understanding of how it works is not exactly correct (or my understanding actually :)). Let’s talk in IRC, we’ll explain it.</div><div><br></div><div>I’d suggest we talk in IRC on Thursday at 8.30 pm (Friday 10.30 in our timezone).</div><div><br></div><div><div>Renat Akhmerov</div><div>@ Mirantis Inc.</div></div><div><br></div></body></html>