Github user mjsax commented on a diff in the pull request:

    https://github.com/apache/flink/pull/1398#discussion_r45742093
  
    --- Diff: 
flink-contrib/flink-storm/src/test/java/org/apache/flink/storm/wrappers/WrapperSetupHelperTest.java
 ---
    @@ -180,8 +178,6 @@ public void testCreateTopologyContext() {
                builder.setBolt("bolt2", (IRichBolt) operators.get("bolt2"), 
dops.get("bolt2")).allGrouping("spout2");
                builder.setBolt("sink", (IRichBolt) operators.get("sink"), 
dops.get("sink"))
                                .shuffleGrouping("bolt1", 
TestDummyBolt.groupingStreamId)
    -                           .shuffleGrouping("bolt1", 
TestDummyBolt.shuffleStreamId)
    -                           .shuffleGrouping("bolt2", 
TestDummyBolt.groupingStreamId)
                                .shuffleGrouping("bolt2", 
TestDummyBolt.shuffleStreamId);
    --- End diff --
    
    Well. From a Storm point of view, there is only `union`. As it is the 
generic Storm case it includes the join case. I guess you specialized join 
solution would be obsolete after generic union is supported. Therefore, I would 
prefer to get it right from the beginning on... My idea would be to try to get 
rid of `TwoInputBoltWrapper` and "union" the incoming streams somehow to feed a 
single stream to `BoltWrapper`. The tricky part is, that we cannot use Flink's 
`union` because it assume the same input type, but Storm can union different 
types into one stream... What do you think about this idea? 


---
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 enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Reply via email to