[
https://issues.apache.org/jira/browse/SAMZA-1202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jagadish updated SAMZA-1202:
----------------------------
Description:
Consider the following code-snippet that invokes graph.getInputStream multiple
times with the same streamId (but with different Message Builders).
{code}
BiFunction<String, String, String> msgBuilder1 = (k, v) -> v;
BiFunction<String, String, Integer> msgBuilder2 = (k, v) -> new Integer(v);
graph.getInputStream("page-views", msgBuilder2);
MessageStream<String> pageViews1 = graph.getInputStream("page-views",
msgBuilder1);
pageViews1.map(..)
.filter(..)
.window(..)
.sink(..)
{code}
TL;DR:
The above snippet results in non-deterministic behavior (Messages may not even
be passed in to the operator chain.) depending on the iteration order of Java
hashmaps.
Here is the exact sequence:
1. User creates two `MessageStream`s by multiple calls to
`graph.getInputStream()` with the same streamId but different MessageBuilders.
2. This invokes StreamGraphImpl#getInputStream, which maintains book-keeping by
`StreamSpec`. (It obtains a StreamSpec instance from the streamId)
3. Depending on the iteration order in which
`streamGraph.getInputStreams().forEach((streamSpec, inputStream)` returns, we
could end up with a different representation of the DAG (with the latest
streamSpec clobbering it's previous one).
was:
Consider the following code-snippet that invokes graph.getInputStream multiple
times with the same streamId (but with different Message Builders).
{code}
BiFunction<String, String, String> msgBuilder1 = (k, v) -> v;
BiFunction<String, String, Integer> msgBuilder2 = (k, v) -> new Integer(v);
graph.getInputStream("page-views", msgBuilder2);
MessageStream<String> pageViews1 = graph.getInputStream("page-views",
msgBuilder1);
pageViews1.map(..)
.filter(..)
.window(..)
.sink(..)
{code}
TL;DR:
The above snippet results in non-deterministic behavior (Messages may not even
be passed in to the operator chain.) depending on the iteration order of Java
hashmaps.
> Multiple calls to `graph.getInputStream()` with the same streamId results in
> non-deterministic behavior
> -------------------------------------------------------------------------------------------------------
>
> Key: SAMZA-1202
> URL: https://issues.apache.org/jira/browse/SAMZA-1202
> Project: Samza
> Issue Type: Bug
> Reporter: Jagadish
>
> Consider the following code-snippet that invokes graph.getInputStream
> multiple times with the same streamId (but with different Message Builders).
> {code}
> BiFunction<String, String, String> msgBuilder1 = (k, v) -> v;
> BiFunction<String, String, Integer> msgBuilder2 = (k, v) -> new
> Integer(v);
> graph.getInputStream("page-views", msgBuilder2);
> MessageStream<String> pageViews1 = graph.getInputStream("page-views",
> msgBuilder1);
> pageViews1.map(..)
> .filter(..)
> .window(..)
> .sink(..)
> {code}
> TL;DR:
> The above snippet results in non-deterministic behavior (Messages may not
> even be passed in to the operator chain.) depending on the iteration order of
> Java hashmaps.
> Here is the exact sequence:
> 1. User creates two `MessageStream`s by multiple calls to
> `graph.getInputStream()` with the same streamId but different MessageBuilders.
> 2. This invokes StreamGraphImpl#getInputStream, which maintains book-keeping
> by `StreamSpec`. (It obtains a StreamSpec instance from the streamId)
> 3. Depending on the iteration order in which
> `streamGraph.getInputStreams().forEach((streamSpec, inputStream)` returns, we
> could end up with a different representation of the DAG (with the latest
> streamSpec clobbering it's previous one).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
