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

[Upgrade to Fury 0.5] class org.apache.fury.serializer.UnexistedClassSerializers$UnexistedSkipClass cannot be cast to class #1600

Open
1 of 2 tasks
cdxf opened this issue May 4, 2024 · 1 comment
Labels
bug Something isn't working

Comments

@cdxf
Copy link

cdxf commented May 4, 2024

Search before asking

  • I had searched in the issues and found no similar issues.

Version

0.5.0

Component(s)

Java

Minimal reproduce step

I have the following code:

//Fury Configuration
    public static ThreadSafeFury fury = new ThreadLocalFury(classLoader -> {
        Fury f = Fury.builder()
                .requireClassRegistration(false)
                .withRefTracking(true)
                .withAsyncCompilation(true)
                .withCompatibleMode(CompatibleMode.SCHEMA_CONSISTENT)
                .withJdkClassSerializableCheck(false)
                .withLanguage(Language.JAVA).withClassLoader(classLoader).build();
        f.register(CircularFifoQueue.class);

// Function 
public T get(String key) {
            try {
                return (T) fury.deserialize(bytes);
            } catch (Exception ex) {
                logger.error("Error deserializing object", ex);
                return null;
            }
}
... later

        Queue<Long> result = get(...);

What did you expect to see?

Fury should throw Exception (which is what I am expecting when upgrading to new version and Fury failed to deserialize the byte[] from the old version) instead of silently deserialize the bytes into UnexistedClassSerializers$UnexistedSkipClass

What did you see instead?

It works fine in Fury 0.4.1, but since I upgraded to 0.5.0, my app throws the following errors:

java.lang.ClassCastException: class org.apache.fury.serializer.UnexistedClassSerializers$UnexistedSkipClass cannot be cast to class java.util.Queue (org.apache.fury.serializer.UnexistedClassSerializers$UnexistedSkipClass is in unnamed module of loader org.springframework.boot.loader.launch.LaunchedClassLoader @1d56ce6a; java.util.Queue is in module java.base of loader 'bootstrap')

Anything Else?

If it is expected behavior, where should I look at in the documentation.
What should I do instead? Is there any configuration I can change to make it throw Exception instead of returning UnexistedSkipClass

Are you willing to submit a PR?

  • I'm willing to submit a PR!
@cdxf cdxf added the bug Something isn't working label May 4, 2024
@chaokunyang
Copy link
Collaborator

chaokunyang commented May 5, 2024

Hi @cdxf , thanks for reporting this issue. It seems that you use newer version of Fury to deserialize data from old version Fury. Fury read a class id for UnexistedSkipClass, so it throw such exception.

Fury registered UnexistedSkipClass


This registered class id may be used by other class in older Fury, it's possible to read it as UnexistedSkipClass, which is the error you see. I can submit a PR to skip register UnexistedSkipClass, but if you use newer Fury to deserialize older Fury, you will still see other strange error. Currently we didn' provide binary compatibility. Such compatibility will be provided in the future, but not now. Could you try https://fury.apache.org/docs/guide/java_object_graph_guide#upgrade-fury to upgrade Fury?

LiangliangSui pushed a commit that referenced this issue May 5, 2024
## What does this PR do?

skip register unexisted skip class if `deserializeUnexistedClass` not
enabled

## Related issues
#1600 

## Does this PR introduce any user-facing change?

<!--
If any user-facing interface changes, please [open an
issue](https://github.com/apache/incubator-fury/issues/new/choose)
describing the need to do so and update the document if necessary.
-->

- [ ] Does this PR introduce any public API change?
- [ ] Does this PR introduce any binary protocol compatibility change?


## Benchmark

<!--
When the PR has an impact on performance (if you don't know whether the
PR will have an impact on performance, you can submit the PR first, and
if it will have impact on performance, the code reviewer will explain
it), be sure to attach a benchmark data here.
-->
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants