a quick update on this issue. According to our investigations the problem was the result of probably two bugs in Jboss.
If the database is not available and the cache limit is reached, the messages are not deleted from the cache after delivery (you can see the the counter going up in the JMX console all the time). When the database is up again JBoss is writing all these messages to the database according to its cache configuration. Because the messages are already delivered these entries are never pickud up again and stay in the database. This in combination with the message cleanup bug on Jboss startup can lead to a unique constraint violation if new messages are written. It might be worth mentioning that the JMS cache configuration was too low given the used hardware, but still the messages should be removed from the cache after delivery. As a solution for now we increased the cache size and implemented a startup services that is cleaning the "T" entries from the JMS Messages table. Cheers View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3851522#3851522 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3851522 ------------------------------------------------------- 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-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
