Yes, you are right - the 'Accept-Encoding: gzip' header is the cause.
Adding that to the curl request causes the response to block, while
removing it from Apache HTTP client request prevents the response blocking.
But I'm not sure why this would be the case. Gzip compression is
something that
Hi Tim!
Sorry about the delay. I was summoned into a meeting that took a while.
Plus my PC is in the process of upgrading from Debian 9 to Debian
10/testing.
On the important matter.
There are certainly differences when it comes to headers. But I suspect the
culprit is the accept-encoding. I don
Hi Luiz,
here are the request headers. For Apache HTTPClient:
accept -> chemical/x-mdl-sdfile
accept-encoding -> gzip
breadcrumbId -> ID-6667e3dab68a-38877-1547658276076-0-15
CamelHttpMethod -> POST
CamelHttpPath ->
CamelHttpQuery -> null
CamelHttpServletRequest ->
org.apache.cata
Hi, Tim!
I'd suggest trying to intercept / dump the HttpAsyncClient request as well
as the curl one. A simple "nc -l -p " in an *NIX OS will do.
My guess is that the perceived difference lies in the request headers.
Might be in the Accept.
Can you post both requests in full, body excluded?
I'm hitting a strange problem with a route that is using the servlet
component to send a large stream of data in its response.
This is part of a route that uses the REST DSL which is set up like this:
restConfiguration().component("servlet").host("0.0.0.0");
The route sets the response body as
Hi, Andrea!
Thanks for the quick reply!
I was looking at the disruptor, but the master component seems much more
suited to the task at hand. For starters, it needs next to no
configuration at all. It looks like a case of just prefixing the routes
with "master:[namespace]". Awesome.
If th
You can take a look at the master component
https://github.com/apache/camel/blob/master/components/camel-master/src/main/docs/master-component.adoc
--
Andrea Cosentino
--
Apache Camel PMC Chair
Apache Karaf Committer
Apache Servicemix PMC Member
Email: ancosen1.
Hi!
Question: is it possible to configure a route so that at any given time
there is at most one consumer?
I thought of using idempotentConsumers. The expression for the message
id would be any constant, really. This way, when another consumer tries
to process the exchange, it'd be discarde
