Hi Hasitha, Thanks a lot for your thoughts. I have made fixes to the diagram.
I have started development and will become familiar with the node and global queues while coding. >> AFAIR, 0L for expiration time in JMS message metadata means that message never expires. Do not write those IDs to the column family. Otherwise we will be reading and checking those without any use. - Agreed >> You need to use existing methods to remove expired messages - will be using the delete methods in message store implementations >> When you read a message ID which is expired, the actual message metadata can be in any node queue having subscribers for that queue or in global queues. - yes. the "MessagesForExpiry" queue will only contain message ID+expiring time Thanks and Cheers, Hasitha Amal De Silva Software Engineer Mobile : 0718133463 WSO2 Inc.: http://wso2.com ( lean.enterprise.middleware. ) On Thu, Jun 12, 2014 at 8:39 AM, Hasitha Hiranya <[email protected]> wrote: > Hi Hasitha, > > Technically, following things should be corrected in your diagram > > >>We have a interface called message store. > CassandraBasedMessageStroreImpl and in-memory message store is > implementations of that. > > Other than that you have understood the flow correctly (You need to > understand how node queues, topic node queues and global queues work as > well). > > Please note following. > > >> AFAIR, 0L for expiration time in JMS message metadata means that > message never expires. Do not write those IDs to the column family. > Otherwise we will be reading and checking those without any use. > >> You need to use existing methods to remove expired messages > >> When you read a message ID which is expired, the actual message > metadata can be in any node queue having subscribers for that queue or in > global queues. > > Thanks > > > > On Wed, Jun 11, 2014 at 6:15 PM, Hasitha Amal De Silva <[email protected]> > wrote: > >> *Problem : >> * >> >> WSO2 MB currently does not support JMS expiration. Previous attempts to >> provide the feature have been rolled back due to; >> >> 1. time consuming searches within message store and >> 2. additional overhead at node queues when removing expired message >> references. >> >> A configurable solution with minimal overhead at above flows is needed. >> The change is required for MB version 3.0.0. >> >> Redmine link : https://redmine.wso2.com/issues/2769 >> >> *JMS Expiration : >> * >> >> This allows to specify when a message should be considered irrelevant >> within a Broker. JMS 1.1 spec provides two parameters to enable expiration: >> >> 1) JMSTimestamp - the time a message is handed off for sending. (Java >> Long Date format) >> >> 2) JMSExpiration [1] >> <http://docs.oracle.com/javaee/1.3/jms/tutorial/1_3_1-fcs/doc/advanced.html#1024689> >> - time to live for the message since JMSTimestamp ( in milliseconds) >> >> Expiration of obsolete messages is crucial to resource-intensive >> consumers as well as message brokers to reduce redundant data overheads. >> >> *Product Background : * >> >> With reference to [2] >> <http://abeykoon.blogspot.com/2013/10/wso2-message-broker-internal.html> >> and discussions with MB team, I have created a technical diagram [3] >> <https://creately.com/diagram/hwaifq5p1/KtVPRsWWenfecedUoniZi3XUg%3D> to >> understand the flow and architecture of WSO2 MB version 3.0.0. Please >> mention if there are any corrections. >> >> *Plan for Solution (As discussed with the MB team)* >> >> *@ Server Initialization* >> >> Add and use configuration property : "JMSExpirationCheckInterval" >> (milliseconds) >> >> Add new Cassandra Column Family (MessagesForExpiry queue) for storing >> MessageIDs with expiration time appended to key - sorted by expiration time >> >> *When Receiving a Message* >> >> Check if message contains JMSExpiration header, and add to >> MessagesForExpiry queue >> >> *On a separate thread* >> >> Run a worker at configured time interval ("JMSExpirationCheckInterval") >> to >> >> 1. Collect all records from "MessagesForExpiry" queue past the >> current time-stamp >> 2. Delete each message from "MessagesForExpiry", Global Queue, and >> node queues.(Modify existing "messagedelete" function) >> >> >> ------------------------------------------------------------------------------------------------------------------------------------- >> >> Do let me know if this approach can be further improved or if i have >> missed anything. >> >> References: >> >> [1] : >> http://docs.oracle.com/javaee/1.3/jms/tutorial/1_3_1-fcs/doc/advanced.html#1024689 >> [2] : >> http://abeykoon.blogspot.com/2013/10/wso2-message-broker-internal.html >> [3] : https://creately.com/diagram/hwaifq5p1/KtVPRsWWenfecedUoniZi3XUg%3D >> [4] : >> http://docs.oracle.com/javaee/1.3/jms/tutorial/1_3_1-fcs/doc/advanced.html#1023387 >> [5] : http://martinfowler.com/articles/lmax.html >> >> Thanks and Cheers, >> Hasitha Amal De Silva >> Software Engineer >> Mobile : 0718133463 >> WSO2 Inc.: http://wso2.com ( lean.enterprise.middleware. ) >> > > > > -- > *Hasitha Abeykoon* > Senior Software Engineer; WSO2, Inc.; http://wso2.com > *cell:* *+94 719363063* > *blog: **abeykoon.blogspot.com* <http://abeykoon.blogspot.com> > >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
