Performance issues with i18n of HAL link titles

[slivotov]

In case of creating link without Title there is no way how to instruct HATEOAS not to try to resolve locale Title.

In our case, most of the links do not require title publishing, so we are not adding such field in Link object. However, when HalLinkListSerializer is performing serialization, internally during converting Link object into HalLink object it is trying to resolve link title name always

private HalLink toHalLink(Link link) {

	HalLinkRelation rel = HalLinkRelation.of(link.getRel());

	return new HalLink(link, getTitle(rel));
}

Internally NoSuchMessageException is thrown, which is creating a hard pressure on our CPUs.
The below profile was created using async-profiler which is visualizing profile with FlameGraph. As you can see we are spending a lot of time in the native code of filling stack trace.

Probably I'm missing some bigger picture, but is it possible to fix this issue? Or at least work around it somehow(I tried but hadn't found an easy way).

[odrotbohm]

I've just pushed a fix that should avoid the exceptions being created in the first place. Snapshots should be available in a bit. Would you mind giving them a try?

[slivotov]

I'll definitely give them a try tomorrow. Need to go to prod soon ) Will you send me a version or I'll have to build it?

And thank you very much for so quick answer!

[odrotbohm]

If you declare the snapshot repository (https://repo.spring.io/libs-snapshot), you can just tweak the spring-hateoas.version property in your Spring Boot application to 1.0.0.BUILD-SNAPSHOT.

[slivotov]

I had tested this fix. It is working. Thank you!

[odrotbohm]

Great to hear. Happy coding! 🙃

[odrotbohm]

I just went a bit further to optimize for the case that a rest-messages resource bundle does not exist in the first place. We now use a dedicated no-op implementation that directly shortcuts the message resolution to avoid even more overhead of an attempted resolution which would result in no result by definition.