[jira] [Comment Edited] (CAMEL-15903) Master component do not retry endpoint startup on failure
[ https://issues.apache.org/jira/browse/CAMEL-15903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17246823#comment-17246823 ] EDGAR CHERNICK edited comment on CAMEL-15903 at 12/9/20, 9:06 PM: -- The Master Consumer does not have a try catch block on leadership taken event handler (https://github.com/apache/camel/blob/master/components/camel-master/src/main/java/org/apache/camel/component/master/MasterConsumer.java#L118). would it be okay If I just added that and then call super.handleException in the catch block ? If the route has bridgeErrorHandler=true this should at least surface the exception for handling, right ? This won't solve the issue by itself but at least end users will have an exception indicating that something is going on. was (Author: edgarcher): The Master Consumer does not have a try catch block on leadership taken event handler (https://github.com/apache/camel/blob/master/components/camel-master/src/main/java/org/apache/camel/component/master/MasterConsumer.java#L118). would it be okay If I just added that and then call super.handleException in the catch block ? If the route has bridgeErrorHandler=true this should at least surface the exception for handling, right ? > Master component do not retry endpoint startup on failure > - > > Key: CAMEL-15903 > URL: https://issues.apache.org/jira/browse/CAMEL-15903 > Project: Camel > Issue Type: Bug > Components: camel-master >Reporter: EDGAR CHERNICK >Priority: Major > Fix For: 3.8.0 > > > The cluster view implementations have a listener attribute where the master > component hooks itself to receive leadership change events. > When the app instance becomes leader the cluster view will mark that instance > as leader then it will trigger the leadershipchangedevent, this will trigger > the master component event handler and it will start the delegated consumer > and endpoint. > The issue happens when the delegated consumer or endpoint fail to start. The > exception throw by them will go up in the stack, however, this exception does > not affect the leadership, i.e., once the app instance becomes leader it will > stay so even if the delegated components fail to start. > Both KubernetesClusterView and FileLockClusterView have this issue. > KubernetesClusterView uses KubernetesLeadershipController to run the > leadership check at an interval. When it acquires the leadership it updates > the configmap with that info and call TimedLeaderNotifier refreshLeadership > method to check if the leadership has changed. The issue here is that it will > mark itself as leader before firing the leadership changed event. Another > issue is that the event is fired in a separete thread, so, when the start of > the delegated components fail the exception will "die" together with the > thread. When the next scheduled leadership check runs the app instance is > already the leader and it will not fire the leadership changed event and the > delegated component will never start. > FileLockClusterView has a similar issue, it acquires the file lock prior to > firing the event, even if the event processing fails it does not rollback the > leader selection. > Other cluster view implementations might have the same issue. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-15903) Master component do not retry endpoint startup on failure
[ https://issues.apache.org/jira/browse/CAMEL-15903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17246823#comment-17246823 ] EDGAR CHERNICK commented on CAMEL-15903: The Master Consumer does not have a try catch block on leadership taken event handler (https://github.com/apache/camel/blob/master/components/camel-master/src/main/java/org/apache/camel/component/master/MasterConsumer.java#L118). would it be okay If I just added that and then call super.handleException in the catch block ? If the route has bridgeErrorHandler=true this should at least surface the exception for handling, right ? > Master component do not retry endpoint startup on failure > - > > Key: CAMEL-15903 > URL: https://issues.apache.org/jira/browse/CAMEL-15903 > Project: Camel > Issue Type: Bug > Components: camel-master >Reporter: EDGAR CHERNICK >Priority: Major > Fix For: 3.8.0 > > > The cluster view implementations have a listener attribute where the master > component hooks itself to receive leadership change events. > When the app instance becomes leader the cluster view will mark that instance > as leader then it will trigger the leadershipchangedevent, this will trigger > the master component event handler and it will start the delegated consumer > and endpoint. > The issue happens when the delegated consumer or endpoint fail to start. The > exception throw by them will go up in the stack, however, this exception does > not affect the leadership, i.e., once the app instance becomes leader it will > stay so even if the delegated components fail to start. > Both KubernetesClusterView and FileLockClusterView have this issue. > KubernetesClusterView uses KubernetesLeadershipController to run the > leadership check at an interval. When it acquires the leadership it updates > the configmap with that info and call TimedLeaderNotifier refreshLeadership > method to check if the leadership has changed. The issue here is that it will > mark itself as leader before firing the leadership changed event. Another > issue is that the event is fired in a separete thread, so, when the start of > the delegated components fail the exception will "die" together with the > thread. When the next scheduled leadership check runs the app instance is > already the leader and it will not fire the leadership changed event and the > delegated component will never start. > FileLockClusterView has a similar issue, it acquires the file lock prior to > firing the event, even if the event processing fails it does not rollback the > leader selection. > Other cluster view implementations might have the same issue. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-15903) Master component do not retry endpoint startup on failure
[ https://issues.apache.org/jira/browse/CAMEL-15903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17244173#comment-17244173 ] EDGAR CHERNICK commented on CAMEL-15903: I think I could have something monitoring the master component but I don't think it would help in this scenario actually. In all app instances the master component route is started (and the route it is in as well). The thing that is not started is the "wrapped by master" component/endpoint, that wrapped component starts when master component receives leadership changed events and trigger its start. One thing that I was thinking is, what if the actual error surfaced to the exception handling mechanism (something similar to what bridgeErrorHandler does). This won't fix the issue of not retrying the startup of it on leadership changes but at least will give users visibility that something is going on (they might even be able to "force" the restart of the route on their own based on the exception that was thrown) > Master component do not retry endpoint startup on failure > - > > Key: CAMEL-15903 > URL: https://issues.apache.org/jira/browse/CAMEL-15903 > Project: Camel > Issue Type: Bug > Components: camel-master >Reporter: EDGAR CHERNICK >Priority: Major > Fix For: 3.8.0 > > > The cluster view implementations have a listener attribute where the master > component hooks itself to receive leadership change events. > When the app instance becomes leader the cluster view will mark that instance > as leader then it will trigger the leadershipchangedevent, this will trigger > the master component event handler and it will start the delegated consumer > and endpoint. > The issue happens when the delegated consumer or endpoint fail to start. The > exception throw by them will go up in the stack, however, this exception does > not affect the leadership, i.e., once the app instance becomes leader it will > stay so even if the delegated components fail to start. > Both KubernetesClusterView and FileLockClusterView have this issue. > KubernetesClusterView uses KubernetesLeadershipController to run the > leadership check at an interval. When it acquires the leadership it updates > the configmap with that info and call TimedLeaderNotifier refreshLeadership > method to check if the leadership has changed. The issue here is that it will > mark itself as leader before firing the leadership changed event. Another > issue is that the event is fired in a separete thread, so, when the start of > the delegated components fail the exception will "die" together with the > thread. When the next scheduled leadership check runs the app instance is > already the leader and it will not fire the leadership changed event and the > delegated component will never start. > FileLockClusterView has a similar issue, it acquires the file lock prior to > firing the event, even if the event processing fails it does not rollback the > leader selection. > Other cluster view implementations might have the same issue. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-15903) Master component do not retry endpoint startup on failure
[
https://issues.apache.org/jira/browse/CAMEL-15903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17239698#comment-17239698
]
EDGAR CHERNICK commented on CAMEL-15903:
I'm using camel to consume from SF streaming api and I got this error when
trying to creating a push topic with a name with more than 25 characters. This
is the stack trace using FileLockClusterView:
org.apache.camel.CamelException: Error creating Topic
proposalOpportunityInjectionSync:
{errors:[{"errorCode":"STRING_TOO_LONG","message":"Topic Name: data value too
large: proposalOpportunityInjectionSync (max
length=25)","fields":["Name"]}],statusCode:400}
at
org.apache.camel.component.salesforce.internal.streaming.PushTopicHelper.createTopic(PushTopicHelper.java:169)
at
org.apache.camel.component.salesforce.internal.streaming.PushTopicHelper.createOrUpdateTopic(PushTopicHelper.java:112)
at
org.apache.camel.component.salesforce.SalesforceConsumer.doStart(SalesforceConsumer.java:312)
at
org.apache.camel.support.service.BaseService.start(BaseService.java:115)
at
org.apache.camel.support.service.ServiceHelper.startService(ServiceHelper.java:84)
at
org.apache.camel.component.master.MasterConsumer.onLeadershipTaken(MasterConsumer.java:133)
at
org.apache.camel.component.master.MasterConsumer.access$100(MasterConsumer.java:43)
at
org.apache.camel.component.master.MasterConsumer$LeadershipListener.leadershipChanged(MasterConsumer.java:160)
at
org.apache.camel.support.cluster.AbstractCamelClusterView.lambda$fireLeadershipChangedEvent$4(AbstractCamelClusterView.java:129)
at
org.apache.camel.support.cluster.AbstractCamelClusterView.lambda$doWithListener$3(AbstractCamelClusterView.java:119)
at
org.apache.camel.util.concurrent.LockHelper.doWithReadLock(LockHelper.java:34)
at
org.apache.camel.support.cluster.AbstractCamelClusterView.doWithListener(AbstractCamelClusterView.java:112)
at
org.apache.camel.support.cluster.AbstractCamelClusterView.fireLeadershipChangedEvent(AbstractCamelClusterView.java:127)
at
org.apache.camel.component.file.cluster.FileLockClusterView.tryLock(FileLockClusterView.java:146)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: org.apache.camel.component.salesforce.api.SalesforceException:
{errors:[{"errorCode":"STRING_TOO_LONG","message":"Topic Name: data value too
large: proposalOpportunityInjectionSync (max
length=25)","fields":["Name"]}],statusCode:400}
at
org.apache.camel.component.salesforce.internal.client.DefaultRestClient.createRestException(DefaultRestClient.java:113)
at
org.apache.camel.component.salesforce.internal.client.AbstractClientBase$1.onComplete(AbstractClientBase.java:231)
at
org.eclipse.jetty.client.ResponseNotifier.notifyComplete(ResponseNotifier.java:202)
at
org.eclipse.jetty.client.ResponseNotifier.notifyComplete(ResponseNotifier.java:194)
at
org.eclipse.jetty.client.ResponseNotifier.forwardSuccessComplete(ResponseNotifier.java:228)
at
org.apache.camel.component.salesforce.internal.client.SalesforceSecurityHandler$SecurityListener.forwardSuccessComplete(SalesforceSecurityHandler.java:269)
at
org.apache.camel.component.salesforce.internal.client.SalesforceSecurityHandler$SecurityListener.onComplete(SalesforceSecurityHandler.java:182)
at
org.eclipse.jetty.client.ResponseNotifier.notifyComplete(ResponseNotifier.java:202)
at
org.eclipse.jetty.client.ResponseNotifier.notifyComplete(ResponseNotifier.java:194)
at
org.eclipse.jetty.client.HttpReceiver.terminateResponse(HttpReceiver.java:470)
at
org.eclipse.jetty.client.HttpReceiver.responseSuccess(HttpReceiver.java:416)
at
org.eclipse.jetty.client.http.HttpReceiverOverHTTP.messageComplete(HttpReceiverOverHTTP.java:316)
at org.eclipse.jetty.http.HttpParser.parseFields(HttpParser.java:1165)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:1525)
at
org.eclipse.jetty.client.http.HttpReceiverOverHTTP.parse(HttpReceiverOverHTTP.java:172)
at
org.eclipse.jetty.client.http.HttpReceiverOverHTTP.process(HttpReceiverOverHTTP.java:135)
at
org.eclipse.jetty.client.http.HttpReceiverOverHTTP.receive(Htt
[jira] [Comment Edited] (CAMEL-15903) Master component do not retry endpoint startup on failure
[ https://issues.apache.org/jira/browse/CAMEL-15903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17239688#comment-17239688 ] EDGAR CHERNICK edited comment on CAMEL-15903 at 11/27/20, 1:58 PM: --- [~davsclaus] I wanted to fix this issue myself but I'm afraid I might fix it for my scenario and keep others uncovered, since I think this issue might be related with all cluster view implementations. Would you mind giving some direction on how this could fixed ? I may try to submit a PR based on this direction then. was (Author: edgarcher): [~davsclaus] I wanted to fix this issue myself but I'm afraid I might fix it for my scenario and keep others uncovered, since I think this issue might be related with all cluster view implementations. Would you mind giving some direction on how this could fixed ? I may try to submit a PR based on this direction then. Edgar. > Master component do not retry endpoint startup on failure > - > > Key: CAMEL-15903 > URL: https://issues.apache.org/jira/browse/CAMEL-15903 > Project: Camel > Issue Type: Bug >Reporter: EDGAR CHERNICK >Priority: Major > > The cluster view implementations have a listener attribute where the master > component hooks itself to receive leadership change events. > When the app instance becomes leader the cluster view will mark that instance > as leader then it will trigger the leadershipchangedevent, this will trigger > the master component event handler and it will start the delegated consumer > and endpoint. > The issue happens when the delegated consumer or endpoint fail to start. The > exception throw by them will go up in the stack, however, this exception does > not affect the leadership, i.e., once the app instance becomes leader it will > stay so even if the delegated components fail to start. > Both KubernetesClusterView and FileLockClusterView have this issue. > KubernetesClusterView uses KubernetesLeadershipController to run the > leadership check at an interval. When it acquires the leadership it updates > the configmap with that info and call TimedLeaderNotifier refreshLeadership > method to check if the leadership has changed. The issue here is that it will > mark itself as leader before firing the leadership changed event. Another > issue is that the event is fired in a separete thread, so, when the start of > the delegated components fail the exception will "die" together with the > thread. When the next scheduled leadership check runs the app instance is > already the leader and it will not fire the leadership changed event and the > delegated component will never start. > FileLockClusterView has a similar issue, it acquires the file lock prior to > firing the event, even if the event processing fails it does not rollback the > leader selection. > Other cluster view implementations might have the same issue. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-15903) Master component do not retry endpoint startup on failure
[ https://issues.apache.org/jira/browse/CAMEL-15903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17239688#comment-17239688 ] EDGAR CHERNICK commented on CAMEL-15903: [~davsclaus] I wanted to fix this issue myself but I'm afraid I might fix it for my scenario and keep others uncovered, since I think this issue might be related with all cluster view implementations. Would you mind giving some direction on how this could fixed ? I may try to submit a PR based on this direction then. Edgar. > Master component do not retry endpoint startup on failure > - > > Key: CAMEL-15903 > URL: https://issues.apache.org/jira/browse/CAMEL-15903 > Project: Camel > Issue Type: Bug >Reporter: EDGAR CHERNICK >Priority: Major > > The cluster view implementations have a listener attribute where the master > component hooks itself to receive leadership change events. > When the app instance becomes leader the cluster view will mark that instance > as leader then it will trigger the leadershipchangedevent, this will trigger > the master component event handler and it will start the delegated consumer > and endpoint. > The issue happens when the delegated consumer or endpoint fail to start. The > exception throw by them will go up in the stack, however, this exception does > not affect the leadership, i.e., once the app instance becomes leader it will > stay so even if the delegated components fail to start. > Both KubernetesClusterView and FileLockClusterView have this issue. > KubernetesClusterView uses KubernetesLeadershipController to run the > leadership check at an interval. When it acquires the leadership it updates > the configmap with that info and call TimedLeaderNotifier refreshLeadership > method to check if the leadership has changed. The issue here is that it will > mark itself as leader before firing the leadership changed event. Another > issue is that the event is fired in a separete thread, so, when the start of > the delegated components fail the exception will "die" together with the > thread. When the next scheduled leadership check runs the app instance is > already the leader and it will not fire the leadership changed event and the > delegated component will never start. > FileLockClusterView has a similar issue, it acquires the file lock prior to > firing the event, even if the event processing fails it does not rollback the > leader selection. > Other cluster view implementations might have the same issue. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CAMEL-15903) Master component do not retry endpoint startup on failure
EDGAR CHERNICK created CAMEL-15903: -- Summary: Master component do not retry endpoint startup on failure Key: CAMEL-15903 URL: https://issues.apache.org/jira/browse/CAMEL-15903 Project: Camel Issue Type: Bug Reporter: EDGAR CHERNICK The cluster view implementations have a listener attribute where the master component hooks itself to receive leadership change events. When the app instance becomes leader the cluster view will mark that instance as leader then it will trigger the leadershipchangedevent, this will trigger the master component event handler and it will start the delegated consumer and endpoint. The issue happens when the delegated consumer or endpoint fail to start. The exception throw by them will go up in the stack, however, this exception does not affect the leadership, i.e., once the app instance becomes leader it will stay so even if the delegated components fail to start. Both KubernetesClusterView and FileLockClusterView have this issue. KubernetesClusterView uses KubernetesLeadershipController to run the leadership check at an interval. When it acquires the leadership it updates the configmap with that info and call TimedLeaderNotifier refreshLeadership method to check if the leadership has changed. The issue here is that it will mark itself as leader before firing the leadership changed event. Another issue is that the event is fired in a separete thread, so, when the start of the delegated components fail the exception will "die" together with the thread. When the next scheduled leadership check runs the app instance is already the leader and it will not fire the leadership changed event and the delegated component will never start. FileLockClusterView has a similar issue, it acquires the file lock prior to firing the event, even if the event processing fails it does not rollback the leader selection. Other cluster view implementations might have the same issue. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-15233) camel-salesforce - CometDReplayExtension does not keep replayId for each message/channel
[
https://issues.apache.org/jira/browse/CAMEL-15233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17151686#comment-17151686
]
Edgar Chernick commented on CAMEL-15233:
PR for 2.25.x created https://github.com/apache/camel/pull/3975
> camel-salesforce - CometDReplayExtension does not keep replayId for each
> message/channel
>
>
> Key: CAMEL-15233
> URL: https://issues.apache.org/jira/browse/CAMEL-15233
> Project: Camel
> Issue Type: Bug
> Components: camel-salesforce
>Reporter: Edgar Chernick
>Priority: Major
> Fix For: 2.25.2, 3.4.1, 3.5.0
>
>
> CometDReplayExtension class try to read the replayId from the message by
> doing
> {code}
> final Object value = message.get(EXTENSION_NAME);
> {code}
> However, the replayId (based on this
> [https://developer.salesforce.com/docs/atlas.en-us.api_streaming.meta/api_streaming/using_streaming_api_durability.htm])
> is actually within data -> event -> replayId.
> By doing the following (the same thing the salesforce consumer does
> https://github.com/apache/camel/blob/master/components/camel-salesforce/camel-salesforce-component/src/main/java/org/apache/camel/component/salesforce/SalesforceConsumer.java#L250)
> {code}
> final Map data = (Map) message.get("data");
> final Map event = (Map) data.get("event");
> final Object value = event.get("replayId");
> {code}
> I was able to properly fetch the replayId from the message.
> Since the current version does not do this properly, If the component loses
> the connection and has to subscribe again it will use the replayid value from
> the endpoint which it will be outdated if any message was read before the
> connection failure.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CAMEL-15233) camel-salesforce - CometDReplayExtension does not keep replayId for each message/channel
[
https://issues.apache.org/jira/browse/CAMEL-15233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17150380#comment-17150380
]
Edgar Chernick commented on CAMEL-15233:
I have drafted the PR https://github.com/apache/camel/pull/3969
> camel-salesforce - CometDReplayExtension does not keep replayId for each
> message/channel
>
>
> Key: CAMEL-15233
> URL: https://issues.apache.org/jira/browse/CAMEL-15233
> Project: Camel
> Issue Type: Bug
> Components: camel-salesforce
>Reporter: Edgar Chernick
>Priority: Major
> Fix For: 2.25.2, 3.5.0
>
>
> CometDReplayExtension class try to read the replayId from the message by
> doing
> {code}
> final Object value = message.get(EXTENSION_NAME);
> {code}
> However, the replayId (based on this
> [https://developer.salesforce.com/docs/atlas.en-us.api_streaming.meta/api_streaming/using_streaming_api_durability.htm])
> is actually within data -> event -> replayId.
> By doing the following (the same thing the salesforce consumer does
> https://github.com/apache/camel/blob/master/components/camel-salesforce/camel-salesforce-component/src/main/java/org/apache/camel/component/salesforce/SalesforceConsumer.java#L250)
> {code}
> final Map data = (Map) message.get("data");
> final Map event = (Map) data.get("event");
> final Object value = event.get("replayId");
> {code}
> I was able to properly fetch the replayId from the message.
> Since the current version does not do this properly, If the component loses
> the connection and has to subscribe again it will use the replayid value from
> the endpoint which it will be outdated if any message was read before the
> connection failure.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (CAMEL-15233) camel-salesforce - CometDReplayExtension does not keep replayId for each message/channel
[
https://issues.apache.org/jira/browse/CAMEL-15233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17149742#comment-17149742
]
Edgar Chernick edited comment on CAMEL-15233 at 7/1/20, 11:34 PM:
--
Hi guys, I've tried fixing the issue myself here
https://github.com/apache/camel/compare/master...edgarc-ciandt:master. Would
you guys mind taking a look and code reviewing it ?
I have deleted the CometDReplayExtension class and used another implementation
of it from
https://github.com/forcedotcom/EMP-Connector/blob/master/src/main/java/com/salesforce/emp/connector/ReplayExtension.java
I have also created some unit tests to cover it.
Another question. I would need to have this fixed on 2.25, do you guys think
it's possible or the fix will probably be applied to the latest version only ?
was (Author: edgarc):
Hi guys, I've tried fixing the issue myself here
https://github.com/apache/camel/compare/master...edgarc-ciandt:master. Would
you guys mind taking a look and code reviewing it ?
I have deleted the CometDReplayExtension class and used another implementation
of it from
https://github.com/forcedotcom/EMP-Connector/blob/master/src/main/java/com/salesforce/emp/connector/ReplayExtension.java
I have also created some unit tests to cover it.
Another question. I would need to have this fixed on 2.25, do you guys think
it's possible or the fix will be applied to the latest version only ?
> camel-salesforce - CometDReplayExtension does not keep replayId for each
> message/channel
>
>
> Key: CAMEL-15233
> URL: https://issues.apache.org/jira/browse/CAMEL-15233
> Project: Camel
> Issue Type: Bug
> Components: camel-salesforce
>Reporter: Edgar Chernick
>Priority: Major
>
> CometDReplayExtension class try to read the replayId from the message by
> doing
> {code}
> final Object value = message.get(EXTENSION_NAME);
> {code}
> However, the replayId (based on this
> [https://developer.salesforce.com/docs/atlas.en-us.api_streaming.meta/api_streaming/using_streaming_api_durability.htm])
> is actually within data -> event -> replayId.
> By doing the following (the same thing the salesforce consumer does
> https://github.com/apache/camel/blob/master/components/camel-salesforce/camel-salesforce-component/src/main/java/org/apache/camel/component/salesforce/SalesforceConsumer.java#L250)
> {code}
> final Map data = (Map) message.get("data");
> final Map event = (Map) data.get("event");
> final Object value = event.get("replayId");
> {code}
> I was able to properly fetch the replayId from the message.
> Since the current version does not do this properly, If the component loses
> the connection and has to subscribe again it will use the replayid value from
> the endpoint which it will be outdated if any message was read before the
> connection failure.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CAMEL-15233) camel-salesforce - CometDReplayExtension does not keep replayId for each message/channel
[
https://issues.apache.org/jira/browse/CAMEL-15233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17149742#comment-17149742
]
Edgar Chernick commented on CAMEL-15233:
Hi guys, I've tried fixing the issue myself here
https://github.com/apache/camel/compare/master...edgarc-ciandt:master. Would
you guys mind taking a look and code reviewing it ?
I have deleted the CometDReplayExtension class and used another implementation
of it from
https://github.com/forcedotcom/EMP-Connector/blob/master/src/main/java/com/salesforce/emp/connector/ReplayExtension.java
I have also created some unit tests to cover it.
Another question. I would need to have this fixed on 2.25, do you guys think
it's possible or the fix will be applied to the latest version only ?
> camel-salesforce - CometDReplayExtension does not keep replayId for each
> message/channel
>
>
> Key: CAMEL-15233
> URL: https://issues.apache.org/jira/browse/CAMEL-15233
> Project: Camel
> Issue Type: Bug
> Components: camel-salesforce
>Reporter: Edgar Chernick
>Priority: Major
>
> CometDReplayExtension class try to read the replayId from the message by
> doing
> {code}
> final Object value = message.get(EXTENSION_NAME);
> {code}
> However, the replayId (based on this
> [https://developer.salesforce.com/docs/atlas.en-us.api_streaming.meta/api_streaming/using_streaming_api_durability.htm])
> is actually within data -> event -> replayId.
> By doing the following (the same thing the salesforce consumer does
> https://github.com/apache/camel/blob/master/components/camel-salesforce/camel-salesforce-component/src/main/java/org/apache/camel/component/salesforce/SalesforceConsumer.java#L250)
> {code}
> final Map data = (Map) message.get("data");
> final Map event = (Map) data.get("event");
> final Object value = event.get("replayId");
> {code}
> I was able to properly fetch the replayId from the message.
> Since the current version does not do this properly, If the component loses
> the connection and has to subscribe again it will use the replayid value from
> the endpoint which it will be outdated if any message was read before the
> connection failure.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CAMEL-15233) camel-salesforce - CometDReplayExtension does not keep replayId for each message/channel
[
https://issues.apache.org/jira/browse/CAMEL-15233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17143857#comment-17143857
]
EDGAR CHERNICK commented on CAMEL-15233:
I looked into open bugs for camel-saleforce and I found one that might be
related to this (I've linked it to this card). However that card is unresolved.
I'm using version 2.25.1. But looking in version 3.4.0 I can see the
CometDReplayExtension class has not been changed.
> camel-salesforce - CometDReplayExtension does not keep replayId for each
> message/channel
>
>
> Key: CAMEL-15233
> URL: https://issues.apache.org/jira/browse/CAMEL-15233
> Project: Camel
> Issue Type: Bug
> Components: camel-salesforce
>Reporter: EDGAR CHERNICK
>Priority: Major
>
> CometDReplayExtension class try to read the replayId from the message by
> doing
> {code}
> final Object value = message.get(EXTENSION_NAME);
> {code}
> However, the replayId (based on this
> [https://developer.salesforce.com/docs/atlas.en-us.api_streaming.meta/api_streaming/using_streaming_api_durability.htm])
> is actually within data -> event -> replayId.
> By doing the following (the same thing the salesforce consumer does
> https://github.com/apache/camel/blob/master/components/camel-salesforce/camel-salesforce-component/src/main/java/org/apache/camel/component/salesforce/SalesforceConsumer.java#L250)
> {code}
> final Map data = (Map) message.get("data");
> final Map event = (Map) data.get("event");
> final Object value = event.get("replayId");
> {code}
> I was able to properly fetch the replayId from the message.
> Since the current version does not do this properly, If the component loses
> the connection and has to subscribe again it will use the replayid value from
> the endpoint which it will be outdated if any message was read before the
> connection failure.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CAMEL-15233) CometDReplayExtension does not keep replayId for each message/channel
[
https://issues.apache.org/jira/browse/CAMEL-15233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
EDGAR CHERNICK updated CAMEL-15233:
---
Description:
CometDReplayExtension class try to read the replayId from the message by doing
{code}
final Object value = message.get(EXTENSION_NAME);
{code}
However, the replayId (based on this
[https://developer.salesforce.com/docs/atlas.en-us.api_streaming.meta/api_streaming/using_streaming_api_durability.htm])
is actually within data -> event -> replayId.
By doing the following (the same thing the salesforce consumer does
https://github.com/apache/camel/blob/master/components/camel-salesforce/camel-salesforce-component/src/main/java/org/apache/camel/component/salesforce/SalesforceConsumer.java#L250)
{code}
final Map data = (Map) message.get("data");
final Map event = (Map) data.get("event");
final Object value = event.get("replayId");
{code}
I was able to properly fetch the replayId from the message.
Since the current version does not do this properly, If the component loses
the connection and has to subscribe again it will use the replayid value from
the endpoint which it will be outdated if any message was read before the
connection failure.
was:
CometDReplayExtension class try to read the replayId from the message by doing
{code}
final Object value = message.get(EXTENSION_NAME);
{code}
However, the replayId (based on this
[https://developer.salesforce.com/docs/atlas.en-us.api_streaming.meta/api_streaming/using_streaming_api_durability.htm])
is actually within data -> event -> replayId.
By doing the following
{code}
final Map data = (Map) message.get("data");
final Map event = (Map) data.get("event");
final Object value = event.get("replayId");
{code}
I was able to properly fetch the replayId from the message.
Since the current version does not do this properly, If the component loses
the connection and has to subscribe again it will use the replayid value from
the endpoint which it will be outdated if any message was read before the
connection failure.
> CometDReplayExtension does not keep replayId for each message/channel
> -
>
> Key: CAMEL-15233
> URL: https://issues.apache.org/jira/browse/CAMEL-15233
> Project: Camel
> Issue Type: Bug
> Components: camel-salesforce
>Reporter: EDGAR CHERNICK
>Priority: Major
>
> CometDReplayExtension class try to read the replayId from the message by
> doing
> {code}
> final Object value = message.get(EXTENSION_NAME);
> {code}
> However, the replayId (based on this
> [https://developer.salesforce.com/docs/atlas.en-us.api_streaming.meta/api_streaming/using_streaming_api_durability.htm])
> is actually within data -> event -> replayId.
> By doing the following (the same thing the salesforce consumer does
> https://github.com/apache/camel/blob/master/components/camel-salesforce/camel-salesforce-component/src/main/java/org/apache/camel/component/salesforce/SalesforceConsumer.java#L250)
> {code}
> final Map data = (Map) message.get("data");
> final Map event = (Map) data.get("event");
> final Object value = event.get("replayId");
> {code}
> I was able to properly fetch the replayId from the message.
> Since the current version does not do this properly, If the component loses
> the connection and has to subscribe again it will use the replayid value from
> the endpoint which it will be outdated if any message was read before the
> connection failure.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CAMEL-15233) CometDReplayExtension does not keep replayId for each message/channel
[
https://issues.apache.org/jira/browse/CAMEL-15233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
EDGAR CHERNICK updated CAMEL-15233:
---
Description:
CometDReplayExtension class try to read the replayId from the message by doing
{code}
final Object value = message.get(EXTENSION_NAME);
{code}
However, the replayId (based on this
[https://developer.salesforce.com/docs/atlas.en-us.api_streaming.meta/api_streaming/using_streaming_api_durability.htm])
is actually within data -> event -> replayId.
By doing the following
{code}
final Map data = (Map) message.get("data");
final Map event = (Map) data.get("event");
final Object value = event.get("replayId");
{code}
I was able to properly fetch the replayId from the message.
Since the current version does not do this properly, If the component loses
the connection and has to subscribe again it will use the replayid value from
the endpoint which it will be outdated if any message was read before the
connection failure.
was:
CometDReplayExtension class try to read the replayId from the message by doing
final Object value = message.get(EXTENSION_NAME);
However, the replayId (based on this
[https://developer.salesforce.com/docs/atlas.en-us.api_streaming.meta/api_streaming/using_streaming_api_durability.htm])
is actually within data -> event -> replayId.
By doing the following
final Map data = (Map) message.get("data");
final Map event = (Map) data.get("event");
final Object value = event.get("replayId");
I was able to properly fetch the replayId from the message.
Since the current version does not do this properly, If the component loses
the connection and has to subscribe again it will use the replayid value from
the endpoint which it will be outdated if any message was read before the
connection failure.
> CometDReplayExtension does not keep replayId for each message/channel
> -
>
> Key: CAMEL-15233
> URL: https://issues.apache.org/jira/browse/CAMEL-15233
> Project: Camel
> Issue Type: Bug
> Components: camel-salesforce
>Reporter: EDGAR CHERNICK
>Priority: Major
>
> CometDReplayExtension class try to read the replayId from the message by
> doing
> {code}
> final Object value = message.get(EXTENSION_NAME);
> {code}
> However, the replayId (based on this
> [https://developer.salesforce.com/docs/atlas.en-us.api_streaming.meta/api_streaming/using_streaming_api_durability.htm])
> is actually within data -> event -> replayId.
> By doing the following
> {code}
> final Map data = (Map) message.get("data");
> final Map event = (Map) data.get("event");
> final Object value = event.get("replayId");
> {code}
> I was able to properly fetch the replayId from the message.
> Since the current version does not do this properly, If the component loses
> the connection and has to subscribe again it will use the replayid value from
> the endpoint which it will be outdated if any message was read before the
> connection failure.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CAMEL-15233) CometDReplayExtension does not keep replayId for each message/channel
[
https://issues.apache.org/jira/browse/CAMEL-15233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
EDGAR CHERNICK updated CAMEL-15233:
---
Description:
CometDReplayExtension class try to read the replayId from the message by doing
{code}
final Object value = message.get(EXTENSION_NAME);
{code}
However, the replayId (based on this
[https://developer.salesforce.com/docs/atlas.en-us.api_streaming.meta/api_streaming/using_streaming_api_durability.htm])
is actually within data -> event -> replayId.
By doing the following
{code}
final Map data = (Map) message.get("data");
final Map event = (Map) data.get("event");
final Object value = event.get("replayId");
{code}
I was able to properly fetch the replayId from the message.
Since the current version does not do this properly, If the component loses
the connection and has to subscribe again it will use the replayid value from
the endpoint which it will be outdated if any message was read before the
connection failure.
was:
CometDReplayExtension class try to read the replayId from the message by doing
{code}
final Object value = message.get(EXTENSION_NAME);
{code}
However, the replayId (based on this
[https://developer.salesforce.com/docs/atlas.en-us.api_streaming.meta/api_streaming/using_streaming_api_durability.htm])
is actually within data -> event -> replayId.
By doing the following
{code}
final Map data = (Map) message.get("data");
final Map event = (Map) data.get("event");
final Object value = event.get("replayId");
{code}
I was able to properly fetch the replayId from the message.
Since the current version does not do this properly, If the component loses
the connection and has to subscribe again it will use the replayid value from
the endpoint which it will be outdated if any message was read before the
connection failure.
> CometDReplayExtension does not keep replayId for each message/channel
> -
>
> Key: CAMEL-15233
> URL: https://issues.apache.org/jira/browse/CAMEL-15233
> Project: Camel
> Issue Type: Bug
> Components: camel-salesforce
>Reporter: EDGAR CHERNICK
>Priority: Major
>
> CometDReplayExtension class try to read the replayId from the message by
> doing
> {code}
> final Object value = message.get(EXTENSION_NAME);
> {code}
> However, the replayId (based on this
> [https://developer.salesforce.com/docs/atlas.en-us.api_streaming.meta/api_streaming/using_streaming_api_durability.htm])
> is actually within data -> event -> replayId.
> By doing the following
> {code}
> final Map data = (Map) message.get("data");
> final Map event = (Map) data.get("event");
> final Object value = event.get("replayId");
> {code}
> I was able to properly fetch the replayId from the message.
> Since the current version does not do this properly, If the component loses
> the connection and has to subscribe again it will use the replayid value from
> the endpoint which it will be outdated if any message was read before the
> connection failure.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CAMEL-15233) CometDReplayExtension does not keep replayId for each message/channel
[
https://issues.apache.org/jira/browse/CAMEL-15233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
EDGAR CHERNICK updated CAMEL-15233:
---
Description:
CometDReplayExtension class try to read the replayId from the message by doing
final Object value = message.get(EXTENSION_NAME);
However, the replayId (based on this
[https://developer.salesforce.com/docs/atlas.en-us.api_streaming.meta/api_streaming/using_streaming_api_durability.htm])
is actually within data -> event -> replayId.
By doing the following
final Map data = (Map) message.get("data");
final Map event = (Map) data.get("event");
final Object value = event.get("replayId");
I was able to properly fetch the replayId from the message.
Since the current version does not do this properly, If the component loses
the connection and has to subscribe again it will use the replayid value from
the endpoint which it will be outdated if any message was read before the
connection failure.
was:
CometDReplayExtension class try to read the replayId from the message by doing
final Object value = message.get(EXTENSION_NAME);
However, the replayId (based on this
[https://developer.salesforce.com/docs/atlas.en-us.api_streaming.meta/api_streaming/using_streaming_api_durability.htm])
is actually within data -> event -> replayId.
By doing the following
final Map data = (Map) message.get("data");
final Map event = (Map) data.get("event");
final Object value = event.get("replayId");
I was able to properly fetch the replayId from the message.
Since the current version does not do this properly, If the component loses the
connection and has to subscribe again it will use the replayid value from the
endpoint which it will be outdated if any message was read before the
connection failure.
> CometDReplayExtension does not keep replayId for each message/channel
> -
>
> Key: CAMEL-15233
> URL: https://issues.apache.org/jira/browse/CAMEL-15233
> Project: Camel
> Issue Type: Bug
> Components: camel-salesforce
>Reporter: EDGAR CHERNICK
>Priority: Major
>
> CometDReplayExtension class try to read the replayId from the message by
> doing
> final Object value = message.get(EXTENSION_NAME);
> However, the replayId (based on this
> [https://developer.salesforce.com/docs/atlas.en-us.api_streaming.meta/api_streaming/using_streaming_api_durability.htm])
> is actually within data -> event -> replayId.
> By doing the following
> final Map data = (Map) message.get("data");
> final Map event = (Map) data.get("event");
> final Object value = event.get("replayId");
> I was able to properly fetch the replayId from the message.
> Since the current version does not do this properly, If the component loses
> the connection and has to subscribe again it will use the replayid value from
> the endpoint which it will be outdated if any message was read before the
> connection failure.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CAMEL-15233) CometDReplayExtension does not keep replayId for each message/channel
EDGAR CHERNICK created CAMEL-15233:
--
Summary: CometDReplayExtension does not keep replayId for each
message/channel
Key: CAMEL-15233
URL: https://issues.apache.org/jira/browse/CAMEL-15233
Project: Camel
Issue Type: Bug
Components: camel-salesforce
Reporter: EDGAR CHERNICK
CometDReplayExtension class try to read the replayId from the message by doing
final Object value = message.get(EXTENSION_NAME);
However, the replayId (based on this
[https://developer.salesforce.com/docs/atlas.en-us.api_streaming.meta/api_streaming/using_streaming_api_durability.htm])
is actually within data -> event -> replayId.
By doing the following
final Map data = (Map) message.get("data");
final Map event = (Map) data.get("event");
final Object value = event.get("replayId");
I was able to properly fetch the replayId from the message.
Since the current version does not do this properly, If the component loses the
connection and has to subscribe again it will use the replayid value from the
endpoint which it will be outdated if any message was read before the
connection failure.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
