Ah likely not. Will check. Do you have a link to the commit?
> On Aug 15, 2015, at 13:34, Clark Haskins wrote:
>
> I know we ran into the same issue with Camus at LinkedIn and it has since
> been fixed. I hope that we committed the patch to open source.
>
> Are you running the latest versi
I know we ran into the same issue with Camus at LinkedIn and it has since been
fixed. I hope that we committed the patch to open source.
Are you running the latest version of Camus?
-Clark
Sent from my iPhone
> On Aug 15, 2015, at 10:25 AM, Andrew Otto wrote:
>
> Hm, interesting. So my real
Hm, interesting. So my real issue is more with Camus than with cluster
problems? It seems that Camus won’t consume if it encounters a
ReplicaNotAvailableException.
> On Aug 15, 2015, at 12:02, Clark Haskins wrote:
>
> Replica not available is not a fatal exception. This simply means that th
Replica not available is not a fatal exception. This simply means that there is
a replica that is down.
If you get Leader not available that means the partition is offline.
-Clark
Sent from my iPhone
> On Aug 15, 2015, at 8:41 AM, Andrew Otto wrote:
>
> Also strange: If I start this broker
Also strange: If I start this broker back up, and then issue a kafkacat
metadata request, I do not see any 'Broker: Replica not available’, even though
this broker’s preferred partitions have not yet replicated back in sync, and
are not the leader. Everything seems normal.
Somehow this broker
I am having trouble with a single broker causing consumers to lag. As I am
troubleshooting this issue, I have stopped this broker in the hopes that other
replicas will take over as leader for this broker’s preferred partitions.
However, when I do so, Camus reports:
kafka.CamusJob: Skipping
