-
Notifications
You must be signed in to change notification settings - Fork 38.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update RestTemplate Javadoc with regards to setting interceptors on startup vs at runtime #29311
Comments
The The more recently designed Aside from that we are not looking to make further changes to the |
Thank you for your answer and spent time on this issue, Rossen Stoyanchev. I had a task to fix a ConcurrentModificationException, so other microservices/projects may have/face the same wrong behavior/way. I understand that the Spring team built the RestTemplate a long time ago. Not-so-skillful developers must use a particular mind pattern when using the legacy RestTemplate. I acknowledge now that the Spring team cannot make such a significant fix change because of the legacy code and the corporations' usage. But it is easy and natural to go with the anti-design pattern if you come from a scripting experience like the Laravel framework. Yes, it will be great if there are a new tutorial and new java docs comments in the space of the Spring community. Emphasizing the marked behavior of the RestTemplate will be enough. |
I want to emphasize again, this isn't some isolated pattern, but a general design approach. In a Spring application, components are typically initialized and configured at startup. For people who come from a very different language background and concurrency model, this does present a learning challenge, but in my opinion that challenge has to do with much broader concepts. The Note also that using a synchronized collection or otherwise allowing interceptors to be added at runtime would be dangerous, as the In any case, we'll add something to the Javadoc if it helps. |
Thank you, Rossen Stoyanchev. |
ConcurrentModificationException Diagram:

Summary:
Hello.
-
ConcurrentModificationException
occurs when one thread is modifying a collection with some interceptors, and another thread is iterating the same data structure with the elements in the context of the topic "ConcurrentModificationException Spring Framework Rest Template Setting Interceptors".-The following code is not thread-safe and developers can potentially use the following code in a not thread-safe way.
-The currently shown source code allows thread-safe misusage, logging spikes, degraded performance and security risks.
-Nothing protects developers from abusing the Spring Framework to be used in an anti-design pattern on production servers.
-We can pass a synchronized collection hypothetically. The method responsible for setting the interceptors returns response always as an unsynchronized collection. The
setInterceptors
function processes the elements of the data structure we pass in a not thread-safe manner using copy action of elements' references, sorting the interceptors redundantly.Note:
https://docs.oracle.com/javase/7/docs/api/java/util/ConcurrentModificationException.html
"Therefore, it would be wrong to write a program that depended on this exception for its correctness: ConcurrentModificationException should be used only to detect bugs."
Code:
https://github.com/spring-projects/spring-framework/blob/main/spring-web/src/main/java/org/springframework/http/client/support/InterceptingHttpAccessor.java
https://github.com/spring-projects/spring-framework/blob/main/spring-web/src/main/java/org/springframework/http/client/InterceptingClientHttpRequest.java
Test Scenario:
DemoApplication.txt
Debugging steps:
-Run Spring Boot Demo Server
-Create restTemplate bean
-Execute testConcurrentModificationExceptionInRestTemplate() method
Debugging results:
The text was updated successfully, but these errors were encountered: