Mailing-List: contact dev-help@flink.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@flink.apache.org
MIME-Version: 1.0
References: <55801173.4070205@informatik.hu-berlin.de>
In-Reply-To: <55801173.4070205@informatik.hu-berlin.de>
From: Aljoscha Krettek <aljoscha@apache.org>
Date: Tue, 16 Jun 2015 14:08:41 +0000
Message-ID: 
 <CANMXwW2cv+vAA_qRc+WT=csD8as4iZY1W_1aLwC2d8SV9baFLQ@mail.gmail.com>
Subject: Re: Question: SourceFunction
To: dev@flink.apache.org
Content-Type: multipart/alternative; boundary=f46d0438933129ed460518a31dae

--f46d0438933129ed460518a31dae
Content-Type: text/plain; charset=UTF-8

But the sources stay inside they run() method the whole execution time, per
design. That's why another thread needs to call cancel() on the source to
break it out of this (in most cases) infinite loop.

On Tue, 16 Jun 2015 at 14:13 Matthias J. Sax <mjsax@informatik.hu-berlin.de>
wrote:

> Hi,
>
> I just encountered, that the (new streaming API) SourceFunction
> interface method cancel() states in the JavaDoc, that one might have a
> "volatile field 'isRunning'". Why should this member be volatile? I do
> not see why different thread should access this field (I would claim, it
> will be implemented as a private/protected member variable), and thus,
> declaring it volatile should not be necessary.
>
> Do I miss anything?
>
> -Matthias
>
>

--f46d0438933129ed460518a31dae--