I didn't follow your second paragraph. The goal with the Chronicle code should be to put the message back in memory after the Chronicle read as it was before the Chronicle write, right? So if the message body (only) was compressed (using the compression algorithm used for ActiveMQ messages, which isn't necessarily the one Chronicle uses), then it should be the same when it comes back out of Chronicle. How does writing over the wire play into that? Don't try to get Chronicle to redo the work ActiveMQ is already doing (because then you have to stay in sync with changes to the compression algorithm, plus it makes the code more complicated); just get the bytes out of the byte array without invoking the getter that will decompress them (and reflection should be able to do that easily).
Bonus points if you can tell Chronicle not to compress/decompress those particular bytes (which saves some CPU cycles because those compressed bytes aren't going to get much smaller and could easily get bigger with a second compression), but even if it's double-compressed, that's better than decompressing it, having Chronicle compress it, having Chronicle decompress it, and then manually recompressing it before sending it on. On Sun, Apr 26, 2015 at 12:03 PM, Kevin Burton <bur...@spinn3r.com> wrote: > > > > > > 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> >
