[
https://issues.apache.org/jira/browse/FLINK-10412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16656557#comment-16656557
]
ASF GitHub Bot commented on FLINK-10412:
----------------------------------------
tillrohrmann commented on issue #6755: [FLINK-10412] toString field in
AbstractID should be transient to avoid been serialized
URL: https://github.com/apache/flink/pull/6755#issuecomment-431311897
As of this
[documentation](https://docs.oracle.com/javase/8/docs/platform/serialization/spec/version.html#a6519),
making a nontransient field transient is identical as removing a field from a
class. What happens is that an earlier version won't find the field data in the
serialized stream and will initialize the field with the default value
(`null`). In general this is an incompatible change when relying on Java
serialization, however in our case if `toString == null`, then we will simply
regenerate the `toString` field when calling `toString`. Therefore, I think it
is ok to merge this change.
I will proceed with merging.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
> toString field in AbstractID should be transient to avoid been serialized
> -------------------------------------------------------------------------
>
> Key: FLINK-10412
> URL: https://issues.apache.org/jira/browse/FLINK-10412
> Project: Flink
> Issue Type: Bug
> Components: Distributed Coordination
> Affects Versions: 1.7.0
> Reporter: Zhu Zhu
> Assignee: vinoyang
> Priority: Major
> Labels: deploy,deployment, pull-request-available, serialization
>
> The toString field in AbstractID will be serialized currently, which makes
> RPC messages body like InputChannelDeploymentDescriptor and PartitionInfo
> larger (50%+).
> It adds more pressure to JM memory especially in large scale job scheduling
> (10000x10000 ALL-to-ALL connection).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)