Hi Sajini, reference to client side compression, +1 for the model.
Thanks Srinath On Mon, Dec 7, 2015 at 10:48 AM, Sajini De Silva <[email protected]> wrote: > Hi Srinath, > > For client side compression, if all the subscribers can handle compressed > data then there is no problem. But if the publisher sends compressed data > and subscribers cannot handle them there MB come in to play. MB should be > able to decompressed those data and send to subscribers those who cannot > handle compressed data. WDYT? > > The second option, server side compression is always transparent from the > user. > > Thank you, > Sajini > > On Mon, Dec 7, 2015 at 10:36 AM, Srinath Perera <[email protected]> wrote: > >> Hi Thilanka, >> >> 1. One question to ask is does client side compression is needed? We >> can easily have the same effect by asking user to compress the data first >> and send? What do we gain by adding this to MB >> 2. +1 for server side compression. I guess this is transparent from >> end user. >> >> Thanks >> Srinath >> >> >> On Fri, Dec 4, 2015 at 11:07 PM, Thilanka Bowala <[email protected]> >> wrote: >> >>> Hi all, >>> >>> Current MB doesn't have any method to compress the message content. >>> Thus, we are willing to use lz4 as the compression algorithm [1]. We are >>> willing to use lz4-java library [2] to this. These are the possibilities. >>> >>> 1. Handling client side compression. Adding a configuration to the >>> publisher to indicate that, if messages are compressed or not. Also, >>> maintaining a flag from a subscriber side to indicate that, if that >>> subscriber can handle decompression or not. >>> 2. Handling server side compression before storing into the >>> database. Adding a configuration to indicate that if the server want to >>> handle compression or not. >>> >>> These are the limitations. >>> >>> 1. Other clients like .Net clients can't handle compression. >>> 2. LZ4 uses data repetitions to compress messages. If the message >>> content haven't repetitions, compressed message size will expand by 0.4% >>> [3] >>> 3. LZ4 has a rule, not to compress data, if the block size is less >>> than 13bytes [3]. Compressing message blocks with less than 13 bytes will >>> increase the size of the block. >>> >>> I'm planning to handle compression using the 1st approach. If time >>> allows, I'm planning to do the 2nd approach also. >>> These are some problems. >>> >>> 1. Is it OK to handle from the server side? >>> 2. Are there any proper libraries better than LZ4? >>> >>> >>> Any comments and suggestions will be highly appreciated. >>> >>> >>> [1] http://cyan4973.github.io/lz4/ >>> [2] https://github.com/jpountz/lz4-java >>> [3] https://github.com/Cyan4973/lz4/blob/master/lz4_Block_format.md >>> >>> >>> Thanks and regards, >>> >>> -- >>> Thilanka Bowala >>> Software Engineering Intern >>> Mobile : +94 (0) 710 403098 >>> [email protected] >>> >> >> >> >> -- >> ============================ >> Blog: http://srinathsview.blogspot.com twitter:@srinath_perera >> Site: http://people.apache.org/~hemapani/ >> Photos: http://www.flickr.com/photos/hemapani/ >> Phone: 0772360902 >> > > > > -- > Sajini De SIlva > Software Engineer; WSO2 Inc.; http://wso2.com , > Email: [email protected] > Blog: http://sajinid.blogspot.com/ > Git hub profile: https://github.com/sajinidesilva > > Phone: +94 712797729 > > -- ============================ Blog: http://srinathsview.blogspot.com twitter:@srinath_perera Site: http://people.apache.org/~hemapani/ Photos: http://www.flickr.com/photos/hemapani/ Phone: 0772360902
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
