[jira] [Commented] (ZOOKEEPER-1112) Add support for C client for SASL authentication

2019-08-12 Thread Damien Diederen (JIRA)


[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16905211#comment-16905211
 ] 

Damien Diederen commented on ZOOKEEPER-1112:


[~klonik_t], [~rgs], [~beeflyme]: See [PR 
1054|https://github.com/apache/zookeeper/pull/1054], which refreshes the 
patches for current {{master}}.

> Add support for C client for SASL authentication
> 
>
> Key: ZOOKEEPER-1112
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1112
> Project: ZooKeeper
>  Issue Type: New Feature
>Reporter: Eugene Koontz
>Assignee: Tom Klonikowski
>Priority: Major
>  Labels: pull-request-available
> Attachments: ZOOKEEPER-1112.patch, ZOOKEEPER-1112_1.patch, 
> ZOOKEEPER-1112_1.patch, ZOOKEEPER-1112_2.patch, ZOOKEEPER-1112_2.patch, 
> ZOOKEEPER-1112_3.patch, zookeeper-c-client-sasl.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Hopefully this would leverage the SASL server-side support provided by 
> ZOOKEEPER-938. It would be similar to the Java SASL client support also 
> provided in ZOOKEEPER-938.
> Java has built-in SASL support, but I'm not sure what C libraries are 
> available for SASL and if so, are they compatible with the Apache license.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Created] (ZOOKEEPER-3510) Frequent 'zkServer.sh stop' failures when running C test suite

2019-08-15 Thread Damien Diederen (JIRA)
Damien Diederen created ZOOKEEPER-3510:
--

 Summary: Frequent 'zkServer.sh stop' failures when running C test 
suite
 Key: ZOOKEEPER-3510
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3510
 Project: ZooKeeper
  Issue Type: Bug
Reporter: Damien Diederen


As mentioned in 
https://github.com/apache/zookeeper/pull/1054#discussion_r314208678 :

There is a {{sleep 3}} statement in {{zkServer.sh restart}}.  I am unable to 
unearth the history of that particular line, but I believe part—if not all—of 
that {{sleep}} should be part of {{zkServer.sh stop}}.

I frequently observe {{FAILED TO START}} errors in the C test suite; the logs 
consistently show that those are caused by {{java.net.BindException: Address 
already in use}}.  Adding a simple {{sleep 1}} before {{echo STOPPED}} "fixes" 
it for me.  I will submit an initial PR with the corresponding change and a 
commit message akin to:



ZOOKEEPER-: Make zkServer.sh stop more reliable

Kill is asynchronous, and without the sleep, the server's TCP port can still be 
busy when the next server is started—causing flaky runs of the C client's test 
suite.

(It would probably be better to spin a few times, probing with ps -p.)



As noted above, the sleep is far from optimal, an adaptive mechanism would be 
better—but I do not want to make the first iteration too complicated.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Commented] (ZOOKEEPER-2965) prevent DNS queries spam

2019-08-29 Thread Damien Diederen (Jira)


[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16918537#comment-16918537
 ] 

Damien Diederen commented on ZOOKEEPER-2965:


FYI, I have submitted a GitHub "pull request" for ZOOKEEPER-1998 which I 
believe obsoletes the patch attached here (as we need a more general solution).

> prevent DNS queries spam
> 
>
> Key: ZOOKEEPER-2965
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2965
> Project: ZooKeeper
>  Issue Type: Improvement
>  Components: c client
>Reporter: Philippe Serreault
>Priority: Minor
> Attachments: 0001-Prevent-DNS-queries-spam.patch
>
>
> Hello,
> First of all, some context about the issue and why it became quite apparent 
> to me:
> * I'm using the native zookeeper client on linux
> * I'm not declaring -DTHREADED
> * My zookeeper ensemble is made of server names that need to be resolved
> * The ensemble and DNS servers are "next" to each other
> * My client is "far" and uses an unreliable network path that can drop UDP 
> requests
> For each run in client's main loop, all servers in ensemble are resolved, 
> even if no change in servers list occurred (zookeeper_interest .. 
> update_addrs .. resolve_hosts).
> In my situation, DNS requests could timeout and would trigger a reconnection 
> to ensemble.
> Please find attached a patch that would prevent DNS queries when hostname was 
> not changed.
> Best regards,



--
This message was sent by Atlassian Jira
(v8.3.2#803003)


[jira] [Commented] (ZOOKEEPER-2282) chroot not stripped from path in asynchronous callbacks

2019-08-29 Thread Damien Diederen (Jira)


[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16918741#comment-16918741
 ] 

Damien Diederen commented on ZOOKEEPER-2282:


I have recently pushed a GitHub "pull request" which addresses this:

https://github.com/apache/zookeeper/pull/1066

It is remarquably similar to the patch attached to this issue (I spotted it too 
late), but also avoids the aforementioned test failure.

> chroot not stripped from path in asynchronous callbacks
> ---
>
> Key: ZOOKEEPER-2282
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2282
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: c client
>Affects Versions: 3.4.6, 3.5.0
> Environment: Centos 6.6
>Reporter: Andrew Grasso
>Assignee: Andrew Grasso
>Priority: Critical
>  Labels: pull-request-available
> Attachments: ZOOKEEPER-2282.patch
>
>   Original Estimate: 1h
>  Time Spent: 10m
>  Remaining Estimate: 50m
>
> Callbacks passed to [zoo_acreate], [zoo_async], and [zoo_amulti] (for create 
> ops) are called on paths that include the chroot. This is analagous to issue 
> 1027, which fixed this bug for synchronous calls.
> I've created a patch to fix this in trunk



--
This message was sent by Atlassian Jira
(v8.3.2#803003)


[jira] [Commented] (ZOOKEEPER-1998) C library calls getaddrinfo unconditionally from zookeeper_interest

2019-08-29 Thread Damien Diederen (Jira)


[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16918728#comment-16918728
 ] 

Damien Diederen commented on ZOOKEEPER-1998:


I have recently pushed a GitHub "pull request" which addresses this:

https://github.com/apache/zookeeper/pull/1068

It passes all tests and (includes some new ones). Comments and/or suggestions 
are welcome.


> C library calls getaddrinfo unconditionally from zookeeper_interest
> ---
>
> Key: ZOOKEEPER-1998
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1998
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: c client
>Affects Versions: 3.5.0
>Reporter: Raul Gutierrez Segales
>Assignee: Raul Gutierrez Segales
>Priority: Major
>  Labels: pull-request-available
> Fix For: 3.6.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> (commented this on ZOOKEEPER-338)
> I've just noticed that we call getaddrinfo from zookeeper_interest... on 
> every call. So from zookeeper_interest we always call update_addrs:
> https://github.com/apache/zookeeper/blob/trunk/src/c/src/zookeeper.c#L2082
> which in turns unconditionally calls resolve_hosts:
> https://github.com/apache/zookeeper/blob/trunk/src/c/src/zookeeper.c#L787
> which does the unconditional calls to getaddrinfo:
> https://github.com/apache/zookeeper/blob/trunk/src/c/src/zookeeper.c#L648
> We should fix this since it'll make 3.5.0 slower for people relying on DNS. I 
> think this is happened as part of ZOOKEEPER-107 in which the list of servers 
> can be updated. 
> cc: [~shralex], [~phunt], [~fpj]



--
This message was sent by Atlassian Jira
(v8.3.2#803003)