[
https://issues.apache.org/jira/browse/CAMEL-16084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17282422#comment-17282422
]
Claus Ibsen commented on CAMEL-16084:
-------------------------------------
Even if synchronous=true was there, then concurrent threads would be able to
overload your SLA with salesforce, if you had the Camel route to be callable
from other routes, etc. But you just happen to be that you had a single
threaded consumer that by synchronous=true gets blocked waiting for the
salesforce reply, before continuing.
The better solution is to use EIP patterns, about throttling / rate-limiting.
Where you can specify that there should only be at most 1 (or what number you
can configure) in-flight message to this endpoint at any given time.
Unfortunately the current throttler EIP is based on timed window. So you can
for example can say 1 message per 10 sec. But in other use-cases you dont care
about the time window, but just want to say "at most X request at any given
time". So for this we have CAMEL-16099
And in Camel 3.8 onwards you can leverage the direct component to make it
synchronous (its about direct method invocations like in Java that are
synchronous - or async with its CompletableFuture API etc) so there is some
resembles there.
from x
split xxx
to direct:rate
from ("direct:rate?synchronous=true")
.to("salesforce....")
But for Camel 3.9 with the rate in throttler (or if we develoed as a new EIP
term - rate)
from xxxx
split xxxx
rate 1
to salesforce
// end rate
/// end split
Or you can put the rate on top of the route
from xxxx
rate 1
split xxx
to sales
> salesforce: Out of order execution
> ----------------------------------
>
> Key: CAMEL-16084
> URL: https://issues.apache.org/jira/browse/CAMEL-16084
> Project: Camel
> Issue Type: Bug
> Components: camel-salesforce
> Affects Versions: 3.7.1
> Reporter: Jeremy Ross
> Assignee: Jeremy Ross
> Priority: Major
> Attachments: wiretap-results.txt
>
>
> When using a salesforce operation after an aggregator, control seems to
> return to the aggregate caller immediately instead of proceeding with
> processors downstream from the salesforce operation. This is the behavior I'd
> expect if using the aggregator with parallelProcessing.
> I believe this is longstanding behavior, however with the removal of the
> `synchronous` option from the salesforce component (CAMEL-14138), we've
> removed a workaround to this issue.
> I'm seeing the same behavior with a salesforce operation via a wiretap with a
> threadpool with poolsize, maxsize and queuesize of 1, which should
> effectively behave in a synchronous manner.
> Test case: https://gist.github.com/jeremyross/4d7d14a33452edf236faefda77ad3e3d
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
