<div><br></div><div><div><br></div></div>
                 
                <p style="color: #A0A0A8;">On Tuesday, January 24, 2012 at 6:05 PM, Zhongyue Luo wrote:</p>
                <blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;">
                    <span><div><div>I assume the messages will be delivered directly to the destination rather than piling up on a queue server?<div></div></div></div></span></blockquote><div>
                    <br>
                </div><div>Although the blueprint doesn't specify this level of detail, the intention had originally been to deliver a queue-server model in Essex with a distributed-model in Folsom.  The first-cut code which passes tests does pile onto a queue server.  I now have code which implements a distributed model, but it is in a raw state. There are a number of edge-cases a distributed model can face, especially in regard to threading mechanisms (i.e. eventlet).</div><div><br></div><div>My current blockers for having this code ready for a merge-proposal are not related to a single-server or distributed model. Once I address these problems, there can be a decision on how much time is left to debug a distributed model within a FFe time-frame, or if this can be accepted as a separate blueprint within E4. If I get a solid 1-2 weeks or more for a FFe, I'll be more confident in the distributed model as there is more room to test, debug, and fix.</div><div><br></div><div>By the way, I must note in this thread, that I haven't done this alone.  A good amount of this work, i.e. the first-first-cut, was completed by Zed Shaw and was made possible through his QAL. Duncan McGreggor has been on hand, helpful, and has contributed some commits as well.</div><div><br></div><div><div>Regards,</div>Eric Windisch</div>