Hello Gabor,
Yes, currently updateVertex only gets called when a new message was
received.
Could you please describe the logic behind your triangle count? The one I
know is described at the beginning of page 1643 in this article:
http://www.cc.gatech.edu/~bader/papers/GraphBSPonXMT-MTAAP2013.pdf
Hi all,
I am implementing a simple triangle counting example for a workshop with
vertex-centric iteration and I found that the updateVertex method only gets
called if there are new messages for that vertex. Is it the expected
behavior?
I know that the iteration should stop for the given vertex wh
Great! That was really needed.
On Mon, Apr 13, 2015 at 9:36 PM Gyula Fóra wrote:
> Dear All,
>
> Today I did a major refactoring of some streaming components, with a lot of
> class renamings and some package restructuring.
>
> https://github.com/apache/flink/pull/594
>
> 1. I refactored the inte
+1 for keeping the API. Even though this will not change your initial
concern much, Aljoscha :) I agree with you that it would be more consistent
to call the result of an operator OperatorDataSet.
On Thu, Apr 16, 2015 at 3:16 PM, Fabian Hueske wrote:
> Renaming the core operators is fine with me
As far as I see in [1], Peter's/Gyula's suggestion is what Infosphere
Streams does: symmetric hash join.
>From [1]:
"When a tuple is received on an input port, it is inserted into the window
corresponding to the input port, which causes the window to trigger. As
part of the trigger processing, the
Theodore Vasiloudis created FLINK-1901:
--
Summary: Create sample operator for Dataset
Key: FLINK-1901
URL: https://issues.apache.org/jira/browse/FLINK-1901
Project: Flink
Issue Type: Impr
Yes, I think that is an interesting idea. The question would be on which
level the integration would happen.
Adding Ignite as a data store to read data from and write it to should not
be too difficult.
A tighter integration such as using it as distributed hash table for ML
models might be interesti
Renaming the core operators is fine with me, but I would not touch API
facing classes.
A big +1 for Timo's suggestion.
2015-04-16 6:30 GMT-05:00 Timo Walther :
> I share Stephans opinion.
>
> By the way, we could also find a common name for operators with two
> inputs. Sometimes it's "TwoInputXXX
Hi,
I want to join two tables in the following way:
case class WeightedEdge(src: Int, target: Int, weight: Double)
case class Community(communityID: Int, nodeID: Int)
case class CommunitySumTotal(communityID: Int, sumTotal: Double)
val communities: DataSet[Community]
val weightedEdges: DataSet[
Timo Walther created FLINK-1900:
---
Summary: Table API documentation example does not work
Key: FLINK-1900
URL: https://issues.apache.org/jira/browse/FLINK-1900
Project: Flink
Issue Type: Bug
Felix Neutatz created FLINK-1899:
Summary: Table API Bug
Key: FLINK-1899
URL: https://issues.apache.org/jira/browse/FLINK-1899
Project: Flink
Issue Type: Bug
Components: Expression
I share Stephans opinion.
By the way, we could also find a common name for operators with two
inputs. Sometimes it's "TwoInputXXX", "DualInputXXX",
"BinaryInputXXX"... pretty inconsistent.
On 15.04.2015 17:48, Till Rohrmann wrote:
I would also be in favour of making the distinction between t
Kostas Tzoumas created FLINK-1898:
-
Summary: Add support for self-joins to Flink on Tez
Key: FLINK-1898
URL: https://issues.apache.org/jira/browse/FLINK-1898
Project: Flink
Issue Type: Bug
Kostas Tzoumas created FLINK-1897:
-
Summary: Add accummulators and counters feature to Flink on Tez
Key: FLINK-1897
URL: https://issues.apache.org/jira/browse/FLINK-1897
Project: Flink
Issue
Kostas Tzoumas created FLINK-1895:
-
Summary: Add task chaining to Flink on Tez
Key: FLINK-1895
URL: https://issues.apache.org/jira/browse/FLINK-1895
Project: Flink
Issue Type: Improvement
Kostas Tzoumas created FLINK-1896:
-
Summary: Add broadcast variables feature to Flink on Tez
Key: FLINK-1896
URL: https://issues.apache.org/jira/browse/FLINK-1896
Project: Flink
Issue Type: I
Kostas Tzoumas created FLINK-1894:
-
Summary: Add Tez execution mode to Flink command-line tools
Key: FLINK-1894
URL: https://issues.apache.org/jira/browse/FLINK-1894
Project: Flink
Issue Type
Kostas Tzoumas created FLINK-1893:
-
Summary: Add Scala support for Flink on Tez
Key: FLINK-1893
URL: https://issues.apache.org/jira/browse/FLINK-1893
Project: Flink
Issue Type: Improvement
Kostas Tzoumas created FLINK-1892:
-
Summary: Local job execution does not exit.
Key: FLINK-1892
URL: https://issues.apache.org/jira/browse/FLINK-1892
Project: Flink
Issue Type: Bug
I would also keep an eye on this issue from the Zeppelin project:
https://issues.apache.org/jira/browse/ZEPPELIN-44
The needed infrastructure is going to be very similar
On Thu, Apr 16, 2015 at 10:15 AM, Kostas Tzoumas
wrote:
> Great, let us know if you run into any issues.
>
> Can you create a
Great, let us know if you run into any issues.
Can you create a JIRA on the REPL and link to your repository for the
community to track the status?
On Wed, Apr 15, 2015 at 4:23 PM, Nikolaas s
wrote:
> Thanks for the feedback guys!
> Apparently The Scala Shell compiles the Shell input to some ki
21 matches
Mail list logo
