2) Maintaining client state across the cluster (similar to HTTP/SFSB replication) This assumes we are not going to do full replication which is a lot more work and much less performant.
The server maintains a list of messages that each client has received but not acknowledged yet. In the event of a singleton failover, this information would need to be on the new server to make sure recovering the destination messages from the db doesn't make the messages available again. Without this processing you get: On initial server: Queue: empty Client1: message1 After failover Queue: message1 Client1: empty Again two possible solutions: 1) Update the db on every message receipt to log which client has which message 2) Replicate this state across the cluser. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3850126#3850126 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3850126 ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
