zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Flavio Junqueira <...@apache.org>
Subject Re: ZooKeeper clients does not handle new error codes properly
Date Tue, 04 Oct 2016 18:53:05 GMT
Yeah, unfortunately, I don't think we make use of the protocol version in ConnectRequest and
Response. When we instantiate ConnectRequest in ClientCnxn, we simply set it to zero. 


> On 04 Oct 2016, at 16:21, Mohammad arshad <mohammad.arshad@huawei.com> wrote:
> Thanks Benjamin Reed,
> Client protocol version is 0, it is not changed. Also there is no logic executed at the
server side based on the client protocol version. Increasing the client protocol version and
converting the errors at server may be the ideal and more precise solution but to handle it
in a generic way can we convert the unknown error to KeeperException.SystemErrorException
at client side? Do you foresee any problem in this solution? 
> Thanks
> -Arshad
> -----Original Message-----
> From: Benjamin Reed [mailto:breed@apache.org] 
> Sent: 04 October 2016 10:27
> To: user@zookeeper.apache.org
> Cc: DevZooKeeper
> Subject: Re: ZooKeeper clients does not handle new error codes properly
> did we bump the protocol version when we added the new errors? the server could do the
conversion when it responds to older clients.
> On Mon, Oct 3, 2016 at 3:05 AM, Flavio Junqueira <fpj@apache.org> wrote:
>> Hi Arshad,
>> It makes sense to me. What if we convert unknown server errors to 
>> KeeperException.SystemErrorException? This is a generic error and it 
>> extends KeeperException.
>> I don't see it as a big issue to make this change, but others may feel 
>> differently. If we do it, then we will need a release note pointing 
>> out the change of behavior.
>> -Flavio
>>> On 03 Oct 2016, at 08:54, Mohammad arshad 
>>> <mohammad.arshad@huawei.com>
>> wrote:
>>> Hi All,
>>> In Zookeeper rolling upgrade scenario where server is new but client 
>>> is
>> old, when sever sends error code which is not understood by a client, 
>> client throws IllegalArgumentException. Generally 
>> IllegalArgumentException is not handled by any of the ZK applications. 
>> It is too generic. How to handle this scenario in ZK applications?
>>> My understanding is instead of throwing IllegalArgumentException we
>> should throw a subclass of KeeperException, for example 
>> InvalidErrorCodeException, so that zk apps can take more specific action.
>>> Any thoughts?
>>> Thanks
>>> -Arshad

View raw message