-
Notifications
You must be signed in to change notification settings - Fork 15
chore: Upgrade deps #103
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
chore: Upgrade deps #103
Conversation
Ran into following exception in
Trying to see if upgrading deps could help (which anyways need upgrade) |
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 expect it to fix it. That error reads to me like we're running grpc 1.40 (which we are) over an older grpc-netty (which we were).
// Config | ||
implementation("com.typesafe:config:1.4.1") | ||
// Logging | ||
implementation("org.slf4j:slf4j-api:1.7.30") | ||
runtimeOnly("org.apache.logging.log4j:log4j-slf4j-impl:2.14.1") | ||
|
||
// GRPC | ||
runtimeOnly("io.grpc:grpc-netty:1.36.1") | ||
runtimeOnly("io.grpc:grpc-netty:1.40.0") |
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.
that said, I would have expected this to show up in the docker compose flavor too.
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.
yeah, so not having high hopes from this change, but wanted to give it a try.
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.
For me, with the existing hypertrace-service image, docker-compose is running fine.
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 should still work - I just noticed you said that it was happening in data query service, not in hypertrace service. Because the wrapper services are pulling in all the containers (a mistake, IMO), of the services they're depending on, I suspect that the individual services going into data query are not bringing in grpc-netty 1.40, but one of the ones coming in here is.
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 suspect that the individual services going into data query are not bringing in grpc-netty 1.40
Yeah, this turned out to be the reason. grpc-netty 1.39 was being used.
Because the wrapper services are pulling in all the containers (a mistake, IMO)
The container dependency would be automatically pulled in with other dependencies?
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.
we're bringing our own container and stuffing a number of impls in it. So we should be depending on
something like implementation("org.hypertrace.config.service:config-service-impl")
only rather than implementation("org.hypertrace.config.service:config-service")
- right now we depend on both (not sure if the code is currently written in such a way to require that, or this can be an easy fix).
The downside to doing is what we just saw - we're getting container runtime dependencies like jetty, grpc-netty etc. from each child service, throwing them into a big pile and then doing conflict resolution across all of them - makes it easy to lead to mismatches.
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.
not sure if the code is currently written in such a way to require that, or this can be an easy fix
Filed #104, will check
No description provided.