[ 
https://issues.apache.org/jira/browse/FLINK-10412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16629901#comment-16629901
 ] 

ASF GitHub Bot commented on FLINK-10412:
----------------------------------------

yanghua 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-424997312
 
 
   Hi @StephanEwen , I verified the scene you said and did not lead to failure. 
Proceed as follows:
   
   1. Serialize the current version of AbstractID to a local file;
   2. Deserialize from the local file and convert the deserialized Object type 
to a new AbstractID (mark the toString field as transient);
   3. Compare the fields and hashcode to be consistent;
   
   Since this test comes from two separate methods and the AbstractID is 
modified in the middle, it seems impossible to write a directly running test 
case.

----------------------------------------------------------------
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)

Reply via email to