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

NotSerializableException when trying to serialize Registration object #647

Closed
krisdx opened this issue Feb 1, 2019 · 10 comments
Closed
Labels
question Any question about leshan

Comments

@krisdx
Copy link

krisdx commented Feb 1, 2019

Hello, I'm doing some basic tests, trying to see ways to recover Registrations, after a server restart/failover, and when trying to write the Registration object to a file, I get:

java.io.NotSerializableException: org.eclipse.leshan.core.request.Identity

So can you tell me what I need to do, in order to Java serialize a Registration object?

@sbernard31 sbernard31 added the question Any question about leshan label Feb 1, 2019
@sbernard31
Copy link
Contributor

sbernard31 commented Feb 1, 2019

To handle "server restart/failover" by persisting registrations in a file, you need to implements your own CaliforniumRegistrationStore.

It could be a bit tricky but you could inspired yourself by looking at InMemoryRegistrationStore and RedisRegistrationStore

RedisRegistrationStore persists Registration in Redis, it uses RegistrationSerDes to serialize/deserialize Registration in JSON. Both classes could be reused.

About java.io.NotSerializableException, that means Identity is not serializable.
We don't use Java serialization anymore (I believe we used it a bit at the begin for testing/demo) that's why you can see Registration implements Serializable interface.

Java serialization is often considered as not well adapted for production use cases.
Frequent reasons exposed :

  • this is slow (Personally I never test it and I don't know if our JSON serialization is faster)
  • bytes serialization is not easy for debug.
  • data migration after a schema modification (adding removing attributes) is hard to handle.
    You could probably found more resources about that searching on the web.

Anyway, if you feel that java serialization is adapted to your use case, I'm not really against trying to make it work in Leshan and to be honest currently the is not really clean to have Registration which implement Serializable with attributes which does not.

Did you try to just make Identity implements Serializable ?

@krisdx
Copy link
Author

krisdx commented Feb 1, 2019

I wasn't aware that you don't use Java serialization. So I'll either have to provide my own serialization/deserialization logic, or reuse RegistrationSerDes, witch I also wasn't aware of.
Ok, Thanks.

@sbernard31
Copy link
Contributor

I will probably make Identity serializable so if someone want to use java serialization it will be able to do it.

@sbernard31
Copy link
Contributor

sbernard31 commented Feb 5, 2019

I created a PR to make Registration serializable again : #649

@krisdx
Copy link
Author

krisdx commented Feb 11, 2019

If you're going to support Java serialization, you should also think about making org.eclipse.leshan.core.observation.Observation and org.eclipse.californium.core.observe.Observation serializable, because they're all needed for the implementation of CaliforniumRegistrationStore.

@sbernard31
Copy link
Contributor

@krisdx Good point ! I totally missed this part ...

Making org.eclipse.leshan.core.observation.Observation "serializable" is not really so hard but also not really useful as it is generally built from org.eclipse.californium.core.observe.Observation
(see InMemoryRegistrationStore)

But making org.eclipse.californium.core.observe.Observation "serializable" is another story ...
Maybe we should reconsider my first idea to make it possible to use Java Serialization.

@boaks Do you have any opinion about that ?

@boaks
Copy link

boaks commented Feb 12, 2019

A PR for californium would be welcome.
Otherwise open an issue in californium.

@sbernard31
Copy link
Contributor

@krisdx I feel making org.eclipse.californium.core.observe.Observation "serializable" will not be easy...

We currently have a json serializer/deserializer, so maybe we should just back out making registration serializable again.

What did you do finally ? You are using RegistrationSerDes ?
Do you feel this is better to have a partial support of java serialization (I mean without org.eclipse.californium.core.observe.Observation or we should just remove it ?

@krisdx
Copy link
Author

krisdx commented Mar 22, 2019

We've implemented the CaliforniumRegistrationStore by persisting only the Registrations in the DB. For the observations, we're just persisting info on what path an observation exists, and the actual org.eclipse.californium.core.observe.Observation objects are stored only at runtime, like in InMemoryRegistrationStore. When our server is restarted we re-initiate them (send new ObservationRequest for every existing path).

We don't plan to serialize org.eclipse.californium.core.observe.Observation, nor to use Java serialization, so the decision is up to you.

@sbernard31
Copy link
Contributor

sbernard31 commented Apr 2, 2019

Ok so I finally decided to integrate the #649 PR in master even if Observation from californium is not Serializable.

This is not so costly, it could maybe help someone and your usecase show it could make sense to create a store which serialize just registration without observation.

Thx @krisdx

sbernard31 added a commit that referenced this issue May 5, 2021
Using JSON serizalization should be enough. See old discussion
#647
sbernard31 added a commit that referenced this issue May 10, 2021
Using JSON serizalization should be enough. See old discussion
#647
sbernard31 added a commit that referenced this issue Jun 3, 2021
Using JSON serizalization should be enough. See old discussion
#647
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Any question about leshan
Projects
None yet
Development

No branches or pull requests

3 participants