Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Fully Asynchronous ResultScanner #703

Closed
udoprog opened this issue Mar 2, 2016 · 4 comments
Closed

Fully Asynchronous ResultScanner #703

udoprog opened this issue Mar 2, 2016 · 4 comments
Assignees
@sduskis
Labels
api: bigtable Issues related to the googleapis/java-bigtable-hbase API.

Comments

@udoprog
Copy link
Contributor

udoprog commented Mar 2, 2016

Hey,

Currently ResultScanner does not provide the means of subscribing for when a new batch is available. This forces users to potentially block, or perform awkward polling on on ResultScanner#available() if they want to build a fully asynchronous scanner.

To patch the current API one could introduce ListenableFuture<Void> ResultScanner#fetchMoreRows() as a complement. This would allow users to implement something like this (example using Datastax).

As a more radical alternative the extended Observer pattern is a much better model of this behavior in my opinion.
@sduskis
Copy link
Contributor

sduskis commented Mar 3, 2016

gRPC has a concept of StreamObserver which we might be able to use: https://github.com/grpc/grpc-java/blob/master/stub/src/main/java/io/grpc/stub/StreamObserver.java

Would that work? It's already built into the infrastructure.

@udoprog
Copy link
Contributor Author

udoprog commented Mar 3, 2016

Yeah, definitely!
In fact, that is the extended Observer pattern :).

@sduskis sduskis mentioned this issue Mar 13, 2016
Closed
@sduskis sduskis mentioned this issue Mar 25, 2016
Merged
@sduskis
Copy link
Contributor

sduskis commented May 10, 2016

We've been doing work towards this goal. We still want to implement this feature.

@udoprog
Copy link
Contributor Author

udoprog commented May 12, 2016

Great to hear, thank you!

sduskis added a commit to sduskis/cloud-bigtable-client that referenced this issue Aug 7, 2016
@sduskis
Moving scan retry logic into a separate class.
f79a18d 
This will allow us to use the retry functionality in other scenarios, specifically observer based responses as described in googleapis#703.
@sduskis sduskis mentioned this issue Aug 7, 2016
Merged
sduskis added a commit to sduskis/cloud-bigtable-client that referenced this issue Aug 8, 2016
@sduskis
Moving scan retry logic into a separate class.
42f2108 
This will allow us to use the retry functionality in other scenarios, specifically observer based responses as described in googleapis#703.
sduskis added a commit to sduskis/cloud-bigtable-client that referenced this issue Aug 8, 2016
@sduskis
Moving scan retry logic into a separate class.
bc46ca5 
This will allow us to use the retry functionality in other scenarios, specifically observer based responses as described in googleapis#703.
sduskis added a commit that referenced this issue Aug 8, 2016
@sduskis
Moving scan retry logic into a separate class. (#949)
9b265ea 
This will allow us to use the retry functionality in other scenarios, specifically observer based responses as described in #703.
sduskis added a commit to sduskis/cloud-bigtable-client that referenced this issue Aug 10, 2016
@sduskis
Refactoring BigtableAsyncRpc
2076a5c 
The goal here is to move the read rows functionality into the same
listener model that all of the other RPCs use.  That will help with
metrics gathering and the "observer" read rows functionality described
in googleapis#703.
@sduskis sduskis mentioned this issue Aug 10, 2016
Merged
sduskis added a commit to sduskis/cloud-bigtable-client that referenced this issue Aug 10, 2016
@sduskis
Refactoring BigtableAsyncRpc
58980c2 
The goal here is to move the read rows functionality into the same
listener model that all of the other RPCs use.  That will help with
metrics gathering and the "observer" read rows functionality described
in googleapis#703.
sduskis added a commit that referenced this issue Aug 11, 2016
@sduskis
Refactoring BigtableAsyncRpc (#959)
36f7173 
The goal here is to move the read rows functionality into the same
listener model that all of the other RPCs use.  That will help with
metrics gathering and the "observer" read rows functionality described
in #703.
@udoprog udoprog mentioned this issue Oct 12, 2016
Closed
sduskis added a commit to sduskis/cloud-bigtable-client that referenced this issue Dec 19, 2016
@sduskis
Moving Status based retries out of ResumingStreamingResultScanner
edd3f0b 
The AbstractRetryingRpcListener already has handling for handling rpc level retries, and using that method reduces code and allows some interesting changes such as googleapis#703.
@sduskis sduskis mentioned this issue Dec 19, 2016
Closed
@udoprog udoprog mentioned this issue Dec 27, 2016
Closed
@sduskis sduskis closed this as completed Jan 16, 2017
@google-cloud-label-sync google-cloud-label-sync bot added the api: bigtable Issues related to the googleapis/java-bigtable-hbase API. label Jan 31, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@sduskis sduskis

Labels
api: bigtable Issues related to the googleapis/java-bigtable-hbase API.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@sduskis @udoprog