No problem. Glad to help.
Best of luck!
~Danny
On Nov 10, 2015, at 4:36 PM, Alex Soto wrote:
> Great, in this case I am not doing any aggregation, so that won’t be a
> problem.
> I just finished testing, and it worked, so thats for the help.
>
> Best regards,
> Alex soto
>
>
>
>> On Nov
Great, in this case I am not doing any aggregation, so that won’t be a problem.
I just finished testing, and it worked, so thats for the help.
Best regards,
Alex soto
> On Nov 10, 2015, at 3:23 PM, Daniel Lamb wrote:
>
> If you do some parallel processing and have an aggregation strategy for
If you do some parallel processing and have an aggregation strategy for the
results, just make sure to put the properties from the old exchange onto the
exchange that you return. Other than that, you’ll be fine.
~Danny
On Nov 10, 2015, at 4:18 PM, Alex Soto wrote:
> Thanks, I will give it a
Thanks, I will give it a try.
Do you know if there is some concern using exchange properties that I should
worry about, perhaps with multi-threading?
Best regards,
Alex soto
> On Nov 10, 2015, at 2:57 PM, Daniel Lamb wrote:
>
> Store the headers as properties on the exchange before filteri
Store the headers as properties on the exchange before filtering them out.
Then you can pull them back out after you get your response from the remote
server and do what you need to do.
~Danny
On Nov 10, 2015, at 3:52 PM, Alex Soto wrote:
> In case its not clear, I need my custom headers fo
In case its not clear, I need my custom headers for after the HTTP request
comes back, I just don’t want these headers to go out to the remote server.
Currently, I am using a headerFilterStrategy, but that seems to remove the
headers entirely, as opposed to filter them, as the name implies.
