Skip to content

Flush readonly map together with shared on SerializerCache.flush() - #3791

Merged
cowtowncoder merged 1 commit into
FasterXML:2.15from
vdaniloff:flush_readonly_map_on_cache_flush
Apr 6, 2023
Merged

Flush readonly map together with shared on SerializerCache.flush()#3791
cowtowncoder merged 1 commit into
FasterXML:2.15from
vdaniloff:flush_readonly_map_on_cache_flush

Conversation

@vdaniloff

Copy link
Copy Markdown
Contributor

Without these flushing the cache may be not enough - for example if a new subtype for existing interface is added by a new provider, serialization cache will still return old serializer for an interface.

@cowtowncoder

cowtowncoder commented Feb 21, 2023

Copy link
Copy Markdown
Member

I would need to have some kind of indication of an observed problem to change something that seems to have been working for a decade now... :)

That is, without a test I don't think I'd want to merge this.

I am also not sure what the problem would be: subtypes are not really relevant here as the cache is keyed by actual type, not supertype.

@cowtowncoder

Copy link
Copy Markdown
Member

Actually, looking at this again, this makes sense. And while it'd be nice to have tests I don't think they are essential after all.
Merging.

@cowtowncoder
cowtowncoder merged commit 508efeb into FasterXML:2.15 Apr 6, 2023
@cowtowncoder cowtowncoder added this to the 2.15.0-rc3 milestone Apr 6, 2023
@cowtowncoder cowtowncoder changed the title Flush readonly map together with shared on serialization cache flush Flush readonly map together with shared on SerializerCache.flush() Apr 6, 2023
cowtowncoder added a commit that referenced this pull request Apr 6, 2023
@vdaniloff

vdaniloff commented Apr 7, 2023

Copy link
Copy Markdown
Contributor Author

Thanks for merging this.

I am really sorry for late answer, forgot about this. After creating the issue I realized it did not help with my original problem anyway (there was a need to make Jackson rebuild polymorphic serializers, after serializer was used before new subclasses where registered). I fixed that problem by changing application.

The change makes some sense, but flushing serializers may still not work:

  1. There a _knownSerializers field in StdSerializerProvider. It is final and if a serializer is already there - it will not be flushed
  2. There's anyway no such method for flush deserialisers in provider (only in DeserializerCache itself)

Combined makes me think maybe there's still something to do. I am not sure now what is the purpose of the method - to really make Jackson recreate serializers (potentially with new logic) or just to free memory (maybe then javadoc update is needed).

@cowtowncoder

Copy link
Copy Markdown
Member

@vdaniloff Ok thank you for additional information. I am also not sure how useful this method really is; it generally is better to just create a new ObjectMapper, to be honest (f.ex ObjectMapper.copy()).
Part wrt (Std)SerializerProvider definitely seem to make cache flush operation about useless.

But as to original intent I am pretty sure it's about saving memory and not so much new functionality.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants