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

Determine why transferTo tests fail for Undertow #25310

Open
poutsma opened this issue Jun 24, 2020 · 2 comments
Open

Determine why transferTo tests fail for Undertow #25310

poutsma opened this issue Jun 24, 2020 · 2 comments
Assignees
Labels
in: web Issues in web modules (web, webmvc, webflux, websocket) type: task A general task
Milestone

Comments

@poutsma
Copy link
Contributor

poutsma commented Jun 24, 2020

With the introduction of the DefaultMultipartParser, two tests started failing when running against Undertow:

  1. org.springframework.web.reactive.function.MultipartIntegrationTests#transferTo and
  2. org.springframework.web.reactive.result.method.annotation.MultipartIntegrationTests#transferTo.

As temporary workaround the tests were disabled for 5.3 M1, but this needs to be resolved by M2.

@poutsma poutsma added the in: web Issues in web modules (web, webmvc, webflux, websocket) label Jun 24, 2020
@poutsma poutsma added this to the 5.3 M2 milestone Jun 24, 2020
@poutsma poutsma self-assigned this Jun 24, 2020
@poutsma poutsma modified the milestones: 5.3 M2, 5.3 RC1 Aug 3, 2020
@poutsma poutsma modified the milestones: 5.3 RC1, 5.3 RC2 Sep 14, 2020
@jhoeller jhoeller modified the milestones: 5.3 RC2, 5.3 GA Oct 13, 2020
@poutsma poutsma modified the milestones: 5.3 GA, 5.x Backlog Oct 26, 2020
sbrannen added a commit to sbrannen/spring-framework that referenced this issue Jan 13, 2022
Instead of simply returning prematurely and allowing the tests to be
marked as SUCCESS, this commit uses a failed assumption to abort the
the trasferTo tests for Undertow, resulting in the parameterized test
invocation properly being marked as ABORTED.

See spring-projectsgh-25310
JiangTChen added a commit to JiangTChen/spring-framework that referenced this issue Jan 14, 2022
JiangTChen added a commit to JiangTChen/spring-framework that referenced this issue Jan 14, 2022
sbrannen pushed a commit that referenced this issue Jan 14, 2022
This commit introduces a dedicated (disabled) transferToWithUndertow()
test method to simplify debugging of transferTo issues with Undertow.

See gh-25310
Closes gh-27908
@jhoeller jhoeller modified the milestones: 6.x Backlog, 6.1.x Jan 11, 2024
@jhoeller jhoeller added the type: task A general task label Jan 11, 2024
@gregw
Copy link

gregw commented Jan 31, 2024

I'm working on a Jetty Core integration that is similar to undertow in that it is a fully asynchronous integration without servlets. We are also failing MultipartWebClientIntegrationTests#transferTo, with the data received not being the correct value.

However, if we copy the bytebuffers as we create the DataBuffer wrappers around the jetty buffer abstraction. We see no leaks of either DataBuffer references, nor the underlying jetty RetainableByteBuffer. Thus our current best theory is that this test is accessing the databuffer after it has been released.

So maybe this is a bad test?? How is undertow failing this test?

@gregw
Copy link

gregw commented Jan 31, 2024

Strangely enough we are also failing org.springframework.web.reactive.function.MultipartRouterFunctionIntegrationTests#proxy, which undertow also is failing. We fail this one with a leak and read after the channel is complete. Is there an issue for this test as well?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: web Issues in web modules (web, webmvc, webflux, websocket) type: task A general task
Projects
None yet
Development

No branches or pull requests

3 participants