[jira] [Created] (FLINK-4862) NPE on EventTimeSessionWindows with ContinuousEventTimeTrigger

Manu Zhang created FLINK-4862: - Summary: NPE on EventTimeSessionWindows with ContinuousEventTimeTrigger Key: FLINK-4862 URL: https://issues.apache.org/jira/browse/FLINK-4862 Project: Flink

Re: FlinkML - Evaluate function should manage LabeledVector

Hi, Two questions: 1- I was thinking of doing this: implicit def evaluateLabeledVector[T <: LabeledVector] = { new EvaluateDataSetOperation[SVM,T,Double]() { override def evaluateDataSet(instance: SVM, evaluateParameters: ParameterMap, testing: DataSet[T]): DataSet[(Double, Double)] = {

[jira] [Created] (FLINK-4861) Package optional project artifacts

Greg Hogan created FLINK-4861: - Summary: Package optional project artifacts Key: FLINK-4861 URL: https://issues.apache.org/jira/browse/FLINK-4861 Project: Flink Issue Type: New Feature

[jira] [Created] (FLINK-4860) Sort performance

Greg Hogan created FLINK-4860: - Summary: Sort performance Key: FLINK-4860 URL: https://issues.apache.org/jira/browse/FLINK-4860 Project: Flink Issue Type: Improvement Reporter: Greg

Re: Removing flink-contrib/flink-operator-stats

Based on a cursory reading of FLINK-1297 I would lean toward dropping the code rather than moving to Apache Bahir. This looks to only be appropriate for batch and this module was not integrated into the runtime. If there is a way forward to make use this code in core Flink then that would be even

Re: FlinkML - Evaluate function should manage LabeledVector

Hello Thomas, since you are calling evaluate here, you should be creating an EvaluateDataSet operation that works with LabeledVector, I see you are creating a new PredictOperation. On Wed, Oct 19, 2016 at 3:05 PM, Thomas FOURNIER < thomasfournier...@gmail.com> wrote: > Hi, > > I'd like to

[jira] [Created] (FLINK-4859) Clearly Separate Responsibilities of StreamOperator and StreamTask

Aljoscha Krettek created FLINK-4859: --- Summary: Clearly Separate Responsibilities of StreamOperator and StreamTask Key: FLINK-4859 URL: https://issues.apache.org/jira/browse/FLINK-4859 Project:

[jira] [Created] (FLINK-4858) Remove Legacy Checkpointing Interfaces

Aljoscha Krettek created FLINK-4858: --- Summary: Remove Legacy Checkpointing Interfaces Key: FLINK-4858 URL: https://issues.apache.org/jira/browse/FLINK-4858 Project: Flink Issue Type:

Re: Removing flink-contrib/flink-operator-stats

+1 for removing it in case it is not widely used. Apache Bahir would be a more appropriate place for this module then. -Max On Wed, Oct 19, 2016 at 3:52 PM, Robert Metzger wrote: > If there are no users and no contributors of the module, I'm +1 to remove > it. > > If we

[jira] [Created] (FLINK-4857) ZooKeeperUtils have a throws exception clause without throwing exceptions

Till Rohrmann created FLINK-4857: Summary: ZooKeeperUtils have a throws exception clause without throwing exceptions Key: FLINK-4857 URL: https://issues.apache.org/jira/browse/FLINK-4857 Project:

Removing flink-contrib/flink-operator-stats

Hey devs, I would like to propose the removal of the flink-contrib/flink-operator-stats module. It is currently causing some build stability issues (https://issues.apache.org/jira/browse/FLINK-4833) and there is no active maintainer for it as far as I can tell. Are there any objections to this?

Re: Add MapState for keyed streams

Hi Jark If the state is very big, it may occupy a lot of memory if we return Set>. By wrapping the returned iterator, we can easily implement a method returning Iterable>. Users can use that returned Iterable in the foreach loop. Regards Xiaogang 2016-10-19

Re: Add MapState for keyed streams

Hi Xiaogang, I think maybe return Set> is better than Iterator>. Because users can use foreach on Set but not Iterator, and can use iterator access via set.iterator(). Maybe Map.entrySet() is a more familiar way to users. - Jark Wu > 在 2016年10月19日，下午5:18，SHI

Re: Add MapState for keyed streams

Agreed. contains(K key) should be provided. The iterator() method should return Iterator> instead of Iterator>. Besides, size() may also be provided. With these methods, MapStates appear very similar to Java Maps. Users will be very happy to use them. Regards,

Re: Type erasure problem solely on cluster execution

Hi Fabian, Thank you for the quick reply and for looking into it. Sorry, I was a bit too quick with the field reference accusation. Turns out, my TypeInformation was wrong, hence the invalid reference exception. However, the type erasure problem still holds. The actual code can be found

Re: Add MapState for keyed streams

Hi Xiaogang, I really like your proposal and think that this would be a valuable addition to Flink :-) For convenience we could maybe add contains(K key), too. Java's Map interface returns a Set of Entry when calling entrySet() (which is the equivalent of iterator() in our interface). The Entry

Re: Type erasure problem solely on cluster execution

Hi Martin, thanks for reporting the problem and providing code to reproduce it. Would you mind to describe the problem with the forwarding annotations in more detail? I would be interested in the error message and how the semantic annotation is provided (@ForwardFields or withForwardedFields()).

Type erasure problem solely on cluster execution

Hi, I am running into a type erasure problem which only occurs when I execute the code using a Flink cluster (1.1.2). I created a Gist [1] which reproduces the problem. I also added a unit test to show that it does not fail in local and collection mode. Maybe it is also interesting to