Hi all,
I run some tests for stream aggregation on rows. The data stream is simply
registered as
val orderA: DataStream[Order] = env.fromCollection(Seq(
Order(1L, "beer", 1),
Order(2L, "diaper", 2),
Order(3L, "diaper", 3),
Order(4L, "rubber", 4)))
tEnv.registerDataStream("
I've now started building the next release candidate.
On Sun, Apr 9, 2017 at 12:37 PM, Robert Metzger wrote:
> Hi Gyula,
>
> I'm trying to push Stefan R. to get the RocksDB fixes in asap.
>
> On Sat, Apr 8, 2017 at 5:17 PM, Gyula Fóra wrote:
>
>> Hi All,
>>
>> Any updates on this?
>>
>> It woul
Dawid Wysakowicz created FLINK-6290:
---
Summary: SharedBuffer is improperly released when multiple edges
between entries
Key: FLINK-6290
URL: https://issues.apache.org/jira/browse/FLINK-6290
Project:
In the worst case scenario we will have a custom build that will just cache
the different partition numbers in a map. (But still call partitioner.open
only once)
I think this simple intermediate fix would actually be good enough for most
people who get blocked by this in the short run.
Gyula
Gyul
Arnaud Linz created FLINK-6289:
--
Summary: ExecutionEnvironment.readTextFile() can read gzip files &
directories but not both
Key: FLINK-6289
URL: https://issues.apache.org/jira/browse/FLINK-6289
Project:
I understand the reasoning, on the other hand this creates a problem that
is very hard to work around. :/
Do you have any suggestions how to get around this?
Gyula
Tzu-Li (Gordon) Tai ezt írta (időpont: 2017. ápr.
10., H, 15:57):
> I would prefer to make this a blocker for a future bugfix actu
I would prefer to make this a blocker for a future bugfix actually, and not
1.2.1.
The reason is that to fix this properly we might need to look again into (and
possibly change) how partitioners are provided.
The main problem is that the `open` method can only possibly be called once
with the p
Thanks for checking this out.
I would say this is definitely a blocking issue for the bugfix release,
what do you think?
Gyula
Tzu-Li (Gordon) Tai ezt írta (időpont: 2017. ápr.
10., H, 15:39):
Hi Gyula,
Yes, I think the semantics of the Partitioner interface is a bit off.
The `numPartitions`
Hi Gyula,
Yes, I think the semantics of the Partitioner interface is a bit off.
The `numPartitions` value ideally should be the number of partitions of the
`targetTopic`.
Here’s a JIRA I just filed to track the issue:
https://issues.apache.org/jira/browse/FLINK-6288.
Cheers,
Gordon
On April 1
Tzu-Li (Gordon) Tai created FLINK-6288:
--
Summary: FlinkKafkaProducer's custom Partitioner is always invoked
with number of partitions of default topic
Key: FLINK-6288
URL: https://issues.apache.org/jira/brows
Nico Kruber created FLINK-6287:
--
Summary: Flakey JobManagerRegistrationTest
Key: FLINK-6287
URL: https://issues.apache.org/jira/browse/FLINK-6287
Project: Flink
Issue Type: Bug
Compone
Jinjiang Ling created FLINK-6286:
Summary: hbase command not found error
Key: FLINK-6286
URL: https://issues.apache.org/jira/browse/FLINK-6286
Project: Flink
Issue Type: Bug
Repor
Hi all,
We had some problems with custom partitioning for the 0.8 Kafka producer
and now that I checked the code it seems there might be a problem with the
logic.
The producer determines the number of partitions in the open method and
seems to be using that as a value passed to the custom partiti
13 matches
Mail list logo