[jira] [Commented] (CAMEL-19409) camel-salesforce - Can not re-subscribe to CDC channel data/ChangeEvents
[ https://issues.apache.org/jira/browse/CAMEL-19409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790218#comment-17790218 ] Jesse Sightler commented on CAMEL-19409: For me, that was the scenarios that caused issues. Once one of the VMs called .logout(), the token would no longer be valid and others would fail. This means another precondition is that sfdc is giving the same auth token to all clients. I'm not sure if an sfdc setting controls that behavior or not, but I've seen it a lot with our clients. > camel-salesforce - Can not re-subscribe to CDC channel data/ChangeEvents > > > Key: CAMEL-19409 > URL: https://issues.apache.org/jira/browse/CAMEL-19409 > Project: Camel > Issue Type: Bug > Components: camel-salesforce >Affects Versions: 3.18.3, 3.19.0 >Reporter: Iva >Priority: Major > Fix For: 4.x > > Attachments: stack-with-pr.txt, stacktrace.txt > > > Hello, I have problem with connection to the salesforce channel ChangeEvents. > I am using quarkus - version 2.13.7 and camel with version 3.18.3 and when an > error occurs my application is not re-subscribing to the channel after that. > Do you know if it is problem from the camel version or do you have any idea > how I can fix it? Thank you in advance > Edit 1: You can find the stacktrace of the exception in this file > [^stacktrace.txt] > The problem seems to be fixed after a restart of the pod but it is not > relevant solution. I have seen similar issue that is said to be fixed in > version 3.14 but it looks like now I have the same problem in latest version > https://issues.apache.org/jira/browse/CAMEL-16370 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-19409) camel-salesforce - Can not re-subscribe to CDC channel data/ChangeEvents
[ https://issues.apache.org/jira/browse/CAMEL-19409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790162#comment-17790162 ] Jesse Sightler commented on CAMEL-19409: Were these running in separate VMs? > camel-salesforce - Can not re-subscribe to CDC channel data/ChangeEvents > > > Key: CAMEL-19409 > URL: https://issues.apache.org/jira/browse/CAMEL-19409 > Project: Camel > Issue Type: Bug > Components: camel-salesforce >Affects Versions: 3.18.3, 3.19.0 >Reporter: Iva >Priority: Major > Fix For: 4.x > > Attachments: stack-with-pr.txt, stacktrace.txt > > > Hello, I have problem with connection to the salesforce channel ChangeEvents. > I am using quarkus - version 2.13.7 and camel with version 3.18.3 and when an > error occurs my application is not re-subscribing to the channel after that. > Do you know if it is problem from the camel version or do you have any idea > how I can fix it? Thank you in advance > Edit 1: You can find the stacktrace of the exception in this file > [^stacktrace.txt] > The problem seems to be fixed after a restart of the pod but it is not > relevant solution. I have seen similar issue that is said to be fixed in > version 3.14 but it looks like now I have the same problem in latest version > https://issues.apache.org/jira/browse/CAMEL-16370 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-19783) camel-salesforce - grpc will not resubscribe on connection failure if no messages have been received
[
https://issues.apache.org/jira/browse/CAMEL-19783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17761395#comment-17761395
]
Jesse Sightler commented on CAMEL-19783:
[~davsclaus] Thank you... I have taken a shot at it:
https://github.com/apache/camel/pull/11285
> camel-salesforce - grpc will not resubscribe on connection failure if no
> messages have been received
>
>
> Key: CAMEL-19783
> URL: https://issues.apache.org/jira/browse/CAMEL-19783
> Project: Camel
> Issue Type: Bug
> Components: camel-salesforce
>Affects Versions: 4.0.0
>Reporter: Jesse Sightler
>Priority: Major
>
> Relevant log:
> {code}
> : io.grpc.StatusRuntimeException: UNAUTHENTICATED: An authentication
> exception occurred. Provide valid authentication via metadata headers. rpcId:
> d493e4d9-9ac9-4723-a9d9-9179e4d58067
> at io.grpc.Status.asRuntimeException(Status.java:539)
> at
> io.grpc.stub.ClientCalls$StreamObserverToCallListenerAdapter.onClose(ClientCalls.java:491)
> at
> io.grpc.internal.DelayedClientCall$DelayedListener$3.run(DelayedClientCall.java:489)
> at
> io.grpc.internal.DelayedClientCall$DelayedListener.delayOrExecute(DelayedClientCall.java:453)
> at
> io.grpc.internal.DelayedClientCall$DelayedListener.onClose(DelayedClientCall.java:486)
> at
> io.grpc.internal.ClientCallImpl.closeObserver(ClientCallImpl.java:567)
> at io.grpc.internal.ClientCallImpl.access$300(ClientCallImpl.java:71)
> at
> io.grpc.internal.ClientCallImpl$ClientStreamListenerImpl$1StreamClosed.runInternal(ClientCallImpl.java:735)
> at
> io.grpc.internal.ClientCallImpl$ClientStreamListenerImpl$1StreamClosed.runInContext(ClientCallImpl.java:716)
> at io.grpc.internal.ContextRunnable.run(ContextRunnable.java:37)
> at
> io.grpc.internal.SerializingExecutor.run(SerializingExecutor.java:133)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at java.base/java.lang.Thread.run(Thread.java:833)
> 2023-08-23T09:01:12.618+ ERROR 1 --- [grpc-default-executor-1]
> org.apache.camel.component.salesforce.in : camel-breadcrumb-id=""
> request-id="" Trailers:
> 2023-08-23T09:01:12.618+ ERROR 1 --- [grpc-default-executor-1]
> org.apache.camel.component.salesforce.in : camel-breadcrumb-id=""
> request-id="" Trailer: date, Value: Wed, 23 Aug 2023 09:01:12 GMT
> 2023-08-23T09:01:12.618+ ERROR 1 --- [grpc-default-executor-1]
> org.apache.camel.component.salesforce.in : camel-breadcrumb-id=""
> request-id="" Trailer: content-type, Value: application/grpc
> 2023-08-23T09:01:12.618+ ERROR 1 --- [grpc-default-executor-1]
> org.apache.camel.component.salesforce.in : camel-breadcrumb-id=""
> request-id="" Trailer: rpc-id, Value: d493e4d9-9ac9-4723-a9d9-9179e4d58067
> 2023-08-23T09:01:12.618+ ERROR 1 --- [grpc-default-executor-1]
> org.apache.camel.component.salesforce.in : camel-breadcrumb-id=""
> request-id="" Trailer: error-code, Value:
> sfdc.platform.eventbus.grpc.service.auth.error
> 2023-08-23T09:01:12.619+ ERROR 1 --- [grpc-default-executor-1]
> org.apache.camel.component.salesforce.in : camel-breadcrumb-id=""
> request-id="" Trailer: type, Value: Subscribe
> 2023-08-23T09:01:12.619+ ERROR 1 --- [grpc-default-executor-1]
> org.apache.camel.component.salesforce.in : camel-breadcrumb-id=""
> request-id="" attempting login
> 2023-08-23T09:01:12.986+ INFO 1 --- [main-EventThread]
> org.apache.camel.component.salesforce.in : camel-breadcrumb-id=""
> request-id="" Login successful
> 2023-08-23T09:01:12.986+ INFO 1 --- [main-EventThread]
> com.redhat.sfdc.tools.outboundmessaging. : camel-breadcrumb-id=""
> request-id="" Forced login complete.
> 2023-08-23T09:01:12.986+ WARN 1 --- [grpc-default-executor-1]
> org.apache.camel.component.salesforce.in : camel-breadcrumb-id=""
> request-id="" Not re-subscribing after error because replayId is null. Topic:
> /event/IE_Outbound__e
> {code}
> The text "Not re-subscribing after error because replayId is null" is printed
> by the private class FetchResponseObserver. The replayId is also private and
> appears to only be set by the class itself when it receives a message. It is
> not set based upon the initialReplayId and it also will not make reasonable
> assumptions if there was no initialReplayId (eg, started with LATEST).
> As a result, it is extremely easy for this consumer to end up in a state with
> few obvious error messages, but no messages being consumed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAMEL-19783) grpc will not resubscribe on connection failure if no messages have been received
Jesse Sightler created CAMEL-19783:
--
Summary: grpc will not resubscribe on connection failure if no
messages have been received
Key: CAMEL-19783
URL: https://issues.apache.org/jira/browse/CAMEL-19783
Project: Camel
Issue Type: Bug
Components: camel-salesforce
Affects Versions: 4.0.0
Reporter: Jesse Sightler
Relevant log:
{code}
: io.grpc.StatusRuntimeException: UNAUTHENTICATED: An authentication exception
occurred. Provide valid authentication via metadata headers. rpcId:
d493e4d9-9ac9-4723-a9d9-9179e4d58067
at io.grpc.Status.asRuntimeException(Status.java:539)
at
io.grpc.stub.ClientCalls$StreamObserverToCallListenerAdapter.onClose(ClientCalls.java:491)
at
io.grpc.internal.DelayedClientCall$DelayedListener$3.run(DelayedClientCall.java:489)
at
io.grpc.internal.DelayedClientCall$DelayedListener.delayOrExecute(DelayedClientCall.java:453)
at
io.grpc.internal.DelayedClientCall$DelayedListener.onClose(DelayedClientCall.java:486)
at
io.grpc.internal.ClientCallImpl.closeObserver(ClientCallImpl.java:567)
at io.grpc.internal.ClientCallImpl.access$300(ClientCallImpl.java:71)
at
io.grpc.internal.ClientCallImpl$ClientStreamListenerImpl$1StreamClosed.runInternal(ClientCallImpl.java:735)
at
io.grpc.internal.ClientCallImpl$ClientStreamListenerImpl$1StreamClosed.runInContext(ClientCallImpl.java:716)
at io.grpc.internal.ContextRunnable.run(ContextRunnable.java:37)
at
io.grpc.internal.SerializingExecutor.run(SerializingExecutor.java:133)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at java.base/java.lang.Thread.run(Thread.java:833)
2023-08-23T09:01:12.618+ ERROR 1 --- [grpc-default-executor-1]
org.apache.camel.component.salesforce.in : camel-breadcrumb-id="" request-id=""
Trailers:
2023-08-23T09:01:12.618+ ERROR 1 --- [grpc-default-executor-1]
org.apache.camel.component.salesforce.in : camel-breadcrumb-id="" request-id=""
Trailer: date, Value: Wed, 23 Aug 2023 09:01:12 GMT
2023-08-23T09:01:12.618+ ERROR 1 --- [grpc-default-executor-1]
org.apache.camel.component.salesforce.in : camel-breadcrumb-id="" request-id=""
Trailer: content-type, Value: application/grpc
2023-08-23T09:01:12.618+ ERROR 1 --- [grpc-default-executor-1]
org.apache.camel.component.salesforce.in : camel-breadcrumb-id="" request-id=""
Trailer: rpc-id, Value: d493e4d9-9ac9-4723-a9d9-9179e4d58067
2023-08-23T09:01:12.618+ ERROR 1 --- [grpc-default-executor-1]
org.apache.camel.component.salesforce.in : camel-breadcrumb-id="" request-id=""
Trailer: error-code, Value: sfdc.platform.eventbus.grpc.service.auth.error
2023-08-23T09:01:12.619+ ERROR 1 --- [grpc-default-executor-1]
org.apache.camel.component.salesforce.in : camel-breadcrumb-id="" request-id=""
Trailer: type, Value: Subscribe
2023-08-23T09:01:12.619+ ERROR 1 --- [grpc-default-executor-1]
org.apache.camel.component.salesforce.in : camel-breadcrumb-id="" request-id=""
attempting login
2023-08-23T09:01:12.986+ INFO 1 --- [main-EventThread]
org.apache.camel.component.salesforce.in : camel-breadcrumb-id="" request-id=""
Login successful
2023-08-23T09:01:12.986+ INFO 1 --- [main-EventThread]
com.redhat.sfdc.tools.outboundmessaging. : camel-breadcrumb-id="" request-id=""
Forced login complete.
2023-08-23T09:01:12.986+ WARN 1 --- [grpc-default-executor-1]
org.apache.camel.component.salesforce.in : camel-breadcrumb-id="" request-id=""
Not re-subscribing after error because replayId is null. Topic:
/event/IE_Outbound__e
{code}
The text "Not re-subscribing after error because replayId is null" is printed
by the private class FetchResponseObserver. The replayId is also private and
appears to only be set by the class itself when it receives a message. It is
not set based upon the initialReplayId and it also will not make reasonable
assumptions if there was no initialReplayId (eg, started with LATEST).
As a result, it is extremely easy for this consumer to end up in a state with
few obvious error messages, but no messages being consumed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-19409) camel-salesforce - Can not re-subscribe to CDC channel data/ChangeEvents
[
https://issues.apache.org/jira/browse/CAMEL-19409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17737345#comment-17737345
]
Jesse Sightler commented on CAMEL-19409:
I made a few changes:
{{code}}
-} else if
(failureReason.equals(AUTHENTICATION_INVALID)) {
+} else if (error != null &&
error.equals(AUTHENTICATION_INVALID)) {
+LOG.info(
+"attempting login due to handshake error:
403 -> 401::Authentication invalid");
+attemptLoginUntilSuccessful();
+subscribe(topicName, consumer, true);
+} else if (msg != null &&
msg.equals(AUTHENTICATION_INVALID)) {
+LOG.info(
+"attempting login due to handshake error:
403 -> 401::Authentication invalid");
+attemptLoginUntilSuccessful();
+subscribe(topicName, consumer, true);
+} else if (failureReason != null &&
failureReason.equals(AUTHENTICATION_INVALID)) {
{{code}}
With these changes, it seems to momentraily get stuck in a loop trying to auth.
However, after some minutes it does seem to recover on its own. I guess that is
an improvement? :)
IMO, the ideal response in this state is actually to restart the whole
connection instead of just subscribing again, though. Just subscribing again on
the same connection doesn't seem to be enough, as the underlying connection has
been invalidated by the other end.
> camel-salesforce - Can not re-subscribe to CDC channel data/ChangeEvents
>
>
> Key: CAMEL-19409
> URL: https://issues.apache.org/jira/browse/CAMEL-19409
> Project: Camel
> Issue Type: Bug
> Components: camel-salesforce
>Affects Versions: 3.18.3, 3.19.0
>Reporter: Iva
>Priority: Major
> Fix For: 3.20.7, 3.21.1, 4.0.0
>
> Attachments: stack-with-pr.txt, stacktrace.txt
>
>
> Hello, I have problem with connection to the salesforce channel ChangeEvents.
> I am using quarkus - version 2.13.7 and camel with version 3.18.3 and when an
> error occurs my application is not re-subscribing to the channel after that.
> Do you know if it is problem from the camel version or do you have any idea
> how I can fix it? Thank you in advance
> Edit 1: You can find the stacktrace of the exception in this file
> [^stacktrace.txt]
> The problem seems to be fixed after a restart of the pod but it is not
> relevant solution. I have seen similar issue that is said to be fixed in
> version 3.14 but it looks like now I have the same problem in latest version
> https://issues.apache.org/jira/browse/CAMEL-16370
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-19409) camel-salesforce - Can not re-subscribe to CDC channel data/ChangeEvents
[ https://issues.apache.org/jira/browse/CAMEL-19409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17737340#comment-17737340 ] Jesse Sightler commented on CAMEL-19409: Hi [~jeremyross] - I have tried the PR, and it failed in a different way. It seems that the error text is in msg, and failureReason is null. > camel-salesforce - Can not re-subscribe to CDC channel data/ChangeEvents > > > Key: CAMEL-19409 > URL: https://issues.apache.org/jira/browse/CAMEL-19409 > Project: Camel > Issue Type: Bug > Components: camel-salesforce >Affects Versions: 3.18.3, 3.19.0 >Reporter: Iva >Priority: Major > Fix For: 3.20.7, 3.21.1, 4.0.0 > > Attachments: stack-with-pr.txt, stacktrace.txt > > > Hello, I have problem with connection to the salesforce channel ChangeEvents. > I am using quarkus - version 2.13.7 and camel with version 3.18.3 and when an > error occurs my application is not re-subscribing to the channel after that. > Do you know if it is problem from the camel version or do you have any idea > how I can fix it? Thank you in advance > Edit 1: You can find the stacktrace of the exception in this file > [^stacktrace.txt] > The problem seems to be fixed after a restart of the pod but it is not > relevant solution. I have seen similar issue that is said to be fixed in > version 3.14 but it looks like now I have the same problem in latest version > https://issues.apache.org/jira/browse/CAMEL-16370 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-19409) camel-salesforce - Can not re-subscribe to CDC channel data/ChangeEvents
[ https://issues.apache.org/jira/browse/CAMEL-19409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jesse Sightler updated CAMEL-19409: --- Attachment: stack-with-pr.txt > camel-salesforce - Can not re-subscribe to CDC channel data/ChangeEvents > > > Key: CAMEL-19409 > URL: https://issues.apache.org/jira/browse/CAMEL-19409 > Project: Camel > Issue Type: Bug > Components: camel-salesforce >Affects Versions: 3.18.3, 3.19.0 >Reporter: Iva >Priority: Major > Fix For: 3.20.7, 3.21.1, 4.0.0 > > Attachments: stack-with-pr.txt, stacktrace.txt > > > Hello, I have problem with connection to the salesforce channel ChangeEvents. > I am using quarkus - version 2.13.7 and camel with version 3.18.3 and when an > error occurs my application is not re-subscribing to the channel after that. > Do you know if it is problem from the camel version or do you have any idea > how I can fix it? Thank you in advance > Edit 1: You can find the stacktrace of the exception in this file > [^stacktrace.txt] > The problem seems to be fixed after a restart of the pod but it is not > relevant solution. I have seen similar issue that is said to be fixed in > version 3.14 but it looks like now I have the same problem in latest version > https://issues.apache.org/jira/browse/CAMEL-16370 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-19409) camel-salesforce - Can not re-subscribe to CDC channel data/ChangeEvents
[ https://issues.apache.org/jira/browse/CAMEL-19409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17737311#comment-17737311 ] Jesse Sightler commented on CAMEL-19409: It is reproducible, but the steps are a bit convoluted. # Start multiple processes, at least one of which is running and one has the route defined, but the route is not started # Shutdown the one that is running. This will trigger logout and invalidate the token # Without restarting any processes, tell the one that was stopped to start its routes. At this point, this one will start throwing errors and cannot recover. Interestingly, this means that normal manual intervention steps, like restarting containers, can have damaging consequences. I will try out your PR. FYI - We do plan to look at the pubsub approach with grpc when it is available. I'm not sure if our salesforce instance has it at this time. > camel-salesforce - Can not re-subscribe to CDC channel data/ChangeEvents > > > Key: CAMEL-19409 > URL: https://issues.apache.org/jira/browse/CAMEL-19409 > Project: Camel > Issue Type: Bug > Components: camel-salesforce >Affects Versions: 3.18.3, 3.19.0 >Reporter: Iva >Priority: Major > Fix For: 3.20.7, 3.21.1, 4.0.0 > > Attachments: stacktrace.txt > > > Hello, I have problem with connection to the salesforce channel ChangeEvents. > I am using quarkus - version 2.13.7 and camel with version 3.18.3 and when an > error occurs my application is not re-subscribing to the channel after that. > Do you know if it is problem from the camel version or do you have any idea > how I can fix it? Thank you in advance > Edit 1: You can find the stacktrace of the exception in this file > [^stacktrace.txt] > The problem seems to be fixed after a restart of the pod but it is not > relevant solution. I have seen similar issue that is said to be fixed in > version 3.14 but it looks like now I have the same problem in latest version > https://issues.apache.org/jira/browse/CAMEL-16370 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-19409) camel-salesforce - Can not re-subscribe to CDC channel data/ChangeEvents
[ https://issues.apache.org/jira/browse/CAMEL-19409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17732749#comment-17732749 ] Jesse Sightler commented on CAMEL-19409: I found it was possible to reproduce it by manually logging out the current token while still connected. It would never recover once that happened. > camel-salesforce - Can not re-subscribe to CDC channel data/ChangeEvents > > > Key: CAMEL-19409 > URL: https://issues.apache.org/jira/browse/CAMEL-19409 > Project: Camel > Issue Type: Bug > Components: camel-salesforce >Affects Versions: 3.18.3, 3.19.0 >Reporter: Iva >Priority: Major > Fix For: 3.20.7, 3.21.1, 4.0 > > Attachments: stacktrace.txt > > > Hello, I have problem with connection to the salesforce channel ChangeEvents. > I am using quarkus - version 2.13.7 and camel with version 3.18.3 and when an > error occurs my application is not re-subscribing to the channel after that. > Do you know if it is problem from the camel version or do you have any idea > how I can fix it? Thank you in advance > Edit 1: You can find the stacktrace of the exception in this file > [^stacktrace.txt] > The problem seems to be fixed after a restart of the pod but it is not > relevant solution. I have seen similar issue that is said to be fixed in > version 3.14 but it looks like now I have the same problem in latest version > https://issues.apache.org/jira/browse/CAMEL-16370 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-19409) camel-salesforce - Can not re-subscribe to CDC channel data/ChangeEvents
[ https://issues.apache.org/jira/browse/CAMEL-19409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17732748#comment-17732748 ] Jesse Sightler commented on CAMEL-19409: Yes, in our case we already had the logic to retry by stop/start when we saw unexpectedly low message volume. It just didn't work since the connection wasn't there. I did notice that that code for picking up 401, but for some reason this doesn't seem to recover on its own. > camel-salesforce - Can not re-subscribe to CDC channel data/ChangeEvents > > > Key: CAMEL-19409 > URL: https://issues.apache.org/jira/browse/CAMEL-19409 > Project: Camel > Issue Type: Bug > Components: camel-salesforce >Affects Versions: 3.18.3, 3.19.0 >Reporter: Iva >Priority: Major > Fix For: 3.20.7, 3.21.1, 4.0 > > Attachments: stacktrace.txt > > > Hello, I have problem with connection to the salesforce channel ChangeEvents. > I am using quarkus - version 2.13.7 and camel with version 3.18.3 and when an > error occurs my application is not re-subscribing to the channel after that. > Do you know if it is problem from the camel version or do you have any idea > how I can fix it? Thank you in advance > Edit 1: You can find the stacktrace of the exception in this file > [^stacktrace.txt] > The problem seems to be fixed after a restart of the pod but it is not > relevant solution. I have seen similar issue that is said to be fixed in > version 3.14 but it looks like now I have the same problem in latest version > https://issues.apache.org/jira/browse/CAMEL-16370 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-19409) camel-salesforce - Can not re-subscribe to CDC channel data/ChangeEvents
[ https://issues.apache.org/jira/browse/CAMEL-19409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17730198#comment-17730198 ] Jesse Sightler commented on CAMEL-19409: I have sent a PR here: [https://github.com/apache/camel/pull/10286] One odd thing that I noticed while doing this... subscriptionhelper calls session.logout() during its stop method. Is that intentional? It seems to me that session.logout() is normally called via session.stop() anyway? > camel-salesforce - Can not re-subscribe to CDC channel data/ChangeEvents > > > Key: CAMEL-19409 > URL: https://issues.apache.org/jira/browse/CAMEL-19409 > Project: Camel > Issue Type: Bug > Components: camel-salesforce >Affects Versions: 3.18.3, 3.19.0 >Reporter: Iva >Priority: Minor > Fix For: 3.20.6, 3.21.0, 4.0 > > Attachments: stacktrace.txt > > > Hello, I have problem with connection to the salesforce channel ChangeEvents. > I am using quarkus - version 2.13.7 and camel with version 3.18.3 and when an > error occurs my application is not re-subscribing to the channel after that. > Do you know if it is problem from the camel version or do you have any idea > how I can fix it? Thank you in advance > Edit 1: You can find the stacktrace of the exception in this file > [^stacktrace.txt] > The problem seems to be fixed after a restart of the pod but it is not > relevant solution. I have seen similar issue that is said to be fixed in > version 3.14 but it looks like now I have the same problem in latest version > https://issues.apache.org/jira/browse/CAMEL-16370 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-19409) camel-salesforce - Can not re-subscribe to CDC channel data/ChangeEvents
[ https://issues.apache.org/jira/browse/CAMEL-19409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17730193#comment-17730193 ] Jesse Sightler commented on CAMEL-19409: We are finding that this happens any time that the underlying access token is invalidated. I can work on sending an MR for it. > camel-salesforce - Can not re-subscribe to CDC channel data/ChangeEvents > > > Key: CAMEL-19409 > URL: https://issues.apache.org/jira/browse/CAMEL-19409 > Project: Camel > Issue Type: Bug > Components: camel-salesforce >Affects Versions: 3.18.3, 3.19.0 >Reporter: Iva >Priority: Minor > Fix For: 3.20.6, 3.21.0, 4.0 > > Attachments: stacktrace.txt > > > Hello, I have problem with connection to the salesforce channel ChangeEvents. > I am using quarkus - version 2.13.7 and camel with version 3.18.3 and when an > error occurs my application is not re-subscribing to the channel after that. > Do you know if it is problem from the camel version or do you have any idea > how I can fix it? Thank you in advance > Edit 1: You can find the stacktrace of the exception in this file > [^stacktrace.txt] > The problem seems to be fixed after a restart of the pod but it is not > relevant solution. I have seen similar issue that is said to be fixed in > version 3.14 but it looks like now I have the same problem in latest version > https://issues.apache.org/jira/browse/CAMEL-16370 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-19409) camel-salesforce - Can not re-subscribe to CDC channel data/ChangeEvents
[ https://issues.apache.org/jira/browse/CAMEL-19409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17729492#comment-17729492 ] Jesse Sightler commented on CAMEL-19409: [~davsclaus] We are having the same issue. I have found that restarting SubscriptionHelper via .stop() and .start() resolves the issue, but there are no public methods to do this. Consumer.stop() and Consumer.start() do not do the same thing. Is there some way that this could be exposed via the API? > camel-salesforce - Can not re-subscribe to CDC channel data/ChangeEvents > > > Key: CAMEL-19409 > URL: https://issues.apache.org/jira/browse/CAMEL-19409 > Project: Camel > Issue Type: Bug > Components: camel-salesforce >Reporter: Iva >Priority: Minor > Attachments: stacktrace.txt > > > Hello, I have problem with connection to the salesforce channel ChangeEvents. > I am using quarkus - version 2.13.7 and camel with version 3.18.3 and when an > error occurs my application is not re-subscribing to the channel after that. > Do you know if it is problem from the camel version or do you have any idea > how I can fix it? Thank you in advance > Edit 1: You can find the stacktrace of the exception in this file > [^stacktrace.txt] > The problem seems to be fixed after a restart of the pod but it is not > relevant solution. I have seen similar issue that is said to be fixed in > version 3.14 but it looks like now I have the same problem in latest version > https://issues.apache.org/jira/browse/CAMEL-16370 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-18007) Support rawPayload for composite tree
Jesse Sightler created CAMEL-18007: -- Summary: Support rawPayload for composite tree Key: CAMEL-18007 URL: https://issues.apache.org/jira/browse/CAMEL-18007 Project: Camel Issue Type: Bug Components: camel-salesforce Reporter: Jesse Sightler Currently this can be done with composite, but it would be good to be able to do it with composite tree as well. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (CAMEL-13180) camel-salesforce - Apex calls could support more flexible response parsing
[ https://issues.apache.org/jira/browse/CAMEL-13180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17488495#comment-17488495 ] Jesse Sightler commented on CAMEL-13180: I have tried it out and it looks like this will work fine for us. Thank you for the new feature! > camel-salesforce - Apex calls could support more flexible response parsing > -- > > Key: CAMEL-13180 > URL: https://issues.apache.org/jira/browse/CAMEL-13180 > Project: Camel > Issue Type: New Feature > Components: camel-salesforce >Reporter: Jesse Sightler >Assignee: Jeremy Ross >Priority: Major > Fix For: 3.15.0 > > > The current approach requires following a very strict format for error codes > other than 2xx. This isn't necessarily the case, though, for custom apex > classes. > Ideally, it would be possible to (optionally) handle the parsing in the camel > route itself. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (CAMEL-13180) camel-salesforce - Apex calls could support more flexible response parsing
[ https://issues.apache.org/jira/browse/CAMEL-13180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460951#comment-17460951 ] Jesse Sightler commented on CAMEL-13180: In you apex class, set your body like this: "RestContext.response.responseBody = Blob.valueOf(JSON.serialize(responseBody))" – responseBody is just a Map. Set the status code with RestContext.response.statusCode = 500 > camel-salesforce - Apex calls could support more flexible response parsing > -- > > Key: CAMEL-13180 > URL: https://issues.apache.org/jira/browse/CAMEL-13180 > Project: Camel > Issue Type: New Feature > Components: camel-salesforce >Reporter: Jesse Sightler >Priority: Major > Fix For: 3.x > > > The current approach requires following a very strict format for error codes > other than 2xx. This isn't necessarily the case, though, for custom apex > classes. > Ideally, it would be possible to (optionally) handle the parsing in the camel > route itself. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (CAMEL-13180) camel-salesforce - Apex calls could support more flexible response parsing
[ https://issues.apache.org/jira/browse/CAMEL-13180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17445389#comment-17445389 ] Jesse Sightler commented on CAMEL-13180: Yeah, having it in a header would work fine. > camel-salesforce - Apex calls could support more flexible response parsing > -- > > Key: CAMEL-13180 > URL: https://issues.apache.org/jira/browse/CAMEL-13180 > Project: Camel > Issue Type: New Feature > Components: camel-salesforce >Reporter: Jesse Sightler >Priority: Major > > The current approach requires following a very strict format for error codes > other than 2xx. This isn't necessarily the case, though, for custom apex > classes. > Ideally, it would be possible to (optionally) handle the parsing in the camel > route itself. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (CAMEL-13180) camel-salesforce - Apex calls could support more flexible response parsing
[ https://issues.apache.org/jira/browse/CAMEL-13180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17445331#comment-17445331 ] Jesse Sightler commented on CAMEL-13180: Yes, but the only way that we came up with to do it was to override SalesforceComponent and override the createRestClientFor(final SalesforceEndpoint endpoint) method. We then have it returning an overridden RestClient instance that overrides the createRestException method to offer customized exception handling. Its really tricky and fairly brittle. > camel-salesforce - Apex calls could support more flexible response parsing > -- > > Key: CAMEL-13180 > URL: https://issues.apache.org/jira/browse/CAMEL-13180 > Project: Camel > Issue Type: New Feature > Components: camel-salesforce >Reporter: Jesse Sightler >Priority: Major > > The current approach requires following a very strict format for error codes > other than 2xx. This isn't necessarily the case, though, for custom apex > classes. > Ideally, it would be possible to (optionally) handle the parsing in the camel > route itself. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (CAMEL-13180) camel-salesforce - Apex calls could support more flexible response parsing
[ https://issues.apache.org/jira/browse/CAMEL-13180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17445324#comment-17445324 ] Jesse Sightler commented on CAMEL-13180: Yes, the apex code generates a custom json response for us, and we parse that response body to get the reason in the case of error messages. > camel-salesforce - Apex calls could support more flexible response parsing > -- > > Key: CAMEL-13180 > URL: https://issues.apache.org/jira/browse/CAMEL-13180 > Project: Camel > Issue Type: New Feature > Components: camel-salesforce >Reporter: Jesse Sightler >Priority: Major > > The current approach requires following a very strict format for error codes > other than 2xx. This isn't necessarily the case, though, for custom apex > classes. > Ideally, it would be possible to (optionally) handle the parsing in the camel > route itself. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (CAMEL-13180) camel-salesforce - Apex calls could support more flexible response parsing
[ https://issues.apache.org/jira/browse/CAMEL-13180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17444798#comment-17444798 ] Jesse Sightler commented on CAMEL-13180: Yes, I'd like the http status code, text, and the message body. The body itself could contain custom generated responses, for example. > camel-salesforce - Apex calls could support more flexible response parsing > -- > > Key: CAMEL-13180 > URL: https://issues.apache.org/jira/browse/CAMEL-13180 > Project: Camel > Issue Type: New Feature > Components: camel-salesforce >Reporter: Jesse Sightler >Priority: Major > > The current approach requires following a very strict format for error codes > other than 2xx. This isn't necessarily the case, though, for custom apex > classes. > Ideally, it would be possible to (optionally) handle the parsing in the camel > route itself. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (CAMEL-17189) camel-salesforce forcably overrides the httpclient from SalesforceEndpointConfig
Jesse Sightler created CAMEL-17189: -- Summary: camel-salesforce forcably overrides the httpclient from SalesforceEndpointConfig Key: CAMEL-17189 URL: https://issues.apache.org/jira/browse/CAMEL-17189 Project: Camel Issue Type: Bug Components: camel-salesforce Reporter: Jesse Sightler The comment here seems to imply that there should be a way to manually create an HttpClient in SalesforceEndpointConfig: [https://github.com/apache/camel/blob/main/components/camel-salesforce/camel-salesforce-component/src/main/java/org/apache/camel/component/salesforce/SalesforceComponent.java#L452] However, in reality, the doStart method always overrides the value provided by the configuration without first checking whether or not the config already has an HttpClient configured. This seems to be a bug. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (CAMEL-16086) camel-salesforce - CompositeApiProcessor requires too many fields in RAW mode
[ https://issues.apache.org/jira/browse/CAMEL-16086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17279830#comment-17279830 ] Jesse Sightler commented on CAMEL-16086: [~jeremyross] - I think so. I believe that external ID becomes part of the URL (if present), but it is an optional part of the URL and should not be required IMO. In my case, I have no valid value to supply for this. I think POST is the common case, and IMO should be the default. It sounds like a composite GET is also possible, though I've never used it. > camel-salesforce - CompositeApiProcessor requires too many fields in RAW mode > - > > Key: CAMEL-16086 > URL: https://issues.apache.org/jira/browse/CAMEL-16086 > Project: Camel > Issue Type: Bug > Components: camel-salesforce >Affects Versions: 3.7.1 >Reporter: Jesse Sightler >Priority: Minor > > [https://github.com/apache/camel/blob/ae2c79dcd64424acc82a29c9a46620809ea6414c/components/camel-salesforce/camel-salesforce-component/src/main/java/org/apache/camel/component/salesforce/internal/processor/CompositeApiProcessor.java#L251https://github.com/apache/camel/blob/master/components/camel-salesforce/camel-salesforce-component/src/main/java/org/apache/camel/component/salesforce/internal/processor/CompositeApiProcessor.java#L251|https://github.com/apache/camel/blob/master/components/camel-salesforce/camel-salesforce-component/src/main/java/org/apache/camel/component/salesforce/internal/processor/CompositeApiProcessor.java#L251] > > This requires the SOBJECT_EXT_ID_NAME, but this should not be required. SFDC > Documentation: > [https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/resources_composite_composite.htm] > In our case, we are using platform events, and upsert ids would not make > sense for us. > > Also this line is requiring a COMPOSITE_METHOD: > [https://github.com/apache/camel/blob/ae2c79dcd64424acc82a29c9a46620809ea6414c/components/camel-salesforce/camel-salesforce-component/src/main/java/org/apache/camel/component/salesforce/internal/processor/CompositeApiProcessor.java#L252] > > This seems unnecessary, as it is already defaulted to POST in > DefaultCompositeApiClient: > [https://github.com/apache/camel/blob/ae2c79dcd64424acc82a29c9a46620809ea6414c/components/camel-salesforce/camel-salesforce-component/src/main/java/org/apache/camel/component/salesforce/internal/client/DefaultCompositeApiClient.java#L106] > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (CAMEL-16086) camel-salesforce - CompositeApiProcessor requires too many fields in RAW mode
[ https://issues.apache.org/jira/browse/CAMEL-16086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17273068#comment-17273068 ] Jesse Sightler edited comment on CAMEL-16086 at 1/27/21, 6:16 PM: -- I'm not sure that this is really minor. It makes Composite operations involving platform-events impossible in raw mode, unless I am overlooking some workaround. was (Author: jsigh...@redhat.com): I'm not sure that this is really minor. It makes Composite operations basically impossible in raw mode, unless I am overlooking some workaround. > camel-salesforce - CompositeApiProcessor requires too many fields in RAW mode > - > > Key: CAMEL-16086 > URL: https://issues.apache.org/jira/browse/CAMEL-16086 > Project: Camel > Issue Type: Bug > Components: camel-salesforce >Affects Versions: 3.7.1 >Reporter: Jesse Sightler >Priority: Minor > > [https://github.com/apache/camel/blob/ae2c79dcd64424acc82a29c9a46620809ea6414c/components/camel-salesforce/camel-salesforce-component/src/main/java/org/apache/camel/component/salesforce/internal/processor/CompositeApiProcessor.java#L251https://github.com/apache/camel/blob/master/components/camel-salesforce/camel-salesforce-component/src/main/java/org/apache/camel/component/salesforce/internal/processor/CompositeApiProcessor.java#L251|https://github.com/apache/camel/blob/master/components/camel-salesforce/camel-salesforce-component/src/main/java/org/apache/camel/component/salesforce/internal/processor/CompositeApiProcessor.java#L251] > > This requires the SOBJECT_EXT_ID_NAME, but this should not be required. SFDC > Documentation: > [https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/resources_composite_composite.htm] > In our case, we are using platform events, and upsert ids would not make > sense for us. > > Also this line is requiring a COMPOSITE_METHOD: > [https://github.com/apache/camel/blob/ae2c79dcd64424acc82a29c9a46620809ea6414c/components/camel-salesforce/camel-salesforce-component/src/main/java/org/apache/camel/component/salesforce/internal/processor/CompositeApiProcessor.java#L252] > > This seems unnecessary, as it is already defaulted to POST in > DefaultCompositeApiClient: > [https://github.com/apache/camel/blob/ae2c79dcd64424acc82a29c9a46620809ea6414c/components/camel-salesforce/camel-salesforce-component/src/main/java/org/apache/camel/component/salesforce/internal/client/DefaultCompositeApiClient.java#L106] > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-16086) camel-salesforce - CompositeApiProcessor requires too many fields in RAW mode
[ https://issues.apache.org/jira/browse/CAMEL-16086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17273068#comment-17273068 ] Jesse Sightler commented on CAMEL-16086: I'm not sure that this is really minor. It makes Composite operations basically impossible in raw mode, unless I am overlooking some workaround. > camel-salesforce - CompositeApiProcessor requires too many fields in RAW mode > - > > Key: CAMEL-16086 > URL: https://issues.apache.org/jira/browse/CAMEL-16086 > Project: Camel > Issue Type: Bug > Components: camel-salesforce >Affects Versions: 3.7.1 >Reporter: Jesse Sightler >Priority: Minor > > [https://github.com/apache/camel/blob/ae2c79dcd64424acc82a29c9a46620809ea6414c/components/camel-salesforce/camel-salesforce-component/src/main/java/org/apache/camel/component/salesforce/internal/processor/CompositeApiProcessor.java#L251https://github.com/apache/camel/blob/master/components/camel-salesforce/camel-salesforce-component/src/main/java/org/apache/camel/component/salesforce/internal/processor/CompositeApiProcessor.java#L251|https://github.com/apache/camel/blob/master/components/camel-salesforce/camel-salesforce-component/src/main/java/org/apache/camel/component/salesforce/internal/processor/CompositeApiProcessor.java#L251] > > This requires the SOBJECT_EXT_ID_NAME, but this should not be required. SFDC > Documentation: > [https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/resources_composite_composite.htm] > In our case, we are using platform events, and upsert ids would not make > sense for us. > > Also this line is requiring a COMPOSITE_METHOD: > [https://github.com/apache/camel/blob/ae2c79dcd64424acc82a29c9a46620809ea6414c/components/camel-salesforce/camel-salesforce-component/src/main/java/org/apache/camel/component/salesforce/internal/processor/CompositeApiProcessor.java#L252] > > This seems unnecessary, as it is already defaulted to POST in > DefaultCompositeApiClient: > [https://github.com/apache/camel/blob/ae2c79dcd64424acc82a29c9a46620809ea6414c/components/camel-salesforce/camel-salesforce-component/src/main/java/org/apache/camel/component/salesforce/internal/client/DefaultCompositeApiClient.java#L106] > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CAMEL-16086) CompositeApiProcessor requires too many fields in RAW mode
Jesse Sightler created CAMEL-16086: -- Summary: CompositeApiProcessor requires too many fields in RAW mode Key: CAMEL-16086 URL: https://issues.apache.org/jira/browse/CAMEL-16086 Project: Camel Issue Type: Bug Components: camel-salesforce Affects Versions: 3.7.1 Reporter: Jesse Sightler [https://github.com/apache/camel/blob/ae2c79dcd64424acc82a29c9a46620809ea6414c/components/camel-salesforce/camel-salesforce-component/src/main/java/org/apache/camel/component/salesforce/internal/processor/CompositeApiProcessor.java#L251https://github.com/apache/camel/blob/master/components/camel-salesforce/camel-salesforce-component/src/main/java/org/apache/camel/component/salesforce/internal/processor/CompositeApiProcessor.java#L251|https://github.com/apache/camel/blob/master/components/camel-salesforce/camel-salesforce-component/src/main/java/org/apache/camel/component/salesforce/internal/processor/CompositeApiProcessor.java#L251] This requires the SOBJECT_EXT_ID_NAME, but this should not be required. SFDC Documentation: [https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/resources_composite_composite.htm] In our case, we are using platform events, and upsert ids would not make sense for us. Also this line is requiring a COMPOSITE_METHOD: [https://github.com/apache/camel/blob/ae2c79dcd64424acc82a29c9a46620809ea6414c/components/camel-salesforce/camel-salesforce-component/src/main/java/org/apache/camel/component/salesforce/internal/processor/CompositeApiProcessor.java#L252] This seems unnecessary, as it is already defaulted to POST in DefaultCompositeApiClient: [https://github.com/apache/camel/blob/ae2c79dcd64424acc82a29c9a46620809ea6414c/components/camel-salesforce/camel-salesforce-component/src/main/java/org/apache/camel/component/salesforce/internal/client/DefaultCompositeApiClient.java#L106] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-16065) Camel Undertow Starter causes configuration issues with DirtiesContext
[ https://issues.apache.org/jira/browse/CAMEL-16065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17268854#comment-17268854 ] Jesse Sightler commented on CAMEL-16065: I'm not sure how to try 3.7.1, but 3.8.0-SNAPSHOT does not have the issue. > Camel Undertow Starter causes configuration issues with DirtiesContext > -- > > Key: CAMEL-16065 > URL: https://issues.apache.org/jira/browse/CAMEL-16065 > Project: Camel > Issue Type: Bug > Components: camel-undertow >Reporter: Jesse Sightler >Priority: Major > > Sample project demonstrating the issue: > [https://github.com/jsight/camel-undertow-configbug] > > If the tests are run all together, DirtiesContext will cause the > configuration to be reloaded between each test. This will work fine for the > first test that runs, but will fail for subsequent tests. > > Why is this? Well, it turns out that the camel undertow component registers a > type converter that causes non-bean-reference Strings to get converted to > null. For some reason, this only happens on the second test within an > execution. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CAMEL-16065) Camel Undertow Starter causes configuration issues with DirtiesContext
Jesse Sightler created CAMEL-16065: -- Summary: Camel Undertow Starter causes configuration issues with DirtiesContext Key: CAMEL-16065 URL: https://issues.apache.org/jira/browse/CAMEL-16065 Project: Camel Issue Type: Bug Components: camel-undertow Reporter: Jesse Sightler Sample project demonstrating the issue: [https://github.com/jsight/camel-undertow-configbug] If the tests are run all together, DirtiesContext will cause the configuration to be reloaded between each test. This will work fine for the first test that runs, but will fail for subsequent tests. Why is this? Well, it turns out that the camel undertow component registers a type converter that causes non-bean-reference Strings to get converted to null. For some reason, this only happens on the second test within an execution. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-13181) camel-salesforce - rest exception parsing produces useless messages
[
https://issues.apache.org/jira/browse/CAMEL-13181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16766169#comment-16766169
]
Jesse Sightler commented on CAMEL-13181:
That is a fair point. Removing this part of the log line would be better than
the current situation, IMO.
> camel-salesforce - rest exception parsing produces useless messages
> ---
>
> Key: CAMEL-13181
> URL: https://issues.apache.org/jira/browse/CAMEL-13181
> Project: Camel
> Issue Type: Improvement
> Components: camel-salesforce
>Reporter: Jesse Sightler
>Priority: Minor
>
> In the case of serialization failures, createRestException swallows the
> exception and logs the inputstream object itself:
>
> [https://github.com/apache/camel/blob/master/components/camel-salesforce/camel-salesforce-component/src/main/java/org/apache/camel/component/salesforce/internal/client/DefaultRestClient.java#L119]
>
> This does not tend to produce an error message, as the response is
> essentially always something like "ByteArrayInputStream@\{hashcode}". Perhaps
> it could try to return the raw contents if it is short and json?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CAMEL-13180) Camel Apex Calls could support more flexible response parsing
Jesse Sightler created CAMEL-13180: -- Summary: Camel Apex Calls could support more flexible response parsing Key: CAMEL-13180 URL: https://issues.apache.org/jira/browse/CAMEL-13180 Project: Camel Issue Type: New Feature Reporter: Jesse Sightler The current approach requires following a very strict format for error codes other than 200. This isn't necessarily the case, though, for custom apex classes. Ideally, it would be possible to call the exception handler only on non 2xx codes, and also to handle the parsing in the camel route itself. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CAMEL-13180) Camel Apex Calls could support more flexible response parsing
[ https://issues.apache.org/jira/browse/CAMEL-13180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jesse Sightler updated CAMEL-13180: --- Description: The current approach requires following a very strict format for error codes other than 2xx. This isn't necessarily the case, though, for custom apex classes. Ideally, it would be possible to (optionally) handle the parsing in the camel route itself. was: The current approach requires following a very strict format for error codes other than 2xx. This isn't necessarily the case, though, for custom apex classes. Ideally, it would be possible to handle the parsing in the camel route itself. > Camel Apex Calls could support more flexible response parsing > - > > Key: CAMEL-13180 > URL: https://issues.apache.org/jira/browse/CAMEL-13180 > Project: Camel > Issue Type: New Feature > Components: camel-salesforce >Reporter: Jesse Sightler >Priority: Major > > The current approach requires following a very strict format for error codes > other than 2xx. This isn't necessarily the case, though, for custom apex > classes. > Ideally, it would be possible to (optionally) handle the parsing in the camel > route itself. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CAMEL-13180) Camel Apex Calls could support more flexible response parsing
[ https://issues.apache.org/jira/browse/CAMEL-13180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jesse Sightler updated CAMEL-13180: --- Description: The current approach requires following a very strict format for error codes other than 2xx. This isn't necessarily the case, though, for custom apex classes. Ideally, it would be possible to handle the parsing in the camel route itself. was: The current approach requires following a very strict format for error codes other than 200. This isn't necessarily the case, though, for custom apex classes. Ideally, it would be possible to call the exception handler only on non 2xx codes, and also to handle the parsing in the camel route itself. > Camel Apex Calls could support more flexible response parsing > - > > Key: CAMEL-13180 > URL: https://issues.apache.org/jira/browse/CAMEL-13180 > Project: Camel > Issue Type: New Feature > Components: camel-salesforce >Reporter: Jesse Sightler >Priority: Major > > The current approach requires following a very strict format for error codes > other than 2xx. This isn't necessarily the case, though, for custom apex > classes. > Ideally, it would be possible to handle the parsing in the camel route itself. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CAMEL-13181) camel rest exception parsing produces useless messages
Jesse Sightler created CAMEL-13181:
--
Summary: camel rest exception parsing produces useless messages
Key: CAMEL-13181
URL: https://issues.apache.org/jira/browse/CAMEL-13181
Project: Camel
Issue Type: Bug
Components: camel-salesforce
Reporter: Jesse Sightler
In the case of serialization failures, createRestException swallows the
exception and logs the inputstream object itself:
[https://github.com/apache/camel/blob/master/components/camel-salesforce/camel-salesforce-component/src/main/java/org/apache/camel/component/salesforce/internal/client/DefaultRestClient.java#L119]
This does not tend to produce an error message, as the response is essentially
always something like "ByteArrayInputStream@\{hashcode}". Perhaps it could try
to return the raw contents if it is short and json?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CAMEL-13180) Camel Apex Calls could support more flexible response parsing
[ https://issues.apache.org/jira/browse/CAMEL-13180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jesse Sightler updated CAMEL-13180: --- Component/s: camel-salesforce > Camel Apex Calls could support more flexible response parsing > - > > Key: CAMEL-13180 > URL: https://issues.apache.org/jira/browse/CAMEL-13180 > Project: Camel > Issue Type: New Feature > Components: camel-salesforce >Reporter: Jesse Sightler >Priority: Major > > The current approach requires following a very strict format for error codes > other than 200. This isn't necessarily the case, though, for custom apex > classes. > Ideally, it would be possible to call the exception handler only on non 2xx > codes, and also to handle the parsing in the camel route itself. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CAMEL-13139) ModelCamelContext.setTracing(true) makes Camel Salesforce APEX calls fragile
Jesse Sightler created CAMEL-13139:
--
Summary: ModelCamelContext.setTracing(true) makes Camel Salesforce
APEX calls fragile
Key: CAMEL-13139
URL: https://issues.apache.org/jira/browse/CAMEL-13139
Project: Camel
Issue Type: Bug
Components: camel-salesforce
Affects Versions: 2.23.1
Reporter: Jesse Sightler
We were having an issue with a process hanging on Salesforce APEX REST calls.
It turns out that the key factor was whether or not tracing was enabled.
It isn't clear to me as to what the correct fix is, but this code change works
around the problem:
{quote}---
a/components/camel-salesforce/camel-salesforce-component/src/main/java/org/apache/camel/component/salesforce/internal/processor/JsonRestProcessor.java
+++
b/components/camel-salesforce/camel-salesforce-component/src/main/java/org/apache/camel/component/salesforce/internal/processor/JsonRestProcessor.java
@@ -188,6 +188,7 @@ public class JsonRestProcessor extends
AbstractRestProcessor {
// if an exception is reported we should not loose it
if (shouldReport(ex)) {
exchange.setException(ex);
+ out.setBody("");
}
} else if (responseEntity != null) {
// do we need to un-marshal a response
{quote}
All of the cases of it hanging were when there were exceptions thrown by the
service.
Basically if the body of the out message is set, then it doesn't hang. I can
provide more details if need be as well.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CAMEL-12985) TransactionErrorHandler fails if UnitOfWork is null -- This seems to happen sometimes with intercepted routes
[ https://issues.apache.org/jira/browse/CAMEL-12985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jesse Sightler updated CAMEL-12985: --- Description: I have been getting NullPointerExceptions on tests for transacted routes as a result of this. PR: [https://github.com/apache/camel/pull/2659] (includes unit test that fails on master) was: I have been getting NullPointerExceptions on tests for transacted routes as a result of this. PR: [https://github.com/apache/camel/pull/2659] > TransactionErrorHandler fails if UnitOfWork is null -- This seems to happen > sometimes with intercepted routes > - > > Key: CAMEL-12985 > URL: https://issues.apache.org/jira/browse/CAMEL-12985 > Project: Camel > Issue Type: Bug > Components: camel-spring-boot >Reporter: Jesse Sightler >Priority: Major > > I have been getting NullPointerExceptions on tests for transacted routes as a > result of this. > > PR: [https://github.com/apache/camel/pull/2659] (includes unit test that > fails on master) > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CAMEL-12985) TransactionErrorHandler fails if UnitOfWork is null -- This seems to happen sometimes with intercepted routes
[ https://issues.apache.org/jira/browse/CAMEL-12985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jesse Sightler updated CAMEL-12985: --- Description: I have been getting NullPointerExceptions on tests for transacted routes as a result of this. PR: [https://github.com/apache/camel/pull/2659] was:I have been getting NullPointerExceptions on tests for transacted routes as a result of this. > TransactionErrorHandler fails if UnitOfWork is null -- This seems to happen > sometimes with intercepted routes > - > > Key: CAMEL-12985 > URL: https://issues.apache.org/jira/browse/CAMEL-12985 > Project: Camel > Issue Type: Bug > Components: camel-spring-boot >Reporter: Jesse Sightler >Priority: Major > > I have been getting NullPointerExceptions on tests for transacted routes as a > result of this. > > PR: [https://github.com/apache/camel/pull/2659] > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CAMEL-12985) TransactionErrorHandler fails if UnitOfWork is null -- This seems to happen sometimes with intercepted routes
Jesse Sightler created CAMEL-12985: -- Summary: TransactionErrorHandler fails if UnitOfWork is null -- This seems to happen sometimes with intercepted routes Key: CAMEL-12985 URL: https://issues.apache.org/jira/browse/CAMEL-12985 Project: Camel Issue Type: Bug Components: camel-spring-boot Reporter: Jesse Sightler I have been getting NullPointerExceptions on tests for transacted routes as a result of this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CAMEL-12712) Camel Salesforce can easily hang when used within an aggregator
[
https://issues.apache.org/jira/browse/CAMEL-12712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16625854#comment-16625854
]
Jesse Sightler commented on CAMEL-12712:
TBH, even if it is the test services there is a serious issue here. Switching
to seda completely changes the behavior in a way that shouldn't be possible.
The services work fine as long as the client doesn't block the response thread.
> Camel Salesforce can easily hang when used within an aggregator
> ---
>
> Key: CAMEL-12712
> URL: https://issues.apache.org/jira/browse/CAMEL-12712
> Project: Camel
> Issue Type: Bug
> Components: camel-salesforce
>Reporter: Jesse Sightler
>Priority: Major
>
> Reproducer project:
> https://github.com/jsight/camel-salesforce-http-aggregator-issue
>
> Run the unit tests and you will observe it hanging.
>
> A workaround is also present. Uncomment this line:
> {quote}// .to("seda:enrichWithJobId?waitForTaskToComplete=Always")
> {quote}
>
> The code that hangs is this:
> {quote}.enrich("direct:createJobAndGetID", new AggregationStrategy() {
> @Override
> public Exchange aggregate(Exchange oldExchange, Exchange newExchange)
> Unknown macro: \{ oldExchange.getIn().setHeader("jobId",
> newExchange.getIn().getBody(JobInfo.class).getId()); return oldExchange; }
> })
> {quote}
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CAMEL-12712) Camel Salesforce can easily hang when used within an aggregator
[
https://issues.apache.org/jira/browse/CAMEL-12712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16623649#comment-16623649
]
Jesse Sightler commented on CAMEL-12712:
I am really disappointed with that response, but ok.
> Camel Salesforce can easily hang when used within an aggregator
> ---
>
> Key: CAMEL-12712
> URL: https://issues.apache.org/jira/browse/CAMEL-12712
> Project: Camel
> Issue Type: Bug
> Components: camel-salesforce
>Reporter: Jesse Sightler
>Priority: Major
>
> Reproducer project:
> https://github.com/jsight/camel-salesforce-http-aggregator-issue
>
> Run the unit tests and you will observe it hanging.
>
> A workaround is also present. Uncomment this line:
> {quote}// .to("seda:enrichWithJobId?waitForTaskToComplete=Always")
> {quote}
>
> The code that hangs is this:
> {quote}.enrich("direct:createJobAndGetID", new AggregationStrategy() {
> @Override
> public Exchange aggregate(Exchange oldExchange, Exchange newExchange)
> Unknown macro: \{ oldExchange.getIn().setHeader("jobId",
> newExchange.getIn().getBody(JobInfo.class).getId()); return oldExchange; }
> })
> {quote}
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CAMEL-12712) Camel Salesforce can easily hang when used within an aggregator
[
https://issues.apache.org/jira/browse/CAMEL-12712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16619499#comment-16619499
]
Jesse Sightler commented on CAMEL-12712:
I don't believe that it is related. From what I can tell, that is only the
salesforce consumer, but my code is only using the producer endpoints. Also,
the test still hangs. I think this is a fairly deep issue with the usage of
Netty. We have worked around it in our code as the aggregator was unnecessary
and problematic for other reasons.
> Camel Salesforce can easily hang when used within an aggregator
> ---
>
> Key: CAMEL-12712
> URL: https://issues.apache.org/jira/browse/CAMEL-12712
> Project: Camel
> Issue Type: Bug
> Components: camel-salesforce
>Reporter: Jesse Sightler
>Priority: Major
>
> Reproducer project:
> https://github.com/jsight/camel-salesforce-http-aggregator-issue
>
> Run the unit tests and you will observe it hanging.
>
> A workaround is also present. Uncomment this line:
> {quote}// .to("seda:enrichWithJobId?waitForTaskToComplete=Always")
> {quote}
>
> The code that hangs is this:
> {quote}.enrich("direct:createJobAndGetID", new AggregationStrategy() {
> @Override
> public Exchange aggregate(Exchange oldExchange, Exchange newExchange)
> Unknown macro: \{ oldExchange.getIn().setHeader("jobId",
> newExchange.getIn().getBody(JobInfo.class).getId()); return oldExchange; }
> })
> {quote}
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CAMEL-12712) Camel Salesforce can easily hang when used within an aggregator
[
https://issues.apache.org/jira/browse/CAMEL-12712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16578290#comment-16578290
]
Jesse Sightler commented on CAMEL-12712:
Working version (just switched to seda, no changes to the server mock):
https://github.com/jsight/camel-salesforce-http-aggregator-issue/tree/working_version
> Camel Salesforce can easily hang when used within an aggregator
> ---
>
> Key: CAMEL-12712
> URL: https://issues.apache.org/jira/browse/CAMEL-12712
> Project: Camel
> Issue Type: Bug
> Components: camel-salesforce
>Reporter: Jesse Sightler
>Priority: Major
>
> Reproducer project:
> https://github.com/jsight/camel-salesforce-http-aggregator-issue
>
> Run the unit tests and you will observe it hanging.
>
> A workaround is also present. Uncomment this line:
> {quote}// .to("seda:enrichWithJobId?waitForTaskToComplete=Always")
> {quote}
>
> The code that hangs is this:
> {quote}.enrich("direct:createJobAndGetID", new AggregationStrategy() {
> @Override
> public Exchange aggregate(Exchange oldExchange, Exchange newExchange)
> Unknown macro: \{ oldExchange.getIn().setHeader("jobId",
> newExchange.getIn().getBody(JobInfo.class).getId()); return oldExchange; }
> })
> {quote}
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CAMEL-12712) Camel Salesforce can easily hang when used within an aggregator
[
https://issues.apache.org/jira/browse/CAMEL-12712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16578278#comment-16578278
]
Jesse Sightler commented on CAMEL-12712:
Did you uncomment the call to the seda and comment out the
".enrich("direct:createJobAndGetID", new AggregationStrategy() {" block? It
will not block if you do that. I can share a video to make this clear if you'd
like?
I'm not convinced that the http stack would crash in the same way with a mock
or that the code would be vastly simpler with Wiremock.
> Camel Salesforce can easily hang when used within an aggregator
> ---
>
> Key: CAMEL-12712
> URL: https://issues.apache.org/jira/browse/CAMEL-12712
> Project: Camel
> Issue Type: Bug
> Components: camel-salesforce
>Reporter: Jesse Sightler
>Priority: Major
>
> Reproducer project:
> https://github.com/jsight/camel-salesforce-http-aggregator-issue
>
> Run the unit tests and you will observe it hanging.
>
> A workaround is also present. Uncomment this line:
> {quote}// .to("seda:enrichWithJobId?waitForTaskToComplete=Always")
> {quote}
>
> The code that hangs is this:
> {quote}.enrich("direct:createJobAndGetID", new AggregationStrategy() {
> @Override
> public Exchange aggregate(Exchange oldExchange, Exchange newExchange)
> Unknown macro: \{ oldExchange.getIn().setHeader("jobId",
> newExchange.getIn().getBody(JobInfo.class).getId()); return oldExchange; }
> })
> {quote}
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CAMEL-12712) Camel Salesforce can easily hang when used within an aggregator
[
https://issues.apache.org/jira/browse/CAMEL-12712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16573311#comment-16573311
]
Jesse Sightler commented on CAMEL-12712:
[~zregvart] - Yes, and that is the bug report. :) The reason the http request
is never received is that the thread that would process the request is stuck
waiting on the response.
If you switch to a seda queue so that the original thread is unblocked, then
the response is received. It seems to be an issue with the way the aggregator
works with the netty client.
> Camel Salesforce can easily hang when used within an aggregator
> ---
>
> Key: CAMEL-12712
> URL: https://issues.apache.org/jira/browse/CAMEL-12712
> Project: Camel
> Issue Type: Bug
> Components: camel-salesforce
>Reporter: Jesse Sightler
>Priority: Major
>
> Reproducer project:
> https://github.com/jsight/camel-salesforce-http-aggregator-issue
>
> Run the unit tests and you will observe it hanging.
>
> A workaround is also present. Uncomment this line:
> {quote}// .to("seda:enrichWithJobId?waitForTaskToComplete=Always")
> {quote}
>
> The code that hangs is this:
> {quote}.enrich("direct:createJobAndGetID", new AggregationStrategy() {
> @Override
> public Exchange aggregate(Exchange oldExchange, Exchange newExchange)
> Unknown macro: \{ oldExchange.getIn().setHeader("jobId",
> newExchange.getIn().getBody(JobInfo.class).getId()); return oldExchange; }
> })
> {quote}
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CAMEL-12712) Camel Salesforce can easily hang when used within an aggregator
[
https://issues.apache.org/jira/browse/CAMEL-12712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16573311#comment-16573311
]
Jesse Sightler edited comment on CAMEL-12712 at 8/8/18 2:45 PM:
[~zregvart] - Yes, and that is the bug report. :) The reason the http request
is never received is that the thread that would process the request is stuck
waiting on the response (inside of aggregator). The thread won't unblock until
it receives a response and also won't process a response until it is unblocked.
If you switch to a seda queue so that the original thread is unblocked, then
the response is received. It seems to be an issue with the way the aggregator
works with the netty client.
was (Author: jsigh...@redhat.com):
[~zregvart] - Yes, and that is the bug report. :) The reason the http request
is never received is that the thread that would process the request is stuck
waiting on the response.
If you switch to a seda queue so that the original thread is unblocked, then
the response is received. It seems to be an issue with the way the aggregator
works with the netty client.
> Camel Salesforce can easily hang when used within an aggregator
> ---
>
> Key: CAMEL-12712
> URL: https://issues.apache.org/jira/browse/CAMEL-12712
> Project: Camel
> Issue Type: Bug
> Components: camel-salesforce
>Reporter: Jesse Sightler
>Priority: Major
>
> Reproducer project:
> https://github.com/jsight/camel-salesforce-http-aggregator-issue
>
> Run the unit tests and you will observe it hanging.
>
> A workaround is also present. Uncomment this line:
> {quote}// .to("seda:enrichWithJobId?waitForTaskToComplete=Always")
> {quote}
>
> The code that hangs is this:
> {quote}.enrich("direct:createJobAndGetID", new AggregationStrategy() {
> @Override
> public Exchange aggregate(Exchange oldExchange, Exchange newExchange)
> Unknown macro: \{ oldExchange.getIn().setHeader("jobId",
> newExchange.getIn().getBody(JobInfo.class).getId()); return oldExchange; }
> })
> {quote}
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CAMEL-12712) Camel Salesforce can easily hang when used within an aggregator
[
https://issues.apache.org/jira/browse/CAMEL-12712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16571902#comment-16571902
]
Jesse Sightler commented on CAMEL-12712:
This was pulled from a running app. I'm not sure how much more it can be
minimized. I mean, you are right that the mocks are pointless as defined here,
but I don't see how that causes a problem? It hangs on the first iteration very
consistently.
I could remove all of the assertions from the test, I guess?
> Camel Salesforce can easily hang when used within an aggregator
> ---
>
> Key: CAMEL-12712
> URL: https://issues.apache.org/jira/browse/CAMEL-12712
> Project: Camel
> Issue Type: Bug
> Components: camel-salesforce
>Reporter: Jesse Sightler
>Priority: Major
>
> Reproducer project:
> https://github.com/jsight/camel-salesforce-http-aggregator-issue
>
> Run the unit tests and you will observe it hanging.
>
> A workaround is also present. Uncomment this line:
> {quote}// .to("seda:enrichWithJobId?waitForTaskToComplete=Always")
> {quote}
>
> The code that hangs is this:
> {quote}.enrich("direct:createJobAndGetID", new AggregationStrategy() {
> @Override
> public Exchange aggregate(Exchange oldExchange, Exchange newExchange)
> Unknown macro: \{ oldExchange.getIn().setHeader("jobId",
> newExchange.getIn().getBody(JobInfo.class).getId()); return oldExchange; }
> })
> {quote}
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CAMEL-12712) Camel Salesforce can easily hang when used within an aggregator
[
https://issues.apache.org/jira/browse/CAMEL-12712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jesse Sightler updated CAMEL-12712:
---
Description:
Reproducer project:
https://github.com/jsight/camel-salesforce-http-aggregator-issue
Run the unit tests and you will observe it hanging.
A workaround is also present. Uncomment this line:
{quote}// .to("seda:enrichWithJobId?waitForTaskToComplete=Always")
{quote}
The code that hangs is this:
{quote}.enrich("direct:createJobAndGetID", new AggregationStrategy() {
@Override
public Exchange aggregate(Exchange oldExchange, Exchange newExchange)
Unknown macro: \{ oldExchange.getIn().setHeader("jobId",
newExchange.getIn().getBody(JobInfo.class).getId()); return oldExchange; }
})
{quote}
was:
Run
[Style|https://issues.apache.org/jira/projects/CAMEL?selectedItem=com.atlassian.jira.jira-projects-plugin:components-page]the
unit tests and you will observe it hanging.
A workaround is also present. Uncomment this line:
{quote}// .to("seda:enrichWithJobId?waitForTaskToComplete=Always")
{quote}
The code that hangs is this:
{quote}
.enrich("direct:createJobAndGetID", new AggregationStrategy() {
@Override
public Exchange aggregate(Exchange oldExchange, Exchange newExchange) {
oldExchange.getIn().setHeader("jobId",
newExchange.getIn().getBody(JobInfo.class).getId());
return oldExchange;
}
})
{quote}
> Camel Salesforce can easily hang when used within an aggregator
> ---
>
> Key: CAMEL-12712
> URL: https://issues.apache.org/jira/browse/CAMEL-12712
> Project: Camel
> Issue Type: Bug
> Components: camel-salesforce
>Reporter: Jesse Sightler
>Priority: Major
>
> Reproducer project:
> https://github.com/jsight/camel-salesforce-http-aggregator-issue
>
> Run the unit tests and you will observe it hanging.
>
> A workaround is also present. Uncomment this line:
> {quote}// .to("seda:enrichWithJobId?waitForTaskToComplete=Always")
> {quote}
>
> The code that hangs is this:
> {quote}.enrich("direct:createJobAndGetID", new AggregationStrategy() {
> @Override
> public Exchange aggregate(Exchange oldExchange, Exchange newExchange)
> Unknown macro: \{ oldExchange.getIn().setHeader("jobId",
> newExchange.getIn().getBody(JobInfo.class).getId()); return oldExchange; }
> })
> {quote}
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CAMEL-12712) Camel Salesforce can easily hang when used within an aggregator
Jesse Sightler created CAMEL-12712:
--
Summary: Camel Salesforce can easily hang when used within an
aggregator
Key: CAMEL-12712
URL: https://issues.apache.org/jira/browse/CAMEL-12712
Project: Camel
Issue Type: Bug
Components: camel-salesforce
Reporter: Jesse Sightler
Run
[Style|https://issues.apache.org/jira/projects/CAMEL?selectedItem=com.atlassian.jira.jira-projects-plugin:components-page]the
unit tests and you will observe it hanging.
A workaround is also present. Uncomment this line:
{quote}// .to("seda:enrichWithJobId?waitForTaskToComplete=Always")
{quote}
The code that hangs is this:
{quote}
.enrich("direct:createJobAndGetID", new AggregationStrategy() {
@Override
public Exchange aggregate(Exchange oldExchange, Exchange newExchange) {
oldExchange.getIn().setHeader("jobId",
newExchange.getIn().getBody(JobInfo.class).getId());
return oldExchange;
}
})
{quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CAMEL-12703) Support JSON as a ContentType for JobInfo
[ https://issues.apache.org/jira/browse/CAMEL-12703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16563962#comment-16563962 ] Jesse Sightler edited comment on CAMEL-12703 at 7/31/18 4:44 PM: - PR here: [https://github.com/apache/camel/pull/2447] was (Author: jsigh...@redhat.com): https://github.com/apache/camel/pull/2447 > Support JSON as a ContentType for JobInfo > - > > Key: CAMEL-12703 > URL: https://issues.apache.org/jira/browse/CAMEL-12703 > Project: Camel > Issue Type: Bug > Components: camel-salesforce >Reporter: Jesse Sightler >Priority: Major > > This content type is listed here: > [https://developer.salesforce.com/docs/atlas.en-us.api_asynch.meta/api_asynch/asynch_api_reference_jobinfo.htm] > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CAMEL-12703) Support JSON as a ContentType for JobInfo
Jesse Sightler created CAMEL-12703: -- Summary: Support JSON as a ContentType for JobInfo Key: CAMEL-12703 URL: https://issues.apache.org/jira/browse/CAMEL-12703 Project: Camel Issue Type: Bug Components: camel-salesforce Reporter: Jesse Sightler This content type is listed here: [https://developer.salesforce.com/docs/atlas.en-us.api_asynch.meta/api_asynch/asynch_api_reference_jobinfo.htm] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CAMEL-12703) Support JSON as a ContentType for JobInfo
[ https://issues.apache.org/jira/browse/CAMEL-12703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16563962#comment-16563962 ] Jesse Sightler commented on CAMEL-12703: https://github.com/apache/camel/pull/2447 > Support JSON as a ContentType for JobInfo > - > > Key: CAMEL-12703 > URL: https://issues.apache.org/jira/browse/CAMEL-12703 > Project: Camel > Issue Type: Bug > Components: camel-salesforce >Reporter: Jesse Sightler >Priority: Major > > This content type is listed here: > [https://developer.salesforce.com/docs/atlas.en-us.api_asynch.meta/api_asynch/asynch_api_reference_jobinfo.htm] > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
