-
Notifications
You must be signed in to change notification settings - Fork 3.3k
HBASE-29325 Gson reflection failures on TestBucketCache.testCacheSimple #6999
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
base: master
Are you sure you want to change the base?
Conversation
Change-Id: I2a2365df7c72d3f9f26175d43904375888742eb8
The PR that has added this patch seems to expect that transient is excluded by default, as it added transient to several members. TBH I'm not sure what we use the JSON serialization for. Is that only for logging/debugging ? |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
I think transient was added as an attempt to get those fields ignored? But for some reason, GSON doesn't ignore it unless explicitly told to. |
+1 with stoty, is this more like a test problem or an actual problem in main code? |
I have seen this manifesting on tests using specific JDK 17 implementations ("Java HotSpot(TM) 64-Bit Server VM (build 17.0.8+9-LTS-211)" and "OpenJDK Runtime Environment (build 17.0.15+6-Ubuntu-0ubuntu124.04)"). Apparently, "Eclipse Adoptium-17.0.11+9" works just fine, as we don't seen this in neither the precommits nor in nightly builds. I guess this error would blow up in any part of the code that tries to convert internal objects to json. I think this is mainly used on the UIs and logging. |
@@ -43,6 +44,8 @@ private GsonUtil() { | |||
*/ | |||
public static GsonBuilder createGson() { | |||
return new GsonBuilder().setLongSerializationPolicy(LongSerializationPolicy.STRING) | |||
.excludeFieldsWithModifiers(Modifier.TRANSIENT).excludeFieldsWithModifiers(Modifier.STATIC) |
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.
Do we need to exclude static and private 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.
I think STATIC and TRANSIENT are default exclusions, so if we are explicitly adding TRANSIENT, we may have to do STATIC as well.
Do we need to do for PRIVATE?
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.
Do we need to exclude static and private too?
We need only private, actually. I'm updating the PR accordingly.
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.
Ah, I see it now. You're right.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Change-Id: Ic7cf980db55c5ac7b6551f7eab44cf04fb7f51d2
Change-Id: Id67614680b8bc1df1fdb4e6aa2cb63c9798ded9e
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.
+1 LGTM
The JSON serialization (at least BlockCacheUtil.toJSON) is only used for logging from tests.
We do not want to serialize private fields? Really? I think most POJOs are private fields with getter and setter? |
The JSON serialization is used in a single test in debug log output. If/when this will be needed again, the person doing the dbugging can figure out which fields they need and fix the JSON serialization. |
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.
LGTM
🎊 +1 overall
This message was automatically generated. |
🎊 +1 overall
This message was automatically generated. |
No it's not, we just got another ticket that demonstrates that it's also called by the UI from JSP. |
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.
GSONUtil is also used from other classes.
I misclicked when checking for references.
Yes, using GSON to serializalize BucketCache is a clusterfuck. We need to check if if / how much if it the UI needs, and find some solution. |
Yes, it's completely bonkers. I totally agree that we should just remove all code that tries to use Gson to serialize complext multigigabyte in-memory cache objects with reflection. TBH Gson itself looks like a spectaculrarly bad fit with modular JAva, and real objects. |
We're calling GsonUtil from rits.jsp , but luckily that's creating a simple map for the values needed on the UI, and not doing anything stupid like trying to serialize BucketCache. |
There seems to be an option where we serialize the entire cache in the UI: https://github.com/apache/hbase/pull/7047/files#diff-a0cc60aec48986f0ec2377528ab6c26f248c246267b57145a1bd3ab9c7e42d07R60 |
You're right, we're doing that. |
No description provided.