From: Aaron L. <aar...@ob...> - 2003-05-14 16:03:40
|
Ulf, I've been thinking of doing something similar to what you've described. Would you like to work together on this? Aaron On Wednesday 14 May 2003 11:14 am, you wrote: > Good input :-) I already have thought about writing that code, but still I > am not sure that I have enought understanding of the internal interactions > between the message cache and the persistence manager ( e.g. threading > and message reference handling issues like softening, hardening, release, > ... ) This might take some time for implementation and much more time for > testing... > > > > > > "Adrian Brock" <ad...@jb...> > Gesendet von: jbo...@li... > 14.05.2003 15:28 > Bitte antworten an jboss-development > > > An: <jbo...@li...> > Kopie: > Thema: RE: [JBoss-dev] JBossMQ JDBC2 Persistence Manager > > > This is a good optimization, > that will help JBossMQ scale better > to a larger number of subscribers. > > You can use the internal header.messageId > as the key to the blob. > > Don't do this for Queues. > Persistence would require two write > operations when only one is necessary. > > Do you want to write this as jdbc3 persistence? > > Regards, > Adrian > > -----Original Message----- > From: jbo...@li... > [mailto:jbo...@li...] On Behalf Of > ulf...@mo... > Sent: 14 May 2003 11:11 > To: jbo...@li... > Subject: [JBoss-dev] JBossMQ JDBC2 Persistence Manager > > > > Is anybody out there with detailed understanding of the JBossMQ JDBC2 > Persistence Manager ( I am sure there is :-) ? I would like to discuss > an optimization of persistent BLOB message storage strategy for JMS > topics. We want to use JBossMQ in production and we have to rely on > persistent messaging via topics with high number of durable subscribers. > > > Currently when persisting a new message for a topic a complete copy of > that message is stored as separate entry for EVERYdurable subscription > in jms_messages (e.g. sending a message to a topic with 10 durable > subscribers leads to 10 message copies INCLUDING the large messageblob > in the JDBC message store ). This strategy has severe performance > impacts because BLOB inserts are high-cost-operations (cpu usage, > storage usage). > > My idea is to store ONLY ONE copy of the messageblob in a separate table > (e.g. jms_messageblobs with columns blobid, messageblob ) an simply > reference that single blob from all messageentries in jms_messages that > share that identical blob. So in the above example a message send to a > topic would lead to 10 SMALL messageentries in jms_messages and only > one blob entry in jms_messageblobs, saving 9 heavy-weight blob inserts ! > > > Another benefit of that strategy maybe would be an optimized / lasy blob > deletion from the database. If a persistent message has been > successfully delivered to its consumer, the persistence manager only > removes the corresponding small messageentry in jms_messages. A timed > background thread then removes all unused blobs ( meaning no more > references from jms_messages.blobid ) with a single SQL statement like > DELETE FROM jms_messageblob WHERE blobid NOT IN( SELECT DISTINCT blobid > FROM jms_messages ). > > Any comments on this idea ? > > Regards > Ulf > > > > > > ------------------------------------------------------- > Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara > The only event dedicated to issues related to Linux enterprise solutions > www.enterpriselinuxforum.com > > _______________________________________________ > Jboss-development mailing list > Jbo...@li... > https://lists.sourceforge.net/lists/listinfo/jboss-development |