Yes, and if on top of that it would be possible to define an own “compression”
algorithm, which actually does compress + encrypt, then this would be a
non-issue.
> On 06 Jun 2016, at 17:11, Ismael Juma wrote:
>
> On Mon, Jun 6, 2016 at 3:12 PM, Tom Brown wrote:
>
>> How would it be possible
tc. That clearly isn't true for all use cases though.
>>
>> Thanks
>>
>> Tom Crayford
>> Heroku Kafka
>>
>> On Thursday, 2 June 2016, Gerard Klijs wrote:
>>
>>> You could add a header to every message, with information whether it's
>
he example from eugene. I don't know the
> kind of messages you have, but you could always wrap something around any
> (de)serializer your currently using.
>
> On Tue, May 31, 2016 at 12:21 PM Bruno Rassaerts <
> bruno.rassae...@novazone.be> wrote:
>
>> I’ve asked
I’ve asked the same question in the past, and disk encryption was suggested as
a solution as well.
However, as far as I know, disk encryption will not prevent your data to be
stolen when the machine is compromised.
What we are looking for is even an additional barrier, so that even system
admini
g/reencrypting the logfiles (with performance
> penalties) or rotate machines in and out as with full disk encryption.
> Though I'll let someone with more knowledge of the implementation
> comment further on what would be required.
>
> Christian
>
> On Mon, May 2, 2016 at 9:
>
> Have I left out a scenario?
>
> --Tom
>
>
> On Mon, May 2, 2016 at 2:01 PM, Bruno Rassaerts > wrote:
>
>> Hello,
>>
>> We tried encrypting the data before sending it to kafka, however this
>> makes the compression done by kafka almost imp
Hello,
We tried encrypting the data before sending it to kafka, however this makes the
compression done by kafka almost impossible.
Also the performance overhead of encrypting the individual messages was quite
significant.
Ideally, a pluggable “compression” algorithm would be best. Where messag
;
> Can you tell me a little bit more about that? A seek() in the
> `onPartitionAssigned`?
>
> Thanks.
>
> 2016-01-25 10:51 GMT+01:00 Han JU :
>
>> Ok I'll create a JIRA issue on this.
>>
>> Thanks!
>>
>> 2016-01-23 21:47 GMT+01:00 Bruno
+1 here
As a workaround we seek to the current offset which resets the current clients
internal states and everything continues.
Regards,
Bruno Rassaerts | Freelance Java Developer
Novazone, Edingsesteenweg 302, B-1755 Gooik, Belgium
T: +32(0)54/26.02.03 - M:+32(0)477/39.01.15
bruno.rassae
t;
> --
> Jim Hoagland, Ph.D.
> Sr. Principal Software Engineer
> Big Data Analytics Team
> Cloud Platform Engineering
>
>
>
> On 1/14/16, 2:23 PM, "Bruno Rassaerts" wrote:
>
>> Hello,
>>
>> In our project we have a very strong requirement t
could add this in the Kafka codebase.
Thanks,
Bruno Rassaerts
request HTTP ——> request topic
<—— wait for corresponding event on response topic
<—— respond HTTP
Mapping request response would be doing by a unique id (maybe offset).
Not sure if this is a good approach, right way of doing things.
All thoughts are welcom
12 matches
Mail list logo