Hi all -
I'm part of the Dataflow team at Google and would like to add a few
features to the Dataflow Runner. Could someone add me as a JIRA
contributor to track the work?
Thanks!
Andrea
ellij can't index java files for generated sources until those
>> generated sources exist.
>>
>> On Fri, Oct 26, 2018 at 12:26 PM Andrea Foegler
>> wrote:
>>
>>> So everything seems to build fine. But the analyzer shows missing
>>> imports fo
ntelliJ docs and the wiki now has much more information:
> https://cwiki.apache.org/confluence/display/BEAM/Using+IntelliJ+IDE
>
> If you're still having issues, take another look. And if you have a new
> issues or tip that's not listed, please add it!
>
> On Fri, Oct
Thank you for the updated docs! I just set up IntelliJ from scratch and
got the build smoothly the the point where it's happy to use up all the
resources on my laptop :)
It was great to be able to just follow the steps provided to get up and
going!
On Fri, Oct 19, 2018 at 2:34 AM Maximilian Mic
described the source.
On Tue, Aug 14, 2018 at 10:43 AM Andrea Foegler wrote:
> Hi folks -
>
> Many of you don't know me, as I don't contribute directly to Beam. But I
> do a lot of work around the periphery, in particular considering how to
> manage and monitor Beam pi
Hi folks -
Many of you don't know me, as I don't contribute directly to Beam. But I
do a lot of work around the periphery, in particular considering how to
manage and monitor Beam pipelines.
I think there's room in Beam to greatly improve both the management and
monitoring story, especially arou
I guess I'm voting for 2. Tests obviously belong in the code repo, both as
a sample usage (not "how-to", more like "man") and, well, for testing.
These pipelines might not be annotated as completely and include hitting
edge cases and other non-standard situations.
Any example where the primary pu
On Fri, Apr 13, 2018 at 5:00 PM Robert Bradshaw wrote:
> On Fri, Apr 13, 2018 at 3:28 PM Andrea Foegler wrote:
>
>> Thanks, Robert!
>>
>> I think my lack of clarity is around the MetricSpec. Maybe what's in my
>> head and what's being proposed a
on metric representation could be a specific URN+payload
>used for most metrics, while extensible ones use a different URN+payload.
>
>
> Thanks for the discussion on this thread today. I'd like us to keep
> engaging like this to come to an agreement.
> Alex
>
> On Fri, A
"beam:counter::" or even
>> "beam:metric::" since metrics have a type separate from
>> their name.
>>
>
> I proposed keeping the "user" in there to avoid possible clashes with the
> system namespaces. (No preference on counter vs. metric, I wasn&#
> (and unknowable if one does not recognize the name). This makes things more
>>> open-ended and easier to evolve and work with.
>>>
>>> Entity could be generalized to Label, or LabelSet if desired. But as
>>> mentioned I think it makes sense to pull this out as a separate
Hi folks -
Before we totally go down the path of highly structured metric protos, I'd
like to propose considering a simple metrics interface between the SDK and
the runner. Something more generic and closer to what most monitoring
systems would use.
To use Spark as an example, the Metric system
12 matches
Mail list logo
