[
https://issues.apache.org/jira/browse/CAMEL-16084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17282540#comment-17282540
]
Jeremy Ross commented on CAMEL-16084:
-------------------------------------
[~davsclaus] Thanks for the explanation. I'd like to clarify that while playing
nice with salesforce (or any API) is a concern, the number of threads that get
spun up is absurd, and starts hitting Jetty HttpClient limits:
{code}
java.util.concurrent.RejectedExecutionException: Max requests queued per
destination 1024 exceeded for
HttpDestination[https://full.my.salesforce.com]@18c0722d,queue=1024,pool=DuplexConnectionPool@164eaea8[c=0/64/64,a=64,i=0]
{code}
So this really isn't about rate limiting. This is about a runaway integration
process that brings itself down. I still can't wrap my head around why anything
downstream from an aggregator runs in hyper parallel mode.
Theoretically, I think the new synchronous property on the direct component
should help. Per your suggestion, I tried SEDA, a la:
{code:java}
from("seda:sendSalesforceComposite?concurrentConsumers=1")
...
.to("seda:sendSalesforceComposite?blockWhenFull=true")
{code}
But I get the same result. Is there some other option I should set?
> 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)
