Release 1.3.2 rc3#4720
Closed
yaochunnian wants to merge 360 commits into
Closed
Conversation
…sspath This closes #3931
Note that the official Docker images for Flink are community supported and not an official release of the Apache Flink PMC. This closes #3932
Introduce more generic parameters
…s multiple Kafka sink topics
…r custom partitioning This commit wraps up some general improvements to the new Kafka sink custom partitioning API, most notably: 1. remove deprecated constructors from base classes, as they are not user-facing. 2. modify producer IT test to test custom partitioning for dynamic topics. 3. improve documentation and Javadocs of the new interfaces. This closes #3901.
In order to guard against deletions of ZooKeeper nodes which are still being used by a different ZooKeeperStateHandleStore, we have to introduce a locking mechanism. Only after all ZooKeeperStateHandleStores have released their lock, the ZNode is allowed to be deleted. THe locking mechanism is implemented via ephemeral child nodes of the respective ZooKeeper node. Whenever a ZooKeeperStateHandleStore wants to lock a ZNode, thus, protecting it from being deleted, it creates an ephemeral child node. The node's name is unique to the ZooKeeperStateHandleStore instance. The delete operations will then only delete the node if it does not have any children associated. In order to guard against oprhaned lock nodes, they are created as ephemeral nodes. This means that they will be deleted by ZooKeeper once the connection of the ZooKeeper client which created the node timed out.
…default The pom.xml for flink-quickstart-java and flink-quickstart-scala must specify scala.version and scala.binary.version. This closes #3910
…Hook - wrap calls to MasterTriggerRestoreHook (and its factory) such that the user classloader is applied This closes #3933.
This was renamed a while ago and namespace is now deprecated.
When running a YARN cluster the cluster-id is automatically derived. Acutally setting a cluster-id can lead to problems if you start multiple per-job YARN sessions with the same cluster-id by accident.
Before, we were describing what happens if you manually specify a cluster-id. Now, we say explicitly that you should not do this when running Flink on a resource manager.
…HandlerTest This closes #4366.
When configuring larger memory segment sizes, configuring the low watermark before the high watermark may lead to an IllegalArgumentException, because the low watermark will temporarily be higher than the high watermark. It's necessary to configure the high watermark before the low watermark. For the queryable state server in KvStateServer I didn't add an extra test as the watermarks cannot be configured there. This closes #4391.
The CombineHint documentation applies to DataSet#reduce not DataSet#reduceGroup and should also be noted for DataSet#distinct. Also correct the usage where the CombineHint is set with setCombineHint rather than alongside the user-defined function parameter. This closes #4372
… FileSystem and ObjectStore
… object stores This closes #4397
…ommitCallbacks This closes #4187.
…stBase This closes #4414.
…rsion The previous sed command for flink-dist/src/main/assemblies/bin.xml was to specific and didn't also fix the Scala version in the gelly examples part.
Contributor
|
Hi @yaochunnian, I think this PR must have been opened by mistake. Could you please close it? Thanks! |
Contributor
|
This looks pretty much like some sort of mistake. Can you please close the PR? |
tzulitai
added a commit
to tzulitai/flink
that referenced
this pull request
Sep 26, 2017
Introduces a common test base that for all REST responses, a subclass should be implemented to verify that the response can be correctly marshalled and unmarshalled. This closes apache#4691. This closes apache#4720.
tzulitai
added a commit
to tzulitai/flink
that referenced
this pull request
Sep 26, 2017
Introduces a common test base that for all REST responses, a subclass should be implemented to verify that the response can be correctly marshalled and unmarshalled. This closes apache#4691. This closes apache#4720.
tzulitai
added a commit
to tzulitai/flink
that referenced
this pull request
Sep 26, 2017
Introduces a common test base that for all REST responses, a subclass should be implemented to verify that the response can be correctly marshalled and unmarshalled. This closes apache#4691. This closes apache#4720.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Thank you very much for contributing to Apache Flink - we are happy that you want to help us improve Flink. To help the community review your contribution in the best possible way, please go through the checklist below, which will get the contribution into a shape in which it can be best reviewed.
Please understand that we do not do this to make contributions to Flink a hassle. In order to uphold a high standard of quality for code contributions, while at the same time managing a large number of contributions, we need contributors to prepare the contributions well, and give reviewers enough contextual information for the review. Please also understand that contributions that do not follow this guide will take longer to review and thus typically be picked up with lower priority by the community.
Contribution Checklist
Make sure that the pull request corresponds to a JIRA issue. Exceptions are made for typos in JavaDoc or documentation files, which need no JIRA issue.
Name the pull request in the form "[FLINK-XXXX] [component] Title of the pull request", where FLINK-XXXX should be replaced by the actual issue number. Skip component if you are unsure about which is the best component.
Typo fixes that have no associated JIRA issue should be named following this pattern:
[hotfix] [docs] Fix typo in event time introductionor[hotfix] [javadocs] Expand JavaDoc for PuncuatedWatermarkGenerator.Fill out the template below to describe the changes contributed by the pull request. That will give reviewers the context they need to do the review.
Make sure that the change passes the automated tests, i.e.,
mvn clean verifypasses. You can set up Travis CI to do that following this guide.Each pull request should address only one issue, not mix up code from multiple issues.
Each commit in the pull request has a meaningful commit message (including the JIRA id)
Once all items of the checklist are addressed, remove the above text and this checklist, leaving only the filled out template below.
(The sections below can be removed for hotfixes of typos)
What is the purpose of the change
(For example: This pull request makes task deployment go through the blob server, rather than through RPC. That way we avoid re-transferring them on each deployment (during recovery).)
Brief change log
(for example:)
Verifying this change
(Please pick either of the following options)
This change is a trivial rework / code cleanup without any test coverage.
(or)
This change is already covered by existing tests, such as (please describe tests).
(or)
This change added tests and can be verified as follows:
(example:)
Does this pull request potentially affect one of the following parts:
@Public(Evolving): (yes / no)Documentation