src/jvm/backtype/storm/drpc/CoordinatedBolt.java:57:1:Wrapper around OutputCollector that tracks where emitted tuples are sent
src/jvm/backtype/storm/drpc/CoordinatedBolt.java:98:1:Called when tuples are emitted, for each task that an emitted tuple is sent to increment the number of tuples "in play" for this request
src/jvm/backtype/storm/drpc/CoordinatedBolt.java:75:1:increment the number of received tuples for this request on ack or fail
src/jvm/backtype/storm/drpc/CoordinatedBolt.java:113:1:a map from request_id to TrackingInfo, TimeCacheMap is useful because tracking info is null and void if the request times out
src/jvm/backtype/storm/drpc/CoordinatedBolt.java:118:1:total number of tuples that have been acked or failed for this request
src/jvm/backtype/storm/drpc/CoordinatedBolt.java:119:1:map from task_id to number of tuples that have been emitted to it
src/jvm/backtype/storm/drpc/CoordinatedBolt.java:136:1:delegates all actions to the bolt it wraps
src/jvm/backtype/storm/drpc/CoordinatedBolt.java:146:1:all the component_ids that are subscribed to the COORDINATED_STREAM_ID
src/jvm/backtype/storm/drpc/CoordinatedBolt.java:151:1:assembles the list of all task_ids that are subscribed to the COORDINATED_STREAM_ID stream across all components from this bolt
src/jvm/backtype/storm/drpc/CoordinatedBolt.java:172:1:tracking info for this request
src/jvm/backtype/storm/drpc/CoordinatedBolt.java:179:1:If the delegate implements FinishedCallback, call its finishedId method
src/jvm/backtype/storm/drpc/CoordinatedBolt.java:183:1:for each task subscribed in a coordinated way, send it the count of tuples this bolt has emitted for this request to it
src/jvm/backtype/storm/drpc/CoordinatedBolt.java:188:1:for this bolt, it has received all the tuples it will receive on this request, it is finished, and there is no reason to keep tracking this request
src/jvm/backtype/storm/drpc/CoordinatedBolt.java:197:1:If we haven't seen any tuples for this request and are therefore not tracking it yet, set up a new tracking info for it
src/jvm/backtype/storm/drpc/CoordinatedBolt.java:206:1:if this is a book keeping tuple, it should not be handled by the delegate but it should change the tracking state
src/jvm/backtype/storm/drpc/CoordinatedBolt.java:224:1:not a book keeping tuple, send on to the delegate
src/jvm/backtype/storm/drpc/CoordinatedBolt.java:237:1:in addition to all the streams/fields the delegate might have, we need a direct stream (COORDINATED_STREAM_ID) to send counts of tuples for a request id to downstream tasks
src/jvm/backtype/storm/drpc/LinearDRPCTopologyBuilder.java:26:1:topology is linear so this is just the list of component steps
src/jvm/backtype/storm/drpc/LinearDRPCTopologyBuilder.java:33:1:just add bolt to the list of steps, will be added to the real topology builder when told to createTopology
src/jvm/backtype/storm/drpc/LinearDRPCTopologyBuilder.java:51:1:helper around the case where we have a LocalDRPC object for our local cluster
src/jvm/backtype/storm/drpc/LinearDRPCTopologyBuilder.java:60:1:creates the actual topology using a topology builder
src/jvm/backtype/storm/drpc/LinearDRPCTopologyBuilder.java:65:1:our spout is set to the DRPCSpout that was passed in
src/jvm/backtype/storm/drpc/LinearDRPCTopologyBuilder.java:66:1:All DRPC requests first pass through PrepareRequest, which generates the request id
src/jvm/backtype/storm/drpc/LinearDRPCTopologyBuilder.java:74:2:if this is the first step, it has no source
src/jvm/backtype/storm/drpc/LinearDRPCTopologyBuilder.java:76:1:If this is the second step it has one source
src/jvm/backtype/storm/drpc/LinearDRPCTopologyBuilder.java:78:1:Otherwise, it has all sources which causes CoordinatedBolt's _numSourceReports to be calculated differently
src/jvm/backtype/storm/drpc/CoordinatedBolt.java:155:1:if there is a single source, the _numSourceReports is 1
src/jvm/backtype/storm/drpc/CoordinatedBolt.java:159:29:otherwise we're going off of the number of component tasks from the previous step
src/jvm/backtype/storm/drpc/CoordinatedBolt.java:161:29:Pretty sure this makes sure that the final step in the topology ignores the tuples coming off of the ID_STREAM of PrepareRequest
src/jvm/backtype/storm/drpc/LinearDRPCTopologyBuilder.java:81:1:if this is the final step and it implements finished callback, it will expect to receive a stream of ids from PrepareRequest
src/jvm/backtype/storm/drpc/LinearDRPCTopologyBuilder.java:84:1:all bolts in the topology need to be wrapped by CoordinatedBolt
src/jvm/backtype/storm/drpc/LinearDRPCTopologyBuilder.java:88:1:If this is the final step and it is a FinishedCallback and expects ids from PrepareRequest, it needs to be hooked up with the ID_STREAM from PrepareRequest
src/jvm/backtype/storm/drpc/LinearDRPCTopologyBuilder.java:91:1:if this is the first step, it needs to be hooked up to the arguments that were sent with the DRPC request and then separated out by PrepareRequest
src/jvm/backtype/storm/drpc/LinearDRPCTopologyBuilder.java:93:1:otherwise, find the previous step (or PrepareRequest if this is the first) and apply the groupings that were declared on the step so that output from the previous step goes over those groupings to this step
src/jvm/backtype/storm/drpc/LinearDRPCTopologyBuilder.java:104:1:if this is not the first step, it needs to receive the count of tuples for a request id over the COORDINATED_STREAM_ID
src/jvm/backtype/storm/drpc/LinearDRPCTopologyBuilder.java:109:1:the last bolt gets special treatment
src/jvm/backtype/storm/drpc/LinearDRPCTopologyBuilder.java:113:1:Linear DRPC topologies require that the final bolt only has one output stream
src/jvm/backtype/storm/drpc/LinearDRPCTopologyBuilder.java:118:1:it is also important that the only fields from the last bolt be a request_id and the result (which is going to get brutally cast to a string)
src/jvm/backtype/storm/drpc/LinearDRPCTopologyBuilder.java:122:1:after the final step, you need to join the result for the request to the return info. JoinResult groups on request id and subscribes to the output from the last step as well as the return info stream from PrepareRequest
src/jvm/backtype/storm/drpc/LinearDRPCTopologyBuilder.java:126:1:the ReturnResults bolt simply sends the result to the client that is reachable from the return_info. This is when your DRPC client will receive the result of the computation
src/jvm/backtype/storm/drpc/LinearDRPCTopologyBuilder.java:128:1:and we're done, notice how this is just a normal storm topology built on top of standard primitives with a significant amount of cleverness in the bolt implementation
src/jvm/backtype/storm/drpc/CoordinatedBolt.java:206:1:if this is the final step and this tuple is coming from PrepareRequest over its ID_STREAM
src/jvm/backtype/storm/drpc/CoordinatedBolt.java:209:1:we can say that we have received the request id and we should check if it is finished
src/jvm/backtype/storm/drpc/CoordinatedBolt.java:214:1:if this is a message from the upstream task over the COORDINATED_STREAM then we should expect another 'count' tuples and also rest assured that task is done and has reported in
src/jvm/backtype/storm/drpc/CoordinatedBolt.java:221:1:and we should of course also check if this thing is finished
src/jvm/backtype/storm/drpc/CoordinatedBolt.java:200:1:if we are not supposed to receive a stream of ids from PrepareRequest, then we can act as though we already received the id (which of course we never will)
src/jvm/backtype/storm/drpc/CoordinatedBolt.java:173:1:this is obviously not finished if we weren't even tracking it
src/jvm/backtype/storm/drpc/CoordinatedBolt.java:174:1:if this is the last step we need to have received the request id from PrepareRequest before this can be considered complete
src/jvm/backtype/storm/drpc/CoordinatedBolt.java:175:1:if we don't have a source, we're complete now
src/jvm/backtype/storm/drpc/CoordinatedBolt.java:177:1:if we do have a source, we need to make sure that all of our upstream tasks have reported in
src/jvm/backtype/storm/drpc/CoordinatedBolt.java:178:1:and that the number of tuples we were told to expect by our upstream tasks matches the number of tuples we, in fact, received