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

    https://github.com/apache/spark/pull/2940#discussion_r19507955
  
    --- Diff: 
streaming/src/main/scala/org/apache/spark/streaming/receiver/ReceiverSupervisorImpl.scala
 ---
    @@ -134,17 +137,32 @@ private[streaming] class ReceiverSupervisorImpl(
           optionalMetadata: Option[Any],
           optionalBlockId: Option[StreamBlockId]
         ) {
    +    pushAndReportBlock(ByteBufferBlock(bytes), optionalMetadata, 
optionalBlockId)
    +  }
    +
    +  /** Store block and report it to driver */
    +  def pushAndReportBlock(
    +      receivedBlock: ReceivedBlock,
    +      optionalMetadata: Option[Any],
    +      optionalBlockId: Option[StreamBlockId]
    +    ) {
         val blockId = optionalBlockId.getOrElse(nextBlockId)
    +    val numRecords = receivedBlock match {
    +      case ArrayBufferBlock(arrayBuffer) => arrayBuffer.size
    +      case _ => -1
    +    }
    +
         val time = System.currentTimeMillis
    -    blockManager.putBytes(blockId, bytes, storageLevel, tellMaster = true)
    -    logDebug("Pushed block " + blockId + " in " + 
(System.currentTimeMillis - time)  + " ms")
    -    reportPushedBlock(blockId, -1, optionalMetadata)
    -  }
    +    val fileSegmentOption = receivedBlockHandler.storeBlock(blockId, 
receivedBlock) match {
    --- End diff --
    
    Personally, I specify Option in the variable name, because it because it 
make it easier to read code like `somethingOption.getOrElse`.  Otherwise, if I 
see `something.getOrElse` I have to track back and see whether `something` is a 
HashMap or Option. And errors like not calling `get` or `getOrElse` when the 
actual value is necessary become more immediately clear.
    
    Again, this is a not a very strong logic, just a personal preference of 
mine.
    
    Regarding consistent naming, if that code is within the scope of the lines 
that I touch in the PR, I will fix it.


---
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 [email protected] or file a JIRA ticket
with INFRA.
---

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to