[
https://issues.apache.org/jira/browse/CAMEL-20918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17863118#comment-17863118
]
Claus Ibsen commented on CAMEL-20918:
-------------------------------------
Thanks for the details. The fix is welcome as PR or attached to this JIRA.
> Salesforce component does not resubscribe after exception
> ---------------------------------------------------------
>
> Key: CAMEL-20918
> URL: https://issues.apache.org/jira/browse/CAMEL-20918
> Project: Camel
> Issue Type: Bug
> Components: camel-salesforce
> Affects Versions: 3.22.2, 4.4.2, 4.6.0
> Reporter: Bartosz Popiela
> Priority: Major
> Fix For: 4.x
>
>
> In February this year I raised a ticket CAMEL-20388 after observing that the
> _SubscriptionHelper#handshake_ method was not being used, as the first thread
> to invoke it would hang in a deadlock state. After it was fixed there is no
> deadlock, but two other issues were introduced:
> - if any exception occurs during the connect phase and the response message
> does not contain a rehandshake advice, it will permanently disconnect the
> client,
> - because _SubscriptionHelper#connectListener_ delegates to a different
> thread poll and there may be a case whereBayeuxClient sends a request to
> rehandshake before _SubscriptionHelper#connectListener_ disconnects the
> client hance the disconnect will fail and consequently terminate the executor
> in _BayeuxClient_. This results in the following exception being thrown:
> {code:java}
> 16:56:01.757 [Camel (camel-1) thread #287 - SalesforceHttpClient] DEBUG
> o.cometd.client.BayeuxClient.598138b - Transport failure:
> FailureInfo@1d90b9a7[transport=null,cause=java.util.concurrent.RejectedExecutionException:
> Task
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask@2ed1c350[Not
> completed, task =
> java.util.concurrent.Executors$RunnableAdapter@2429a820[Wrapped task =
> org.cometd.client.http.jetty.JettyHttpClientTransport$$Lambda$1947/0x00007f1581f26718@2aee42d5]]
> rejected from org.cometd.client.BayeuxClient$Scheduler@6bd348ee[Terminated,
> pool size = 0, active threads = 0, queued tasks = 0, completed tasks =
> 27],action=handshake] for
> {failure={exception=java.util.concurrent.RejectedExecutionException: Task
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask@2ed1c350[Not
> completed, task =
> java.util.concurrent.Executors$RunnableAdapter@2429a820[Wrapped task =
> org.cometd.client.http.jetty.JettyHttpClientTransport$$Lambda$1947/0x00007f1581f26718@2aee42d5]]
> rejected from org.cometd.client.BayeuxClient$Scheduler@6bd348ee[Terminated,
> pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 27],
> message={ext={replay=true}, supportedConnectionTypes=[long-polling],
> channel=/meta/handshake, id=304, version=1.0}, connectionType=long-polling},
> channel=/meta/handshake, id=304, successful=false}
> {code}
> In addition, because SubscriptionHelper#connectListener clears
> SubscriptionHelper#connectListener and subscriptionListener doesn't put the
> listeners back to the map if the subscription message fails, the Salesforce
> component will not be able to recover (SubscriptionHelper@listenerMap will be
> empty).
> Also, SalesforceComponent#REQUEST_TIMEOUT should be greater than 110 sec as
> this is the default Salesforce timeout for long-polling as per [Clients and
> Timeouts|https://developer.salesforce.com/docs/atlas.en-us.api_streaming.meta/api_streaming/using_streaming_api_timeouts.htm]
> and
> [CometD#1142|https://github.com/cometd/cometd/issues/1142#issuecomment-1048256297].
> Otherwise, java.util.concurrent.TimeoutException will be thrown if there are
> is no event before the timeout expires.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
