Hi,
Since the 4.0.0-M3 update of Apache Camel, I encountered a problem where
the InputStream in the message body is being consumed (and then closed).
As far as I could see, the problem was introduced when Apache Camel HTTP
component started using Apache HttpCore5.
The idea behind this use case is to take the inputstream from the message's
body (from the "TO" response), and copy it directly into the HttpResponse
outputstream.
A simplified example of the route would be:
from("direct:test_stream")
.noStreamCaching()
.to("http://localhost:8080/test/streamfile?disableStreamCache=true";)
.process(exchange -> {
OutputStream responseStream = exchange.getProperty("RESPONSE_STREAM",
ServletOutputStream.class);
InputStream inputStream =
exchange.getMessage().getBody(EofSensorInputStream.class);
StreamUtils.copy(inputStream, responseStream);
});
And a simplified usage example would be:
@RestController
@RequestMapping(value ="/test")
public class TestController {
@Autowired
private ProducerTemplate producerTemplate;
@RequestMapping(method = RequestMethod.GET)
public void getFile(HttpServletResponse httpServletResponse) {
producerTemplate.send("direct:test_stream", ExchangePattern.InOut,
x -> {
x.setProperty("RESPONSE_STREAM",
httpServletResponse.getOutputStream());
});
}
@RequestMapping(method = RequestMethod.GET, path = "/streamfile",
produces = MediaType.IMAGE_JPEG_VALUE)
public @ResponseBody Resource streamFile() throws IOException {
return new
InputStreamResource(Objects.requireNonNull(getClass().getClassLoader().getResourceAsStream("1.jpg")));
}
}
The error produced is:
org.apache.hc.core5.http.StreamClosedException: Stream already closed
at
org.apache.hc.core5.http.impl.io.ChunkedInputStream.read(ChunkedInputStream.java:176)
~[httpcore5-5.1.5.jar:5.1.5]
at
org.apache.hc.core5.http.io.EofSensorInputStream.read(EofSensorInputStream.java:135)
~[httpcore5-5.1.5.jar:5.1.5]
at java.base/java.io.InputStream.transferTo(InputStream.java:782)
~[na:na]
at org.springframework.util.StreamUtils.copy(StreamUtils.java:153)
~[spring-core-6.0.8.jar:6.0.8]
This use case works in all versions up to 4.0.0-M2, including all 3.x I
could test.
Anyone have an idea on how I could work around this issue, or if I should
proceed to create a bug in the JIRA.
Thank you.
Regards,
Arthur
