[ 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)