Hi Hasitha, Each row has the storageQueue as the key, each message as a column with the message_id as the column name and metadata as the value. Same as the suggested new column family.
Thank you On Wed, Jun 17, 2015 at 3:12 PM, Hasitha Hiranya <hasit...@wso2.com> wrote: > 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 <sasik...@wso2.com> > 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 >> Dev@wso2.org >> 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> > > -- Sasikala Kottegoda *Software Engineer* WSO2 Inc., http://wso2.com/ lean. enterprise. middleware Mobile: +94 774835928/712792401
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
