You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@camel.apache.org by "Bartosz Popiela (Jira)" <ji...@apache.org> on 2024/07/04 02:45:00 UTC
[jira] [Updated] (CAMEL-20918) Salesforce component does not resubscribe after exception
[ https://issues.apache.org/jira/browse/CAMEL-20918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bartosz Popiela updated CAMEL-20918:
------------------------------------
Description:
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.
was:TODO will be updated
> 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)