[
https://issues.apache.org/jira/browse/BEAM-4775?focusedWorklogId=200790&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-200790
]
ASF GitHub Bot logged work on BEAM-4775:
----------------------------------------
Author: ASF GitHub Bot
Created on: 19/Feb/19 18:01
Start Date: 19/Feb/19 18:01
Worklog Time Spent: 10m
Work Description: ryan-williams commented on issue #7866: [BEAM-4775] mv
function pkg from fn-harness to java-core
URL: https://github.com/apache/beam/pull/7866#issuecomment-465241925
Yea, sorry it's not clear. I need to think more about metrics/proto
package-structures in #7823 that may affect this. Let me do that and circle
back.
In the meantime, here's some context for the package-move, as it currently
stands:
- in #7823, [I have a use for `ThrowingConsumer` in
`sdks/java/core`](https://github.com/apache/beam/pull/7823/files#diff-e819ee62f70ca51640a1d798c8a9befeR72)
- it (and its friends) currently live in `sdks/java/fn-harness`
- they don't have anything to do with the fn-harness
- ideally, they'd be in `java.util.function`, or something like Guava;
they don't have anything to do with Beam
- `sdks/java/core` seems the most logical place to put them that is
accessible from `sdks/java/core`
- I could also make a new module, and have java-core depend on that
- However, that has all the downsides from a "lots of things now
transitively depend on this" perpspective
- It would keep things a bit more modular in general though, and leave
the option to rearrange things later, better parallelize builds in the
meantime, etc., so maybe that's worth doing.
- It's also possible I can move the java-core metrics stuff to a
different, less "core", package
- Let me think about this for a bit, I need to think more about where
all the Java SDK metrics stuff should live in #7823 anyway.
re: parameterizing ThrowingConsumer`'s `Exception`-type:
- I pass a JSON-serialization action as a lambda and need to encode that it
`throws IOException`
- If [the code that receives that
lambda](https://github.com/apache/beam/pull/7823/files#diff-e819ee62f70ca51640a1d798c8a9befeR72)
declares a generic `throws Exception`, then [code that calls
that](https://github.com/apache/beam/pull/7823/files#diff-1677e5001d798d26293b99815a5c16d8R114)
would have to do some unwieldy catching/casting to go from `Exception` back to
`IOException`.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 200790)
Time Spent: 8h 10m (was: 8h)
> JobService should support returning metrics
> -------------------------------------------
>
> Key: BEAM-4775
> URL: https://issues.apache.org/jira/browse/BEAM-4775
> Project: Beam
> Issue Type: Bug
> Components: beam-model
> Reporter: Eugene Kirpichov
> Assignee: Ryan Williams
> Priority: Major
> Labels: triaged
> Time Spent: 8h 10m
> Remaining Estimate: 0h
>
> [https://github.com/apache/beam/blob/master/model/job-management/src/main/proto/beam_job_api.proto]
> currently doesn't appear to have a way for JobService to return metrics to a
> user, even though
> [https://github.com/apache/beam/blob/master/model/fn-execution/src/main/proto/beam_fn_api.proto]
> includes support for reporting SDK metrics to the runner harness.
>
> Metrics are apparently necessary to run any ValidatesRunner tests because
> PAssert needs to validate that the assertions succeeded. However, this
> statement should be double-checked: perhaps it's possible to somehow work
> with PAssert without metrics support.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
