delta/python-packages/kafka-python.git/test, branch ssl_set_ciphers github.com: mumrah/kafka-python.git Error if connections_max_idle_ms not larger than request_timeout_ms (#1688) 2019-03-15T00:34:59+00:00 Jeff Widman jeff@jeffwidman.com 2019-03-15T00:34:59+00:00 965d21b21387e69c53f583fd76cdcec2a4d0f944 






Retry bootstrapping after backoff when necessary (#1736)
2019-03-14T16:39:28+00:00

Dana Powers
dana.powers@gmail.com

2019-03-14T16:39:28+00:00

812de351f75beefe73bd9bef55847ab61ccc951d

The current client attempts to bootstrap once during initialization, but if it fails there is no second attempt and the client will be inoperable. This can happen, for example, if an entire cluster is down at the time a long-running client starts execution.

This commit attempts to fix this by removing the synchronous bootstrapping from `KafkaClient` init, and instead merges bootstrap metadata with the cluster metadata. The Java client uses a similar approach. This allows us to continue falling back to bootstrap data when necessary throughout the life of a long-running consumer or producer.

Fix #1670




The current client attempts to bootstrap once during initialization, but if it fails there is no second attempt and the client will be inoperable. This can happen, for example, if an entire cluster is down at the time a long-running client starts execution.

This commit attempts to fix this by removing the synchronous bootstrapping from `KafkaClient` init, and instead merges bootstrap metadata with the cluster metadata. The Java client uses a similar approach. This allows us to continue falling back to bootstrap data when necessary throughout the life of a long-running consumer or producer.

Fix #1670






Mock dns lookups in test_conn (#1739)
2019-03-14T04:43:29+00:00

Dana Powers
dana.powers@gmail.com

2019-03-14T04:43:29+00:00

39dd8c28da133fcc5005db3db127d687882dfe99

Small change to avoid doing dns resolution when running local connection tests. This fixture always returns a broker on localhost:9092, so DNS lookups don't make sense here.




Small change to avoid doing dns resolution when running local connection tests. This fixture always returns a broker on localhost:9092, so DNS lookups don't make sense here.






Recheck connecting nodes sooner when refreshing metadata (#1737)
2019-03-14T04:38:28+00:00

Dana Powers
dana.powers@gmail.com

2019-03-14T04:38:28+00:00

302b30c7c9f911ce8ec948926021d3fdf16cbedc












Synchronize puts to KafkaConsumer protocol buffer during async sends
2019-03-12T20:36:52+00:00

Dana Powers
dana.powers@gmail.com

2019-03-12T04:48:31+00:00

2a91ca1a8fd767d2e1f9981c7431ce31dcbddf00












Do network connections and writes in KafkaClient.poll() (#1729)
2019-03-08T16:01:48+00:00

Dana Powers
dana.powers@gmail.com

2019-03-08T16:01:48+00:00

8c0792581d8a38822c01b40f5d3926c659b0c439

* Add BrokerConnection.send_pending_requests to support async network sends
* Send network requests during KafkaClient.poll() rather than in KafkaClient.send()
* Dont acquire lock during KafkaClient.send if node is connected / ready
* Move all network connection IO into KafkaClient.poll()




* Add BrokerConnection.send_pending_requests to support async network sends
* Send network requests during KafkaClient.poll() rather than in KafkaClient.send()
* Dont acquire lock during KafkaClient.send if node is connected / ready
* Move all network connection IO into KafkaClient.poll()






Use test.fixtures.version not test.conftest.version to avoid warnings (#1731)
2019-03-07T03:10:29+00:00

Dana Powers
dana.powers@gmail.com

2019-03-07T03:10:29+00:00

37699be51f868bd736e0fd595f2afc4c03b00ca4












Fix test_legacy_correct_metadata_response on x86 arch (#1718)
2019-02-21T09:04:59+00:00

Stanislav Levin
31205609+stanislavlevin@users.noreply.github.com

2019-02-21T09:04:59+00:00

03664ebe9ed8bc965391f925d50219eea4d6ac57

The problem is that the type of required operation result is
"long".

```
>>> type(278251978 & 0xffffffff)
<type 'long'>
```

However, by default "format" method uses __format__():

```
>>> (278251978 & 0xffffffff).__format__('')
'278251978'
```

So, let's compare things using the same engine:

```
>>> "{!r}".format(278251978 & 0xffffffff)
'278251978L'
```

Fixes: https://github.com/dpkp/kafka-python/issues/1717
Signed-off-by: Stanislav Levin <slev@altlinux.org>




The problem is that the type of required operation result is
"long".

```
>>> type(278251978 & 0xffffffff)
<type 'long'>
```

However, by default "format" method uses __format__():

```
>>> (278251978 & 0xffffffff).__format__('')
'278251978'
```

So, let's compare things using the same engine:

```
>>> "{!r}".format(278251978 & 0xffffffff)
'278251978L'
```

Fixes: https://github.com/dpkp/kafka-python/issues/1717
Signed-off-by: Stanislav Levin <slev@altlinux.org>






Use Popen.communicate() instead of Popen.wait()
2019-01-05T22:38:53+00:00

Brian Sang
sang.bri@gmail.com

2019-01-05T06:16:28+00:00

d2f9413b0311e6ec4d782cf9983f61c9f258cc7b

Popen objects may deadlock when using stdout=PIPE or stderr=PIPE
with Popen.wait(). Using Popen.communicate() avoids the issue.





Popen objects may deadlock when using stdout=PIPE or stderr=PIPE
with Popen.wait(). Using Popen.communicate() avoids the issue.







Cleanup formatting, no functional changes
2018-11-20T19:00:24+00:00

Jeff Widman
jeff@jeffwidman.com

2018-11-20T17:30:31+00:00

7444e07011cc5374d1fbdff422f868241f4d1e77

Cleanup the formatting, remove parens, extraneous spaces, etc.





Cleanup the formatting, remove parens, extraneous spaces, etc.