Github user mjsax closed the pull request at:
https://github.com/apache/flink/pull/1483
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabl
Github user mjsax commented on the pull request:
https://github.com/apache/flink/pull/1483#issuecomment-177069344
I would like to keep this open, until
[FLINK-2721](https://issues.apache.org/jira/browse/FLINK-2721) is merged. To
make sure, we do not need this -- for this case, we can
Github user aljoscha commented on the pull request:
https://github.com/apache/flink/pull/1483#issuecomment-176839873
@mjsax What is the status on this PR? Can it be closed since the feature in
Storm will be implemented another way?
---
If your project is set up for it, you can reply
Github user mjsax commented on the pull request:
https://github.com/apache/flink/pull/1483#issuecomment-171944496
With embedded mode, I mean to use a spout/bolt within a regular Flink
streaming program. For this, you could even have a "plain/raw" input stream
(eg, `DataStream`) or a P
Github user aljoscha commented on the pull request:
https://github.com/apache/flink/pull/1483#issuecomment-171931389
I think that the Storm compatibility layer is very important. I also think,
however, that when making decisions about whether to enhance to core API to
serve other APIs
Github user aljoscha commented on the pull request:
https://github.com/apache/flink/pull/1483#issuecomment-171930800
What do you mean by embedded usage? Also, isn't there the `StormTuple` that
is used as output of some operations. Then, even if plain Tuples are used, they
could have a
Github user mjsax commented on the pull request:
https://github.com/apache/flink/pull/1483#issuecomment-171928147
We do not have any message wrappers on the wire. Data is transfered as
plain Flink `TupleX` types and are translated into Storm format before handing
them over to the bolt
Github user aljoscha commented on the pull request:
https://github.com/apache/flink/pull/1483#issuecomment-171926900
Hi,
I would be strongly against exposing the input channel index in any way to
operators/user functions. How the index of a channel maps to an upstream
operator is
Github user mjsax commented on the pull request:
https://github.com/apache/flink/pull/1483#issuecomment-171790057
Ok. I will try to rework this to the custom operator approach...
About your last statement: We could decide to omit this information in the
Storm compatibility lay
Github user StephanEwen commented on the pull request:
https://github.com/apache/flink/pull/1483#issuecomment-171785899
Right, you cannot secure users from writing bad code, of course.
But a good way to guide then to writing good code is to expose only
information they can act
Github user mjsax commented on the pull request:
https://github.com/apache/flink/pull/1483#issuecomment-170244363
I understand your skeptic, but I don't see it as dangerous as you. If
somebody access this information and does not use it properly, it's his/her own
fault... (same as usi
Github user StephanEwen commented on the pull request:
https://github.com/apache/flink/pull/1483#issuecomment-170083592
I am big time skeptic when it comes to putting this into the
`RuntimeContext`.
If we really need to expose that beyond the `StreamInputProcessor`, it
would
Github user mjsax commented on the pull request:
https://github.com/apache/flink/pull/1483#issuecomment-170073172
If you implement a Bolt you can retrieve this information from Storm. Thus,
the compatibility layer should provide this information, too.
---
If your project is set up fo
Github user StephanEwen commented on the pull request:
https://github.com/apache/flink/pull/1483#issuecomment-170044112
The user code should not deal with what channel an element came from. It
wires assumptions about the parallelism of the predecessor into the user code.
Adjustments o
Github user mjsax commented on the pull request:
https://github.com/apache/flink/pull/1483#issuecomment-168748526
Needed for Storm compatibility. This information is made available in Storm
to the user. Not sure why adding it to `RuntimeContext` breaks abstraction
layer (it's only met
Github user StephanEwen commented on the pull request:
https://github.com/apache/flink/pull/1483#issuecomment-168620418
Can you give us a bit of context why this is needed?
Also: The `RuntimeContext` object is what is exposed to user-defined
functions. Exposing the number of t
Github user mjsax commented on the pull request:
https://github.com/apache/flink/pull/1483#issuecomment-168464116
Travis failed due to know instable test...
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project
GitHub user mjsax opened a pull request:
https://github.com/apache/flink/pull/1483
[FLINK-1870] Reintroduce indexed reader functionality to streaming
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/mjsax/flink flink-1870-inputCha
18 matches
Mail list logo
