-
Notifications
You must be signed in to change notification settings - Fork 3.4k
HBASE-27657: Connection and Request Attributes #5326
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.
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
Changes from 8 commits
a2d67c3
441ae90
33481e1
beef1fb
c3dde33
d5e092d
ee3eef8
0b23de4
99169a2
2be8a9f
e68afb6
fe17ca3
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -19,6 +19,7 @@ | |
|
|
||
| import static org.apache.hadoop.hbase.client.ConnectionUtils.retries2Attempts; | ||
|
|
||
| import java.util.Map; | ||
| import java.util.concurrent.TimeUnit; | ||
| import org.apache.hadoop.hbase.HBaseServerException; | ||
| import org.apache.yetus.audience.InterfaceAudience; | ||
|
|
@@ -137,6 +138,11 @@ default AsyncTableBuilder<C> setMaxRetries(int maxRetries) { | |
| */ | ||
| AsyncTableBuilder<C> setStartLogErrorsCnt(int startLogErrorsCnt); | ||
|
|
||
| /** | ||
| * Sets the map of request attributes | ||
| */ | ||
| AsyncTableBuilder<C> setRequestAttributes(Map<String, byte[]> requestAttributes); | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What do you think about
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We prob could leave all the *Caller classes as you have them since they are internal and post-build, but for the TableBuilder/AsyncTableBuilder it might be nice.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah I'd be happy to add that. Just to clarify, we should probably support both, right? And calling setRA after addRA would implicitly overwrite the individual additions?
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't have a strong opinion on whether we should continue to support If we do support both, then yea we need to figure out the interplay. I agree that calling set after add would overwrite, but what about add after set? One could imagine someone calling set with an immutable map, so we'd probably have to copy it in order to ensure add operations work.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Yeah that's a good point.
I don't feel particularly strongly, but it seems plausible that someone will have a map of requests pre-constructed, particularly if they have several attributes to pass, and that it would be nicer to pass it in than need to iterate calls to addRA
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If we provide a
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Just pushed a change which allows for the two methods
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. it may be worth simplifying this to all just be additive. I was thinking about it and this is just a temporary builder. To one of your earlier comments, I don't think we need to support removal of attributes and here it's hard to imagine the case for someone to do something like: getTableBuilder(table)
.setRequestAttribute("foo", "bar")
.setRequestAttribute("abc", "def")
.setRequestAttributes(Map.of("foo", "asdfa")) // actually forget those, i want to just use this
.build()I could see needing to support replacement/removal/etc if we allowed modifying the longer-lived Table objects. I know some builders out there have like a BuiltObject.toBuilder() method, in which case maybe it'd be good to support these things for evolving Tables over time. But our builders are pretty simple and one-off, so not necessary. So trying to think about KISS here, and to me that means simply additive. I could even imagine changing the plural method to be named One other note -- many people will not use request attributes. Let's default the
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Also, I think you need to update the ThriftConnection to override the new method.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 👍 good points, I'll update this morning |
||
|
|
||
| /** | ||
| * Create the {@link AsyncTable} instance. | ||
| */ | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.