-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
Dynamodb - URL connection http client support #4471
Dynamodb - URL connection http client support #4471
Conversation
public class SyncHttpClientConfig { | ||
|
||
/** | ||
* Type of the sync HTTP client implementation |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You should mention the accepted values here (APACHE, URL)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added
public ApacheHttpClientConfig apacheHttp; | ||
|
||
@ConfigGroup | ||
public static class ApacheHttpClientConfig { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you don't use the APACHE client, how do you configure all these details? Proxy, TLS?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are no configuration options for URL connection other than socket timeout and connection timeout. But it's fine, as the lightweight url conn as sync client is fine for lambdas. For other app models like container talking to the dynamodb the apache sync client can be used that enables configurations for more connectivity aspects
d8973fc
to
85344c5
Compare
Just a heads up that I plan to review this one. |
* Type of the sync HTTP client implementation | ||
* | ||
* <p> | ||
* Accepted values are `URL` or `APACHE` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In fact, you shouldn't :). They will be automatically added to the documentation as it's an enum. So you can get rid of it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, I forgot about that :) Will fix.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suggested a few things. Open to discussion so don't hesitate to push back :).
* The maximum amount of time to establish a connection before timing out. | ||
* | ||
* <p> | ||
* Used by `URL` and `APACHE` clients |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I would drop all these (the last line of documentation).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will drop
* Apache HTTP client additional configuration | ||
*/ | ||
@ConfigItem(name = ConfigItem.PARENT) | ||
public ApacheHttpClientConfig apacheHttp; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wondering if it shouldn't be in an apache
group instead of added to the parent? This way, it's clear it's Apache specific and you don't need any additional documentation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it make sense. However, since I wanted to avoid duplications, the connectionTimeout & socketTimeout that are on the parent and apply to URL connection are also applies to Apache. Wondering if it worth to reflect that on the documentation somehow..
* The amount of time to wait when acquiring a connection from the pool before giving up and timing out. | ||
* | ||
* <p> | ||
* Used by `APACHE` client only |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Then you could drop this. I will tweak the documentation with some sections and it will be pretty much OK I think.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
will drop it
@@ -1,3 +1,4 @@ | |||
quarkus.dynamodb.sync-client.type = APACHE |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So for enums, the recommended way is to use lower case, dashed versions in the application.properties
. They will be automatically converted. Typically the documentation will contain apache
and url
so let's be consistent.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
will clean it up
<groupId>software.amazon.awssdk</groupId> | ||
<artifactId>url-connection-client</artifactId> | ||
<version>${awssdk.version}</version> | ||
</dependency> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What annoys me a bit is that you get all the dependencies with the extension. I wonder if it's a wise choice and we shouldn't be more careful about that especially in the lambda use case.
That being said, I'm not totally sure we can find a nice way to do that properly but IMHO it's worth a try.
If we can get to the point of the dependencies being optional and we can throw a warning or an error if something is configured for a "backend" and the correct dependencies are not in the classpath, that would be OK IMHO.
I don't think it's blocking for this PR tbh so I think we could merge this and see how we can improve things later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the idea and in fact tried it, check the latest commits. In general:
- I made client deps as optional
- the deployment processor checks if required service exists on the classpath, if not throws deploymentException
- the application should explicitly add required dependency to the classpath
Do you think it make sense ? Once you verify the idea, I'll update docs & quickstart
85344c5
to
5d68871
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please find the latest changes
@marcinczeczko looks good to me. Can you rebase, squash everything and work on the doc/quickstart update? I'll move that to 0.27.0 for now as I'm freezing the 0.26.0 code very soon. |
ff96848
to
a111da7
Compare
Thanks. I updated guide & quickstart (quarkusio/quarkus-quickstarts#328) |
a111da7
to
7212d70
Compare
7212d70
to
f1a34cd
Compare
I force-pushed a small change to fix a doc issue and rebased, I'll merge this one as soon as CI is green. |
CI failures is unrelated. |
Implementation for #4406