[jira] [Resolved] (CAMEL-20195) Components with mixed jetty versions
[
https://issues.apache.org/jira/browse/CAMEL-20195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Federico Mariani resolved CAMEL-20195.
--
Resolution: Not A Bug
> Components with mixed jetty versions
>
>
> Key: CAMEL-20195
> URL: https://issues.apache.org/jira/browse/CAMEL-20195
> Project: Camel
> Issue Type: Dependency upgrade
>Reporter: Federico Mariani
>Priority: Minor
> Fix For: 4.x
>
>
> The following camel spring boot components are using different jetty versions:
> camel-debezium-mysql-starter
> camel-debezium-postgres-starter
> camel-hdfs-starter
> in particular, these 3 components requires jetty 9, but the camel and spring
> boot boms overrides the jetty version to 12 therefore the dependency tree is
> like this:
> {code:java}
> [INFO] | | | | +- org.eclipse.jetty:jetty-server:jar:12.0.3:runtime
> [INFO] | | | | | +- org.eclipse.jetty:jetty-http:jar:12.0.3:runtime
> [INFO] | | | | | \- org.eclipse.jetty:jetty-io:jar:12.0.3:runtime
> [INFO] | | | | +-
> org.eclipse.jetty:jetty-servlet:jar:9.4.52.v20230823:runtime
> [INFO] | | | | | +- org.eclipse.jetty:jetty-security:jar:12.0.3:runtime
> [INFO] | | | | | \- org.eclipse.jetty:jetty-util-ajax:jar:12.0.3:runtime
> [INFO] | | | | +-
> org.eclipse.jetty:jetty-servlets:jar:9.4.52.v20230823:runtime
> [INFO] | | | | | +-
> org.eclipse.jetty:jetty-continuation:jar:9.4.52.v20230823:runtime
> [INFO] | | | | | \- org.eclipse.jetty:jetty-util:jar:12.0.3:runtime
> [INFO] | | | | +- org.eclipse.jetty:jetty-client:jar:12.0.3:runtime
> [INFO] | | | | | \-
> org.eclipse.jetty:jetty-alpn-client:jar:12.0.3:runtime
> {code}
> as you can see, jetty9 and jetty12 versions are mixed, we do not have any
> example or test for this component, but I am pretty sure it won't work, and
> most probably was not working in the past (I do not think that jetty9 was
> compatible with 11).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-20195) Components with mixed jetty versions
[
https://issues.apache.org/jira/browse/CAMEL-20195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17851961#comment-17851961
]
Federico Mariani commented on CAMEL-20195:
--
{code:java}
jetty is just a transitivi dependency of Kafka Connect runtime and is not used
by Debezium at all so it can be safely excluded. Looking at dependency tree it
seems to me it is even test dep only {code}
I asked in Debezium zulip chat, and seems like that jetty is not a real issue,
we may exclude it since it is most probably used for testing purposes
> Components with mixed jetty versions
>
>
> Key: CAMEL-20195
> URL: https://issues.apache.org/jira/browse/CAMEL-20195
> Project: Camel
> Issue Type: Dependency upgrade
>Reporter: Federico Mariani
>Priority: Minor
> Fix For: 4.x
>
>
> The following camel spring boot components are using different jetty versions:
> camel-debezium-mysql-starter
> camel-debezium-postgres-starter
> camel-hdfs-starter
> in particular, these 3 components requires jetty 9, but the camel and spring
> boot boms overrides the jetty version to 12 therefore the dependency tree is
> like this:
> {code:java}
> [INFO] | | | | +- org.eclipse.jetty:jetty-server:jar:12.0.3:runtime
> [INFO] | | | | | +- org.eclipse.jetty:jetty-http:jar:12.0.3:runtime
> [INFO] | | | | | \- org.eclipse.jetty:jetty-io:jar:12.0.3:runtime
> [INFO] | | | | +-
> org.eclipse.jetty:jetty-servlet:jar:9.4.52.v20230823:runtime
> [INFO] | | | | | +- org.eclipse.jetty:jetty-security:jar:12.0.3:runtime
> [INFO] | | | | | \- org.eclipse.jetty:jetty-util-ajax:jar:12.0.3:runtime
> [INFO] | | | | +-
> org.eclipse.jetty:jetty-servlets:jar:9.4.52.v20230823:runtime
> [INFO] | | | | | +-
> org.eclipse.jetty:jetty-continuation:jar:9.4.52.v20230823:runtime
> [INFO] | | | | | \- org.eclipse.jetty:jetty-util:jar:12.0.3:runtime
> [INFO] | | | | +- org.eclipse.jetty:jetty-client:jar:12.0.3:runtime
> [INFO] | | | | | \-
> org.eclipse.jetty:jetty-alpn-client:jar:12.0.3:runtime
> {code}
> as you can see, jetty9 and jetty12 versions are mixed, we do not have any
> example or test for this component, but I am pretty sure it won't work, and
> most probably was not working in the past (I do not think that jetty9 was
> compatible with 11).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-20195) Components with mixed jetty versions
[
https://issues.apache.org/jira/browse/CAMEL-20195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17851971#comment-17851971
]
Federico Mariani commented on CAMEL-20195:
--
Kafka version 4.0 will use jetty 12
[https://lists.apache.org/thread/p4qbqh8r77h4khn3yoof2b0gbq3wbc5q] , to have an
aligned dependency tree, Apache Kafka 4 has to be released.
> Components with mixed jetty versions
>
>
> Key: CAMEL-20195
> URL: https://issues.apache.org/jira/browse/CAMEL-20195
> Project: Camel
> Issue Type: Dependency upgrade
>Reporter: Federico Mariani
>Priority: Minor
> Fix For: 4.x
>
>
> The following camel spring boot components are using different jetty versions:
> camel-debezium-mysql-starter
> camel-debezium-postgres-starter
> camel-hdfs-starter
> in particular, these 3 components requires jetty 9, but the camel and spring
> boot boms overrides the jetty version to 12 therefore the dependency tree is
> like this:
> {code:java}
> [INFO] | | | | +- org.eclipse.jetty:jetty-server:jar:12.0.3:runtime
> [INFO] | | | | | +- org.eclipse.jetty:jetty-http:jar:12.0.3:runtime
> [INFO] | | | | | \- org.eclipse.jetty:jetty-io:jar:12.0.3:runtime
> [INFO] | | | | +-
> org.eclipse.jetty:jetty-servlet:jar:9.4.52.v20230823:runtime
> [INFO] | | | | | +- org.eclipse.jetty:jetty-security:jar:12.0.3:runtime
> [INFO] | | | | | \- org.eclipse.jetty:jetty-util-ajax:jar:12.0.3:runtime
> [INFO] | | | | +-
> org.eclipse.jetty:jetty-servlets:jar:9.4.52.v20230823:runtime
> [INFO] | | | | | +-
> org.eclipse.jetty:jetty-continuation:jar:9.4.52.v20230823:runtime
> [INFO] | | | | | \- org.eclipse.jetty:jetty-util:jar:12.0.3:runtime
> [INFO] | | | | +- org.eclipse.jetty:jetty-client:jar:12.0.3:runtime
> [INFO] | | | | | \-
> org.eclipse.jetty:jetty-alpn-client:jar:12.0.3:runtime
> {code}
> as you can see, jetty9 and jetty12 versions are mixed, we do not have any
> example or test for this component, but I am pretty sure it won't work, and
> most probably was not working in the past (I do not think that jetty9 was
> compatible with 11).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CAMEL-20828) camel-platform-http - Allow to known if platform engine is in use or not without triggering creation
[ https://issues.apache.org/jira/browse/CAMEL-20828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-20828. - Resolution: Fixed > camel-platform-http - Allow to known if platform engine is in use or not > without triggering creation > > > Key: CAMEL-20828 > URL: https://issues.apache.org/jira/browse/CAMEL-20828 > Project: Camel > Issue Type: Improvement > Components: camel-platform-http >Affects Versions: 4.7.0 >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Minor > Fix For: 4.7.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-20830) camel-jetty - Upgrading causes SSL tests to fail
Claus Ibsen created CAMEL-20830: --- Summary: camel-jetty - Upgrading causes SSL tests to fail Key: CAMEL-20830 URL: https://issues.apache.org/jira/browse/CAMEL-20830 Project: Camel Issue Type: Dependency upgrade Components: camel-jetty Reporter: Claus Ibsen Fix For: 4.x [ERROR] Tests run: 3, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.037 s <<< FAILURE! -- in org.apache.camel.component.jetty.rest.RestJettyGetCorsTest [ERROR] org.apache.camel.component.jetty.HttpsRouteWithSslConnectorPropertiesTest.testEndpoint -- Time elapsed: 0.381 s <<< ERROR! java.lang.IllegalStateException: Response does not exist (likely recycled) at org.eclipse.jetty.ee10.servlet.ServletChannel.getResponse(ServletChannel.java:297) at org.eclipse.jetty.ee10.servlet.ServletApiResponse.getResponse(ServletApiResponse.java:97) at org.eclipse.jetty.ee10.servlet.ServletApiResponse.toString(ServletApiResponse.java:520) at java.base/java.lang.String.valueOf(String.java:4218) at java.base/java.lang.StringBuilder.append(StringBuilder.java:173) at java.base/java.util.AbstractMap.toString(AbstractMap.java:555) at java.base/java.lang.StringConcatHelper.stringOf(StringConcatHelper.java:453) at java.base/java.lang.StringConcatHelper.simpleConcat(StringConcatHelper.java:408) at org.apache.camel.component.jetty.HttpsRouteTest.testEndpoint(HttpsRouteTest.java:142) at java.base/java.lang.reflect.Method.invoke(Method.java:568) at java.base/java.util.concurrent.RecursiveAction.exec(RecursiveAction.java:194) at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:373) at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1182) at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1655) at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1622) at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:165) 12.0.8 works. Newer version fails. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-20830) camel-jetty - Upgrading causes SSL tests to fail
[ https://issues.apache.org/jira/browse/CAMEL-20830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-20830: Priority: Minor (was: Major) > camel-jetty - Upgrading causes SSL tests to fail > > > Key: CAMEL-20830 > URL: https://issues.apache.org/jira/browse/CAMEL-20830 > Project: Camel > Issue Type: Dependency upgrade > Components: camel-jetty >Reporter: Claus Ibsen >Priority: Minor > Fix For: 4.x > > > [ERROR] Tests run: 3, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.037 > s <<< FAILURE! -- in > org.apache.camel.component.jetty.rest.RestJettyGetCorsTest > [ERROR] > org.apache.camel.component.jetty.HttpsRouteWithSslConnectorPropertiesTest.testEndpoint > -- Time elapsed: 0.381 s <<< ERROR! > java.lang.IllegalStateException: Response does not exist (likely recycled) > at > org.eclipse.jetty.ee10.servlet.ServletChannel.getResponse(ServletChannel.java:297) > at > org.eclipse.jetty.ee10.servlet.ServletApiResponse.getResponse(ServletApiResponse.java:97) > at > org.eclipse.jetty.ee10.servlet.ServletApiResponse.toString(ServletApiResponse.java:520) > at java.base/java.lang.String.valueOf(String.java:4218) > at java.base/java.lang.StringBuilder.append(StringBuilder.java:173) > at java.base/java.util.AbstractMap.toString(AbstractMap.java:555) > at > java.base/java.lang.StringConcatHelper.stringOf(StringConcatHelper.java:453) > at > java.base/java.lang.StringConcatHelper.simpleConcat(StringConcatHelper.java:408) > at > org.apache.camel.component.jetty.HttpsRouteTest.testEndpoint(HttpsRouteTest.java:142) > at java.base/java.lang.reflect.Method.invoke(Method.java:568) > at > java.base/java.util.concurrent.RecursiveAction.exec(RecursiveAction.java:194) > at > java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:373) > at > java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1182) > at > java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1655) > at > java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1622) > at > java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:165) > > 12.0.8 works. > Newer version fails. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-20831) camel-salesforce fails when InitialContext specified
Alexander Anpilov created CAMEL-20831: - Summary: camel-salesforce fails when InitialContext specified Key: CAMEL-20831 URL: https://issues.apache.org/jira/browse/CAMEL-20831 Project: Camel Issue Type: Bug Components: camel-salesforce Affects Versions: 4.6.0, 4.4.2 Reporter: Alexander Anpilov [(428) #camel > Possible bug with camel-salesforce - camel - Zulip (zulipchat.com)|https://camel.zulipchat.com/#narrow/stream/257298-camel/topic/Possible.20bug.20with.20camel-salesforce] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-20831) camel-salesforce fails when InitialContext specified
[ https://issues.apache.org/jira/browse/CAMEL-20831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Anpilov updated CAMEL-20831: -- Attachment: camel-test.zip > camel-salesforce fails when InitialContext specified > > > Key: CAMEL-20831 > URL: https://issues.apache.org/jira/browse/CAMEL-20831 > Project: Camel > Issue Type: Bug > Components: camel-salesforce >Affects Versions: 4.4.2, 4.6.0 >Reporter: Alexander Anpilov >Priority: Minor > Attachments: camel-test.zip > > > [(428) #camel > Possible bug with camel-salesforce - camel - Zulip > (zulipchat.com)|https://camel.zulipchat.com/#narrow/stream/257298-camel/topic/Possible.20bug.20with.20camel-salesforce] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-20831) camel-salesforce fails when InitialContext specified
[ https://issues.apache.org/jira/browse/CAMEL-20831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17852038#comment-17852038 ] Alexander Anpilov commented on CAMEL-20831: --- Attached camel-test maven project. "mvn test" fails with "BeanInstantiationException: Failed to instantiate [com.fasterxml.jackson.core.JsonGenerator]: Is it an abstract class?" If renaming jndi.properties, it fails requiring clientId - that's OK because connection params not specified. I need jndi.properties for setup datasources for quartz and quickfix - they lookup DS via jndi > camel-salesforce fails when InitialContext specified > > > Key: CAMEL-20831 > URL: https://issues.apache.org/jira/browse/CAMEL-20831 > Project: Camel > Issue Type: Bug > Components: camel-salesforce >Affects Versions: 4.4.2, 4.6.0 >Reporter: Alexander Anpilov >Priority: Minor > Attachments: camel-test.zip > > > [(428) #camel > Possible bug with camel-salesforce - camel - Zulip > (zulipchat.com)|https://camel.zulipchat.com/#narrow/stream/257298-camel/topic/Possible.20bug.20with.20camel-salesforce] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-20832) camel-openapi-java - Validate message body for json using a json schema valdaitor
Claus Ibsen created CAMEL-20832: --- Summary: camel-openapi-java - Validate message body for json using a json schema valdaitor Key: CAMEL-20832 URL: https://issues.apache.org/jira/browse/CAMEL-20832 Project: Camel Issue Type: Improvement Components: camel-openapi-java Reporter: Claus Ibsen Assignee: Claus Ibsen Fix For: 4.x To make it pluggable to validate incoming message body if its valid according to a json schema / openapi contract in a light weight fashion. Should be pluggable to discover json validator JAR library to use -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-20833) Add recursive option to camel-smb
Thomas Cunningham created CAMEL-20833: - Summary: Add recursive option to camel-smb Key: CAMEL-20833 URL: https://issues.apache.org/jira/browse/CAMEL-20833 Project: Camel Issue Type: Bug Components: camel-smb Affects Versions: 4.6.0 Reporter: Thomas Cunningham Assignee: Thomas Cunningham Add a recursive option to camel-smb -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-20834) A NullPointException in SubscriptionHelper.subscribe() results in the interruption of the platform-event channel subscription and events are not received
Jason created CAMEL-20834:
-
Summary: A NullPointException in SubscriptionHelper.subscribe()
results in the interruption of the platform-event channel subscription and
events are not received
Key: CAMEL-20834
URL: https://issues.apache.org/jira/browse/CAMEL-20834
Project: Camel
Issue Type: Bug
Components: camel-salesforce
Affects Versions: 4.6.0, 4.5.0
Environment: Spring-Boot: 3.2.6
Camel: 4.5.0 or 4.6.0
Java: 17
Reporter: Jason
I appears that when the `SubscriptionHelper` attempts to reconnect and
resubscribe to a channel in Salesforce, that occasionally and at an
unpredictable rate, the `subscriptionListener` in
`SubscriptionHelper.subscribe` throws an NPE when attempting to get the
`SUBSCRIPTION_FIELD` from the response message from Salesforce because in some
cases that message does not contain a `subscription` property in the JSON
response.
This results in the component seeming to
This seems to be the offending line:
https://github.com/apache/camel/blob/main/components/camel-salesforce/camel-salesforce-component/src/main/java/org/apache/camel/component/salesforce/internal/streaming/SubscriptionHelper.java#L475
The reconnection seem to happen, but never actually re-subscribes to the
channel and therefore the flow of platform-events stops until the spring-boot
application is restarted.
Here is some of the associated logging:
{noformat}
[DEBUG] 2024-06-04 00:17:20,212
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
[Camel (camel-1) thread #319 - SalesforceHttpClient ] -
[CHANNEL:META_HANDSHAKE]: {ext={replay=true, payload.format=true},
minimumVersion=1.0, clientId=REDACTED, supportedConnectionTypes=[long-polling],
channel=/meta/handshake, id=328, version=1.0, successful=true}
[DEBUG] 2024-06-04 00:17:20,227
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
[Camel (camel-1) thread #320 - SalesforceHttpClient ] - [CHANNEL:META_CONNECT]:
{clientId=REDACTED, advice={reconnect=retry, interval=0, timeout=11},
channel=/meta/connect, id=329, successful=true}
[DEBUG] 2024-06-04 00:17:20,227
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
[Camel (camel-1) thread #320 - SalesforceHttpClient ] - Refreshing
subscriptions to 1 channels on reconnect
[INFO ] 2024-06-04 00:17:20,227
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
[Camel (camel-1) thread #320 - SalesforceHttpClient ] - Subscribing to channel
/event/M1SF_SObject_Capture__e...
[DEBUG] 2024-06-04 00:17:20,243
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
[Camel (camel-1) thread #321 - SalesforceHttpClient ] - [CHANNEL:META_CONNECT]:
{advice={reconnect=handshake, interval=0}, channel=/meta/connect, id=330,
error=403::Unknown client, successful=false}
[WARN ] 2024-06-04 00:17:20,243
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
[Camel (camel-1) thread #321 - SalesforceHttpClient ] - Connect failure:
{advice={reconnect=handshake, interval=0}, channel=/meta/connect, id=330,
error=403::Unknown client, successful=false}
[DEBUG] 2024-06-04 00:17:20,243
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
[Camel (camel-1) thread #321 - SalesforceHttpClient ] - Advice != retry, so
handshaking
[DEBUG] 2024-06-04 00:17:20,243
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
[Camel (camel-1) thread #321 - SalesforceHttpClient ] - Begin handshake if not
already in progress.
[DEBUG] 2024-06-04 00:17:20,269
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
[SalesforceHttpClient@f13e0a2-34 ] - [CHANNEL:META_SUBSCRIBE]:
{advice={reconnect=handshake, interval=0}, channel=/meta/subscribe, id=331,
error=403::Unknown client, successful=false}
[INFO ] 2024-06-04 00:17:20,270 org.cometd.bayeux.client.ClientSession
[SalesforceHttpClient@f13e0a2-34 ] - Exception while invoking listener
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper$5@704dd2c3
java.lang.NullPointerException: Cannot invoke "Object.toString()" because the
return value of "org.cometd.bayeux.Message.get(Object)" is null
at
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper$5.onMessage(SubscriptionHelper.java:452)
at
org.cometd.common.AbstractClientSession$AbstractSessionChannel.notifyOnMessage(AbstractClientSession.java:599)
at
org.cometd.common.AbstractClientSession$AbstractSessionChannel.notifyMessageListeners(AbstractClientSession.java:586)
at
org.cometd.common.AbstractClientSession.notifyListeners(AbstractClientSession.java:311)
at
org.cometd.common.AbstractClientSession.lambda$receive$4(AbstractClientSession.java:268)
at org.cometd.bayeux.Promise$2.succeed(Promise.java:96)
[jira] [Updated] (CAMEL-20834) A NullPointException in SubscriptionHelper.subscribe() results in the interruption of the platform-event channel subscription and events are not received
[
https://issues.apache.org/jira/browse/CAMEL-20834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason updated CAMEL-20834:
--
Description:
I appears that when the {{SubscriptionHelper}} attempts to reconnect and
resubscribe to a channel in Salesforce, that occasionally and at an
unpredictable rate, the {{subscriptionListene}} instance in
{{SubscriptionHelper.subscribe}} throws an NPE when attempting to get the
{{SUBSCRIPTION_FIELD}} from the response message from Salesforce because in
some cases that message does not contain a {{subscription}} property in the
JSON response.
This results in the component seeming to
This seems to be the offending line:
https://github.com/apache/camel/blob/main/components/camel-salesforce/camel-salesforce-component/src/main/java/org/apache/camel/component/salesforce/internal/streaming/SubscriptionHelper.java#L475
The reconnection seem to happen, but never actually re-subscribes to the
channel and therefore the flow of platform-events stops until the spring-boot
application is restarted.
Here is some of the associated logging:
{noformat}
[DEBUG] 2024-06-04 00:17:20,212
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
[Camel (camel-1) thread #319 - SalesforceHttpClient ] -
[CHANNEL:META_HANDSHAKE]: {ext={replay=true, payload.format=true},
minimumVersion=1.0, clientId=REDACTED, supportedConnectionTypes=[long-polling],
channel=/meta/handshake, id=328, version=1.0, successful=true}
[DEBUG] 2024-06-04 00:17:20,227
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
[Camel (camel-1) thread #320 - SalesforceHttpClient ] - [CHANNEL:META_CONNECT]:
{clientId=REDACTED, advice={reconnect=retry, interval=0, timeout=11},
channel=/meta/connect, id=329, successful=true}
[DEBUG] 2024-06-04 00:17:20,227
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
[Camel (camel-1) thread #320 - SalesforceHttpClient ] - Refreshing
subscriptions to 1 channels on reconnect
[INFO ] 2024-06-04 00:17:20,227
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
[Camel (camel-1) thread #320 - SalesforceHttpClient ] - Subscribing to channel
/event/M1SF_SObject_Capture__e...
[DEBUG] 2024-06-04 00:17:20,243
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
[Camel (camel-1) thread #321 - SalesforceHttpClient ] - [CHANNEL:META_CONNECT]:
{advice={reconnect=handshake, interval=0}, channel=/meta/connect, id=330,
error=403::Unknown client, successful=false}
[WARN ] 2024-06-04 00:17:20,243
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
[Camel (camel-1) thread #321 - SalesforceHttpClient ] - Connect failure:
{advice={reconnect=handshake, interval=0}, channel=/meta/connect, id=330,
error=403::Unknown client, successful=false}
[DEBUG] 2024-06-04 00:17:20,243
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
[Camel (camel-1) thread #321 - SalesforceHttpClient ] - Advice != retry, so
handshaking
[DEBUG] 2024-06-04 00:17:20,243
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
[Camel (camel-1) thread #321 - SalesforceHttpClient ] - Begin handshake if not
already in progress.
[DEBUG] 2024-06-04 00:17:20,269
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
[SalesforceHttpClient@f13e0a2-34 ] - [CHANNEL:META_SUBSCRIBE]:
{advice={reconnect=handshake, interval=0}, channel=/meta/subscribe, id=331,
error=403::Unknown client, successful=false}
[INFO ] 2024-06-04 00:17:20,270 org.cometd.bayeux.client.ClientSession
[SalesforceHttpClient@f13e0a2-34 ] - Exception while invoking listener
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper$5@704dd2c3
java.lang.NullPointerException: Cannot invoke "Object.toString()" because the
return value of "org.cometd.bayeux.Message.get(Object)" is null
at
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper$5.onMessage(SubscriptionHelper.java:452)
at
org.cometd.common.AbstractClientSession$AbstractSessionChannel.notifyOnMessage(AbstractClientSession.java:599)
at
org.cometd.common.AbstractClientSession$AbstractSessionChannel.notifyMessageListeners(AbstractClientSession.java:586)
at
org.cometd.common.AbstractClientSession.notifyListeners(AbstractClientSession.java:311)
at
org.cometd.common.AbstractClientSession.lambda$receive$4(AbstractClientSession.java:268)
at org.cometd.bayeux.Promise$2.succeed(Promise.java:96)
at
org.cometd.common.AsyncFoldLeft$AbstractLoop.run(AsyncFoldLeft.java:236)
at org.cometd.common.AsyncFoldLeft.run(AsyncFoldLeft.java:107)
at
org.cometd.common.AbstractClientSession.extendIncoming(AbstractClientSession.java:99)
at
org.cometd.common.AbstractClientSession.receive(AbstractClientSession.java:262)
at org
[jira] [Updated] (CAMEL-20834) A NullPointException in SubscriptionHelper.subscribe() results in the interruption of the platform-event channel subscription and events are not received
[
https://issues.apache.org/jira/browse/CAMEL-20834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason updated CAMEL-20834:
--
Description:
I appears that when the {{SubscriptionHelper}} attempts to reconnect and
resubscribe to a channel in Salesforce, that occasionally and at an
unpredictable rate, the {{subscriptionListene}} instance in
{{SubscriptionHelper.subscribe}} throws an NPE when attempting to get the
{{SUBSCRIPTION_FIELD}} from the response message from Salesforce because in
some cases that message does not contain a `subscription` property in the JSON
response.
This results in the component seeming to
This seems to be the offending line:
https://github.com/apache/camel/blob/main/components/camel-salesforce/camel-salesforce-component/src/main/java/org/apache/camel/component/salesforce/internal/streaming/SubscriptionHelper.java#L475
The reconnection seem to happen, but never actually re-subscribes to the
channel and therefore the flow of platform-events stops until the spring-boot
application is restarted.
Here is some of the associated logging:
{noformat}
[DEBUG] 2024-06-04 00:17:20,212
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
[Camel (camel-1) thread #319 - SalesforceHttpClient ] -
[CHANNEL:META_HANDSHAKE]: {ext={replay=true, payload.format=true},
minimumVersion=1.0, clientId=REDACTED, supportedConnectionTypes=[long-polling],
channel=/meta/handshake, id=328, version=1.0, successful=true}
[DEBUG] 2024-06-04 00:17:20,227
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
[Camel (camel-1) thread #320 - SalesforceHttpClient ] - [CHANNEL:META_CONNECT]:
{clientId=REDACTED, advice={reconnect=retry, interval=0, timeout=11},
channel=/meta/connect, id=329, successful=true}
[DEBUG] 2024-06-04 00:17:20,227
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
[Camel (camel-1) thread #320 - SalesforceHttpClient ] - Refreshing
subscriptions to 1 channels on reconnect
[INFO ] 2024-06-04 00:17:20,227
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
[Camel (camel-1) thread #320 - SalesforceHttpClient ] - Subscribing to channel
/event/M1SF_SObject_Capture__e...
[DEBUG] 2024-06-04 00:17:20,243
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
[Camel (camel-1) thread #321 - SalesforceHttpClient ] - [CHANNEL:META_CONNECT]:
{advice={reconnect=handshake, interval=0}, channel=/meta/connect, id=330,
error=403::Unknown client, successful=false}
[WARN ] 2024-06-04 00:17:20,243
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
[Camel (camel-1) thread #321 - SalesforceHttpClient ] - Connect failure:
{advice={reconnect=handshake, interval=0}, channel=/meta/connect, id=330,
error=403::Unknown client, successful=false}
[DEBUG] 2024-06-04 00:17:20,243
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
[Camel (camel-1) thread #321 - SalesforceHttpClient ] - Advice != retry, so
handshaking
[DEBUG] 2024-06-04 00:17:20,243
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
[Camel (camel-1) thread #321 - SalesforceHttpClient ] - Begin handshake if not
already in progress.
[DEBUG] 2024-06-04 00:17:20,269
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
[SalesforceHttpClient@f13e0a2-34 ] - [CHANNEL:META_SUBSCRIBE]:
{advice={reconnect=handshake, interval=0}, channel=/meta/subscribe, id=331,
error=403::Unknown client, successful=false}
[INFO ] 2024-06-04 00:17:20,270 org.cometd.bayeux.client.ClientSession
[SalesforceHttpClient@f13e0a2-34 ] - Exception while invoking listener
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper$5@704dd2c3
java.lang.NullPointerException: Cannot invoke "Object.toString()" because the
return value of "org.cometd.bayeux.Message.get(Object)" is null
at
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper$5.onMessage(SubscriptionHelper.java:452)
at
org.cometd.common.AbstractClientSession$AbstractSessionChannel.notifyOnMessage(AbstractClientSession.java:599)
at
org.cometd.common.AbstractClientSession$AbstractSessionChannel.notifyMessageListeners(AbstractClientSession.java:586)
at
org.cometd.common.AbstractClientSession.notifyListeners(AbstractClientSession.java:311)
at
org.cometd.common.AbstractClientSession.lambda$receive$4(AbstractClientSession.java:268)
at org.cometd.bayeux.Promise$2.succeed(Promise.java:96)
at
org.cometd.common.AsyncFoldLeft$AbstractLoop.run(AsyncFoldLeft.java:236)
at org.cometd.common.AsyncFoldLeft.run(AsyncFoldLeft.java:107)
at
org.cometd.common.AbstractClientSession.extendIncoming(AbstractClientSession.java:99)
at
org.cometd.common.AbstractClientSession.receive(AbstractClientSession.java:262)
at org.c
[jira] [Updated] (CAMEL-20834) A NullPointException in SubscriptionHelper.subscribe() results in the interruption of the platform-event channel subscription and events are not received
[
https://issues.apache.org/jira/browse/CAMEL-20834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason updated CAMEL-20834:
--
Description:
I appears that when the {{SubscriptionHelper}} attempts to reconnect and
resubscribe to a channel in Salesforce, that occasionally and at an
unpredictable rate, the {{subscriptionListener}} instance in
{{SubscriptionHelper.subscribe}} throws an NPE when attempting to get the
{{SUBSCRIPTION_FIELD}} from the response message from Salesforce because in
some cases that message does not contain a {{subscription}} property in the
JSON response.
This results in the component seeming to
This seems to be the offending line:
https://github.com/apache/camel/blob/main/components/camel-salesforce/camel-salesforce-component/src/main/java/org/apache/camel/component/salesforce/internal/streaming/SubscriptionHelper.java#L475
The reconnection seem to happen, but never actually re-subscribes to the
channel and therefore the flow of platform-events stops until the spring-boot
application is restarted.
Here is some of the associated logging:
{noformat}
[DEBUG] 2024-06-04 00:17:20,212
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
[Camel (camel-1) thread #319 - SalesforceHttpClient ] -
[CHANNEL:META_HANDSHAKE]: {ext={replay=true, payload.format=true},
minimumVersion=1.0, clientId=REDACTED, supportedConnectionTypes=[long-polling],
channel=/meta/handshake, id=328, version=1.0, successful=true}
[DEBUG] 2024-06-04 00:17:20,227
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
[Camel (camel-1) thread #320 - SalesforceHttpClient ] - [CHANNEL:META_CONNECT]:
{clientId=REDACTED, advice={reconnect=retry, interval=0, timeout=11},
channel=/meta/connect, id=329, successful=true}
[DEBUG] 2024-06-04 00:17:20,227
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
[Camel (camel-1) thread #320 - SalesforceHttpClient ] - Refreshing
subscriptions to 1 channels on reconnect
[INFO ] 2024-06-04 00:17:20,227
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
[Camel (camel-1) thread #320 - SalesforceHttpClient ] - Subscribing to channel
/event/M1SF_SObject_Capture__e...
[DEBUG] 2024-06-04 00:17:20,243
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
[Camel (camel-1) thread #321 - SalesforceHttpClient ] - [CHANNEL:META_CONNECT]:
{advice={reconnect=handshake, interval=0}, channel=/meta/connect, id=330,
error=403::Unknown client, successful=false}
[WARN ] 2024-06-04 00:17:20,243
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
[Camel (camel-1) thread #321 - SalesforceHttpClient ] - Connect failure:
{advice={reconnect=handshake, interval=0}, channel=/meta/connect, id=330,
error=403::Unknown client, successful=false}
[DEBUG] 2024-06-04 00:17:20,243
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
[Camel (camel-1) thread #321 - SalesforceHttpClient ] - Advice != retry, so
handshaking
[DEBUG] 2024-06-04 00:17:20,243
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
[Camel (camel-1) thread #321 - SalesforceHttpClient ] - Begin handshake if not
already in progress.
[DEBUG] 2024-06-04 00:17:20,269
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
[SalesforceHttpClient@f13e0a2-34 ] - [CHANNEL:META_SUBSCRIBE]:
{advice={reconnect=handshake, interval=0}, channel=/meta/subscribe, id=331,
error=403::Unknown client, successful=false}
[INFO ] 2024-06-04 00:17:20,270 org.cometd.bayeux.client.ClientSession
[SalesforceHttpClient@f13e0a2-34 ] - Exception while invoking listener
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper$5@704dd2c3
java.lang.NullPointerException: Cannot invoke "Object.toString()" because the
return value of "org.cometd.bayeux.Message.get(Object)" is null
at
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper$5.onMessage(SubscriptionHelper.java:452)
at
org.cometd.common.AbstractClientSession$AbstractSessionChannel.notifyOnMessage(AbstractClientSession.java:599)
at
org.cometd.common.AbstractClientSession$AbstractSessionChannel.notifyMessageListeners(AbstractClientSession.java:586)
at
org.cometd.common.AbstractClientSession.notifyListeners(AbstractClientSession.java:311)
at
org.cometd.common.AbstractClientSession.lambda$receive$4(AbstractClientSession.java:268)
at org.cometd.bayeux.Promise$2.succeed(Promise.java:96)
at
org.cometd.common.AsyncFoldLeft$AbstractLoop.run(AsyncFoldLeft.java:236)
at org.cometd.common.AsyncFoldLeft.run(AsyncFoldLeft.java:107)
at
org.cometd.common.AbstractClientSession.extendIncoming(AbstractClientSession.java:99)
at
org.cometd.common.AbstractClientSession.receive(AbstractClientSession.java:262)
at or
[jira] [Created] (CAMEL-20835) OOM using RecipientList
Arthur Naseef created CAMEL-20835:
-
Summary: OOM using RecipientList
Key: CAMEL-20835
URL: https://issues.apache.org/jira/browse/CAMEL-20835
Project: Camel
Issue Type: Bug
Components: camel-core
Affects Versions: 4.6.0, 3.10.0
Reporter: Arthur Naseef
Out Of Memory (OOM) occurs when using the Recipient List with a large number of
dynamic URLs. For example:
.recipientList(simple("http://\{{downstream-server}}/employee/${header.emplId}";))
with a large number of values for ${header.emplId} leads to the OOM.
REPRODUCER:
=
[https://github.com/artnaseef/camel-recipient-list-oom-reproducer]
- See the README.md for instructions to reproduce and detect the problem
DETAILS
===
The MulticastProcessor, which RecipientListProcessor extends, has the
following "unlimited" cache:
private final ConcurrentMap errorHandlers = new
ConcurrentHashMap<>();
Entries are added to this map for every unique processor created - every unique
URL generates a unique processor. The entries themselves are wrapped processor
instances for error handling IIUC (to support the custom error handling used by
multicast and recipient-list). Entries are only removed from this map on
shutdown. Ironically, there is an LRUCache for the processors themselves, with
a default maximum size of 1000, so the wrapped processors may get recreated
even though the error handler remains in the map indefinitely.
*IMPACT VERSIONS:*
**
Appears to impact versions >= 3.10.0
*COMMIT: 0d9227ff16fb00e047fdd087740c87cce01bb545*
*===*
It appears this commit introduced the use of the errorHandlers "unlimited"
cache for recipient lists.
*FOLLOW-UP*
*==*
I have ideas and questions for implemeting a fix:
- IDEA 1: We can use an LRUCache for this data structure as well.
- Does it make more sense to remove the entries from errorHandlers when the
related Processor entry is removed from it's LRUCache?
- IDEA 2: setting on recipient list to disable the errorHandler cache (for
dyamic urls with little chance of duplicates, this could be the best)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-20835) OOM using RecipientList
[
https://issues.apache.org/jira/browse/CAMEL-20835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arthur Naseef updated CAMEL-20835:
--
Description:
Out Of Memory (OOM) occurs when using the Recipient List with a large number of
dynamic URLs. For example:
.recipientList(simple("http://{{{}downstream-server{}}}/employee/${header.emplId}";))
with a large number of values for ${header.emplId} leads to the OOM.
*REPRODUCER:*
*=*
[https://github.com/artnaseef/camel-recipient-list-oom-reproducer]
See the README.md for instructions to reproduce and detect the problem
*DETAILS*
*===*
The MulticastProcessor, which RecipientListProcessor extends, has the
following "unlimited" cache:
private final ConcurrentMap errorHandlers = new
ConcurrentHashMap<>();
Entries are added to this map for every unique processor created - every unique
URL generates a unique processor. The entries themselves are wrapped processor
instances for error handling IIUC (to support the custom error handling used by
multicast and recipient-list). Entries are only removed from this map on
shutdown. Ironically, there is an LRUCache for the processors themselves, with
a default maximum size of 1000, so the wrapped processors may get recreated
even though the error handler remains in the map indefinitely.
*IMPACT VERSIONS:*
**
Appears to impact versions >= 3.10.0
*COMMIT: 0d9227ff16fb00e047fdd087740c87cce01bb545*
*===*
It appears this commit introduced the use of the errorHandlers "unlimited"
cache for recipient lists.
*FOLLOW-UP*
*==*
I have ideas and questions for implemeting a fix:
- IDEA 1: We can use an LRUCache for this data structure as well.
- Does it make more sense to remove the entries from errorHandlers when the
related Processor entry is removed from it's LRUCache?
- IDEA 2: setting on recipient list to disable the errorHandler cache (for
dyamic urls with little chance of duplicates, this could be the best)
was:
Out Of Memory (OOM) occurs when using the Recipient List with a large number of
dynamic URLs. For example:
.recipientList(simple("http://\{{downstream-server}}/employee/${header.emplId}";))
with a large number of values for ${header.emplId} leads to the OOM.
REPRODUCER:
=
[https://github.com/artnaseef/camel-recipient-list-oom-reproducer]
- See the README.md for instructions to reproduce and detect the problem
DETAILS
===
The MulticastProcessor, which RecipientListProcessor extends, has the
following "unlimited" cache:
private final ConcurrentMap errorHandlers = new
ConcurrentHashMap<>();
Entries are added to this map for every unique processor created - every unique
URL generates a unique processor. The entries themselves are wrapped processor
instances for error handling IIUC (to support the custom error handling used by
multicast and recipient-list). Entries are only removed from this map on
shutdown. Ironically, there is an LRUCache for the processors themselves, with
a default maximum size of 1000, so the wrapped processors may get recreated
even though the error handler remains in the map indefinitely.
*IMPACT VERSIONS:*
**
Appears to impact versions >= 3.10.0
*COMMIT: 0d9227ff16fb00e047fdd087740c87cce01bb545*
*===*
It appears this commit introduced the use of the errorHandlers "unlimited"
cache for recipient lists.
*FOLLOW-UP*
*==*
I have ideas and questions for implemeting a fix:
- IDEA 1: We can use an LRUCache for this data structure as well.
- Does it make more sense to remove the entries from errorHandlers when the
related Processor entry is removed from it's LRUCache?
- IDEA 2: setting on recipient list to disable the errorHandler cache (for
dyamic urls with little chance of duplicates, this could be the best)
POC commits can be found here:
https://github.com/apache/camel/compare/main...artnaseef:camel:asn/disable-error-handler-cache-setting
> OOM using RecipientList
> ---
>
> Key: CAMEL-20835
> URL: https://issues.apache.org/jira/browse/CAMEL-20835
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 3.10.0, 4.6.0
>Reporter: Arthur Naseef
>Priority: Critical
>
> Out Of Memory (OOM) occurs when using the Recipient List with a large number
> of dynamic URLs. For example:
>
>
> .recipientList(simple("http://{{{}downstream-server{}}}/employee/${header.emplId}";))
>
> with a large number of values for ${header.emplId} leads to the OOM.
>
> *REPRODUCER:*
> *=*
> [https://github.com/artnaseef/camel-recipient-list-oom-reproducer]
>
> See the README.md for instructions to reproduce and detect the problem
>
> *DETAILS*
> *===*
> The MulticastProcessor, which RecipientListProcessor exte
[jira] [Updated] (CAMEL-20835) OOM using RecipientList
[
https://issues.apache.org/jira/browse/CAMEL-20835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-20835:
Priority: Major (was: Critical)
> OOM using RecipientList
> ---
>
> Key: CAMEL-20835
> URL: https://issues.apache.org/jira/browse/CAMEL-20835
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 3.10.0, 4.6.0
>Reporter: Arthur Naseef
>Priority: Major
>
> Out Of Memory (OOM) occurs when using the Recipient List with a large number
> of dynamic URLs. For example:
>
>
> .recipientList(simple("http://{{{}downstream-server{}}}/employee/${header.emplId}";))
>
> with a large number of values for ${header.emplId} leads to the OOM.
>
> *REPRODUCER:*
> *=*
> [https://github.com/artnaseef/camel-recipient-list-oom-reproducer]
>
> See the README.md for instructions to reproduce and detect the problem
>
> *DETAILS*
> *===*
> The MulticastProcessor, which RecipientListProcessor extends, has the
> following "unlimited" cache:
>
> private final ConcurrentMap errorHandlers = new
> ConcurrentHashMap<>();
>
> Entries are added to this map for every unique processor created - every
> unique URL generates a unique processor. The entries themselves are wrapped
> processor instances for error handling IIUC (to support the custom error
> handling used by multicast and recipient-list). Entries are only removed
> from this map on shutdown. Ironically, there is an LRUCache for the
> processors themselves, with a default maximum size of 1000, so the wrapped
> processors may get recreated even though the error handler remains in the map
> indefinitely.
>
> *IMPACT VERSIONS:*
> **
> Appears to impact versions >= 3.10.0
> *COMMIT: 0d9227ff16fb00e047fdd087740c87cce01bb545*
> *===*
> It appears this commit introduced the use of the errorHandlers "unlimited"
> cache for recipient lists.
>
> *FOLLOW-UP*
> *==*
> I have ideas and questions for implemeting a fix:
> - IDEA 1: We can use an LRUCache for this data structure as well.
> - Does it make more sense to remove the entries from errorHandlers when
> the related Processor entry is removed from it's LRUCache?
> - IDEA 2: setting on recipient list to disable the errorHandler cache
> (for dyamic urls with little chance of duplicates, this could be the best)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-20833) Add recursive option to camel-smb
[ https://issues.apache.org/jira/browse/CAMEL-20833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-20833: Issue Type: Improvement (was: Bug) > Add recursive option to camel-smb > - > > Key: CAMEL-20833 > URL: https://issues.apache.org/jira/browse/CAMEL-20833 > Project: Camel > Issue Type: Improvement > Components: camel-smb >Affects Versions: 4.6.0 >Reporter: Thomas Cunningham >Assignee: Thomas Cunningham >Priority: Major > > Add a recursive option to camel-smb -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-20833) Add recursive option to camel-smb
[ https://issues.apache.org/jira/browse/CAMEL-20833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-20833: Fix Version/s: 4.7.0 > Add recursive option to camel-smb > - > > Key: CAMEL-20833 > URL: https://issues.apache.org/jira/browse/CAMEL-20833 > Project: Camel > Issue Type: Improvement > Components: camel-smb >Affects Versions: 4.6.0 >Reporter: Thomas Cunningham >Assignee: Thomas Cunningham >Priority: Major > Fix For: 4.7.0 > > > Add a recursive option to camel-smb -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-20822) camel-langchain4j-chat - implement tool capabilities
[
https://issues.apache.org/jira/browse/CAMEL-20822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-20822.
-
Resolution: Fixed
> camel-langchain4j-chat - implement tool capabilities
>
>
> Key: CAMEL-20822
> URL: https://issues.apache.org/jira/browse/CAMEL-20822
> Project: Camel
> Issue Type: New Feature
> Components: camel-ai
>Reporter: Federico Mariani
>Assignee: Federico Mariani
>Priority: Major
> Fix For: 4.7.0
>
>
> Implement OpenAI Tool capabilities, so that camel consumer route can be used
> as Tool logic ala:
> {code:java}
> from("langchain4j-chat:chatId").to("sql:SELECT name FROM users WHERE id =
> :#id") {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-20834) camel-salesforce - A NullPointException in SubscriptionHelper.subscribe() events are not received
[
https://issues.apache.org/jira/browse/CAMEL-20834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-20834:
Summary: camel-salesforce - A NullPointException in
SubscriptionHelper.subscribe() events are not received (was: A
NullPointException in SubscriptionHelper.subscribe() results in the
interruption of the platform-event channel subscription and events are not
received)
> camel-salesforce - A NullPointException in SubscriptionHelper.subscribe()
> events are not received
> -
>
> Key: CAMEL-20834
> URL: https://issues.apache.org/jira/browse/CAMEL-20834
> Project: Camel
> Issue Type: Bug
> Components: camel-salesforce
>Affects Versions: 4.5.0, 4.6.0
> Environment: Spring-Boot: 3.2.6
> Camel: 4.5.0 or 4.6.0
> Java: 17
>Reporter: Jason
>Priority: Major
>
> I appears that when the {{SubscriptionHelper}} attempts to reconnect and
> resubscribe to a channel in Salesforce, that occasionally and at an
> unpredictable rate, the {{subscriptionListener}} instance in
> {{SubscriptionHelper.subscribe}} throws an NPE when attempting to get the
> {{SUBSCRIPTION_FIELD}} from the response message from Salesforce because in
> some cases that message does not contain a {{subscription}} property in the
> JSON response.
> This results in the component seeming to
> This seems to be the offending line:
> https://github.com/apache/camel/blob/main/components/camel-salesforce/camel-salesforce-component/src/main/java/org/apache/camel/component/salesforce/internal/streaming/SubscriptionHelper.java#L475
> The reconnection seem to happen, but never actually re-subscribes to the
> channel and therefore the flow of platform-events stops until the spring-boot
> application is restarted.
> Here is some of the associated logging:
> {noformat}
> [DEBUG] 2024-06-04 00:17:20,212
> org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
> [Camel (camel-1) thread #319 - SalesforceHttpClient ] -
> [CHANNEL:META_HANDSHAKE]: {ext={replay=true, payload.format=true},
> minimumVersion=1.0, clientId=REDACTED,
> supportedConnectionTypes=[long-polling], channel=/meta/handshake, id=328,
> version=1.0, successful=true}
> [DEBUG] 2024-06-04 00:17:20,227
> org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
> [Camel (camel-1) thread #320 - SalesforceHttpClient ] -
> [CHANNEL:META_CONNECT]: {clientId=REDACTED, advice={reconnect=retry,
> interval=0, timeout=11}, channel=/meta/connect, id=329, successful=true}
> [DEBUG] 2024-06-04 00:17:20,227
> org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
> [Camel (camel-1) thread #320 - SalesforceHttpClient ] - Refreshing
> subscriptions to 1 channels on reconnect
> [INFO ] 2024-06-04 00:17:20,227
> org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
> [Camel (camel-1) thread #320 - SalesforceHttpClient ] - Subscribing to
> channel /event/M1SF_SObject_Capture__e...
> [DEBUG] 2024-06-04 00:17:20,243
> org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
> [Camel (camel-1) thread #321 - SalesforceHttpClient ] -
> [CHANNEL:META_CONNECT]: {advice={reconnect=handshake, interval=0},
> channel=/meta/connect, id=330, error=403::Unknown client, successful=false}
> [WARN ] 2024-06-04 00:17:20,243
> org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
> [Camel (camel-1) thread #321 - SalesforceHttpClient ] - Connect failure:
> {advice={reconnect=handshake, interval=0}, channel=/meta/connect, id=330,
> error=403::Unknown client, successful=false}
> [DEBUG] 2024-06-04 00:17:20,243
> org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
> [Camel (camel-1) thread #321 - SalesforceHttpClient ] - Advice != retry, so
> handshaking
> [DEBUG] 2024-06-04 00:17:20,243
> org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
> [Camel (camel-1) thread #321 - SalesforceHttpClient ] - Begin handshake if
> not already in progress.
> [DEBUG] 2024-06-04 00:17:20,269
> org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
> [SalesforceHttpClient@f13e0a2-34 ] - [CHANNEL:META_SUBSCRIBE]:
> {advice={reconnect=handshake, interval=0}, channel=/meta/subscribe, id=331,
> error=403::Unknown client, successful=false}
> [INFO ] 2024-06-04 00:17:20,270 org.cometd.bayeux.client.ClientSession
> [SalesforceHttpClient@f13e0a2-34 ] - Exception while invoking listener
> org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper$5@704dd2c3
> java.lang.NullPointerException: Cannot invoke "Object.toString()" because the
> return value of "org.cometd.bayeux
[jira] [Updated] (CAMEL-20660) camel-azure-servicebus: Consumer fails to acknowledge messages
[
https://issues.apache.org/jira/browse/CAMEL-20660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-20660:
Fix Version/s: 4.7.0
(was: 4.x)
> camel-azure-servicebus: Consumer fails to acknowledge messages
> --
>
> Key: CAMEL-20660
> URL: https://issues.apache.org/jira/browse/CAMEL-20660
> Project: Camel
> Issue Type: Bug
> Components: camel-azure
>Affects Versions: 4.4.0, 4.4.1, 4.5.0
>Reporter: Dylan Piergies
>Priority: Major
> Fix For: 4.7.0
>
>
> We have observed issues with the Service Bus consumer from Camel 4.4+ where
> consumed messages are not acknowledged/completed correctly and landing in the
> dead-letter queue, despite the Exchange having successfully delivered the
> message to its destination.
> Our routes all follow the general form:
> {{from(azureServicebus(...))}}
> {{ // ...}}
> {{ .to(https(...))}}
> {{ .log("Message delivered to...");}}
> In our logs, we are seeing the message from the final {{log}} EIP and we can
> confirm that the message has been delivered to the destination service, but
> this is often followed by a log message from the
> {{com.azure.messaging.servicebus.ServiceBusReceiverAsyncClient}} logger:
> {{Cannot perform operation 'completed' on a disposed receiver.}}
> We then see many of these messages arriving in the DLQ, once the retry count
> is exceeded.
> The issue is difficult to create a reproduction for: it is intermittent and
> occurs most frequently during a spike in message volumes.
> The issue disappears after downgrading Camel to 4.3.0.
> Whilst we do not know the root cause for sure, we suspect this may be a
> defect of CAMEL-19262, occurring if the client is closed and recreated while
> an Exchange is in flight.
> Related Zulip chat discussion:
> https://camel.zulipchat.com/#narrow/stream/257298-camel/topic/Azure.20Service.20Bus.20Consumer.20failing.20to.20acknowledge.20messages
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (CAMEL-20660) camel-azure-servicebus: Consumer fails to acknowledge messages
[
https://issues.apache.org/jira/browse/CAMEL-20660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen reassigned CAMEL-20660:
---
Assignee: Dylan Piergies
> camel-azure-servicebus: Consumer fails to acknowledge messages
> --
>
> Key: CAMEL-20660
> URL: https://issues.apache.org/jira/browse/CAMEL-20660
> Project: Camel
> Issue Type: Bug
> Components: camel-azure
>Affects Versions: 4.4.0, 4.4.1, 4.5.0
>Reporter: Dylan Piergies
>Assignee: Dylan Piergies
>Priority: Major
> Fix For: 4.7.0
>
>
> We have observed issues with the Service Bus consumer from Camel 4.4+ where
> consumed messages are not acknowledged/completed correctly and landing in the
> dead-letter queue, despite the Exchange having successfully delivered the
> message to its destination.
> Our routes all follow the general form:
> {{from(azureServicebus(...))}}
> {{ // ...}}
> {{ .to(https(...))}}
> {{ .log("Message delivered to...");}}
> In our logs, we are seeing the message from the final {{log}} EIP and we can
> confirm that the message has been delivered to the destination service, but
> this is often followed by a log message from the
> {{com.azure.messaging.servicebus.ServiceBusReceiverAsyncClient}} logger:
> {{Cannot perform operation 'completed' on a disposed receiver.}}
> We then see many of these messages arriving in the DLQ, once the retry count
> is exceeded.
> The issue is difficult to create a reproduction for: it is intermittent and
> occurs most frequently during a spike in message volumes.
> The issue disappears after downgrading Camel to 4.3.0.
> Whilst we do not know the root cause for sure, we suspect this may be a
> defect of CAMEL-19262, occurring if the client is closed and recreated while
> an Exchange is in flight.
> Related Zulip chat discussion:
> https://camel.zulipchat.com/#narrow/stream/257298-camel/topic/Azure.20Service.20Bus.20Consumer.20failing.20to.20acknowledge.20messages
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-20831) camel-salesforce fails when JNDI InitialContext specified
[ https://issues.apache.org/jira/browse/CAMEL-20831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-20831: Summary: camel-salesforce fails when JNDI InitialContext specified (was: camel-salesforce fails when InitialContext specified) > camel-salesforce fails when JNDI InitialContext specified > - > > Key: CAMEL-20831 > URL: https://issues.apache.org/jira/browse/CAMEL-20831 > Project: Camel > Issue Type: Bug > Components: camel-salesforce >Affects Versions: 4.4.2, 4.6.0 >Reporter: Alexander Anpilov >Priority: Minor > Attachments: camel-test.zip > > > [(428) #camel > Possible bug with camel-salesforce - camel - Zulip > (zulipchat.com)|https://camel.zulipchat.com/#narrow/stream/257298-camel/topic/Possible.20bug.20with.20camel-salesforce] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-20831) camel-salesforce fails when JNDI InitialContext specified
[ https://issues.apache.org/jira/browse/CAMEL-20831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17852280#comment-17852280 ] Claus Ibsen commented on CAMEL-20831: - Can you past the full stacktrace here thanks, and use Camel 4.6.0 > camel-salesforce fails when JNDI InitialContext specified > - > > Key: CAMEL-20831 > URL: https://issues.apache.org/jira/browse/CAMEL-20831 > Project: Camel > Issue Type: Bug > Components: camel-salesforce >Affects Versions: 4.4.2, 4.6.0 >Reporter: Alexander Anpilov >Priority: Minor > Attachments: camel-test.zip > > > [(428) #camel > Possible bug with camel-salesforce - camel - Zulip > (zulipchat.com)|https://camel.zulipchat.com/#narrow/stream/257298-camel/topic/Possible.20bug.20with.20camel-salesforce] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-20831) camel-salesforce fails when JNDI InitialContext specified
[ https://issues.apache.org/jira/browse/CAMEL-20831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-20831: Fix Version/s: 4.x > camel-salesforce fails when JNDI InitialContext specified > - > > Key: CAMEL-20831 > URL: https://issues.apache.org/jira/browse/CAMEL-20831 > Project: Camel > Issue Type: Bug > Components: camel-salesforce >Affects Versions: 4.4.2, 4.6.0 >Reporter: Alexander Anpilov >Priority: Minor > Fix For: 4.x > > Attachments: camel-test.zip > > > [(428) #camel > Possible bug with camel-salesforce - camel - Zulip > (zulipchat.com)|https://camel.zulipchat.com/#narrow/stream/257298-camel/topic/Possible.20bug.20with.20camel-salesforce] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-20722) camel-kafka: reduce KafkaBreakOnFirstError tests are too unreliable for CIs
[ https://issues.apache.org/jira/browse/CAMEL-20722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17852284#comment-17852284 ] Jang-Vijay Singh commented on CAMEL-20722: -- Happy to contribute, [~davsclaus] :) , and thank you for the acknowledgement > camel-kafka: reduce KafkaBreakOnFirstError tests are too unreliable for CIs > --- > > Key: CAMEL-20722 > URL: https://issues.apache.org/jira/browse/CAMEL-20722 > Project: Camel > Issue Type: Task > Components: camel-kafka >Affects Versions: 4.4.1, 4.5.0 >Reporter: Otavio Rodolfo Piske >Assignee: Jang-Vijay Singh >Priority: Major > Labels: help-wanted > Fix For: 4.x > > Attachments: build-log.txt > > > All the tests named KafkaBreakOnFirst.*IT are unreliable when running on the > CI. They fail often, sometimes in multiple archs. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-20722) camel-kafka: reduce KafkaBreakOnFirstError tests are too unreliable for CIs
[
https://issues.apache.org/jira/browse/CAMEL-20722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17852285#comment-17852285
]
Jang-Vijay Singh commented on CAMEL-20722:
--
I expect this pull request to resolve the NoSuchElementException symptom seen
on CI in test
{color:#00}{color:#00}KafkaBreakOnFirstErrorSeekIssueIT{color}{color}
{color:#00}{color:#00}https://github.com/apache/camel/pull/14376{color}{color}
> camel-kafka: reduce KafkaBreakOnFirstError tests are too unreliable for CIs
> ---
>
> Key: CAMEL-20722
> URL: https://issues.apache.org/jira/browse/CAMEL-20722
> Project: Camel
> Issue Type: Task
> Components: camel-kafka
>Affects Versions: 4.4.1, 4.5.0
>Reporter: Otavio Rodolfo Piske
>Assignee: Jang-Vijay Singh
>Priority: Major
> Labels: help-wanted
> Fix For: 4.x
>
> Attachments: build-log.txt
>
>
> All the tests named KafkaBreakOnFirst.*IT are unreliable when running on the
> CI. They fail often, sometimes in multiple archs.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-20831) camel-salesforce fails when JNDI InitialContext specified
[ https://issues.apache.org/jira/browse/CAMEL-20831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Anpilov updated CAMEL-20831: -- Attachment: camel-salesforce-stacktrace.txt > camel-salesforce fails when JNDI InitialContext specified > - > > Key: CAMEL-20831 > URL: https://issues.apache.org/jira/browse/CAMEL-20831 > Project: Camel > Issue Type: Bug > Components: camel-salesforce >Affects Versions: 4.4.2, 4.6.0 >Reporter: Alexander Anpilov >Priority: Minor > Fix For: 4.x > > Attachments: camel-salesforce-stacktrace.txt, camel-test.zip > > > [(428) #camel > Possible bug with camel-salesforce - camel - Zulip > (zulipchat.com)|https://camel.zulipchat.com/#narrow/stream/257298-camel/topic/Possible.20bug.20with.20camel-salesforce] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-20831) camel-salesforce fails when JNDI InitialContext specified
[ https://issues.apache.org/jira/browse/CAMEL-20831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17852302#comment-17852302 ] Alexander Anpilov commented on CAMEL-20831: --- Stacktrace file placed > camel-salesforce fails when JNDI InitialContext specified > - > > Key: CAMEL-20831 > URL: https://issues.apache.org/jira/browse/CAMEL-20831 > Project: Camel > Issue Type: Bug > Components: camel-salesforce >Affects Versions: 4.4.2, 4.6.0 >Reporter: Alexander Anpilov >Priority: Minor > Fix For: 4.x > > Attachments: camel-salesforce-stacktrace.txt, camel-test.zip > > > [(428) #camel > Possible bug with camel-salesforce - camel - Zulip > (zulipchat.com)|https://camel.zulipchat.com/#narrow/stream/257298-camel/topic/Possible.20bug.20with.20camel-salesforce] -- This message was sent by Atlassian Jira (v8.20.10#820010)
