Re: 0.8.0 HEAD 3/4/2013 performance jump?

ducer runs fastest in this mode. The argument for making the default ack 1 or -1 is that they gave you better reliability. I am not sure what's the best thing to do that here since correct setting really depends on the application. What do people feel? Thanks, Jun -- *Colin Blower* /So

Re: 0.8 protocol exception

.appendShort((short) "foo".getBytes("UTF-8").length).appendString( >> "foo", "UTF-8") //ShortString clientId >> >> .appendShort((short) "myTopic".getBytes("UTF-8").length).appendString >> ("myTopic", "UTF-8"); //ShortString topicName >> >> Buffer message = new Buffer(); >> >> message.appendInt(writeBuffer.length()); //add total Message size to >> buffer >> >> System.out.println(writeBuffer.length()); >> >> message.appendBuffer(writeBuffer); >> >> socket.write(message); >> >> >> -- >> The intuitive mind is a sacred gift and the >> rational mind is a faithful servant. We have >> created a society that honors the servant and >> has forgotten the gift. >> > > -- *Colin Blower* /Software Engineer/ Barracuda Networks Inc. +1 408-342-5576 (o)

Re: 0.8 protocol exception

quest/Responses now :) > > > On Mon, Jul 8, 2013 at 5:13 PM, Colin Blower wrote: > >> I had the exact same problem when I started writing code for the new >> protocol. This is an oddity with the way the protocol spec uses EBNF to >> specify arrays. >> >> C

Re: Stale TopicMetadata

"byteLength": 26 >> }, >> { >> "replicas": [ >> 0 >> ], >> "isr": [], >> "

Re: OffsetResponse: protocol size error

et": 0 > } > ], > "topicName": "myTopic" > } > ], > "responseSize": 31, > "correlationId": 1979, > "byteLength": 35 > } > > It would be ok if not the fact that while reading the bytes from the > server, when I get to the offset position, there's only 4 bytes left, not 8 > as expected. I've fixed this on my code by reading only an Int32 instead. > Is this a bug? > > Regards > > -- *Colin Blower* /Software Engineer/ Barracuda Networks Inc. +1 408-342-5576 (o)

Re: Protocol:Offsetrespose

ameter is that -1 would fetch the latest offset > available for consumption, this topic had no message consumed so far, so > shouldn't it always return 0? > > Regards -- *Colin Blower* /Software Engineer/ Barracuda Networks Inc. +1 408-342-5576 (o)