Hi Kafka Team,
I just wanted to bring this to your attention regarding Java New Producer
limitation compare to old producer.
a) Partition Increasing is limited to configured memory allocation.
buffer.memory
batch.size
The maximum partition you could have before impacting (New Java Producers)
+1 (binding)
artifacts and quick start look good. I ran in some client code, minor edits
from 0-8.2-beta https://github.com/stealthly/scala-kafka/pull/26
On Mon, Jan 26, 2015 at 3:38 AM, Manikumar Reddy
wrote:
> +1 (Non-binding)
> Verified source package, unit tests, release build, topic deleti
+1 (Non-binding)
Verified source package, unit tests, release build, topic deletion,
compaction and random testing
On Mon, Jan 26, 2015 at 6:14 AM, Neha Narkhede wrote:
> +1 (binding)
> Verified keys, quick start, unit tests.
>
> On Sat, Jan 24, 2015 at 4:26 PM, Joe Stein wrote:
>
> > That make
+1 (binding)
Verified keys, quick start, unit tests.
On Sat, Jan 24, 2015 at 4:26 PM, Joe Stein wrote:
> That makes sense, thanks!
>
> On Sat, Jan 24, 2015 at 7:00 PM, Jay Kreps wrote:
>
> > But I think the flaw in trying to guess what kind of serializer they will
> > use is when we get it wron
That makes sense, thanks!
On Sat, Jan 24, 2015 at 7:00 PM, Jay Kreps wrote:
> But I think the flaw in trying to guess what kind of serializer they will
> use is when we get it wrong. Basically let's say we guess "String". Say 30%
> of the time we will be right and we will save the two configurat
But I think the flaw in trying to guess what kind of serializer they will
use is when we get it wrong. Basically let's say we guess "String". Say 30%
of the time we will be right and we will save the two configuration lines.
70% of the time we will be wrong and the user gets a super cryptic
ClassCa
Maybe. I think the StringSerialzer could look more like a typical type of
message. Instead of encoding being a property it would be more typically
just written in the bytes.
On Sat, Jan 24, 2015 at 12:12 AM, Jay Kreps wrote:
> I don't think so--see if you buy my explanation. We previously defau
I don't think so--see if you buy my explanation. We previously defaulted to
the byte array serializer and it was a source of unending frustration and
confusion. Since it wasn't a required config people just went along
plugging in whatever objects they had, and thinking that changing the
parametric
Should value.serializer in the new java producer be defaulted to
Array[Byte] ?
I was working on testing some upgrade paths and got this
! return exception in callback when buffer cannot accept message
ConfigException: Missing required configuration "value.serializer"
which has no defau
