On Aug 11 2013 10:14 AM, Michael Haberler wrote: > Am 11.08.2013 um 16:51 schrieb EBo <[email protected]>: > >> On Aug 11 2013 8:25 AM, Michael Haberler wrote: >>> ... >>> >>> for instance it turns out that waiting for command completion must >>> be >>> idempotent in face of serial reuse with the same ticket id. Another >>> reason why you'd want total ordering of tickets, otherwise this >>> becomes very messy. >> >> Now were are definitely in the weeds... > > not me ..
not implying that you are, but the whole process stack might be... No, these are very subtle issues and it is good to see that someone had gotten on it. >> Is this why you did not want >> to reuse ID's? Also, what is causing the ticket ordering to get out >> of >> sync? Can the message passing (and everything else in the stream) >> guarantee in the worst case that any given ticket will have enough >> time >> to get collected and put in its slot before it is time to execute? > > no, all I am saying is: client code might ask more than once for the > completion of the current ticket/command - easy to do by caching the > last ticket and status. makes sense, but I am not sure that this will be sufficient. Were you able to guarantee before hand that the ticket ordering was not munged? EBo -- ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
