Skip to content

Take latest master from main line #1

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 162 commits into from
Nov 2, 2020
Merged

Take latest master from main line #1

merged 162 commits into from
Nov 2, 2020

Conversation

keithks
Copy link
Owner

@keithks keithks commented Nov 2, 2020

No description provided.

stanislavlevin and others added 30 commits February 27, 2019 10:14
Since 1.3b1 (released Oct 10, 2014) Sphinx has support for NumPy and
Google style docstring support via sphinx.ext.napoleon extension.
The latter is already used, but sphinxcontrib-napoleon requirement
still presents.

Signed-off-by: Stanislav Levin <[email protected]>
In an effort to reduce the surface area of lock coordination, and thereby hopefully reduce lock contention, I think we can remove locking from the read-only KafkaClient methods: connected, is_disconnected, in_flight_request_count, and least_loaded_node . Given that the read data could change after the lock is released but before the caller uses it, the value of acquiring a lock here does not seem high to me.
* 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 xenial dist for travis builds
* Use openjdk8 for all travis tests
* Update python build matrix -- add 3.7, drop 3.5/3.6 (keep 2.7, 3.4, pypy2.7)
Underlying issue here is a race on consumer.close() between the client, the connections/sockets, and the heartbeat thread. Although the heartbeat thread is signaled to close, we do not block for it. So when we go on to close the client and its underlying connections, if the heartbeat is still doing work it can cause errors/crashes if it attempts to access the now closed objects (selectors and/or sockets, primarily).

So this commit adds a blocking thread join to the heartbeat close. This may cause some additional blocking time on consumer.close() while the heartbeat thread finishes. But it should be small in average case and in the worst case will be no longer than the heartbeat_timeout_ms (though if we timeout the join, race errors may still occur).

Fix #1666
I noticed during local testing that version probing was happening twice when connecting to newer broker versions. This was because we call check_version() once explicitly, and then again implicitly within get_api_versions(). But once we have _api_versions data cached, we can just return it and avoid probing versions a second time.
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.
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
This doesn't fully implement SSL fixtures, but as a first step it should help with automatically generating required certificates / keystores / etc. My hope is that this helps generate more community support for SSL testing!
kvfi and others added 29 commits March 2, 2020 08:52
This was previously supported but wasn't documented.

Fix #1990.
This is in preparation for adding `zstd` support.
* Add logic for inferring newer broker versions

- New Fetch / ListOffsets request / response objects
- Add new test cases to inferr code based on mentioned objects
- Add unit test to check inferred version against whatever resides in KAFKA_VERSION
- Add new kafka broker versions to integration list
- Add more kafka broker versions to travis task list
- Add support for broker version 2.5 id

* Implement PR change requests: fewer versions for travis testing, remove unused older versions for inference code, remove one minor version from known server list
Do not use newly created ACL request / responses in allowed version lists, due to flexible versions enabling in kafka actually requiring a serialization protocol header update
Revert admin client file change
Co-authored-by: MostafaElmenabawy <[email protected]>
Co-authored-by: MostafaElmenabawy <[email protected]>
Adding namedtuples for DescribeConsumerGroup response; Adding Serialization of MemberData and MemberAssignment for the response

Co-authored-by: Apurva Telang <[email protected]>
Co-authored-by: Jeff Widman <[email protected]>
Currently there's no way to pass timeout to check_version if called from admin.
Fix initialization order in KafkaClient
* Add consumergroup related errors
* Add DeleteGroups to protocol.admin
* Implement delete_groups feature on KafkaAdminClient
Small cleanup leftover from #2035
Previously there were two methods:
* `_find_coordinator_id()`
* `_find_many_coordinator_ids()`

But they do basically the same thing internally. And we need the plural
two places, but the singular only one place.

So merge them, and change the function signature to take a list of
`group_ids` and return a dict of `group_id: coordinator_id`s.

As a result of this, the `describe_groups()` command should scale better
because the `_find_coordinator_ids()` command issues all the requests
async, instead of sequentially blocking as the `described_groups()` used
to do.
Fix a deprecation warning in the newest version.
Also re-order lexicographically.

Note that I did not exhaustively test this... there could be edge cases
depending on the python version. But I think we should be okay because
`tox.ini` is currently testing using with unpinned versions, so I think
we're already running these versions in our test suite.
@keithks keithks merged commit fcf6cd2 into keithks:master Nov 2, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.