Details
-
Bug
-
Status: Resolved
-
Major
-
Resolution: Done
-
None
-
Security Level: Public
-
None
-
S1
-
No
-
Production Defect
-
0
-
Prod Eng - U2 12/16
-
S1
-
performance
-
Description
When streaming responses, the HTTP client uses a PipedInputStream/PipedOuputStream to write the body parts read from the socket, and it's currently doing this operation in an IO scheduler.
These kind of streams are being read usually schedulers using threads from the same pool (the uber).
So, it's possible to be using the same thread-pool (and therefore the same thread) to read/write from/to the same pipe. If it happens, we have a deadlock.
To avoid this situation, we should use a custom scheduler to handle the response parts and write them to the pipes.
Attachments
Issue Links
- relates to
-
MULE-19084 Investigate how many schedulers may be created in complex apps by GrizzlyHttpClient when streamResponse is activated
-
- New
-
-
MULE-16597 HTTP client should use worker pool when streaming responses
-
- Resolved
-
-
HTTPC-75 Use IO threads to handle HTTP response streaming
-
- Resolved
-