[CAMEL-20918] Salesforce component does not resubscribe after exception

• Type: Bug
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 3.22.2, 4.4.2, 4.6.0
• Fix Version/s: 4.8.0
• Component/s: camel-salesforce
• Estimated Complexity: Unknown
• Assignee: Andrea Cosentino
• Reporter: Bartosz Popiela
• Created: 25/Jun/24 10:45
• Updated: 22/Jul/24 10:26
• Resolved: 22/Jul/24 10:26

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:

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}

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 and CometD#1142.

Otherwise, java.util.concurrent.TimeoutException will be thrown if there are is no event before the timeout expires.

Issue Links

• is related to: CAMEL-10238 Camel-salesforce component never tries to reconnect after a disconnect
• is related to: CAMEL-20388 Salesforce component does not handshake on the connection failure
• is related to: CAMEL-20834 camel-salesforce - A NullPointException in SubscriptionHelper.subscribe() interrupts platform-event subscription
• links to: https://github.com/apache/camel/pull/14778