As follow up to the recent discussion about limited versus unlimited channels consider the following story. There is an expensive commercial Java software that consists of several components that run on different servers for performance and fault tolerance.
The software extensively uses bounded queues for its message passing between components. As administrator can change the size of the queues it resulted in rather tunable system when one can make clear tradeoff between say, latency and throughput. It also made the system rather resilient to traffic spikes allowing to drop some processing if the system can not deal with the input fast enough. The bad part is that the software contains at least one internal unlimited queue. The assumption was that in practice the queue would always be small. Of cause after some months of nice running a particular traffic variation happened. In theory it should not affect the system at all. In practice the result was that queue had eaten all the memory and triggered OutOfMemory in a particularly bad spot. That failure propagated through the whole system resulting in complete halt of all the components. The vendor now works hard for several days trying to provide a fix. Apparently changing that queue to bounded one requires substantial code changes that cannot be accounted as a hot fix, so I guess they try to sprinkle the code with few try/catch(OutOfMemory) or whatever...
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
