Today we had a discussion with Robert on this issue. I would like to
eventually have the streaming grouped and the windowing buffers/state maybe
along with the crucial state of the user in the managed memory. If we had
this separating the two modes could became less important as streaming
would als
+1
I agree it’s a proper way to go.
On 18 Feb 2015, at 10:41, Max Michels mailto:m...@apache.org>>
wrote:
+1
On Tue, Feb 17, 2015 at 2:40 PM, Aljoscha Krettek
mailto:aljos...@apache.org>> wrote:
+1
On Tue, Feb 17, 2015 at 1:34 PM, Till Rohrmann
mailto:trohrm...@apache.org>> wrote:
+1
On Tu
+1
On Tue, Feb 17, 2015 at 2:40 PM, Aljoscha Krettek wrote:
> +1
>
> On Tue, Feb 17, 2015 at 1:34 PM, Till Rohrmann wrote:
>> +1
>>
>> On Tue, Feb 17, 2015 at 1:34 PM, Kostas Tzoumas wrote:
>>
>>> +1
>>>
>>> On Tue, Feb 17, 2015 at 12:14 PM, Márton Balassi
>>> wrote:
>>>
>>> > When it comes to
+1
On Tue, Feb 17, 2015 at 1:34 PM, Till Rohrmann wrote:
> +1
>
> On Tue, Feb 17, 2015 at 1:34 PM, Kostas Tzoumas wrote:
>
>> +1
>>
>> On Tue, Feb 17, 2015 at 12:14 PM, Márton Balassi
>> wrote:
>>
>> > When it comes to the current use cases I'm for this separation.
>> > @Ufuk: As Gyula has alre
+1
On Tue, Feb 17, 2015 at 1:34 PM, Kostas Tzoumas wrote:
> +1
>
> On Tue, Feb 17, 2015 at 12:14 PM, Márton Balassi
> wrote:
>
> > When it comes to the current use cases I'm for this separation.
> > @Ufuk: As Gyula has already pointed out with the current design of
> > integration it should not
+1
On Tue, Feb 17, 2015 at 12:14 PM, Márton Balassi
wrote:
> When it comes to the current use cases I'm for this separation.
> @Ufuk: As Gyula has already pointed out with the current design of
> integration it should not be a problem. Even if we submitted programs to
> the wrong clusters it wou
When it comes to the current use cases I'm for this separation.
@Ufuk: As Gyula has already pointed out with the current design of
integration it should not be a problem. Even if we submitted programs to
the wrong clusters it would only cause performance issues.
Eventually it would be nice to have
So the current setup is to share results between the two apis by files. So
I dont see any reason why this couldnt work with the 2 cluster setup. It
makes deployment a little trickier but still feasible.
On Tue, Feb 17, 2015 at 11:55 AM, Ufuk Celebi wrote:
> I think this separation reflects the w
I think this separation reflects the way that Flink is used currently
anyways. I would be in favor of it as well.
- What about the ongoing efforts (I think by Gyula) to combine both the
batch and stream processing APIs? I assume that this would only effect the
performance and wouldn't pose a funda
+1
Let's do this soon to avoid performance issues for streaming.
On Tue, Feb 17, 2015 at 11:39 AM, Fabian Hueske wrote:
> sounds like a good idea to me.
> +1
>
> 2015-02-17 11:28 GMT+01:00 Stephan Ewen :
>
> > Hi everyone!
> >
> > What do you think about making the streaming execution mode of th
sounds like a good idea to me.
+1
2015-02-17 11:28 GMT+01:00 Stephan Ewen :
> Hi everyone!
>
> What do you think about making the streaming execution mode of the system
> explicit? That means that people start a Flink cluster explicitly in Batch
> mode or in Streaming mode.
>
> The rational behin
Hi everyone!
What do you think about making the streaming execution mode of the system
explicit? That means that people start a Flink cluster explicitly in Batch
mode or in Streaming mode.
The rational behind this idea is that I am not sure how batch and streaming
clusters are really shared in a
12 matches
Mail list logo
