Hi Sasikala, +1 for the idea.
"The respective cassandra column family (DLCMetaData) structure will be the same as the current cassandra MetaData column family. Each row will have storageQueue as the key, each message as a column with the message_id as the column name and metadata as the value as follows:" How does it store messages in Cassandra in current impl? Thanks On Wed, Jun 17, 2015 at 4:22 AM, Sasikala Kottegoda <[email protected]> wrote: > Hi all, > > Currently WSO2MB stores message metadata in a single table with the > following attributes: > > 1. MESSAGE_ID > 2. QUEUE_ID > 3. MESSAGE_METADATA > > Also, WSO2MB supports movement of messages to a DLC (dead letter channel) > when a problem is identified in the receiver's end. When moving a message > from a queue to a DLC, the DLCQueueName (which is tenant specific) is > retrieved, the metadata row under the relevant storageQueue is removed and > a new metadata row is added with the QUEUE_ID set to the DLC queue. > > Therefore, when we need to, > > - reroute messages for a specific queue > - purge a particular queue > > we need to retrieve MESSAGE_METADATA of each row with the QUEUE_ID set to > any DLCQueue and extract the actual storageQueue (The storageQueue is one > of the information stored under the MESSAGE_METADATA attribute). This > operation is highly computationally expensive since we need to read all > rows for all DLC queues even though we might actually have a few relevant > rows. > > What I'm suggesting is to have a seperate MB_DLC_METADATA table with the > following attributes (same as the MB_METADATA table): > > 1. MESSAGE_ID > 2. SOTRAGE_QUEUE_ID > 3. MESSAGE_METADATA > > The respective cassandra column family (DLCMetaData) structure will be the > same as the current cassandra MetaData column family. Each row will have > storageQueue as the key, each message as a column with the message_id as > the column name and metadata as the value as follows: > > Queue_ID > > m_id1 > > m_id2 > > m_id3 > > meta1 > > meta2 > > meta3 > > > By having this we will be able to easily filter out messages by the > storageQueue from which the messages were moved. Therefore, it will save a > lot of time and memory in the previously mentioned scenarios and in any > other DLC specific operations. > > Comments and suggestions are highly valued. > > Thank you > > -- > Sasikala Kottegoda > *Software Engineer* > WSO2 Inc., http://wso2.com/ > lean. enterprise. middleware > Mobile: +94 774835928/712792401 > > _______________________________________________ > Dev mailing list > [email protected] > http://wso2.org/cgi-bin/mailman/listinfo/dev > > -- *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
