Skip to content
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

On async request, ServletRequestAttributes are being completed before the request is really completed [SPR-9905] #14538

Closed
spring-projects-issues opened this issue Oct 22, 2012 · 4 comments
Assignees
Labels
in: web status: declined

Comments

@spring-projects-issues
Copy link
Collaborator

spring-projects-issues commented Oct 22, 2012

Jesus Alonso opened SPR-9905 and commented

FrameworkServlet is always completing the associated ServletRequestAttributes even when a controller returns a ReferredResult.

Line 933 should be replaced with:

if (!asyncManager.isConcurrentHandlingStarted()) {
requestAttributes.requestCompleted();
}

The ServletRequestAttributes is correctly completed when the async response is processed in DispacherServlet:934


Affects: 3.2 M2

Attachments:

@spring-projects-issues
Copy link
Collaborator Author

spring-projects-issues commented Oct 22, 2012

Rossen Stoyanchev commented

This is actually intended. The FrameworkServlet has always used one RequestAttributes instance or more for example in the case of forwarding. Is it causing any specific issues?

@spring-projects-issues
Copy link
Collaborator Author

spring-projects-issues commented Oct 22, 2012

Jesus Alonso commented

Our application connects to a remote server, so we are using async functionality to process the requests more efficiently. That remote request is executed asynchronously too, so when the request to the remote server is send, the controller responds with a DeferredResult.

When the remote response is processed, we try to use a bean with scope request. However, this process is not executed within a web-aware Spring ApplicationContext, To make it works, we have previously stored the RequestAttributes and are established in the new thread just after start processing the remote response. The problem is that as the request was completed and we receive an exception.

So, taking into account that the request has not really been completed, we have created this JIRA to not complete the RequestAttributes until the request has been completely processed. Just adding that if condition makes it work

@spring-projects-issues
Copy link
Collaborator Author

spring-projects-issues commented Oct 22, 2012

Rossen Stoyanchev commented

Thanks for clarifying.

In the case of Callable, which is handled with a Spring MVC thread we create a new ServletRequestAttributes instance for the duration of the thread (see FrameworkServlet.createRequestBindingInterceptor. In the case of DeferredResult, where the thread is not known to Spring MVC I would recommend also creating a new RequestAttributes instance, which should satisfy the need to use a request-scoped bean:

RequestContextHolder.setRequestAttributes(new ServletRequestAttributes(request));

I do understand the point that the overall request is not completed, but the code has never really worked that way. For example, even before Servlet 3 async processing, each new forward used a separate RequestAttributes instance. Trying to extend a single RequestAttributes over the duration of async processing would require changing that behavior.

The best way to explain the use of RequestAttributes, is that it is scoped to a specific dispatch -- be it a forward, an async dispatch, or a thread exiting to give way to async processing.

@spring-projects-issues
Copy link
Collaborator Author

spring-projects-issues commented Oct 23, 2012

Jesus Alonso commented

Thanks, your solution works.

@spring-projects-issues spring-projects-issues added type: bug status: declined in: web labels Jan 11, 2019
@spring-projects-issues spring-projects-issues removed the type: bug label Jan 12, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: web status: declined
Projects
None yet
Development

No branches or pull requests

2 participants