[jira] [Commented] (STORM-1961) Come up with streams api for storm core use cases

2016-10-19 Thread Jungtaek Lim (JIRA)

[ 
https://issues.apache.org/jira/browse/STORM-1961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15590719#comment-15590719
 ] 

Jungtaek Lim commented on STORM-1961:
-

I've left some comments on google doc, but looks great overall. Nice work!
I'll dive into the pull request.

> Come up with streams api for storm core use cases
> -
>
> Key: STORM-1961
> URL: https://issues.apache.org/jira/browse/STORM-1961
> Project: Apache Storm
>  Issue Type: Sub-task
>Reporter: Arun Mahadevan
>Assignee: Arun Mahadevan
> Attachments: UnifiedStreamapiforStorm.pdf, 
> UnifiedStreamapiforStorm_v2.pdf
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (STORM-1961) Come up with streams api for storm core use cases

2016-10-18 Thread Boyang Jerry Peng (JIRA)

[ 
https://issues.apache.org/jira/browse/STORM-1961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15586697#comment-15586697
 ] 

Boyang Jerry Peng commented on STORM-1961:
--

This new API is what storm needs!  Quick question: how is state handled for 
some of the operations?  More specifically is there any fault tolerance built 
in for stateful operators?

> Come up with streams api for storm core use cases
> -
>
> Key: STORM-1961
> URL: https://issues.apache.org/jira/browse/STORM-1961
> Project: Apache Storm
>  Issue Type: Sub-task
>Reporter: Arun Mahadevan
>Assignee: Arun Mahadevan
> Attachments: UnifiedStreamapiforStorm.pdf
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (STORM-1961) Come up with streams api for storm core use cases

2016-09-22 Thread Roshan Naik (JIRA)

[ 
https://issues.apache.org/jira/browse/STORM-1961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15515234#comment-15515234
 ] 

Roshan Naik commented on STORM-1961:


# Strong typing in the APIs is really great!
# Would be good to do away with StreamBuilder and write it more directly and 
concisely :
{quote}
   Stream x  = new Stream(...).flatmap().blah()
{quote}
# Can we avoid the build() call there 
{quote}
StormSubmitter.submitTopologyWithProgressBar("test", new Config(), 
builder.build());
{quote}
and simplify it to
{quote}
StormSubmitter.submitTopologyWithProgressBar("test", new Config(), stream );
{quote}
and have the build() or whatever else needs to happen, get invoked internally 
within submitTopology ?
# Good to have overloaded version taking arrays in flatMap(T[] ) and elsewhere 
to natively support arrays... so that conversion via Arrays.asList is  not 
needed.
# The doc Needs to have a more concrete definition for Stream concept.  
#* Is it just the data stream produced by the first operator/spout ? or is it 
the  whole pipeline of operators ? 
#* is if different from what we call 'topology' in storm ?  When you say ... 
Stream  .. what is T ? Is the type of value produced by the terminal 
operator ? or that of the first ? #*What if there is a branch/split and each 
terminal operator creates different types ? 
#* Can a stream pick up data from two different sources ? for example from 
kafka and hdfs.
# The diagram in the doc shows fields and shuffle groupings. Not clear from the 
examples as to who the various gropings will be supported in the API. 
# Would like to see API examples in doc as how to the grouping and parallelism 
hints will be expressed in code.
# Would this API provide a mechanism to use the existing set of Storm spouts 
and terminal bolts (like KafkaSpout, HdfsSpout, HbaseBolt, etc) ? Or do we need 
to have new implementations ?

> Come up with streams api for storm core use cases
> -
>
> Key: STORM-1961
> URL: https://issues.apache.org/jira/browse/STORM-1961
> Project: Apache Storm
>  Issue Type: Sub-task
>Reporter: Arun Mahadevan
>Assignee: Arun Mahadevan
> Attachments: UnifiedStreamapiforStorm.pdf
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)