A second thought. We are designing very coarse grained services. I doubt that the delays, of order even minutes, will matter.
Hours ... yes starts to be a problem. Had not thought about these issues though, so it is good to add them to the thought process. BobLQ On 3/15/07, Bob La Quey <[EMAIL PROTECTED]> wrote:
Thanks Andy. I will pass that advice on to the guys building the system. On 3/15/07, Andrew Lentvorski <[EMAIL PROTECTED]> wrote: > Bob La Quey wrote: > > > We are planning to use it to toss data back and forth between > > web services. It looks promising but I will hold off making strong > > comments until we get further into the project. > > Word of caution: make them put in a debugging time delay before every > transaction. The delay should be turned off in production code, but > should *always* be on in development code. > > If you really want to get fancy, make that delay 25 milliseconds + .1 > milliseconds per byte. > > Without this delay, people will bloat the XML transactions until you are > transmitting megabytes of information per transaction. Everything will > work fine until you deploy. Suddenly, when deployed, the network goes > from being Gigabit Ethernet with a single switch to a piece of damp > string with cascaded routers dropping packets. This of course exposes > the fact that everybody is transmitting far too much crap and then the > political maneuvering begins as to who gets cut. > > Putting a time delay into the transactions *at the start* short circuits > this process and results in a product which actually works around the > problem at the architectural level rather than slapping on duct tape at > the end. > > -a > > > -- > [email protected] > http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list >
-- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
