> > > I don't think it's the network stack where that code works; I'm pretty sure > the message itself does decompression when the body is accessed via the > getter. But when you read the message body to serialize it to Chronicle, > you're likely to invoke that decompression code and end up undoing the > compression of the message. So you could use a flag that'll tell you to > recompress it when you read it back out of Chronicle, but then you're doing > wasteful decompress/compress operations. It would be better to access the > compressed bytes without running through the decompression code (e.g. using > reflection to grab the field directly) to avoid those wasteful operations. > Either way, make sure the message is still compressed when you send it > onwards if it was compressed when you received it... >
Ah.. interesting. So I think you can control Chronicle compression / decompression directly. It’s designed for this so that you can control performance. So it might be possible to read compressed data and write it over the wire. The downside is that the client would need to be able to read the chronicle data. -- Founder/CEO Spinn3r.com Location: *San Francisco, CA* blog: http://burtonator.wordpress.com … or check out my Google+ profile <https://plus.google.com/102718274791889610666/posts> <http://spinn3r.com>
