ulysses-you opened a new pull request, #58466:
URL: https://github.com/apache/spark/pull/58466

   ### What changes were proposed in this pull request?
   
     Make `RocksDB.get` and `LevelDB.get` return `null` instead of throwing 
`NoSuchElementException` when a key is absent, and let the callers decide 
whether a missing key is an error:
   
     - `read` still throws `NoSuchElementException` for a missing key, 
preserving the `KVStore` contract.
     - `getMetadata`, the constructor, `updateBatch`, and the secondary-index 
iterator path handle the `null` directly instead of catching an exception.
   
     ### Why are the changes needed?
   
     `updateBatch` looks up the existing value via `get` before writing. During 
an event-log rebuild most writes are **new** entries, so the key is absent and 
`get` throws
     `NoSuchElementException` on essentially every write. That exception is 
immediately caught, but constructing it still fills in a full stack trace — 
using exceptions for ordinary control
     flow. In a History Server CPU profile this showed up as a measurable share 
of CPU spent in `Throwable.fillInStackTrace` under `RocksDB.get`. Returning 
`null` avoids building the exception
     entirely.
   
     ### Does this PR introduce any user-facing change?
   
     No. The public `KVStore` behavior is unchanged: `read` still throws 
`NoSuchElementException` for a missing key, and `getMetadata` still returns 
`null` when no metadata is present.
   
     ### How was this patch tested?
   
     Added `testGetMissingKeyReturnsNull` to both `RocksDBSuite` and 
`LevelDBSuite`, verifying that `get` returns `null` for a missing key and 
returns the stored value for a present key.
     Existing kvstore test suites pass.
   
   ### Was this patch authored or co-authored using generative AI tooling?
   
   Yes. Generated-by: Claude Code.
   
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


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

Reply via email to