The issue is one of philosophy. JBossMQ has some interfaces that you can implement to provide whatever persistence/caching mechanism you like: http://cvs.sourceforge.net/viewcvs.py/jboss/jbossmq/src/main/org/jboss/mq/pm/ I've even seen somebody implement the PM over an Object Database.
If you want a fast/unreliable mechanism then you can do it yourself, but we aren't going to add to this the JBoss codebase or support it. We would allow it as an option on something that does work in the default configuration, e.g. I've considered allowing a delayed batch write in the JDBC2 PM. As a matter of history, I have rejected all patches submitted against the file PMs on the grounds that we are not going to add features or rerun tests when we know there are fundamental problems with the implementation. Nobody who was interested in writing new features was interested in fixing the problems. If code remains unmaintained like this, it will be deleted from the JBoss codebase. JBoss is not a dumping ground for half-baked implementations. OTHER IMPLEMENTATIONS: Virtually ever other JMS has an option to be fast and unreliable and it is usually the default setting to fool benchmarks :-). We do not take this approach in JBossMQ. If you ask for reliable persistence, that is what you get! (at least in so far as the DB is reliable). View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880621#3880621 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880621 ------------------------------------------------------- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20 _______________________________________________ JBoss-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jboss-user
