When serializing JID instances in a cluster, do not use the (expensive) JID constructor
Description
Constructing a JID class via the regular constructors is a resource intensive task (the stringprepping that occurs requires a lot of CPU-cycles). This should be avoided when needed.
When a JID instance is moved between cluster nodes, it is safe to assume that the original instance got node-prepped. The marshalling/unmarshalling (between cluster nodes) does not need to repeat this process. Currently, a String representation is serialized/deserialized and fed to the (resource intensive) JID constructors. As the JID class is Serializable itself, there is a lot to be gained here.
Environment
None
Activity
Guus der Kinderen February 2, 2013 at 8:22 PM
In revision 13425, the way a JID was Externalized was changed. Instead of using its string representation, the Serializable interface of the JID class is now utilized.
Constructing a JID class via the regular constructors is a resource intensive task (the stringprepping that occurs requires a lot of CPU-cycles). This should be avoided when needed.
When a JID instance is moved between cluster nodes, it is safe to assume that the original instance got node-prepped. The marshalling/unmarshalling (between cluster nodes) does not need to repeat this process. Currently, a String representation is serialized/deserialized and fed to the (resource intensive) JID constructors. As the JID class is Serializable itself, there is a lot to be gained here.