Henry Saputra created FLINK-2815:
Summary: [REFACTOR] Remove Pact from class and file names since it
is no longer valid reference
Key: FLINK-2815
URL: https://issues.apache.org/jira/browse/FLINK-2815
Greg Hogan created FLINK-2814:
-
Summary: DeltaIteration: DualInputPlanNode cannot be cast to
SingleInputPlanNode
Key: FLINK-2814
URL: https://issues.apache.org/jira/browse/FLINK-2814
Project: Flink
One of my colleagues found it today when we where hunting bugs today. We
where using the latest 0.10 version pulled from maven this morning.
The program we where testing is new code so I cant tell you if the behavior
has changed or if it was always like this.
On Fri, Oct 2, 2015 at 7:46 PM, Stepha
+1
From: Henry Saputra
Sent: Friday, October 2, 2015 19:34
To: dev@flink.apache.org
Subject: Re: Pulling Streaming out of staging and project restructure
+1
On Friday, October 2, 2015, Matthias J. Sax wrote:
> It think, rename "flink-storm-compatibility-core" to just "flink-storm"
> would be
Do we know what kind of impact the non-reuse policy has? Maybe the
serialization overhead is subsumed by other effects.
But in general I'm ok with changing the default to non copying. We just
have to document this feature properly.
On Oct 2, 2015 6:31 PM, "Maximilian Michels" wrote:
> +1 Good id
Robert, how hard it is to move these missing features to the new front end?
I prefer to remove the old one to prevent another duplicate things in Flink.
- Henry
On Fri, Oct 2, 2015 at 6:53 AM, Robert Metzger wrote:
> The new one does not have access to the JobManager log file.
> Also, the graph
I think these operations were recently moved to the internal state
interface. Did the behavior change then?
@Marton or Gyula, can you comment? Is it per chance not mapped to the
partitioned state?
On Fri, Oct 2, 2015 at 6:37 PM, Martin Neumann wrote:
> Hej,
>
> In one of my Programs I run a Fol
+1
On Friday, October 2, 2015, Matthias J. Sax wrote:
> It think, rename "flink-storm-compatibility-core" to just "flink-storm"
> would be the cleanest solution.
>
> So in flink-contrib there would be two modules:
> - flink-storm
> - flink-storm-examples
>
> Please let me know if you have an
Hej,
In one of my Programs I run a Fold on a GroupedDataStream. The aim is to
aggregate the values in each group.
It seems the aggregator in the Fold function is shared on operator level,
so all groups that end up on the same operator get mashed together.
Is this the wanted behavior? If so, what
+1 Good idea. I think we can save quite some CPU cycles by not copying
records.
That is basically the behavior of the batch API, and there has so far never
> been an issue with that (people running into the trap of overwritten
> mutable elements).
As far as I know, this is only the case for chai
@Martin:
I think you were a user of the Batch API before we made the non-reuse mode
the default mode.
By now, when you use a GroupReduceFunction or a MapPartitionFunction or so,
you need not do any cloning or copying. All functions that receive groups
will always get fresh elements.
This chaining
It seems like I'm one of the few people that run into the mutable elements
trap on the Batch API from time to time. At the moment I always clone when
I'm not 100% sure to avoid hunting the bugs later. So far I was happy to
learn that this is not a problem in Streaming, but that's just me.
When wor
Maximilian Michels created FLINK-2813:
-
Summary: Document off-heap configuration
Key: FLINK-2813
URL: https://issues.apache.org/jira/browse/FLINK-2813
Project: Flink
Issue Type: Bug
+1 for disable copy by default
On 10/02/2015 05:53 PM, Stephan Ewen wrote:
> Hi all!
>
> Now that we are coming to the next release, I wanted to make sure we
> finalize the decision on that point, because it would be nice to not break
> the behavior of system afterwards.
>
> Right now, when tas
Hi all!
Now that we are coming to the next release, I wanted to make sure we
finalize the decision on that point, because it would be nice to not break
the behavior of system afterwards.
Right now, when tasks are chained together, the system copies the elements
always between different tasks in t
Márton Balassi created FLINK-2812:
-
Summary: KeySelectorUtil.getSelectorForKeys and
TypeExtractor.getKeySelectorTypes are incompatible
Key: FLINK-2812
URL: https://issues.apache.org/jira/browse/FLINK-2812
Robert Metzger created FLINK-2811:
-
Summary: Add page with configuration overview
Key: FLINK-2811
URL: https://issues.apache.org/jira/browse/FLINK-2811
Project: Flink
Issue Type: Sub-task
right, I meant DataStream
On Fri, Oct 2, 2015 at 2:47 PM, Robert Metzger wrote:
> I suspect: "- Deletion of "DataSet.forward() and .global()"" is a typo, you
> meant DataStream ?
>
> On Fri, Oct 2, 2015 at 2:44 PM, Kostas Tzoumas
> wrote:
>
> > Oh, and of course, support for event time. I might
You made very sensible choices for improving and finalizing the
Streaming API. The documentation is much clearer now. By the way, here
is the pull request: https://github.com/apache/flink/pull/1208
On Fri, Oct 2, 2015 at 3:02 PM, Stephan Ewen wrote:
> I added two comments to the pull request that
The new one does not have access to the JobManager log file.
Also, the graphs for the TaskManagers are missing.
On Fri, Oct 2, 2015 at 3:51 PM, Stephan Ewen wrote:
> I would actually like to remove the old one, but I am okay with keeping it
> and activating the new one by default
>
> On Fri, Oc
I would actually like to remove the old one, but I am okay with keeping it
and activating the new one by default
On Fri, Oct 2, 2015 at 3:49 PM, Robert Metzger wrote:
> The list from Kostas also contained the new JobManager front end.
>
> Do we want to enable it by default in the 0.10 release?
>
The list from Kostas also contained the new JobManager front end.
Do we want to enable it by default in the 0.10 release?
Are we going to keep the old interface, or are we removing it?
I'm voting for enabling the new one by default and keeping the old one for
the next release.
What do you think?
Greg Hogan created FLINK-2810:
-
Summary: Warn user if bc not installed
Key: FLINK-2810
URL: https://issues.apache.org/jira/browse/FLINK-2810
Project: Flink
Issue Type: Improvement
Compo
Gabor Gevay created FLINK-2809:
--
Summary: DataSet[Unit] doesn't work
Key: FLINK-2809
URL: https://issues.apache.org/jira/browse/FLINK-2809
Project: Flink
Issue Type: Bug
Components: Sc
I added two comments to the pull request that this is based on...
On Fri, Oct 2, 2015 at 2:47 PM, Robert Metzger wrote:
> I suspect: "- Deletion of "DataSet.forward() and .global()"" is a typo, you
> meant DataStream ?
>
> On Fri, Oct 2, 2015 at 2:44 PM, Kostas Tzoumas
> wrote:
>
> > Oh, and of
Stephan Ewen created FLINK-2808:
---
Summary: Rework / Extend the StatehandleProvider
Key: FLINK-2808
URL: https://issues.apache.org/jira/browse/FLINK-2808
Project: Flink
Issue Type: Improvement
I suspect: "- Deletion of "DataSet.forward() and .global()"" is a typo, you
meant DataStream ?
On Fri, Oct 2, 2015 at 2:44 PM, Kostas Tzoumas wrote:
> Oh, and of course, support for event time. I might be forgetting more, feel
> free to add to the list
>
>
> On Fri, Oct 2, 2015 at 2:40 PM, Kosta
Oh, and of course, support for event time. I might be forgetting more, feel
free to add to the list
On Fri, Oct 2, 2015 at 2:40 PM, Kostas Tzoumas wrote:
> Hi folks,
>
> Currently, Aljoscha, Stephan, and I are reworking the DataStream API as
> discussed before. Things are a bit in-flight right
Hi folks,
Currently, Aljoscha, Stephan, and I are reworking the DataStream API as
discussed before. Things are a bit in-flight right now with several commits
and pull requests, and the current master containing code from both the old
and the new API.
I want to give you an idea of how the new API
Gyula Fora created FLINK-2807:
-
Summary: Add javadocs/comments to new windowing mechanics
Key: FLINK-2807
URL: https://issues.apache.org/jira/browse/FLINK-2807
Project: Flink
Issue Type: Sub-task
Gabor Gevay created FLINK-2806:
--
Summary: No TypeInfo for Scala's Nothing type
Key: FLINK-2806
URL: https://issues.apache.org/jira/browse/FLINK-2806
Project: Flink
Issue Type: Bug
Comp
Ufuk Celebi created FLINK-2805:
--
Summary: Make user jars available for all job managers to recover
Key: FLINK-2805
URL: https://issues.apache.org/jira/browse/FLINK-2805
Project: Flink
Issue Type
Ufuk Celebi created FLINK-2804:
--
Summary: Support blocking job submission with Job Manager recovery
Key: FLINK-2804
URL: https://issues.apache.org/jira/browse/FLINK-2804
Project: Flink
Issue Typ
+1
On Fri, 2 Oct 2015 at 11:37 Márton Balassi wrote:
> @Matthias: +1.
>
> On Fri, Oct 2, 2015 at 11:27 AM, Stephan Ewen wrote:
>
> > @matthias +1 for that approach
> >
> > On Fri, Oct 2, 2015 at 11:21 AM, Matthias J. Sax
> wrote:
> >
> > > It think, rename "flink-storm-compatibility-core" to j
@Matthias: +1.
On Fri, Oct 2, 2015 at 11:27 AM, Stephan Ewen wrote:
> @matthias +1 for that approach
>
> On Fri, Oct 2, 2015 at 11:21 AM, Matthias J. Sax wrote:
>
> > It think, rename "flink-storm-compatibility-core" to just "flink-storm"
> > would be the cleanest solution.
> >
> > So in flink-
@matthias +1 for that approach
On Fri, Oct 2, 2015 at 11:21 AM, Matthias J. Sax wrote:
> It think, rename "flink-storm-compatibility-core" to just "flink-storm"
> would be the cleanest solution.
>
> So in flink-contrib there would be two modules:
> - flink-storm
> - flink-storm-examples
>
>
I think that roughly, an approach like the compacting hash table is the
right one.
Go ahead and take a stab at it, if you want, ping us if you run into
obstacles.
Here are a few thoughts on the hash-aggregator from discussions between
Fabian and me:
1) It may be worth to have a specialized implem
It think, rename "flink-storm-compatibility-core" to just "flink-storm"
would be the cleanest solution.
So in flink-contrib there would be two modules:
- flink-storm
- flink-storm-examples
Please let me know if you have any objection about it.
-Matthias
On 10/02/2015 10:45 AM, Matthias J. S
Maximilian Michels created FLINK-2803:
-
Summary: Add test case for Flink's memory allocation
Key: FLINK-2803
URL: https://issues.apache.org/jira/browse/FLINK-2803
Project: Flink
Issue Typ
Sure. Will do that.
-Matthias
On 10/02/2015 10:35 AM, Stephan Ewen wrote:
> @Matthias: How about getting rid of the storm-compatibility-parent and
> making the core and examples projects directly projects in "contrib"
>
> On Fri, Oct 2, 2015 at 10:34 AM, Till Rohrmann wrote:
>
>> +1 for the ne
@Matthias: How about getting rid of the storm-compatibility-parent and
making the core and examples projects directly projects in "contrib"
On Fri, Oct 2, 2015 at 10:34 AM, Till Rohrmann wrote:
> +1 for the new project structure. Getting rid of our code dump is a good
> thing.
>
> On Fri, Oct 2,
+1 for the new project structure. Getting rid of our code dump is a good
thing.
On Fri, Oct 2, 2015 at 10:25 AM, Maximilian Michels wrote:
> +1 Matthias, let's limit the overhead this has for the module maintainers.
>
> On Fri, Oct 2, 2015 at 12:17 AM, Matthias J. Sax wrote:
> > I will commit s
+1 Matthias, let's limit the overhead this has for the module maintainers.
On Fri, Oct 2, 2015 at 12:17 AM, Matthias J. Sax wrote:
> I will commit something to flink-storm-compatibility tomorrow that
> contains some internal package restructuring. I think, renaming the
> three modules in this com
Gyula Fora created FLINK-2802:
-
Summary: Watermark triggered operators cannot progress with cyclic
flows
Key: FLINK-2802
URL: https://issues.apache.org/jira/browse/FLINK-2802
Project: Flink
Issu
Stephan Ewen created FLINK-2801:
---
Summary: Rework Storm Compatibility Tests
Key: FLINK-2801
URL: https://issues.apache.org/jira/browse/FLINK-2801
Project: Flink
Issue Type: Bug
Compon
Stefano Bortoli created FLINK-2800:
--
Summary: kryo serialization problem
Key: FLINK-2800
URL: https://issues.apache.org/jira/browse/FLINK-2800
Project: Flink
Issue Type: Bug
Compon
46 matches
Mail list logo
