-
Notifications
You must be signed in to change notification settings - Fork 560
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
Fix Asynchronous Dispatch Logic in AwsAsyncContext with Spring's DispatcherServlet #631
Conversation
Ensure post-processing logic is executed before re-dispatching during asynchronous request handling * SpringBootLambdaContainerHandler - Added logic within the handleRequest method to reprocess the request in cases where an asynchronous request requires re-dispatching. * AwsAsyncContext - Added an isDispatchStarted method that returns whether the dispatch has started or not. - Removed the part where doFilter is directly called within the dispatch function.
*AwsAsyncContextTest -Disabled servlet mapping tests as it no longer make servlet requests.
Thanks for your contribution. I will review this today and let you know. |
Looks good to me. Could you add tests, please? |
I added test cases |
How do we plan to deal with the |
-get reqServlet before doFilter for redispatch
-Added re-dispatch logic inside SpringLambdaContainerHandler's handleRequest
-Added test cases for async request
The two However, in my commit, this line has removed from the However, as you pointed out, I seem to have overlooked testing whether the request path is properly amended when |
I missed that both |
@deki Any further feedback on my update? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AwsAsyncContext
no longer depends on the AwsLambdaServletContainerHandler
could you please remove the unused variable as well?
...-core/src/test/java/com/amazonaws/serverless/proxy/internal/servlet/AwsAsyncContextTest.java
Outdated
Show resolved
Hide resolved
Hey @2012160085, I read https://jakarta.ee/specifications/servlet/6.0/jakarta-servlet-spec-6.0#asynchronous-processing, looked at https://github.com/apache/tomcat/blob/main/java/org/apache/catalina/core/AsyncContextImpl.java and noticed we may required additional fixes. The async processing capability should work within aws-serverless-java-container-core but with the proposed change you made calling filters exclusive to -spring and -springboot3. Filters for apps running -jersey and other potential implementations would no longer be called or am I missing something? |
You seem to be correct based on what I've reviewed. I will take a closer look into this |
@2012160085 just a heads up, we are planning to release 2.0.0 at the end of this month. are you still working on it so we can include it? |
I haven't been able to focus on this recently, but I will make sure to wrap it up by the end of the month. |
dispatch_sendsToCorrectServlet dispatchNewPath_sendsToCorrectServlet
@deki I think I've wrapped it up.
|
… is no longer dependent on AwsLambdaServletContainerHandler
...iner-core/src/main/java/com/amazonaws/serverless/proxy/internal/servlet/AwsAsyncContext.java
Outdated
Show resolved
Hide resolved
Thanks again for your contribution, @2012160085! |
*Issue #, if available: #630
*Description of changes:
Problem
While examining #630, I found an issue within the asynchronous dispatch logic of
AwsAsyncContext
when interacting with Spring'sDispatcherServlet
.Premature Re-dispatch: Currently,
AwsAsyncContext
prematurly triggers re-dispatch.When handling asynchronous requests with
DispatcherServlet
,DispatcherServlet
'sdoDispatch
should be called to complete the initial request. Only after the initial request concludes, should thedoDispatch
be called again for re-dispatch. However, in the present implementation, this sequence is disrupted. During the processing of the initial request by thedoDispatch
method, thedispatch
method ofAwsAsyncContext
is invoked, which in turn directly calls thedoFilter
method for immediate re-dispatch. This leads to premature execution of the re-dispatch before the post-processing logic ofdoDispatch
(which is handling the initial request) is executed.EntityManager Bind Timing Issue: While using Spring JPA, due to the aforementioned issue, an error arises when trying to bind the
EntityManager
to threadLocal during the preHandle phase of the re-dispatch. This is because theEntityManager
is already bound from the initial request, and the post-processing logic meant to unbind it hasn't been executed yet. As a result, attempting to bind it again triggers the following error:Changes
To resolve this, I made modifications to the
SpringBootLambdaContainerHandler::handleRequest
andAwsAsyncContext::dispatch
by referencing the way requests are handled inapache.coyote.AbstractProcessorLight::process
.The snippet for the proposed solution is as follows:
By ensuring that the post-processing of the initial request is complete and only then re-invoking the doFilter when necessary, we can bypass the issues mentioned above.
I have not yet added test cases, and there are two test cases marked with @disable since AwsAsyncContext no longer maps requests to the servlet. I think we can talk about this solution or potentially explore better approaches.
By submitting this pull request