Recreate logger on new term

[nahguam]

In zerolog, log keys are additive and it does not deduplicate fields in json output

[andrasbeni]

I'm surprised this does not get caught by the race condition detection of go test since we do not guard fc.log in any way. But I think it is OK if the go memory model states that assignments are atomic. Do you know if this is the case?

[nahguam]

I'm surprised this does not get caught by the race condition detection of go test since we do not guard fc.log in any way. But I think it is OK if the go memory model states that assignments are atomic. Do you know if this is the case?

race only detects at runtime, so not really surprising. I've added a lock

[nahguam]

I'm surprised this does not get caught by the race condition detection of go test since we do not guard fc.log in any way. But I think it is OK if the go memory model states that assignments are atomic. Do you know if this is the case?

race only detects at runtime, so not really surprising. I've added a lock

Actually, the logger is only set on construction and in a method that is already utilizing a lock, so I've reverted my last

[andrasbeni]

Yes, construction is covered with locks, but not all reads of leaderController.log are. E.g.,func (lc *leaderController) read(... uses log without a lock. But in java it would still be fine since pointer assignments are atomic. I just don't know if they are atomic in golang.