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

[Java] Custom Serializer for fields #1806

Open
miladamery opened this issue Aug 16, 2024 · 4 comments
Open

[Java] Custom Serializer for fields #1806

miladamery opened this issue Aug 16, 2024 · 4 comments
Labels
enhancement New feature or request

Comments

@miladamery
Copy link

miladamery commented Aug 16, 2024

Hi. When using Akka toolkit you need to serialize objects for persistence and clustering. Akka gives you the option for providing
your own serializer. The problem is, in akka you have something called ActorRef. this class is used for replying to actors that send commands. but this ActorRef serialization/deserialization is special in Akka. Here describes how you can serizlize/deserialize ActorRef.
Fury provides custom serializers for whole class according to here.
Here is my implementation for serializing ActorRef (I appreciate it if some one can say if this is correct)

import akka.actor.typed.ActorRef;
import akka.actor.typed.ActorRefResolver;
import org.apache.fury.Fury;
import org.apache.fury.memory.MemoryBuffer;
import org.apache.fury.serializer.Serializer;

public class FuryActorRefSerializer extends Serializer<ActorRef> {

    private final ActorRefResolver actorRefResolver;

    public FuryActorRefSerializer(Fury fury, ActorRefResolver actorRefResolver) {
        super(fury, ActorRef.class);
        this.actorRefResolver = actorRefResolver;
    }

    @Override
    public void write(MemoryBuffer buffer, ActorRef value) {
       // toSerializationFormat returns String
        var serialized = actorRefResolver.toSerializationFormat(value).getBytes();
        buffer.writeInt32(serialized.length);
        buffer.writeBytes(serialized);
    }

    @Override
    public ActorRef read(MemoryBuffer buffer) {
        var length = buffer.readInt32();
        var ref = buffer.readBytes(length);
        return actorRefResolver.resolveActorRef(new String(ref));
    }
}

but this ActorRef discussed earlier is usually used as a field in commands(which are Java Records) not as a standalone class.
Because creating a custom serializer for each Record of my project is not logical Is there a way that Fury support this?
I mean writing a serializer like above and fury understands class field it is serializing and
use appropriate serializer for that field?

@miladamery miladamery added the enhancement New feature or request label Aug 16, 2024
@chaokunyang
Copy link
Collaborator

Hi @miladamery , you are right. If you register a serializer for a type, the serialization for fields of this type will use this serializer too

@miladamery
Copy link
Author

miladamery commented Aug 18, 2024

@chaokunyang
Thanks for your reply, i really appreciate it.
The serializer mentioned in issue didn't work so I though problem is that fury doesn't respect custom serializers for fields which was wrong. By debugging I found what the problem was.
ActorRef is an interface not the implementation, on serializing/deserializing fury was checking the actual implementation type which was ActorRefAdapter and was choosing the general serializer for ActorRefAdapter not the custom one provided. So i changed FuryActorRefSerializer type from ActorRef to ActorRefAdapter and everything works now.
But my question is shouldn't fury pick the custom serializer for interface and its implementations?

@chaokunyang
Copy link
Collaborator

Hi @miladamery , Fury should pick customized serializer for interface. It should get serializer for concrete type first. If It doesn't exist, it should pick serializer for its inferface. Would you like to contribute this feature?

@miladamery
Copy link
Author

@chaokunyang
Hi, I will try to see if i can do it

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants