y have plans to move to the "new" consumer for reasons unrelated
to throughput on the client-side
(eg: SSL, long-term support from the Kafka community). However, these plans
have not gotten enough traction.
Please let me know if there are further questions.
-- Jagadish
On Mon, Jul 9,
Anyone have any input here?
On Mon, 2018-07-02 at 11:50 +, Thomas Becker wrote:
Hey folks,
I have a question regarding potential performance impacts of running
Samza against newer Kafka brokers. We have languished on the old on-
disk message format for Kafka for some time, and want
Hey folks,
I have a question regarding potential performance impacts of running
Samza against newer Kafka brokers. We have languished on the old on-
disk message format for Kafka for some time, and want to upgrade to
the newer format which supports timestamps. Samza currently accounts
for quite a
oposal
> s.t. it is more transparent and open to the whole community, through
> the
> newly proposed SEP process. These kind of breaking changes will go
> through
> the SEP discuss-vote process in the future and hopefully capture all
> these
> kind of concerns earlier.
>
> B
Yes, we were burned by this. The changelog mapping will be regenerated
instead of migrated and the result will completely hose the job
(because the mapping was not generated deterministically in previous
versions of Samza). I don't understand why the migration code was
removed but it was, and to
, 2015 at 4:27 PM, Thomas Becker tobec...@tivo.com wrote:
Hi Yi,
Thanks a lot for your reply. I don't doubt we can get it to work by
mucking with the networking configuration, but to me this feels like a
workaround, not a solution. InetAddress.getLocalHost().getHostAddress
