Perrin Harkins writes: > Bas A.Schulte wrote: > > I do when the delivery mechanism has failed for 6 hours and I have 12000 > > messages in the queue *and* make sure current messages get sent in time? > > I don't know, that's an application-specific choice. Of course JMS > doesn't know either.
This is one of the endemic problems with J2EE. It doesn't know, and it has to offer you lots of options to allow you to control the horizontal and vertical. Since it is a distributed platform, it can't export "hooks" (callbacks), which allow you to decide on the fly. The options get out of control, and make it look like the system is fancier than it really is. Rather, when you see an option, it usually means the developers couldn't agree on what to do (paraphrased from Joel Spolsky, http://www.joelonsoftware.com/). With bOP, we tend to make policy decisions like this centrally, e.g., no exactly-once semantics. There's a real cost, but then we've used bOP for a wide variety of batch and Web applications without much strain so we keep doing it this way. When we stress the system too much, we add a decision point (option) for the programmer. However, we only do this after careful deliberation. This is one of the reasons we don't release "bOP in parts" as some have suggested. You can use it in layers, but every application we've built ends up using all the layers. J2EE has too many competing/conflicting components, and each of those components can be configured in myriad ways. Only experienced building distributed systems builders can know the trade-offs. J2EE is sold as an everyman's platform for everybody's problem. This means people often get caught using the wrong tool (entity beans) the wrong way (a bean per DB row). There's no easy answer to the problem of distributed systems (esp. one as complex as SMS message queueing), and J2EE gives one the impression there is, all in imiho, of course. :-) BTW, the issue of exactly-once vs at-most-once is a tough one (and was subject to much debate in the 80s). JMS tries to guarantee exactly-once, but that's really hard to do. Especially in an SMS situation where network partitioning is a real problem. My alphanumeric pager service holds messages for 3 days, and that's a long time imo. They can only do this, because pagers aren't bi-directional (for the most part). Once you get into SMS space, where devices are bi-directional and much more useful, you have a real problem promising exactly-once semantics. Rob
