Hi Sasikala, OK. This means in RDBMS problem will be solved. Thanks for clarification.
Thanks On Wed, Jun 17, 2015 at 4:53 AM, Sasikala Kottegoda <[email protected]> wrote: > 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 <[email protected]> > 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 <[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> >> >> > > > -- > Sasikala Kottegoda > *Software Engineer* > WSO2 Inc., http://wso2.com/ > lean. enterprise. middleware > Mobile: +94 774835928/712792401 > -- *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
