Navigation Menu

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.

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

CachedCodecLookup wrongly assumes uniqueness of hashCode() #511

Closed
mar-v-in opened this issue May 13, 2022 · 5 comments
Closed

CachedCodecLookup wrongly assumes uniqueness of hashCode() #511

mar-v-in opened this issue May 13, 2022 · 5 comments
Assignees
Labels
type: bug A general bug

Comments

@mar-v-in
Copy link

Bug Report

I got the following error on one of my machines repeatedly, when the same code worked fine on others:

class java.util.UUID cannot be cast to class java.net.InetAddress (java.util.UUID and java.net.InetAddress are in module java.base of loader 'bootstrap')
at io.r2dbc.postgresql.codec.InetAddressCodec.doEncode(InetAddressCodec.java:35)

It took me some time to debug this (also because running the JVM with debugger enabled would change the behavior), but I finally found the culprit.

It seems that it can happen that java.util.UUID.class.hashCode() == java.net.InetAddress.class.hashCode() and the CachedCodecLookup implementation does not handle that case. I don't know why this happens and would assume that the JVM makes best effort to not let this happen, but it does happen for me and for as far as I can tell, the JVM and Java documentation do not guarantee that it can't happen.

Versions

  • Driver: 0.8.11
  • Database: 13.5
  • Java: 11.0.15
  • OS: Linux 5.10
@mar-v-in mar-v-in added the status: waiting-for-triage An issue we've not yet triaged label May 13, 2022
@mp911de mp911de added type: bug A general bug and removed status: waiting-for-triage An issue we've not yet triaged labels May 16, 2022
@mp911de mp911de self-assigned this May 17, 2022
@mp911de mp911de added this to the 0.9.2.RELEASE milestone May 17, 2022
mp911de added a commit that referenced this issue May 17, 2022
Codecs are now cached using their value type for simple value/null encoding. Additionally, for decoding we check whether the cached codec can decode the desired format/data type/value type and fall back to the cache supplier if there was a hash collision.

[resolves #511]

Signed-off-by: Mark Paluch <mpaluch@vmware.com>
@mp911de
Copy link
Collaborator

mp911de commented May 17, 2022

That's fixed now. Care to restest against the latest snapshots?

@mar-v-in
Copy link
Author

Mind backporting this to 0.8.x? The codebase where I see this issue is using Spring Boot 2.6.x, making tests with r2dbc-postgresql 0.9.x unfeasible.

mp911de added a commit that referenced this issue May 18, 2022
Codecs are now cached using their value type for simple value/null encoding. Additionally, for decoding we check whether the cached codec can decode the desired format/data type/value type and fall back to the cache supplier if there was a hash collision.

[resolves #511]

Signed-off-by: Mark Paluch <mpaluch@vmware.com>
@mp911de
Copy link
Collaborator

mp911de commented May 18, 2022

That's backported to 0.8.x now.

@mp911de mp911de modified the milestones: 0.9.2.RELEASE, 0.8.13.RELEASE May 18, 2022
@mar-v-in
Copy link
Author

Thanks. Can confirm it works fine on the system where it failed before using 0.8.13.BUILD-SNAPSHOT.

@edeesis
Copy link

edeesis commented Oct 25, 2022

We ran into this on 0.9.1.RELEASE, and had trouble finding the issue in the search.

For those looking for a fix to ClassCastException when using r2dbc postgres, upgrading to 0.9.2.RELEASE fixed it for us.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: bug A general bug
Projects
None yet
Development

No branches or pull requests

3 participants