Using RequiredAcksNone causes panic when writing to kafka.

[keep94]

Here is my code:

awriter.broker, err = kafka.Dial(myEndpoints, kafka.NewBrokerConf("myapp"))
count, err = awriter.broker.PartitionCount("metricTopic")
if err != nil {
  return
}
conf := kafka.NewProducerConf()
conf.RequiredAcks = proto.RequiredAcksNone  // If I use proto.RequiredAcksLocal, then no panic.
producer := awriter.broker.Producer(conf)
awriter.producer = kafka.NewRoundRobinProducer(producer, count)

When I later call

awriter.producer.Distribute("myApp", msgs...)

It panics with the following:

panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xb code=0x1 addr=0x0 pc=0x61ef4d]

goroutine 2657 [running]:
github.com/optiopay/kafka.(*producer).produce(0xc82e351e80, 0xc8200f6420, 0xb, 0xc800000000, 0xc835ce4000, 0x3e8, 0x3e8, 0x0, 0x0, 0x0)
        /home/bill/mygo/src/github.com/optiopay/kafka/broker.go:816 +0x128d
github.com/optiopay/kafka.(*producer).Produce(0xc82e351e80, 0xc8200f6420, 0xb, 0x0, 0xc835ce4000, 0x3e8, 0x3e8, 0x0, 0x0, 0x0)
        /home/bill/mygo/src/github.com/optiopay/kafka/broker.go:742 +0xcb
github.com/optiopay/kafka.(*roundRobinProducer).Distribute(0xc82e378a40, 0xc8200f6420, 0xb, 0xc835ce4000, 0x3e8, 0x3e8, 0x0, 0x0, 0x0)
        /home/bill/mygo/src/github.com/optiopay/kafka/distributing_producer.go:85 +0xf7

Best I can tell is in broker.go around line 800, the call to resp, err := conn.Produce(&req) is probably returning both a nil resp and a nil error.

[Piotr H]

Which version are you using? Your stack trace is saying that broker.go:816 is line where (*producer).produce is called, but HEAD looks differently https://github.com/optiopay/kafka/blob/master/broker.go#L813-L816

[keep94]

Ill do a pull tomorrow

On Thursday, February 18, 2016, Piotr Husiatyński [e-mail]
wrote:

Which version are you using? Your stack trace is saying that broker.go:816
is line where (*producer).produce is called, but HEAD looks differently
https://github.com/optiopay/kafka/blob/master/broker.go#L813-L816

—
Reply to this email directly or view it on GitHub
#54 (comment).

[keep94]

After doing the pull, this problem went away. Closing.