Github user Xazax-hun commented on the issue:
https://github.com/apache/flink/pull/2211
Hi Ufuk!
I have some good news. With this version the code distribution is a solved
problem. I did experience some problem with the checkpointing though, but I
think that shouldn't be too
Github user Xazax-hun commented on the issue:
https://github.com/apache/flink/pull/2211
Hi!
This patch depends on the following pull request:
https://github.com/apache/flink/pull/2094
Once it is landed I will remove the [WIP] tag. I did not remove it yet
because I did not
Github user Xazax-hun commented on a diff in the pull request:
https://github.com/apache/flink/pull/2211#discussion_r78087961
--- Diff: flink-core/src/main/resources/PojoComparatorTemplate.ftl ---
@@ -0,0 +1,195 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF
Github user Xazax-hun commented on a diff in the pull request:
https://github.com/apache/flink/pull/2211#discussion_r78087704
--- Diff:
flink-core/src/main/java/org/apache/flink/api/java/typeutils/runtime/PojoSerializerGenerator.java
---
@@ -0,0 +1,259 @@
+/*
+ * Licensed
Github user Xazax-hun commented on a diff in the pull request:
https://github.com/apache/flink/pull/2211#discussion_r78086011
--- Diff:
flink-core/src/main/java/org/apache/flink/api/java/typeutils/PojoTypeInfo.java
---
@@ -419,4 +481,61 @@ public String toString
GitHub user Xazax-hun opened a pull request:
https://github.com/apache/flink/pull/2211
[WIP][FLINK-3599] Code generation for PojoSerializer and PojoComparator
The current implementation of the serializers can be a
performance bottleneck in some scenarios. These performance
Github user Xazax-hun commented on the pull request:
https://github.com/apache/flink/pull/1769#issuecomment-194419456
I think the soft references solution is not worth investigating, and I
agree that the best way to solve the problem is to make the operators smarter
for the iterative
Github user Xazax-hun commented on the pull request:
https://github.com/apache/flink/pull/1769#issuecomment-193443590
> I would be curious about the soft reference implementation as in
DetaIteration cases I think it is a valid situation that the job needs less and
less memory. Ple
GitHub user Xazax-hun opened a pull request:
https://github.com/apache/flink/pull/1769
[FLINK-3322] MemoryManager creates too much GC pressure with iterative jobs.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/Xazax-hun/flink
Github user Xazax-hun commented on the pull request:
https://github.com/apache/flink/pull/1685#issuecomment-189944863
I think this change is done and ready to be considered for the merge. I
think it should be merged to both the master and the release-1.0 branch.
---
If your project
Github user Xazax-hun commented on the pull request:
https://github.com/apache/flink/pull/1685#issuecomment-187076733
Thank you for your insight! I think you are right.
I will move the murmur hash to MathUtils as well, and document that which
hash should be used to which purpose
GitHub user Xazax-hun opened a pull request:
https://github.com/apache/flink/pull/1685
[WIP][FLINK-3422][streaming][api-breaking] Scramble HashPartitioner hashes.
This pull request contains a fix for FLINK-3422. Some of the tests are
failing at the moment, because they utilized
12 matches
Mail list logo
