> No kidding? > *cough*
My initial wild guess is that the problem is in the queen. Going by the > description it's way overly complicated, with plenty of opportunities > for something to get lost. > Perhaps. It's not a long driver, as code goes. > > Your whole architecture seems overly complicated for what it does. Why > is the coordinator (queen) so intimately involved? Why not have the > workers process an ID end to end [read the source table, calculate, > update the result table]? All the coordinator should do is load balance > and ensure that all the IDs actually get processed. > FWIW, to make sure that workers don't pull IDs on a duplicate basis, I have one process farming them out. Hence, the worker requests an ID, does the work, and submits the work back to the manager. The manager doles out IDs, and then stores results. But, yes, I can look to simplify. Is the *source* table ever being updated outside of your program? > And what is the DBMS? > No. They're two SQLite tables. The readers should never block readers, to the best of my understanding, and there is only a single writer (to a completely separate DB/table). I'm not aware that DP channels can drop messages - they are built on top > of TCP for reliability. The whole idea is that places may be widely > separated and communicating by Internet. > Yep. respond. Instrumenting both sides would be best, but it should be > simple enough for the queen to check that there is 1:1 correspondence > Yep. There are myriad ways a distributed program can screw up. I can't claim > that the Racket place infrastructure is bullet-proof, but it certainly > is well tested. Any bugs are far more likely to be in your code. :-) > I agree. Appreciate having a sounding board. Thank you. Back into the fray. More simplification, more contracts, more logging, and simplify! simplify! simplify! Cheers, Matt -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
