TICKET =
LI_DESCRIPTION =

[LI-HOTFIX] Add build changes to publish github LinkedIn Kafka artifacts to bintray (#1)
TICKET =
LI_DESCRIPTION =

[NOTE] This is a temporary measure to publish artifacts until CI is properly set up to do the job automatically. Users are not expected to run this themselves.

EXIT_CRITERIA = MANUAL ["describe exit criteria"]

[LI-HOTFIX] Add changes for CI builds and publishing artifacts to bintray. (#2)
TICKET =
LI_DESCRIPTION =

Travis will kick off a build and publish artifacts to bintray upon creating a tag in the "x.y.z.w" format.

EXIT_CRITERIA = MANUAL ["describe exit criteria"]

[LI-HOTFIX] Try different encrypted bintray-related env variables for Travis (apache#4)
TICKET =
LI_DESCRIPTION =

Travis couldn't access one of the initially encrypted variables for some reason.

EXIT_CRITERIA = MANUAL ["describe exit criteria"]

[LI-HOTFIX] Set Bintray-related env variables via repository setting instead of in .travis.yml (apache#5)
TICKET =
LI_DESCRIPTION =

EXIT_CRITERIA = MANUAL ["describe exit criteria"]

[LI-HOTFIX] Use the maven repo under the LinkedIn Bintray account to publish artifacts (apache#25)
TICKET =
LI_DESCRIPTION =

EXIT_CRITERIA = MANUAL ["describe exit criteria"]

EXIT_CRITERIA = MANUAL ["describe exit criteria"]
# EXIT_CRITERIA = <EXIT_CRITERIA> <PARAMETERS>
# e.g.,
# when the specified hash(s) is presented in the history, this commit is no longer needed:
# EXIT_CRITERIA = HASH [<hash1>, <hash2> ...]
# When the specified tickets are closed and there are patches with these tickets in the title in the commit history, this commit is no longer needed:
# EXIT_CRITERIA = TICKET [<ticket1>, <ticket2> ...]
# The exit criteria for this commit requires manual investigation:
# EXIT_CRITERIA = MANUAL [<description>]

…pache#7305)

A partition log in initialized in following steps:

1. Fetch log config from ZK
2. Call LogManager.getOrCreateLog which creates the Log object, then
3. Registers the Log object

Step #3 enables Configuration update thread to deliver configuration
updates to the log. But if any update arrives between step #1 and #3
then that update is missed. It breaks following use case:

1. Create a topic with default configuration, and immediately after that
2. Update the configuration of topic

There is a race condition here and in random cases update made in
second step will get dropped.

This change fixes it by tracking updates arriving between step #1 and #3
Once a Partition is done initializing log, it checks if it has missed any
update. If yes, then the configuration is read from ZK again.

Added unit tests to make sure a dirty configuration is refreshed. Tested
on local cluster to make sure that topic configuration and updates are
handled correctly.

Reviewers: Jason Gustafson <jason@confluent.io>