[jira] [Updated] (CAMEL-20022) camel-yaml-dsl: Add WARN log if kebab-case is detected
[ https://issues.apache.org/jira/browse/CAMEL-20022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomohisa Igarashi updated CAMEL-20022: -- Fix Version/s: 4.0.3 > camel-yaml-dsl: Add WARN log if kebab-case is detected > -- > > Key: CAMEL-20022 > URL: https://issues.apache.org/jira/browse/CAMEL-20022 > Project: Camel > Issue Type: Task > Components: camel-yaml-dsl >Reporter: Tomohisa Igarashi >Assignee: Tomohisa Igarashi >Priority: Minor > Fix For: 4.0.3, 4.2.0 > > > kebab-case will be removed from runtime at some point, see CAMEL-20018 > In the meantime, we can add WARN log when it detects the kebab-case in YAML > DSL, and suggest to use camelCase. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work started] (CAMEL-20022) camel-yaml-dsl: Add WARN log if kebab-case is detected
[ https://issues.apache.org/jira/browse/CAMEL-20022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CAMEL-20022 started by Tomohisa Igarashi. - > camel-yaml-dsl: Add WARN log if kebab-case is detected > -- > > Key: CAMEL-20022 > URL: https://issues.apache.org/jira/browse/CAMEL-20022 > Project: Camel > Issue Type: Task > Components: camel-yaml-dsl >Reporter: Tomohisa Igarashi >Assignee: Tomohisa Igarashi >Priority: Minor > Fix For: 4.2.0 > > > kebab-case will be removed from runtime at some point, see CAMEL-20018 > In the meantime, we can add WARN log when it detects the kebab-case in YAML > DSL, and suggest to use camelCase. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-20017) camel-yaml-dsl - ExchangeProperty language is duplicated in yaml schema
[ https://issues.apache.org/jira/browse/CAMEL-20017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomohisa Igarashi resolved CAMEL-20017. --- Resolution: Fixed > camel-yaml-dsl - ExchangeProperty language is duplicated in yaml schema > --- > > Key: CAMEL-20017 > URL: https://issues.apache.org/jira/browse/CAMEL-20017 > Project: Camel > Issue Type: Bug > Components: camel-yaml-dsl, tooling >Affects Versions: 4.1.0 >Reporter: Claus Ibsen >Assignee: Tomohisa Igarashi >Priority: Minor > Fix For: 4.2.0 > > > The schema has it listed 2 times > https://github.com/apache/camel/blob/main/dsl/camel-yaml-dsl/camel-yaml-dsl/src/generated/resources/schema/camelYamlDsl.json#L854 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-20022) camel-yaml-dsl: Add WARN log if kebab-case is detected
[ https://issues.apache.org/jira/browse/CAMEL-20022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomohisa Igarashi updated CAMEL-20022: -- Fix Version/s: 4.2.0 > camel-yaml-dsl: Add WARN log if kebab-case is detected > -- > > Key: CAMEL-20022 > URL: https://issues.apache.org/jira/browse/CAMEL-20022 > Project: Camel > Issue Type: Task > Components: camel-yaml-dsl >Reporter: Tomohisa Igarashi >Assignee: Tomohisa Igarashi >Priority: Minor > Fix For: 4.2.0 > > > kebab-case will be removed from runtime at some point, see CAMEL-20018 > In the meantime, we can add WARN log when it detects the kebab-case in YAML > DSL, and suggest to use camelCase. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CAMEL-20025) camel-aws - Should we make region an enum
[ https://issues.apache.org/jira/browse/CAMEL-20025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrea Cosentino reassigned CAMEL-20025: Assignee: Andrea Cosentino > camel-aws - Should we make region an enum > - > > Key: CAMEL-20025 > URL: https://issues.apache.org/jira/browse/CAMEL-20025 > Project: Camel > Issue Type: Improvement > Components: camel-aws >Reporter: Claus Ibsen >Assignee: Andrea Cosentino >Priority: Major > Fix For: 4.x > > > All the aws components has to set region as option. Its a string type. > But the AWS client requests to map this to a Region enum class, that has > hardcoded all known regions in the AWS SDK. There is about 40 regions in > total. > We could make region a Region instead of String in the code, then it will be > an enum automatic with those values. > This makes tooling more friendly as they would show a list of enums to choose > among. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-20025) camel-aws - Should we make region an enum
[ https://issues.apache.org/jira/browse/CAMEL-20025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrea Cosentino updated CAMEL-20025: - Fix Version/s: 4.2.0 (was: 4.x) > camel-aws - Should we make region an enum > - > > Key: CAMEL-20025 > URL: https://issues.apache.org/jira/browse/CAMEL-20025 > Project: Camel > Issue Type: Improvement > Components: camel-aws >Reporter: Claus Ibsen >Assignee: Andrea Cosentino >Priority: Major > Fix For: 4.2.0 > > > All the aws components has to set region as option. Its a string type. > But the AWS client requests to map this to a Region enum class, that has > hardcoded all known regions in the AWS SDK. There is about 40 regions in > total. > We could make region a Region instead of String in the code, then it will be > an enum automatic with those values. > This makes tooling more friendly as they would show a list of enums to choose > among. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-20025) camel-aws - Should we make region an enum
[ https://issues.apache.org/jira/browse/CAMEL-20025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrea Cosentino resolved CAMEL-20025. -- Resolution: Fixed > camel-aws - Should we make region an enum > - > > Key: CAMEL-20025 > URL: https://issues.apache.org/jira/browse/CAMEL-20025 > Project: Camel > Issue Type: Improvement > Components: camel-aws >Reporter: Claus Ibsen >Assignee: Andrea Cosentino >Priority: Major > Fix For: 4.2.0 > > > All the aws components has to set region as option. Its a string type. > But the AWS client requests to map this to a Region enum class, that has > hardcoded all known regions in the AWS SDK. There is about 40 regions in > total. > We could make region a Region instead of String in the code, then it will be > an enum automatic with those values. > This makes tooling more friendly as they would show a list of enums to choose > among. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-20044) On rejoining consumer group Camel can set offset incorrectly causing messages to be replayed
[
https://issues.apache.org/jira/browse/CAMEL-20044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Barlotta updated CAMEL-20044:
--
Environment:
* Rocky Linux 8.7
* Open JDK 11.0.8
* Camel 3.21.0
* Spring Boot 2.7.14
* Strimzi Kafka 0.28.0/3.0.0
was:
{*}Reproducing (intermittent){*}:
* Configure camel kafka consumer with following:
** autoCommitEnable = false
** allowManualCommit = true
** autoOffsetReset = earliest
** maxPollRecords = 1
** breakOnFirstError = true
* Produce a series of records to kafka record to both partitions.
* Throw an exception that is unhandled
* commit the offset in the onException block
*Expected behavior:*
* Application should consume the record 1 more time, then move on to the next
offset in the partition
*Actual behavior:*
* Application will often work. Occasionally will use the offset from another
partition and assign that to the partition where the record failed. This can
then result in the consumer replaying messages instead of moving forward.
I put together a sample that can recreate the error. However, given its
intermittent nature it may not fail on each run. I have included the logs from
3 different runs on my laptop from this test. Two of them show the error
occurring. One of the them has a successful run. I have also provided more
details in the README.
* https://github.com/CodeSmell/CamelKafkaOffset
This seems related to other issues with how Camel processes the
_breakOnFirstError_ attribute.
* CAMEL-14935
* CAMEL-18350
* CAMEL-19894
> On rejoining consumer group Camel can set offset incorrectly causing messages
> to be replayed
>
>
> Key: CAMEL-20044
> URL: https://issues.apache.org/jira/browse/CAMEL-20044
> Project: Camel
> Issue Type: Bug
> Components: camel-kafka
>Affects Versions: 3.21.0
> Environment: * Rocky Linux 8.7
> * Open JDK 11.0.8
> * Camel 3.21.0
> * Spring Boot 2.7.14
> * Strimzi Kafka 0.28.0/3.0.0
>Reporter: Mike Barlotta
>Priority: Major
>
> {*}Reproducing (intermittent){*}:
> * Configure camel kafka consumer with following:
> ** autoCommitEnable = false
> ** allowManualCommit = true
> ** autoOffsetReset = earliest
> ** maxPollRecords = 1
> ** breakOnFirstError = true
> * Produce a series of records to kafka record to both partitions.
> * Throw an exception that is unhandled
> * commit the offset in the onException block
> *Expected behavior:*
> * Application should consume the record 1 more time, then move on to the
> next offset in the partition
> *Actual behavior:*
> * Application will often work. Occasionally will use the offset from another
> partition and assign that to the partition where the record failed. This can
> then result in the consumer replaying messages instead of moving forward.
> I put together a sample that can recreate the error. However, given its
> intermittent nature it may not fail on each run. I have included the logs
> from 3 different runs on my laptop from this test. Two of them show the error
> occurring. One of the them has a successful run. I have also provided more
> details in the README.
> * [https://github.com/CodeSmell/CamelKafkaOffset]
> This seems related to other issues with how Camel processes the
> _breakOnFirstError_ attribute.
> * CAMEL-14935
> * CAMEL-18350
> * CAMEL-19894
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-20044) On rejoining consumer group Camel can set offset incorrectly causing messages to be replayed
[
https://issues.apache.org/jira/browse/CAMEL-20044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Barlotta updated CAMEL-20044:
--
Description:
{*}Reproducing (intermittent){*}:
* Configure camel kafka consumer with following:
** autoCommitEnable = false
** allowManualCommit = true
** autoOffsetReset = earliest
** maxPollRecords = 1
** breakOnFirstError = true
* Produce a series of records to kafka record to both partitions.
* Throw an exception that is unhandled
* commit the offset in the onException block
*Expected behavior:*
* Application should consume the record 1 more time, then move on to the next
offset in the partition
*Actual behavior:*
* Application will often work. Occasionally will use the offset from another
partition and assign that to the partition where the record failed. This can
then result in the consumer replaying messages instead of moving forward.
I put together a sample that can recreate the error. However, given its
intermittent nature it may not fail on each run. I have included the logs from
3 different runs on my laptop from this test. Two of them show the error
occurring. One of the them has a successful run. I have also provided more
details in the README.
* [https://github.com/CodeSmell/CamelKafkaOffset]
This seems related to other issues with how Camel processes the
_breakOnFirstError_ attribute.
* CAMEL-14935
* CAMEL-18350
* CAMEL-19894
> On rejoining consumer group Camel can set offset incorrectly causing messages
> to be replayed
>
>
> Key: CAMEL-20044
> URL: https://issues.apache.org/jira/browse/CAMEL-20044
> Project: Camel
> Issue Type: Bug
> Components: camel-kafka
>Affects Versions: 3.21.0
> Environment: {*}Reproducing (intermittent){*}:
> * Configure camel kafka consumer with following:
> ** autoCommitEnable = false
> ** allowManualCommit = true
> ** autoOffsetReset = earliest
> ** maxPollRecords = 1
> ** breakOnFirstError = true
> * Produce a series of records to kafka record to both partitions.
> * Throw an exception that is unhandled
> * commit the offset in the onException block
> *Expected behavior:*
> * Application should consume the record 1 more time, then move on to the
> next offset in the partition
> *Actual behavior:*
> * Application will often work. Occasionally will use the offset from another
> partition and assign that to the partition where the record failed. This can
> then result in the consumer replaying messages instead of moving forward.
> I put together a sample that can recreate the error. However, given its
> intermittent nature it may not fail on each run. I have included the logs
> from 3 different runs on my laptop from this test. Two of them show the error
> occurring. One of the them has a successful run. I have also provided more
> details in the README.
> * https://github.com/CodeSmell/CamelKafkaOffset
> This seems related to other issues with how Camel processes the
> _breakOnFirstError_ attribute.
> * CAMEL-14935
> * CAMEL-18350
> * CAMEL-19894
>Reporter: Mike Barlotta
>Priority: Major
>
> {*}Reproducing (intermittent){*}:
> * Configure camel kafka consumer with following:
> ** autoCommitEnable = false
> ** allowManualCommit = true
> ** autoOffsetReset = earliest
> ** maxPollRecords = 1
> ** breakOnFirstError = true
> * Produce a series of records to kafka record to both partitions.
> * Throw an exception that is unhandled
> * commit the offset in the onException block
> *Expected behavior:*
> * Application should consume the record 1 more time, then move on to the
> next offset in the partition
> *Actual behavior:*
> * Application will often work. Occasionally will use the offset from another
> partition and assign that to the partition where the record failed. This can
> then result in the consumer replaying messages instead of moving forward.
> I put together a sample that can recreate the error. However, given its
> intermittent nature it may not fail on each run. I have included the logs
> from 3 different runs on my laptop from this test. Two of them show the error
> occurring. One of the them has a successful run. I have also provided more
> details in the README.
> * [https://github.com/CodeSmell/CamelKafkaOffset]
> This seems related to other issues with how Camel processes the
> _breakOnFirstError_ attribute.
> * CAMEL-14935
> * CAMEL-18350
> * CAMEL-19894
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAMEL-20044) On rejoining consumer group Camel can set offset incorrectly causing messages to be replayed
Mike Barlotta created CAMEL-20044:
-
Summary: On rejoining consumer group Camel can set offset
incorrectly causing messages to be replayed
Key: CAMEL-20044
URL: https://issues.apache.org/jira/browse/CAMEL-20044
Project: Camel
Issue Type: Bug
Components: camel-kafka
Affects Versions: 3.21.0
Environment: {*}Reproducing (intermittent){*}:
* Configure camel kafka consumer with following:
** autoCommitEnable = false
** allowManualCommit = true
** autoOffsetReset = earliest
** maxPollRecords = 1
** breakOnFirstError = true
* Produce a series of records to kafka record to both partitions.
* Throw an exception that is unhandled
* commit the offset in the onException block
*Expected behavior:*
* Application should consume the record 1 more time, then move on to the next
offset in the partition
*Actual behavior:*
* Application will often work. Occasionally will use the offset from another
partition and assign that to the partition where the record failed. This can
then result in the consumer replaying messages instead of moving forward.
I put together a sample that can recreate the error. However, given its
intermittent nature it may not fail on each run. I have included the logs from
3 different runs on my laptop from this test. Two of them show the error
occurring. One of the them has a successful run. I have also provided more
details in the README.
* https://github.com/CodeSmell/CamelKafkaOffset
This seems related to other issues with how Camel processes the
_breakOnFirstError_ attribute.
* CAMEL-14935
* CAMEL-18350
* CAMEL-19894
Reporter: Mike Barlotta
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-20043) Micrometer: unclear instructions of docInstrumentedThreadPoolFactory configuration in the documentation
[ https://issues.apache.org/jira/browse/CAMEL-20043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiri Ondrusek updated CAMEL-20043: -- Affects Version/s: 4.x > Micrometer: unclear instructions of docInstrumentedThreadPoolFactory > configuration in the documentation > --- > > Key: CAMEL-20043 > URL: https://issues.apache.org/jira/browse/CAMEL-20043 > Project: Camel > Issue Type: Bug > Components: camel-micrometer >Affects Versions: 4.x >Reporter: Jiri Ondrusek >Assignee: Jiri Ondrusek >Priority: Minor > > Chapter [Instrumenting Camel Thread > Pools|https://camel.apache.org/components/4.0.x/micrometer-component.html#_instrumenting_camel_thread_pools] > in the documentation states: _See more details at Advanced configuration of > CamelContext using Spring._ > There is nothing like Advanced configuration in the page. Link for the > appropriate page should be used ([THREADING > MODEL|https://camel.apache.org/manual/threading-model.html] seems like the > right choice). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-20043) Micrometer: unclear instructions of docInstrumentedThreadPoolFactory configuration in the documentation
Jiri Ondrusek created CAMEL-20043: - Summary: Micrometer: unclear instructions of docInstrumentedThreadPoolFactory configuration in the documentation Key: CAMEL-20043 URL: https://issues.apache.org/jira/browse/CAMEL-20043 Project: Camel Issue Type: Bug Components: camel-micrometer Reporter: Jiri Ondrusek Assignee: Jiri Ondrusek Chapter [Instrumenting Camel Thread Pools|https://camel.apache.org/components/4.0.x/micrometer-component.html#_instrumenting_camel_thread_pools] in the documentation states: _See more details at Advanced configuration of CamelContext using Spring._ There is nothing like Advanced configuration in the page. Link for the appropriate page should be used ([THREADING MODEL|https://camel.apache.org/manual/threading-model.html] seems like the right choice). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-20042) camel-sql, use primary spring data source by default
Leo Breuss created CAMEL-20042: -- Summary: camel-sql, use primary spring data source by default Key: CAMEL-20042 URL: https://issues.apache.org/jira/browse/CAMEL-20042 Project: Camel Issue Type: Improvement Components: camel-sql Affects Versions: 3.18.8 Reporter: Leo Breuss Improvement suggestion: If there are more than one datasource available, the method shall return the primary datasource, or none if there is no primary datasource. DefaultAutowiredLifecycleStrategy#autwire() does not return any datasource from the spring context if there are more than one datasource in the spring context. This improvement will mitigate the following inconvenience: When adding a second datasource, e.g. by external XML spring bean configuration, the existing SQL endpoints not having a datasource parameter stopped using the default spring datasource and failed at runtime. This problem was very hard to come by, as there is no obvious reason or message, why the former datasource still present in the context is no longer used. Defining the main spring.datasource as @Primary did not resolve the problem. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Moved] (CAMEL-20041) Move CxfMessageHeadersRelayTest to camel-cxf-soap
[ https://issues.apache.org/jira/browse/CAMEL-20041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh moved CXF-8949 to CAMEL-20041: -- Key: CAMEL-20041 (was: CXF-8949) Workflow: classic default workflow (was: Default workflow, editable Closed status) Project: Camel (was: CXF) > Move CxfMessageHeadersRelayTest to camel-cxf-soap > - > > Key: CAMEL-20041 > URL: https://issues.apache.org/jira/browse/CAMEL-20041 > Project: Camel > Issue Type: Bug >Reporter: Peter Palaga >Priority: Major > > The named test currently lives under > [camel-cxf-spring-soap|https://github.com/apache/camel/blob/0e26ffa824b7529fb916a53c327d7daeb78205ed/components/camel-cxf/camel-cxf-spring-soap/src/test/java/org/apache/camel/component/cxf/soap/headers/CxfMessageHeadersRelayTest.java#L731CxfMessageHeadersRelayTest] > but there does not seem to be anything Spring specific in the test. Moreover > it is cited on the CXF component page > https://camel.apache.org/components/4.0.x/cxf-component.html#_how_to_get_and_set_soap_headers_in_pojo_mode. > > We should attempt to move the test to > [camel-cxf-soap|https://github.com/apache/camel/tree/main/components/camel-cxf/camel-cxf-soap] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-20040) Move CxfMessageHeadersRelayTest to camel-cxf-soap
Peter Palaga created CAMEL-20040: Summary: Move CxfMessageHeadersRelayTest to camel-cxf-soap Key: CAMEL-20040 URL: https://issues.apache.org/jira/browse/CAMEL-20040 Project: Camel Issue Type: Task Components: camel-cxf Reporter: Peter Palaga The named test currently lives under [camel-cxf-spring-soap|https://github.com/apache/camel/blob/0e26ffa824b7529fb916a53c327d7daeb78205ed/components/camel-cxf/camel-cxf-spring-soap/src/test/java/org/apache/camel/component/cxf/soap/headers/CxfMessageHeadersRelayTest.java#L731CxfMessageHeadersRelayTest] but there does not seem to be anything Spring specific in the test. Moreover it is cited on the CXF component page https://camel.apache.org/components/4.0.x/cxf-component.html#_how_to_get_and_set_soap_headers_in_pojo_mode. We should attempt to move the test to [camel-cxf-soap|https://github.com/apache/camel/tree/main/components/camel-cxf/camel-cxf-soap] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-20039) camel-core - SimpleLRUCache add support for soft cache
[ https://issues.apache.org/jira/browse/CAMEL-20039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17779073#comment-17779073 ] Claus Ibsen commented on CAMEL-20039: - And btw do you have 2 different accounts in JIRA ? > camel-core - SimpleLRUCache add support for soft cache > -- > > Key: CAMEL-20039 > URL: https://issues.apache.org/jira/browse/CAMEL-20039 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Claus Ibsen >Priority: Major > Fix For: 4.0.3, 4.2.0 > > > The SimpleLRUCache does not have support for SoftReference to have soft keys. > There is an old implementation at > https://github.com/apache/camel/blob/camel-2.10.6/camel-core/src/main/java/org/apache/camel/util/LRUSoftCache.java -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-20039) camel-core - SimpleLRUCache add support for soft cache
[ https://issues.apache.org/jira/browse/CAMEL-20039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17779072#comment-17779072 ] Claus Ibsen commented on CAMEL-20039: - Thanks that is fine > camel-core - SimpleLRUCache add support for soft cache > -- > > Key: CAMEL-20039 > URL: https://issues.apache.org/jira/browse/CAMEL-20039 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Claus Ibsen >Priority: Major > Fix For: 4.0.3, 4.2.0 > > > The SimpleLRUCache does not have support for SoftReference to have soft keys. > There is an old implementation at > https://github.com/apache/camel/blob/camel-2.10.6/camel-core/src/main/java/org/apache/camel/util/LRUSoftCache.java -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-20039) camel-core - SimpleLRUCache add support for soft cache
[ https://issues.apache.org/jira/browse/CAMEL-20039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17779067#comment-17779067 ] Nicolas Filotto commented on CAMEL-20039: - It sounds really fun, thank you for proposing, I would be happy to do it but I can only do it next week. > camel-core - SimpleLRUCache add support for soft cache > -- > > Key: CAMEL-20039 > URL: https://issues.apache.org/jira/browse/CAMEL-20039 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Claus Ibsen >Priority: Major > Fix For: 4.0.3, 4.2.0 > > > The SimpleLRUCache does not have support for SoftReference to have soft keys. > There is an old implementation at > https://github.com/apache/camel/blob/camel-2.10.6/camel-core/src/main/java/org/apache/camel/util/LRUSoftCache.java -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-20039) camel-core - SimpleLRUCache add support for soft cache
[ https://issues.apache.org/jira/browse/CAMEL-20039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17779059#comment-17779059 ] Claus Ibsen commented on CAMEL-20039: - [~nfilotto] in case you want to have some fun with Camel, then see how we can make the keys be SoftReference in the cache implementation. > camel-core - SimpleLRUCache add support for soft cache > -- > > Key: CAMEL-20039 > URL: https://issues.apache.org/jira/browse/CAMEL-20039 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Claus Ibsen >Priority: Major > Fix For: 4.0.3, 4.2.0 > > > The SimpleLRUCache does not have support for SoftReference to have soft keys. > There is an old implementation at > https://github.com/apache/camel/blob/camel-2.10.6/camel-core/src/main/java/org/apache/camel/util/LRUSoftCache.java -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-20039) camel-core - SimpleLRUCache add support for soft cache
Claus Ibsen created CAMEL-20039: --- Summary: camel-core - SimpleLRUCache add support for soft cache Key: CAMEL-20039 URL: https://issues.apache.org/jira/browse/CAMEL-20039 Project: Camel Issue Type: Improvement Components: camel-core Reporter: Claus Ibsen Fix For: 4.0.3, 4.2.0 The SimpleLRUCache does not have support for SoftReference to have soft keys. There is an old implementation at https://github.com/apache/camel/blob/camel-2.10.6/camel-core/src/main/java/org/apache/camel/util/LRUSoftCache.java -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-20038) camel-core - Deprecate LRUWeakCache
[ https://issues.apache.org/jira/browse/CAMEL-20038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-20038. - Fix Version/s: 4.0.3 Resolution: Fixed > camel-core - Deprecate LRUWeakCache > --- > > Key: CAMEL-20038 > URL: https://issues.apache.org/jira/browse/CAMEL-20038 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Major > Fix For: 4.0.3, 4.2.0 > > > Related to CAMEL-20035 - We can use soft cache instead of weak, which makes > the JVM able to GC objects that are no longer in use. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CAMEL-20038) camel-core - Deprecate LRUWeakCache
[ https://issues.apache.org/jira/browse/CAMEL-20038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen reassigned CAMEL-20038: --- Assignee: Claus Ibsen > camel-core - Deprecate LRUWeakCache > --- > > Key: CAMEL-20038 > URL: https://issues.apache.org/jira/browse/CAMEL-20038 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Major > Fix For: 4.2.0 > > > Related to CAMEL-20035 - We can use soft cache instead of weak, which makes > the JVM able to GC objects that are no longer in use. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-20038) camel-core - Deprecate LRUWeakCache
Claus Ibsen created CAMEL-20038: --- Summary: camel-core - Deprecate LRUWeakCache Key: CAMEL-20038 URL: https://issues.apache.org/jira/browse/CAMEL-20038 Project: Camel Issue Type: Improvement Components: camel-core Reporter: Claus Ibsen Fix For: 4.2.0 Related to CAMEL-20035 - We can use soft cache instead of weak, which makes the JVM able to GC objects that are no longer in use. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-20035) Program terminates with OutOfMemoryError
[
https://issues.apache.org/jira/browse/CAMEL-20035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17779038#comment-17779038
]
Claus Ibsen commented on CAMEL-20035:
-
https://github.com/apache/camel/blob/camel-2.10.6/camel-core/src/main/java/org/apache/camel/util/LRUSoftCache.java
> Program terminates with OutOfMemoryError
>
>
> Key: CAMEL-20035
> URL: https://issues.apache.org/jira/browse/CAMEL-20035
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 4.0.0
>Reporter: Marco Bungart
>Assignee: Claus Ibsen
>Priority: Major
> Fix For: 3.20.9, 3.21.3, 3.22.0, 4.0.3, 4.2.0
>
>
> Given the following route:
> {code:java}
> public class Timer {
> ...
> static RouteBuilder timerRoute() {
> return new RouteBuilder() {
> private final AtomicInteger calls = new AtomicInteger();
> @Override
> public void configure() {
> // @formatter:off
> from(
> timer("timer")
> .period(Duration.ofMillis(100).toMillis())
> .fixedRate(true))
> .process(exchange -> {
> log.info("calls: {}", calls.incrementAndGet());
> exchange.getIn().setBody(new LargeObject());
> })
> .log("${body.fieldTwo}");
> // @formatter:on
> }
> };
> }
> }
> {code}
> and the following implementation of {{LargeObject}}
> {code:java}
> public class LargeObject {
> private static final Random RANDOM = new Random();
> byte[] data;
> String fieldOne;
> String fieldTwo;
> public LargeObject() {
> this.data = new byte[100 * 1024 * 1024]; // 100 MB
> RANDOM.nextBytes(data);
> fieldOne = UUID.randomUUID().toString();
> fieldTwo = UUID.randomUUID().toString();
> }
> }
> {code}
> We would expect that the program runs indefinitely. But if we limit the
> memory to e.g. ~3.2 GB (which is 10% of the whole system memory in my case)
> by running:
> {code:bash}
> java \
> -XX:MinRAMPercentage=10 \
> -XX:MaxRAMPercentage=10 \
> -XX:+ExitOnOutOfMemoryError \
> -jar ...
> {code}
> The program terminates with an {{OutOfMemoryError}} in the 32nd execution of
> the route.
> —
> [Reproducer 1 (pure camel,
> {{github.com}})|https://github.com/turing85/camel-lru-cache]
> [Reproducer 2 (quarkus camel, allow to define the size of the
> {{LargeObject}},
> {{github.com}})|https://github.com/turing85/quarkus-camel-lru-cache]
> For both repositories, please read the {{README.adoc}} for instructions.
> —
> Observations:
> - For the quarkus-sample and a heap-limitation of ~3.2 GB, the breaking
> point is an {{object.size}} of {{2047K}}/{{2048K}}. With {{2047K}}, the
> program runs indefinitely, with {{2048K}}, the program crashes.
> - The problem also exist in native mode, but the breaking point is different
> - Looking at the implementation of the [{{SimpleLRUCache}}
> ({{github.com}})|https://github.com/apache/camel/blob/HEAD/core/camel-support/src/main/java/org/apache/camel/support/DefaultLRUCacheFactory.java#L150],
> it seems that this class is not using {{SoftReference}} s or
> {{WeakReference}} s. As far as I understand it, this means that if 1000
> elements of whatever is stored in this cache exceed the heap limit of the
> JVM, the program will throw an {{OutOfMemoryError}} .
> - Conversely, this means that if a program "survives" the first 1000 calls,
> it will (most likely) run indefinitely.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CAMEL-20035) Program terminates with OutOfMemoryError
[
https://issues.apache.org/jira/browse/CAMEL-20035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17779014#comment-17779014
]
Claus Ibsen edited comment on CAMEL-20035 at 10/24/23 11:04 AM:
Okay so there are two things
- the bean info cache was instance based (CAMEL-19487) which is only in need
for a rare use-case *DONE*
- soft reference was no longer in use which needs to be added into the simple
lru cache
was (Author: davsclaus):
Okay so there are two things
- the bean info cache was instance based (CAMEL-19487) which is only in need
for a rare use-case
- soft reference was no longer in use which needs to be added into the simple
lru cache
> Program terminates with OutOfMemoryError
>
>
> Key: CAMEL-20035
> URL: https://issues.apache.org/jira/browse/CAMEL-20035
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 4.0.0
>Reporter: Marco Bungart
>Assignee: Claus Ibsen
>Priority: Major
> Fix For: 3.20.9, 3.21.3, 3.22.0, 4.0.3, 4.2.0
>
>
> Given the following route:
> {code:java}
> public class Timer {
> ...
> static RouteBuilder timerRoute() {
> return new RouteBuilder() {
> private final AtomicInteger calls = new AtomicInteger();
> @Override
> public void configure() {
> // @formatter:off
> from(
> timer("timer")
> .period(Duration.ofMillis(100).toMillis())
> .fixedRate(true))
> .process(exchange -> {
> log.info("calls: {}", calls.incrementAndGet());
> exchange.getIn().setBody(new LargeObject());
> })
> .log("${body.fieldTwo}");
> // @formatter:on
> }
> };
> }
> }
> {code}
> and the following implementation of {{LargeObject}}
> {code:java}
> public class LargeObject {
> private static final Random RANDOM = new Random();
> byte[] data;
> String fieldOne;
> String fieldTwo;
> public LargeObject() {
> this.data = new byte[100 * 1024 * 1024]; // 100 MB
> RANDOM.nextBytes(data);
> fieldOne = UUID.randomUUID().toString();
> fieldTwo = UUID.randomUUID().toString();
> }
> }
> {code}
> We would expect that the program runs indefinitely. But if we limit the
> memory to e.g. ~3.2 GB (which is 10% of the whole system memory in my case)
> by running:
> {code:bash}
> java \
> -XX:MinRAMPercentage=10 \
> -XX:MaxRAMPercentage=10 \
> -XX:+ExitOnOutOfMemoryError \
> -jar ...
> {code}
> The program terminates with an {{OutOfMemoryError}} in the 32nd execution of
> the route.
> —
> [Reproducer 1 (pure camel,
> {{github.com}})|https://github.com/turing85/camel-lru-cache]
> [Reproducer 2 (quarkus camel, allow to define the size of the
> {{LargeObject}},
> {{github.com}})|https://github.com/turing85/quarkus-camel-lru-cache]
> For both repositories, please read the {{README.adoc}} for instructions.
> —
> Observations:
> - For the quarkus-sample and a heap-limitation of ~3.2 GB, the breaking
> point is an {{object.size}} of {{2047K}}/{{2048K}}. With {{2047K}}, the
> program runs indefinitely, with {{2048K}}, the program crashes.
> - The problem also exist in native mode, but the breaking point is different
> - Looking at the implementation of the [{{SimpleLRUCache}}
> ({{github.com}})|https://github.com/apache/camel/blob/HEAD/core/camel-support/src/main/java/org/apache/camel/support/DefaultLRUCacheFactory.java#L150],
> it seems that this class is not using {{SoftReference}} s or
> {{WeakReference}} s. As far as I understand it, this means that if 1000
> elements of whatever is stored in this cache exceed the heap limit of the
> JVM, the program will throw an {{OutOfMemoryError}} .
> - Conversely, this means that if a program "survives" the first 1000 calls,
> it will (most likely) run indefinitely.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-19999) camel-bean - Allow to configure bean introspection cache on component
[ https://issues.apache.org/jira/browse/CAMEL-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-1: Fix Version/s: 4.0.3 > camel-bean - Allow to configure bean introspection cache on component > - > > Key: CAMEL-1 > URL: https://issues.apache.org/jira/browse/CAMEL-1 > Project: Camel > Issue Type: Improvement > Components: camel-bean >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Minor > Fix For: 4.0.3, 4.2.0 > > > The cache is 1000 and its soft reference. But in some low memory environments > you may want to have lower cache size. And also be able to clear cache > on-demand with a method on bean component. > https://camel.zulipchat.com/#narrow/stream/257298-camel/topic/Camel.20Bean.20and.20LRU.20Cache -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-20037) camel-http builds StringEntity with wrong contentEncoding
[
https://issues.apache.org/jira/browse/CAMEL-20037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-20037:
Fix Version/s: 4.2.0
> camel-http builds StringEntity with wrong contentEncoding
> -
>
> Key: CAMEL-20037
> URL: https://issues.apache.org/jira/browse/CAMEL-20037
> Project: Camel
> Issue Type: Bug
> Components: camel-http
>Affects Versions: 4.1.0
>Reporter: Simo Kivimäki
>Priority: Major
> Fix For: 4.2.0
>
>
> HttpProducer.java line 781:
> {code:java}
> answer = new StringEntity(content, contentType, charset, false);
> {code}
> Here the third parameter should be contentEncoding (e.g. null). Not charset.
> This will produce HTTP request having for example header:
> {code}
> Content-Encoding: utf-8
> {code}
> UTF-8 is not allowed Content-Encoding. See
> https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Encoding.
> Some http servers returns HTTP 415 Unsupported Media Type because of that.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-20037) camel-http builds StringEntity with wrong contentEncoding
[
https://issues.apache.org/jira/browse/CAMEL-20037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17779021#comment-17779021
]
Claus Ibsen commented on CAMEL-20037:
-
You are welcome to send a PR against main branch
> camel-http builds StringEntity with wrong contentEncoding
> -
>
> Key: CAMEL-20037
> URL: https://issues.apache.org/jira/browse/CAMEL-20037
> Project: Camel
> Issue Type: Bug
> Components: camel-http
>Affects Versions: 4.1.0
>Reporter: Simo Kivimäki
>Priority: Major
>
> HttpProducer.java line 781:
> {code:java}
> answer = new StringEntity(content, contentType, charset, false);
> {code}
> Here the third parameter should be contentEncoding (e.g. null). Not charset.
> This will produce HTTP request having for example header:
> {code}
> Content-Encoding: utf-8
> {code}
> UTF-8 is not allowed Content-Encoding. See
> https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Encoding.
> Some http servers returns HTTP 415 Unsupported Media Type because of that.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-20035) Program terminates with OutOfMemoryError
[
https://issues.apache.org/jira/browse/CAMEL-20035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-20035:
Fix Version/s: 3.20.9
3.21.3
3.22.0
> Program terminates with OutOfMemoryError
>
>
> Key: CAMEL-20035
> URL: https://issues.apache.org/jira/browse/CAMEL-20035
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 4.0.0
>Reporter: Marco Bungart
>Assignee: Claus Ibsen
>Priority: Major
> Fix For: 3.21.3, 3.22.0, 4.0.3, 4.2.0, 3.20.9
>
>
> Given the following route:
> {code:java}
> public class Timer {
> ...
> static RouteBuilder timerRoute() {
> return new RouteBuilder() {
> private final AtomicInteger calls = new AtomicInteger();
> @Override
> public void configure() {
> // @formatter:off
> from(
> timer("timer")
> .period(Duration.ofMillis(100).toMillis())
> .fixedRate(true))
> .process(exchange -> {
> log.info("calls: {}", calls.incrementAndGet());
> exchange.getIn().setBody(new LargeObject());
> })
> .log("${body.fieldTwo}");
> // @formatter:on
> }
> };
> }
> }
> {code}
> and the following implementation of {{LargeObject}}
> {code:java}
> public class LargeObject {
> private static final Random RANDOM = new Random();
> byte[] data;
> String fieldOne;
> String fieldTwo;
> public LargeObject() {
> this.data = new byte[100 * 1024 * 1024]; // 100 MB
> RANDOM.nextBytes(data);
> fieldOne = UUID.randomUUID().toString();
> fieldTwo = UUID.randomUUID().toString();
> }
> }
> {code}
> We would expect that the program runs indefinitely. But if we limit the
> memory to e.g. ~3.2 GB (which is 10% of the whole system memory in my case)
> by running:
> {code:bash}
> java \
> -XX:MinRAMPercentage=10 \
> -XX:MaxRAMPercentage=10 \
> -XX:+ExitOnOutOfMemoryError \
> -jar ...
> {code}
> The program terminates with an {{OutOfMemoryError}} in the 32nd execution of
> the route.
> —
> [Reproducer 1 (pure camel,
> {{github.com}})|https://github.com/turing85/camel-lru-cache]
> [Reproducer 2 (quarkus camel, allow to define the size of the
> {{LargeObject}},
> {{github.com}})|https://github.com/turing85/quarkus-camel-lru-cache]
> For both repositories, please read the {{README.adoc}} for instructions.
> —
> Observations:
> - For the quarkus-sample and a heap-limitation of ~3.2 GB, the breaking
> point is an {{object.size}} of {{2047K}}/{{2048K}}. With {{2047K}}, the
> program runs indefinitely, with {{2048K}}, the program crashes.
> - The problem also exist in native mode, but the breaking point is different
> - Looking at the implementation of the [{{SimpleLRUCache}}
> ({{github.com}})|https://github.com/apache/camel/blob/HEAD/core/camel-support/src/main/java/org/apache/camel/support/DefaultLRUCacheFactory.java#L150],
> it seems that this class is not using {{SoftReference}} s or
> {{WeakReference}} s. As far as I understand it, this means that if 1000
> elements of whatever is stored in this cache exceed the heap limit of the
> JVM, the program will throw an {{OutOfMemoryError}} .
> - Conversely, this means that if a program "survives" the first 1000 calls,
> it will (most likely) run indefinitely.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAMEL-20037) camel-http builds StringEntity with wrong contentEncoding
Simo Kivimäki created CAMEL-20037:
-
Summary: camel-http builds StringEntity with wrong contentEncoding
Key: CAMEL-20037
URL: https://issues.apache.org/jira/browse/CAMEL-20037
Project: Camel
Issue Type: Bug
Components: camel-http
Affects Versions: 4.1.0
Reporter: Simo Kivimäki
HttpProducer.java line 781:
{code:java}
answer = new StringEntity(content, contentType, charset, false);
{code}
Here the third parameter should be contentEncoding (e.g. null). Not charset.
This will produce HTTP request having for example header:
{code}
Content-Encoding: utf-8
{code}
UTF-8 is not allowed Content-Encoding. See
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Encoding.
Some http servers returns HTTP 415 Unsupported Media Type because of that.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-20035) Program terminates with OutOfMemoryError
[
https://issues.apache.org/jira/browse/CAMEL-20035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17779014#comment-17779014
]
Claus Ibsen commented on CAMEL-20035:
-
Okay so there are two things
- the bean info cache was instance based (CAMEL-19487) which is only in need
for a rare use-case
- soft reference was no longer in use which needs to be added into the simple
lru cache
> Program terminates with OutOfMemoryError
>
>
> Key: CAMEL-20035
> URL: https://issues.apache.org/jira/browse/CAMEL-20035
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 4.0.0
>Reporter: Marco Bungart
>Assignee: Claus Ibsen
>Priority: Major
> Fix For: 4.0.3, 4.2.0
>
>
> Given the following route:
> {code:java}
> public class Timer {
> ...
> static RouteBuilder timerRoute() {
> return new RouteBuilder() {
> private final AtomicInteger calls = new AtomicInteger();
> @Override
> public void configure() {
> // @formatter:off
> from(
> timer("timer")
> .period(Duration.ofMillis(100).toMillis())
> .fixedRate(true))
> .process(exchange -> {
> log.info("calls: {}", calls.incrementAndGet());
> exchange.getIn().setBody(new LargeObject());
> })
> .log("${body.fieldTwo}");
> // @formatter:on
> }
> };
> }
> }
> {code}
> and the following implementation of {{LargeObject}}
> {code:java}
> public class LargeObject {
> private static final Random RANDOM = new Random();
> byte[] data;
> String fieldOne;
> String fieldTwo;
> public LargeObject() {
> this.data = new byte[100 * 1024 * 1024]; // 100 MB
> RANDOM.nextBytes(data);
> fieldOne = UUID.randomUUID().toString();
> fieldTwo = UUID.randomUUID().toString();
> }
> }
> {code}
> We would expect that the program runs indefinitely. But if we limit the
> memory to e.g. ~3.2 GB (which is 10% of the whole system memory in my case)
> by running:
> {code:bash}
> java \
> -XX:MinRAMPercentage=10 \
> -XX:MaxRAMPercentage=10 \
> -XX:+ExitOnOutOfMemoryError \
> -jar ...
> {code}
> The program terminates with an {{OutOfMemoryError}} in the 32nd execution of
> the route.
> —
> [Reproducer 1 (pure camel,
> {{github.com}})|https://github.com/turing85/camel-lru-cache]
> [Reproducer 2 (quarkus camel, allow to define the size of the
> {{LargeObject}},
> {{github.com}})|https://github.com/turing85/quarkus-camel-lru-cache]
> For both repositories, please read the {{README.adoc}} for instructions.
> —
> Observations:
> - For the quarkus-sample and a heap-limitation of ~3.2 GB, the breaking
> point is an {{object.size}} of {{2047K}}/{{2048K}}. With {{2047K}}, the
> program runs indefinitely, with {{2048K}}, the program crashes.
> - The problem also exist in native mode, but the breaking point is different
> - Looking at the implementation of the [{{SimpleLRUCache}}
> ({{github.com}})|https://github.com/apache/camel/blob/HEAD/core/camel-support/src/main/java/org/apache/camel/support/DefaultLRUCacheFactory.java#L150],
> it seems that this class is not using {{SoftReference}} s or
> {{WeakReference}} s. As far as I understand it, this means that if 1000
> elements of whatever is stored in this cache exceed the heap limit of the
> JVM, the program will throw an {{OutOfMemoryError}} .
> - Conversely, this means that if a program "survives" the first 1000 calls,
> it will (most likely) run indefinitely.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-20035) Program terminates with OutOfMemoryError
[
https://issues.apache.org/jira/browse/CAMEL-20035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17779011#comment-17779011
]
Claus Ibsen commented on CAMEL-20035:
-
[l-1) thread #1 - timer://timer] route1 INFO
b705b8cb-946e-479b-b1d6-66b1868f5210
[l-1) thread #1 - timer://timer] Timer$1INFO calls:
3875
> Program terminates with OutOfMemoryError
>
>
> Key: CAMEL-20035
> URL: https://issues.apache.org/jira/browse/CAMEL-20035
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 4.0.0
>Reporter: Marco Bungart
>Assignee: Claus Ibsen
>Priority: Major
> Fix For: 4.0.3, 4.2.0
>
>
> Given the following route:
> {code:java}
> public class Timer {
> ...
> static RouteBuilder timerRoute() {
> return new RouteBuilder() {
> private final AtomicInteger calls = new AtomicInteger();
> @Override
> public void configure() {
> // @formatter:off
> from(
> timer("timer")
> .period(Duration.ofMillis(100).toMillis())
> .fixedRate(true))
> .process(exchange -> {
> log.info("calls: {}", calls.incrementAndGet());
> exchange.getIn().setBody(new LargeObject());
> })
> .log("${body.fieldTwo}");
> // @formatter:on
> }
> };
> }
> }
> {code}
> and the following implementation of {{LargeObject}}
> {code:java}
> public class LargeObject {
> private static final Random RANDOM = new Random();
> byte[] data;
> String fieldOne;
> String fieldTwo;
> public LargeObject() {
> this.data = new byte[100 * 1024 * 1024]; // 100 MB
> RANDOM.nextBytes(data);
> fieldOne = UUID.randomUUID().toString();
> fieldTwo = UUID.randomUUID().toString();
> }
> }
> {code}
> We would expect that the program runs indefinitely. But if we limit the
> memory to e.g. ~3.2 GB (which is 10% of the whole system memory in my case)
> by running:
> {code:bash}
> java \
> -XX:MinRAMPercentage=10 \
> -XX:MaxRAMPercentage=10 \
> -XX:+ExitOnOutOfMemoryError \
> -jar ...
> {code}
> The program terminates with an {{OutOfMemoryError}} in the 32nd execution of
> the route.
> —
> [Reproducer 1 (pure camel,
> {{github.com}})|https://github.com/turing85/camel-lru-cache]
> [Reproducer 2 (quarkus camel, allow to define the size of the
> {{LargeObject}},
> {{github.com}})|https://github.com/turing85/quarkus-camel-lru-cache]
> For both repositories, please read the {{README.adoc}} for instructions.
> —
> Observations:
> - For the quarkus-sample and a heap-limitation of ~3.2 GB, the breaking
> point is an {{object.size}} of {{2047K}}/{{2048K}}. With {{2047K}}, the
> program runs indefinitely, with {{2048K}}, the program crashes.
> - The problem also exist in native mode, but the breaking point is different
> - Looking at the implementation of the [{{SimpleLRUCache}}
> ({{github.com}})|https://github.com/apache/camel/blob/HEAD/core/camel-support/src/main/java/org/apache/camel/support/DefaultLRUCacheFactory.java#L150],
> it seems that this class is not using {{SoftReference}} s or
> {{WeakReference}} s. As far as I understand it, this means that if 1000
> elements of whatever is stored in this cache exceed the heap limit of the
> JVM, the program will throw an {{OutOfMemoryError}} .
> - Conversely, this means that if a program "survives" the first 1000 calls,
> it will (most likely) run indefinitely.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-20035) Program terminates with OutOfMemoryError
[
https://issues.apache.org/jira/browse/CAMEL-20035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17778977#comment-17778977
]
Claus Ibsen commented on CAMEL-20035:
-
[l-1) thread #1 - timer://timer] route1 INFO
f9c92be3-d97e-4b40-926e-c1e9781364aa
[l-1) thread #1 - timer://timer] Timer$1INFO calls: 131
> Program terminates with OutOfMemoryError
>
>
> Key: CAMEL-20035
> URL: https://issues.apache.org/jira/browse/CAMEL-20035
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 4.0.0
>Reporter: Marco Bungart
>Assignee: Claus Ibsen
>Priority: Major
> Fix For: 4.0.3, 4.2.0
>
>
> Given the following route:
> {code:java}
> public class Timer {
> ...
> static RouteBuilder timerRoute() {
> return new RouteBuilder() {
> private final AtomicInteger calls = new AtomicInteger();
> @Override
> public void configure() {
> // @formatter:off
> from(
> timer("timer")
> .period(Duration.ofMillis(100).toMillis())
> .fixedRate(true))
> .process(exchange -> {
> log.info("calls: {}", calls.incrementAndGet());
> exchange.getIn().setBody(new LargeObject());
> })
> .log("${body.fieldTwo}");
> // @formatter:on
> }
> };
> }
> }
> {code}
> and the following implementation of {{LargeObject}}
> {code:java}
> public class LargeObject {
> private static final Random RANDOM = new Random();
> byte[] data;
> String fieldOne;
> String fieldTwo;
> public LargeObject() {
> this.data = new byte[100 * 1024 * 1024]; // 100 MB
> RANDOM.nextBytes(data);
> fieldOne = UUID.randomUUID().toString();
> fieldTwo = UUID.randomUUID().toString();
> }
> }
> {code}
> We would expect that the program runs indefinitely. But if we limit the
> memory to e.g. ~3.2 GB (which is 10% of the whole system memory in my case)
> by running:
> {code:bash}
> java \
> -XX:MinRAMPercentage=10 \
> -XX:MaxRAMPercentage=10 \
> -XX:+ExitOnOutOfMemoryError \
> -jar ...
> {code}
> The program terminates with an {{OutOfMemoryError}} in the 32nd execution of
> the route.
> —
> [Reproducer 1 (pure camel,
> {{github.com}})|https://github.com/turing85/camel-lru-cache]
> [Reproducer 2 (quarkus camel, allow to define the size of the
> {{LargeObject}},
> {{github.com}})|https://github.com/turing85/quarkus-camel-lru-cache]
> For both repositories, please read the {{README.adoc}} for instructions.
> —
> Observations:
> - For the quarkus-sample and a heap-limitation of ~3.2 GB, the breaking
> point is an {{object.size}} of {{2047K}}/{{2048K}}. With {{2047K}}, the
> program runs indefinitely, with {{2048K}}, the program crashes.
> - The problem also exist in native mode, but the breaking point is different
> - Looking at the implementation of the [{{SimpleLRUCache}}
> ({{github.com}})|https://github.com/apache/camel/blob/HEAD/core/camel-support/src/main/java/org/apache/camel/support/DefaultLRUCacheFactory.java#L150],
> it seems that this class is not using {{SoftReference}} s or
> {{WeakReference}} s. As far as I understand it, this means that if 1000
> elements of whatever is stored in this cache exceed the heap limit of the
> JVM, the program will throw an {{OutOfMemoryError}} .
> - Conversely, this means that if a program "survives" the first 1000 calls,
> it will (most likely) run indefinitely.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (CAMEL-20035) Program terminates with OutOfMemoryError
[
https://issues.apache.org/jira/browse/CAMEL-20035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen reassigned CAMEL-20035:
---
Assignee: Claus Ibsen
> Program terminates with OutOfMemoryError
>
>
> Key: CAMEL-20035
> URL: https://issues.apache.org/jira/browse/CAMEL-20035
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 4.0.0
>Reporter: Marco Bungart
>Assignee: Claus Ibsen
>Priority: Major
> Fix For: 4.0.3, 4.2.0
>
>
> Given the following route:
> {code:java}
> public class Timer {
> ...
> static RouteBuilder timerRoute() {
> return new RouteBuilder() {
> private final AtomicInteger calls = new AtomicInteger();
> @Override
> public void configure() {
> // @formatter:off
> from(
> timer("timer")
> .period(Duration.ofMillis(100).toMillis())
> .fixedRate(true))
> .process(exchange -> {
> log.info("calls: {}", calls.incrementAndGet());
> exchange.getIn().setBody(new LargeObject());
> })
> .log("${body.fieldTwo}");
> // @formatter:on
> }
> };
> }
> }
> {code}
> and the following implementation of {{LargeObject}}
> {code:java}
> public class LargeObject {
> private static final Random RANDOM = new Random();
> byte[] data;
> String fieldOne;
> String fieldTwo;
> public LargeObject() {
> this.data = new byte[100 * 1024 * 1024]; // 100 MB
> RANDOM.nextBytes(data);
> fieldOne = UUID.randomUUID().toString();
> fieldTwo = UUID.randomUUID().toString();
> }
> }
> {code}
> We would expect that the program runs indefinitely. But if we limit the
> memory to e.g. ~3.2 GB (which is 10% of the whole system memory in my case)
> by running:
> {code:bash}
> java \
> -XX:MinRAMPercentage=10 \
> -XX:MaxRAMPercentage=10 \
> -XX:+ExitOnOutOfMemoryError \
> -jar ...
> {code}
> The program terminates with an {{OutOfMemoryError}} in the 32nd execution of
> the route.
> —
> [Reproducer 1 (pure camel,
> {{github.com}})|https://github.com/turing85/camel-lru-cache]
> [Reproducer 2 (quarkus camel, allow to define the size of the
> {{LargeObject}},
> {{github.com}})|https://github.com/turing85/quarkus-camel-lru-cache]
> For both repositories, please read the {{README.adoc}} for instructions.
> —
> Observations:
> - For the quarkus-sample and a heap-limitation of ~3.2 GB, the breaking
> point is an {{object.size}} of {{2047K}}/{{2048K}}. With {{2047K}}, the
> program runs indefinitely, with {{2048K}}, the program crashes.
> - The problem also exist in native mode, but the breaking point is different
> - Looking at the implementation of the [{{SimpleLRUCache}}
> ({{github.com}})|https://github.com/apache/camel/blob/HEAD/core/camel-support/src/main/java/org/apache/camel/support/DefaultLRUCacheFactory.java#L150],
> it seems that this class is not using {{SoftReference}} s or
> {{WeakReference}} s. As far as I understand it, this means that if 1000
> elements of whatever is stored in this cache exceed the heap limit of the
> JVM, the program will throw an {{OutOfMemoryError}} .
> - Conversely, this means that if a program "survives" the first 1000 calls,
> it will (most likely) run indefinitely.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-20035) Program terminates with OutOfMemoryError
[
https://issues.apache.org/jira/browse/CAMEL-20035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17778969#comment-17778969
]
Claus Ibsen commented on CAMEL-20035:
-
Its CAMEL-19487 that is causing a problem, the cache is not reusing as its per
instance based instead of class type.
> Program terminates with OutOfMemoryError
>
>
> Key: CAMEL-20035
> URL: https://issues.apache.org/jira/browse/CAMEL-20035
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 4.0.0
>Reporter: Marco Bungart
>Priority: Major
> Fix For: 4.0.3, 4.2.0
>
>
> Given the following route:
> {code:java}
> public class Timer {
> ...
> static RouteBuilder timerRoute() {
> return new RouteBuilder() {
> private final AtomicInteger calls = new AtomicInteger();
> @Override
> public void configure() {
> // @formatter:off
> from(
> timer("timer")
> .period(Duration.ofMillis(100).toMillis())
> .fixedRate(true))
> .process(exchange -> {
> log.info("calls: {}", calls.incrementAndGet());
> exchange.getIn().setBody(new LargeObject());
> })
> .log("${body.fieldTwo}");
> // @formatter:on
> }
> };
> }
> }
> {code}
> and the following implementation of {{LargeObject}}
> {code:java}
> public class LargeObject {
> private static final Random RANDOM = new Random();
> byte[] data;
> String fieldOne;
> String fieldTwo;
> public LargeObject() {
> this.data = new byte[100 * 1024 * 1024]; // 100 MB
> RANDOM.nextBytes(data);
> fieldOne = UUID.randomUUID().toString();
> fieldTwo = UUID.randomUUID().toString();
> }
> }
> {code}
> We would expect that the program runs indefinitely. But if we limit the
> memory to e.g. ~3.2 GB (which is 10% of the whole system memory in my case)
> by running:
> {code:bash}
> java \
> -XX:MinRAMPercentage=10 \
> -XX:MaxRAMPercentage=10 \
> -XX:+ExitOnOutOfMemoryError \
> -jar ...
> {code}
> The program terminates with an {{OutOfMemoryError}} in the 32nd execution of
> the route.
> —
> [Reproducer 1 (pure camel,
> {{github.com}})|https://github.com/turing85/camel-lru-cache]
> [Reproducer 2 (quarkus camel, allow to define the size of the
> {{LargeObject}},
> {{github.com}})|https://github.com/turing85/quarkus-camel-lru-cache]
> For both repositories, please read the {{README.adoc}} for instructions.
> —
> Observations:
> - For the quarkus-sample and a heap-limitation of ~3.2 GB, the breaking
> point is an {{object.size}} of {{2047K}}/{{2048K}}. With {{2047K}}, the
> program runs indefinitely, with {{2048K}}, the program crashes.
> - The problem also exist in native mode, but the breaking point is different
> - Looking at the implementation of the [{{SimpleLRUCache}}
> ({{github.com}})|https://github.com/apache/camel/blob/HEAD/core/camel-support/src/main/java/org/apache/camel/support/DefaultLRUCacheFactory.java#L150],
> it seems that this class is not using {{SoftReference}} s or
> {{WeakReference}} s. As far as I understand it, this means that if 1000
> elements of whatever is stored in this cache exceed the heap limit of the
> JVM, the program will throw an {{OutOfMemoryError}} .
> - Conversely, this means that if a program "survives" the first 1000 calls,
> it will (most likely) run indefinitely.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-20035) Program terminates with OutOfMemoryError
[
https://issues.apache.org/jira/browse/CAMEL-20035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-20035:
Fix Version/s: 4.0.3
4.2.0
> Program terminates with OutOfMemoryError
>
>
> Key: CAMEL-20035
> URL: https://issues.apache.org/jira/browse/CAMEL-20035
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 4.0.0
>Reporter: Marco Bungart
>Priority: Major
> Fix For: 4.0.3, 4.2.0
>
>
> Given the following route:
> {code:java}
> public class Timer {
> ...
> static RouteBuilder timerRoute() {
> return new RouteBuilder() {
> private final AtomicInteger calls = new AtomicInteger();
> @Override
> public void configure() {
> // @formatter:off
> from(
> timer("timer")
> .period(Duration.ofMillis(100).toMillis())
> .fixedRate(true))
> .process(exchange -> {
> log.info("calls: {}", calls.incrementAndGet());
> exchange.getIn().setBody(new LargeObject());
> })
> .log("${body.fieldTwo}");
> // @formatter:on
> }
> };
> }
> }
> {code}
> and the following implementation of {{LargeObject}}
> {code:java}
> public class LargeObject {
> private static final Random RANDOM = new Random();
> byte[] data;
> String fieldOne;
> String fieldTwo;
> public LargeObject() {
> this.data = new byte[100 * 1024 * 1024]; // 100 MB
> RANDOM.nextBytes(data);
> fieldOne = UUID.randomUUID().toString();
> fieldTwo = UUID.randomUUID().toString();
> }
> }
> {code}
> We would expect that the program runs indefinitely. But if we limit the
> memory to e.g. ~3.2 GB (which is 10% of the whole system memory in my case)
> by running:
> {code:bash}
> java \
> -XX:MinRAMPercentage=10 \
> -XX:MaxRAMPercentage=10 \
> -XX:+ExitOnOutOfMemoryError \
> -jar ...
> {code}
> The program terminates with an {{OutOfMemoryError}} in the 32nd execution of
> the route.
> —
> [Reproducer 1 (pure camel,
> {{github.com}})|https://github.com/turing85/camel-lru-cache]
> [Reproducer 2 (quarkus camel, allow to define the size of the
> {{LargeObject}},
> {{github.com}})|https://github.com/turing85/quarkus-camel-lru-cache]
> For both repositories, please read the {{README.adoc}} for instructions.
> —
> Observations:
> - For the quarkus-sample and a heap-limitation of ~3.2 GB, the breaking
> point is an {{object.size}} of {{2047K}}/{{2048K}}. With {{2047K}}, the
> program runs indefinitely, with {{2048K}}, the program crashes.
> - The problem also exist in native mode, but the breaking point is different
> - Looking at the implementation of the [{{SimpleLRUCache}}
> ({{github.com}})|https://github.com/apache/camel/blob/HEAD/core/camel-support/src/main/java/org/apache/camel/support/DefaultLRUCacheFactory.java#L150],
> it seems that this class is not using {{SoftReference}} s or
> {{WeakReference}} s. As far as I understand it, this means that if 1000
> elements of whatever is stored in this cache exceed the heap limit of the
> JVM, the program will throw an {{OutOfMemoryError}} .
> - Conversely, this means that if a program "survives" the first 1000 calls,
> it will (most likely) run indefinitely.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-20025) camel-aws - Should we make region an enum
[ https://issues.apache.org/jira/browse/CAMEL-20025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17778948#comment-17778948 ] Claus Ibsen commented on CAMEL-20025: - Yeah if you want then you are welcome to work on that, and add the enum to all the components, thanks. > camel-aws - Should we make region an enum > - > > Key: CAMEL-20025 > URL: https://issues.apache.org/jira/browse/CAMEL-20025 > Project: Camel > Issue Type: Improvement > Components: camel-aws >Reporter: Claus Ibsen >Priority: Major > Fix For: 4.x > > > All the aws components has to set region as option. Its a string type. > But the AWS client requests to map this to a Region enum class, that has > hardcoded all known regions in the AWS SDK. There is about 40 regions in > total. > We could make region a Region instead of String in the code, then it will be > an enum automatic with those values. > This makes tooling more friendly as they would show a list of enums to choose > among. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-20025) camel-aws - Should we make region an enum
[ https://issues.apache.org/jira/browse/CAMEL-20025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17778946#comment-17778946 ] Claus Ibsen commented on CAMEL-20025: - Yeah for the regen, we could have a little jbang script that calls Region.getRegions() and then lower-case and replace dot with dash, and then ,space with comma. > camel-aws - Should we make region an enum > - > > Key: CAMEL-20025 > URL: https://issues.apache.org/jira/browse/CAMEL-20025 > Project: Camel > Issue Type: Improvement > Components: camel-aws >Reporter: Claus Ibsen >Priority: Major > Fix For: 4.x > > > All the aws components has to set region as option. Its a string type. > But the AWS client requests to map this to a Region enum class, that has > hardcoded all known regions in the AWS SDK. There is about 40 regions in > total. > We could make region a Region instead of String in the code, then it will be > an enum automatic with those values. > This makes tooling more friendly as they would show a list of enums to choose > among. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-20036) Provide endpoint producer builder for https endpoints
[
https://issues.apache.org/jira/browse/CAMEL-20036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17778943#comment-17778943
]
Andrea Cosentino commented on CAMEL-20036:
--
If it's really trivial why don't you open a PR?
> Provide endpoint producer builder for https endpoints
> --
>
> Key: CAMEL-20036
> URL: https://issues.apache.org/jira/browse/CAMEL-20036
> Project: Camel
> Issue Type: New Feature
> Components: camel-http
>Reporter: Marco Bungart
>Priority: Minor
> Fix For: 4.x
>
>
> When one uses the [{{camel-http}}
> component|https://camel.apache.org/components/4.0.x/http-component.html#_endpoint_header_CamelHttpUri]
> to call a {{https}} url, one has to set the URL via the header:
> {code:java}
> from(...)
> ...
> .setHeader(Exchange.HTTP_URL,
> constant("https://fruityvice.com/api/fruit/all;))
> .to(http("ignored").httpMethod(HttpMethods.GET))
>
> {code}
> or use the (already present) corresponding endpoint builder factory, setting
> the {{component}} to {{{}"https"{}}}:
> {code:java}
> from(...)
> ...
> .to(HttpEndpointBuilderFactory.endpointBuilder("https",
> "fruityvice.com/api/fruit/all").httpMethod(HttpMethods.GET))
> ...
> {code}
> It would be nice to have a separte {{{}https(...){}}}-method to call
> {{{}"https"{}}}-resources:
> {code:java}
> from(...)
> ...
> .to(https("fruityvice.com/api/fruit/all").httpMethod(HttpMethods.GET))
> ...
> {code}
> —
> Story:
> *As* a camel-user
> *When* I need to call a https URL
> *Then* I want an endpoint builder with dsl support
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-20036) Provide endpoint producer builder for https endpoints
[
https://issues.apache.org/jira/browse/CAMEL-20036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-20036:
Priority: Minor (was: Trivial)
> Provide endpoint producer builder for https endpoints
> --
>
> Key: CAMEL-20036
> URL: https://issues.apache.org/jira/browse/CAMEL-20036
> Project: Camel
> Issue Type: New Feature
> Components: camel-http
>Reporter: Marco Bungart
>Priority: Minor
>
> When one uses the [{{camel-http}}
> component|https://camel.apache.org/components/4.0.x/http-component.html#_endpoint_header_CamelHttpUri]
> to call a {{https}} url, one has to set the URL via the header:
> {code:java}
> from(...)
> ...
> .setHeader(Exchange.HTTP_URL,
> constant("https://fruityvice.com/api/fruit/all;))
> .to(http("ignored").httpMethod(HttpMethods.GET))
>
> {code}
> or use the (already present) corresponding endpoint builder factory, setting
> the {{component}} to {{{}"https"{}}}:
> {code:java}
> from(...)
> ...
> .to(HttpEndpointBuilderFactory.endpointBuilder("https",
> "fruityvice.com/api/fruit/all").httpMethod(HttpMethods.GET))
> ...
> {code}
> It would be nice to have a separte {{{}https(...){}}}-method to call
> {{{}"https"{}}}-resources:
> {code:java}
> from(...)
> ...
> .to(https("fruityvice.com/api/fruit/all").httpMethod(HttpMethods.GET))
> ...
> {code}
> —
> Story:
> *As* a camel-user
> *When* I need to call a https URL
> *Then* I want an endpoint builder with dsl support
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-20036) Provide endpoint producer builder for https endpoints
[
https://issues.apache.org/jira/browse/CAMEL-20036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-20036:
Fix Version/s: 4.x
> Provide endpoint producer builder for https endpoints
> --
>
> Key: CAMEL-20036
> URL: https://issues.apache.org/jira/browse/CAMEL-20036
> Project: Camel
> Issue Type: New Feature
> Components: camel-http
>Reporter: Marco Bungart
>Priority: Minor
> Fix For: 4.x
>
>
> When one uses the [{{camel-http}}
> component|https://camel.apache.org/components/4.0.x/http-component.html#_endpoint_header_CamelHttpUri]
> to call a {{https}} url, one has to set the URL via the header:
> {code:java}
> from(...)
> ...
> .setHeader(Exchange.HTTP_URL,
> constant("https://fruityvice.com/api/fruit/all;))
> .to(http("ignored").httpMethod(HttpMethods.GET))
>
> {code}
> or use the (already present) corresponding endpoint builder factory, setting
> the {{component}} to {{{}"https"{}}}:
> {code:java}
> from(...)
> ...
> .to(HttpEndpointBuilderFactory.endpointBuilder("https",
> "fruityvice.com/api/fruit/all").httpMethod(HttpMethods.GET))
> ...
> {code}
> It would be nice to have a separte {{{}https(...){}}}-method to call
> {{{}"https"{}}}-resources:
> {code:java}
> from(...)
> ...
> .to(https("fruityvice.com/api/fruit/all").httpMethod(HttpMethods.GET))
> ...
> {code}
> —
> Story:
> *As* a camel-user
> *When* I need to call a https URL
> *Then* I want an endpoint builder with dsl support
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
