[jira] [Commented] (CAMEL-20199) Complete support of Virtual Threads
[
https://issues.apache.org/jira/browse/CAMEL-20199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17879118#comment-17879118
]
Nicolas Filotto commented on CAMEL-20199:
-
Awesome, thank you for your help and understanding
> Complete support of Virtual Threads
> ---
>
> Key: CAMEL-20199
> URL: https://issues.apache.org/jira/browse/CAMEL-20199
> Project: Camel
> Issue Type: Improvement
> Components: came-core
>Reporter: Nicolas Filotto
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 4.x
>
>
> For full support of Virtual Threads, several sub-tasks need to be done:
> * Avoid Lengthy and Frequent Pinning by replacing synchronized blocks with
> ReentrantLocks (use the option {{-Djdk.tracePinnedThreads=ful}} to print
> stack traces when a thread blocks while pinned)
> * Don't Cache Expensive Reusable Objects in Thread-Local Variables by
> avoiding thread locals when possible since when using Virtual Threads, the
> objects will never be reused so if the thread-local variables are never
> reset, it will end up with an OOME.
> * Use Semaphores to Limit Concurrency instead of relying on the size of the
> thread pool when applicable
> * Allow to expose {{ThreadPerTaskExecutor}} through JMX indeed so far it is
> limited to {{ThreadPoolExecutor}}
> References https://docs.oracle.com/en/java/javase/21/core/virtual-threads.html
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CAMEL-20199) Complete support of Virtual Threads
[
https://issues.apache.org/jira/browse/CAMEL-20199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17879108#comment-17879108
]
Nicolas Filotto edited comment on CAMEL-20199 at 9/4/24 6:22 AM:
-
FYI I still work on it but I can hardly work full time on it.
[~gnodet] Maybe we can discuss about how to split the task, if you want to get
involved. Since I started to work on the synchronized block issue, maybe you
can simply pick another item in the list.
was (Author: JIRAUSER285918):
FYI I still work on it but I can hardly work full time on it.
[~gnodet] Maybe we can discuss about how to split the task, if you want to get
involved
> Complete support of Virtual Threads
> ---
>
> Key: CAMEL-20199
> URL: https://issues.apache.org/jira/browse/CAMEL-20199
> Project: Camel
> Issue Type: Improvement
> Components: came-core
>Reporter: Nicolas Filotto
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 4.x
>
>
> For full support of Virtual Threads, several sub-tasks need to be done:
> * Avoid Lengthy and Frequent Pinning by replacing synchronized blocks with
> ReentrantLocks (use the option {{-Djdk.tracePinnedThreads=ful}} to print
> stack traces when a thread blocks while pinned)
> * Don't Cache Expensive Reusable Objects in Thread-Local Variables by
> avoiding thread locals when possible since when using Virtual Threads, the
> objects will never be reused so if the thread-local variables are never
> reset, it will end up with an OOME.
> * Use Semaphores to Limit Concurrency instead of relying on the size of the
> thread pool when applicable
> * Allow to expose {{ThreadPerTaskExecutor}} through JMX indeed so far it is
> limited to {{ThreadPoolExecutor}}
> References https://docs.oracle.com/en/java/javase/21/core/virtual-threads.html
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CAMEL-20850) LRUCache evicts entries unexpectedly
[
https://issues.apache.org/jira/browse/CAMEL-20850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicolas Filotto resolved CAMEL-20850.
-
Resolution: Fixed
> LRUCache evicts entries unexpectedly
>
>
> Key: CAMEL-20850
> URL: https://issues.apache.org/jira/browse/CAMEL-20850
> Project: Camel
> Issue Type: Bug
> Components: came-core
>Affects Versions: 4.0.3, 4.2.0
>Reporter: Timur
>Assignee: Nicolas Filotto
>Priority: Minor
> Fix For: 4.0.6, 4.4.3, 4.7.0
>
>
> h1. Summary
> We encountered an infinite loop while downloading files using the SFTP
> endpoint.
> During our investigation, we discovered the {{InProgressRepository}}
> utilizing the {{SimpleLRUCache}}. This cache incorporates an unconventional
> eviction implementation that involves a changes tracking queue.
> Any attempt to modify the cache, even when putting the same element, results
> in an increase in the cache size, potentially causing eviction to occur even
> for a single element.
> The code is as follows:
> {code:java}
> Map lruCache = LRUCacheFactory.newLRUCache(1, 1);
> int numberOfInserts = 0;
> lruCache.put("key", "value");
> while (lruCache.size() > 0) {
> lruCache.put("key", "value");
> numberOfInserts++;
> }
> throw new IllegalStateException("We should never reach this point, we
> inserted the same element " + numberOfInserts + " times");
> {code}
> In the provided code, the failure occurs when the number of inserts reaches 2.
> h1. Expected Result
> Utilize the LRU Cache limited only by the maximum size passed into it, rather
> than by some internal implementation limits.
> h1. Proposed Solution
> Implement a standard LRUCache, say, by leveraging a {{LRUMap}} from Apache
> Commons.
> We may provide the PR later on.
> h1. The Background
> We need to use a dynamic SFTP route (the download parameters depend on some
> configuration passed from the outside). By default, this is impossible, so we
> will have to use {{pollEnrich}}:
> {code:java}
> .pollEnrich().simple(SFTP_DYNAMIC_URI)
> .timeout(RETURN_CURRENT_RESULT_WITHOUT_WAIT)
> {code}
> The pollEnrich takes only one element (see {{GenericFilePollingConsumer}}).
> The file consumer requests from the SFTP endpoint the list of all files, then
> takes the first, then gets the list again and takes the second file, and so
> on.
> The combination of {{InProgressRepository}} and idempotent consumer is used
> to avoid handling the same files again.
> However, every time the SFTP endpoint lists files, the endpoints and polling
> consumers adjust the list in the {{InProgressRepository}}, thus affecting the
> {{SimpleLRUCache}}.
> The number of elements in the cache doesn't grow, however, the number of
> changes grows with almost n^2 speed.
> With the limit of 50k files, the SimpleLRUCache is evicted already on ~600(!)
> files. This leads to an infinite loop while processing the files.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-20850) LRUCache evicts entries unexpectedly
[
https://issues.apache.org/jira/browse/CAMEL-20850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17854102#comment-17854102
]
Nicolas Filotto commented on CAMEL-20850:
-
Corresponding PRs:
* 4.7 https://github.com/apache/camel/pull/14424
* 4.4 https://github.com/apache/camel/pull/14482
* 4.0 https://github.com/apache/camel/pull/14483
> LRUCache evicts entries unexpectedly
>
>
> Key: CAMEL-20850
> URL: https://issues.apache.org/jira/browse/CAMEL-20850
> Project: Camel
> Issue Type: Bug
> Components: came-core
>Affects Versions: 4.0.3, 4.2.0
>Reporter: Timur
>Assignee: Nicolas Filotto
>Priority: Minor
> Fix For: 4.0.6, 4.4.3, 4.7.0
>
>
> h1. Summary
> We encountered an infinite loop while downloading files using the SFTP
> endpoint.
> During our investigation, we discovered the {{InProgressRepository}}
> utilizing the {{SimpleLRUCache}}. This cache incorporates an unconventional
> eviction implementation that involves a changes tracking queue.
> Any attempt to modify the cache, even when putting the same element, results
> in an increase in the cache size, potentially causing eviction to occur even
> for a single element.
> The code is as follows:
> {code:java}
> Map lruCache = LRUCacheFactory.newLRUCache(1, 1);
> int numberOfInserts = 0;
> lruCache.put("key", "value");
> while (lruCache.size() > 0) {
> lruCache.put("key", "value");
> numberOfInserts++;
> }
> throw new IllegalStateException("We should never reach this point, we
> inserted the same element " + numberOfInserts + " times");
> {code}
> In the provided code, the failure occurs when the number of inserts reaches 2.
> h1. Expected Result
> Utilize the LRU Cache limited only by the maximum size passed into it, rather
> than by some internal implementation limits.
> h1. Proposed Solution
> Implement a standard LRUCache, say, by leveraging a {{LRUMap}} from Apache
> Commons.
> We may provide the PR later on.
> h1. The Background
> We need to use a dynamic SFTP route (the download parameters depend on some
> configuration passed from the outside). By default, this is impossible, so we
> will have to use {{pollEnrich}}:
> {code:java}
> .pollEnrich().simple(SFTP_DYNAMIC_URI)
> .timeout(RETURN_CURRENT_RESULT_WITHOUT_WAIT)
> {code}
> The pollEnrich takes only one element (see {{GenericFilePollingConsumer}}).
> The file consumer requests from the SFTP endpoint the list of all files, then
> takes the first, then gets the list again and takes the second file, and so
> on.
> The combination of {{InProgressRepository}} and idempotent consumer is used
> to avoid handling the same files again.
> However, every time the SFTP endpoint lists files, the endpoints and polling
> consumers adjust the list in the {{InProgressRepository}}, thus affecting the
> {{SimpleLRUCache}}.
> The number of elements in the cache doesn't grow, however, the number of
> changes grows with almost n^2 speed.
> With the limit of 50k files, the SimpleLRUCache is evicted already on ~600(!)
> files. This leads to an infinite loop while processing the files.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-20862) Avoid Kafka IT tests to be played with -Pfastinstall profile
[ https://issues.apache.org/jira/browse/CAMEL-20862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17854014#comment-17854014 ] Nicolas Filotto commented on CAMEL-20862: - Warning AFAIK fastinstall only exists in Camel 3 starting from Camel 4 we use quickly like in Quarkus and Camel Quarkus > Avoid Kafka IT tests to be played with -Pfastinstall profile > > > Key: CAMEL-20862 > URL: https://issues.apache.org/jira/browse/CAMEL-20862 > Project: Camel > Issue Type: Task > Components: camel-kafka >Affects Versions: 4.7.0 >Reporter: Aurélien Pupier >Priority: Minor > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-20850) LRUCache evicts entries unexpectedly
[
https://issues.apache.org/jira/browse/CAMEL-20850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicolas Filotto updated CAMEL-20850:
Fix Version/s: 4.0.6
4.4.3
> LRUCache evicts entries unexpectedly
>
>
> Key: CAMEL-20850
> URL: https://issues.apache.org/jira/browse/CAMEL-20850
> Project: Camel
> Issue Type: Bug
> Components: came-core
>Affects Versions: 4.0.3, 4.2.0
>Reporter: Timur
>Assignee: Nicolas Filotto
>Priority: Minor
> Fix For: 4.0.6, 4.4.3
>
>
> h1. Summary
> We encountered an infinite loop while downloading files using the SFTP
> endpoint.
> During our investigation, we discovered the {{InProgressRepository}}
> utilizing the {{SimpleLRUCache}}. This cache incorporates an unconventional
> eviction implementation that involves a changes tracking queue.
> Any attempt to modify the cache, even when putting the same element, results
> in an increase in the cache size, potentially causing eviction to occur even
> for a single element.
> The code is as follows:
> {code:java}
> Map lruCache = LRUCacheFactory.newLRUCache(1, 1);
> int numberOfInserts = 0;
> lruCache.put("key", "value");
> while (lruCache.size() > 0) {
> lruCache.put("key", "value");
> numberOfInserts++;
> }
> throw new IllegalStateException("We should never reach this point, we
> inserted the same element " + numberOfInserts + " times");
> {code}
> In the provided code, the failure occurs when the number of inserts reaches 2.
> h1. Expected Result
> Utilize the LRU Cache limited only by the maximum size passed into it, rather
> than by some internal implementation limits.
> h1. Proposed Solution
> Implement a standard LRUCache, say, by leveraging a {{LRUMap}} from Apache
> Commons.
> We may provide the PR later on.
> h1. The Background
> We need to use a dynamic SFTP route (the download parameters depend on some
> configuration passed from the outside). By default, this is impossible, so we
> will have to use {{pollEnrich}}:
> {code:java}
> .pollEnrich().simple(SFTP_DYNAMIC_URI)
> .timeout(RETURN_CURRENT_RESULT_WITHOUT_WAIT)
> {code}
> The pollEnrich takes only one element (see {{GenericFilePollingConsumer}}).
> The file consumer requests from the SFTP endpoint the list of all files, then
> takes the first, then gets the list again and takes the second file, and so
> on.
> The combination of {{InProgressRepository}} and idempotent consumer is used
> to avoid handling the same files again.
> However, every time the SFTP endpoint lists files, the endpoints and polling
> consumers adjust the list in the {{InProgressRepository}}, thus affecting the
> {{SimpleLRUCache}}.
> The number of elements in the cache doesn't grow, however, the number of
> changes grows with almost n^2 speed.
> With the limit of 50k files, the SimpleLRUCache is evicted already on ~600(!)
> files. This leads to an infinite loop while processing the files.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-20850) LRUCache evicts entries unexpectedly
[
https://issues.apache.org/jira/browse/CAMEL-20850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicolas Filotto updated CAMEL-20850:
Fix Version/s: 4.7.0
> LRUCache evicts entries unexpectedly
>
>
> Key: CAMEL-20850
> URL: https://issues.apache.org/jira/browse/CAMEL-20850
> Project: Camel
> Issue Type: Bug
> Components: came-core
>Affects Versions: 4.0.3, 4.2.0
>Reporter: Timur
>Assignee: Nicolas Filotto
>Priority: Minor
> Fix For: 4.0.6, 4.4.3, 4.7.0
>
>
> h1. Summary
> We encountered an infinite loop while downloading files using the SFTP
> endpoint.
> During our investigation, we discovered the {{InProgressRepository}}
> utilizing the {{SimpleLRUCache}}. This cache incorporates an unconventional
> eviction implementation that involves a changes tracking queue.
> Any attempt to modify the cache, even when putting the same element, results
> in an increase in the cache size, potentially causing eviction to occur even
> for a single element.
> The code is as follows:
> {code:java}
> Map lruCache = LRUCacheFactory.newLRUCache(1, 1);
> int numberOfInserts = 0;
> lruCache.put("key", "value");
> while (lruCache.size() > 0) {
> lruCache.put("key", "value");
> numberOfInserts++;
> }
> throw new IllegalStateException("We should never reach this point, we
> inserted the same element " + numberOfInserts + " times");
> {code}
> In the provided code, the failure occurs when the number of inserts reaches 2.
> h1. Expected Result
> Utilize the LRU Cache limited only by the maximum size passed into it, rather
> than by some internal implementation limits.
> h1. Proposed Solution
> Implement a standard LRUCache, say, by leveraging a {{LRUMap}} from Apache
> Commons.
> We may provide the PR later on.
> h1. The Background
> We need to use a dynamic SFTP route (the download parameters depend on some
> configuration passed from the outside). By default, this is impossible, so we
> will have to use {{pollEnrich}}:
> {code:java}
> .pollEnrich().simple(SFTP_DYNAMIC_URI)
> .timeout(RETURN_CURRENT_RESULT_WITHOUT_WAIT)
> {code}
> The pollEnrich takes only one element (see {{GenericFilePollingConsumer}}).
> The file consumer requests from the SFTP endpoint the list of all files, then
> takes the first, then gets the list again and takes the second file, and so
> on.
> The combination of {{InProgressRepository}} and idempotent consumer is used
> to avoid handling the same files again.
> However, every time the SFTP endpoint lists files, the endpoints and polling
> consumers adjust the list in the {{InProgressRepository}}, thus affecting the
> {{SimpleLRUCache}}.
> The number of elements in the cache doesn't grow, however, the number of
> changes grows with almost n^2 speed.
> With the limit of 50k files, the SimpleLRUCache is evicted already on ~600(!)
> files. This leads to an infinite loop while processing the files.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-20850) LRUCache evicts entries unexpectedly
[
https://issues.apache.org/jira/browse/CAMEL-20850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17853914#comment-17853914
]
Nicolas Filotto commented on CAMEL-20850:
-
Good news, thx for the feedback
> LRUCache evicts entries unexpectedly
>
>
> Key: CAMEL-20850
> URL: https://issues.apache.org/jira/browse/CAMEL-20850
> Project: Camel
> Issue Type: Bug
> Components: came-core
>Affects Versions: 4.0.3, 4.2.0
>Reporter: Timur
>Assignee: Nicolas Filotto
>Priority: Minor
>
> h1. Summary
> We encountered an infinite loop while downloading files using the SFTP
> endpoint.
> During our investigation, we discovered the {{InProgressRepository}}
> utilizing the {{SimpleLRUCache}}. This cache incorporates an unconventional
> eviction implementation that involves a changes tracking queue.
> Any attempt to modify the cache, even when putting the same element, results
> in an increase in the cache size, potentially causing eviction to occur even
> for a single element.
> The code is as follows:
> {code:java}
> Map lruCache = LRUCacheFactory.newLRUCache(1, 1);
> int numberOfInserts = 0;
> lruCache.put("key", "value");
> while (lruCache.size() > 0) {
> lruCache.put("key", "value");
> numberOfInserts++;
> }
> throw new IllegalStateException("We should never reach this point, we
> inserted the same element " + numberOfInserts + " times");
> {code}
> In the provided code, the failure occurs when the number of inserts reaches 2.
> h1. Expected Result
> Utilize the LRU Cache limited only by the maximum size passed into it, rather
> than by some internal implementation limits.
> h1. Proposed Solution
> Implement a standard LRUCache, say, by leveraging a {{LRUMap}} from Apache
> Commons.
> We may provide the PR later on.
> h1. The Background
> We need to use a dynamic SFTP route (the download parameters depend on some
> configuration passed from the outside). By default, this is impossible, so we
> will have to use {{pollEnrich}}:
> {code:java}
> .pollEnrich().simple(SFTP_DYNAMIC_URI)
> .timeout(RETURN_CURRENT_RESULT_WITHOUT_WAIT)
> {code}
> The pollEnrich takes only one element (see {{GenericFilePollingConsumer}}).
> The file consumer requests from the SFTP endpoint the list of all files, then
> takes the first, then gets the list again and takes the second file, and so
> on.
> The combination of {{InProgressRepository}} and idempotent consumer is used
> to avoid handling the same files again.
> However, every time the SFTP endpoint lists files, the endpoints and polling
> consumers adjust the list in the {{InProgressRepository}}, thus affecting the
> {{SimpleLRUCache}}.
> The number of elements in the cache doesn't grow, however, the number of
> changes grows with almost n^2 speed.
> With the limit of 50k files, the SimpleLRUCache is evicted already on ~600(!)
> files. This leads to an infinite loop while processing the files.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CAMEL-20850) LRUCache evicts entries unexpectedly
[
https://issues.apache.org/jira/browse/CAMEL-20850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17853669#comment-17853669
]
Nicolas Filotto edited comment on CAMEL-20850 at 6/10/24 1:34 PM:
--
[~Nizametdinov] could you please test with the fix in this PR
https://github.com/apache/camel/pull/14424 before I merge it? Or at least
provide a use case to reproduce
was (Author: JIRAUSER285918):
[~Nizametdinov] could you please test with the fix in this PR
https://github.com/apache/camel/pull/14424 before I merge it?
> LRUCache evicts entries unexpectedly
>
>
> Key: CAMEL-20850
> URL: https://issues.apache.org/jira/browse/CAMEL-20850
> Project: Camel
> Issue Type: Bug
> Components: came-core
>Affects Versions: 4.0.3, 4.2.0
>Reporter: Timur
>Assignee: Nicolas Filotto
>Priority: Minor
>
> h1. Summary
> We encountered an infinite loop while downloading files using the SFTP
> endpoint.
> During our investigation, we discovered the {{InProgressRepository}}
> utilizing the {{SimpleLRUCache}}. This cache incorporates an unconventional
> eviction implementation that involves a changes tracking queue.
> Any attempt to modify the cache, even when putting the same element, results
> in an increase in the cache size, potentially causing eviction to occur even
> for a single element.
> The code is as follows:
> {code:java}
> Map lruCache = LRUCacheFactory.newLRUCache(1, 1);
> int numberOfInserts = 0;
> lruCache.put("key", "value");
> while (lruCache.size() > 0) {
> lruCache.put("key", "value");
> numberOfInserts++;
> }
> throw new IllegalStateException("We should never reach this point, we
> inserted the same element " + numberOfInserts + " times");
> {code}
> In the provided code, the failure occurs when the number of inserts reaches 2.
> h1. Expected Result
> Utilize the LRU Cache limited only by the maximum size passed into it, rather
> than by some internal implementation limits.
> h1. Proposed Solution
> Implement a standard LRUCache, say, by leveraging a {{LRUMap}} from Apache
> Commons.
> We may provide the PR later on.
> h1. The Background
> We need to use a dynamic SFTP route (the download parameters depend on some
> configuration passed from the outside). By default, this is impossible, so we
> will have to use {{pollEnrich}}:
> {code:java}
> .pollEnrich().simple(SFTP_DYNAMIC_URI)
> .timeout(RETURN_CURRENT_RESULT_WITHOUT_WAIT)
> {code}
> The pollEnrich takes only one element (see {{GenericFilePollingConsumer}}).
> The file consumer requests from the SFTP endpoint the list of all files, then
> takes the first, then gets the list again and takes the second file, and so
> on.
> The combination of {{InProgressRepository}} and idempotent consumer is used
> to avoid handling the same files again.
> However, every time the SFTP endpoint lists files, the endpoints and polling
> consumers adjust the list in the {{InProgressRepository}}, thus affecting the
> {{SimpleLRUCache}}.
> The number of elements in the cache doesn't grow, however, the number of
> changes grows with almost n^2 speed.
> With the limit of 50k files, the SimpleLRUCache is evicted already on ~600(!)
> files. This leads to an infinite loop while processing the files.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-20850) LRUCache evicts entries unexpectedly
[
https://issues.apache.org/jira/browse/CAMEL-20850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17853669#comment-17853669
]
Nicolas Filotto commented on CAMEL-20850:
-
[~Nizametdinov] could you please test with the fix in this PR
https://github.com/apache/camel/pull/14424 before I merge it?
> LRUCache evicts entries unexpectedly
>
>
> Key: CAMEL-20850
> URL: https://issues.apache.org/jira/browse/CAMEL-20850
> Project: Camel
> Issue Type: Bug
> Components: came-core
>Affects Versions: 4.0.3, 4.2.0
>Reporter: Timur
>Assignee: Nicolas Filotto
>Priority: Minor
>
> h1. Summary
> We encountered an infinite loop while downloading files using the SFTP
> endpoint.
> During our investigation, we discovered the {{InProgressRepository}}
> utilizing the {{SimpleLRUCache}}. This cache incorporates an unconventional
> eviction implementation that involves a changes tracking queue.
> Any attempt to modify the cache, even when putting the same element, results
> in an increase in the cache size, potentially causing eviction to occur even
> for a single element.
> The code is as follows:
> {code:java}
> Map lruCache = LRUCacheFactory.newLRUCache(1, 1);
> int numberOfInserts = 0;
> lruCache.put("key", "value");
> while (lruCache.size() > 0) {
> lruCache.put("key", "value");
> numberOfInserts++;
> }
> throw new IllegalStateException("We should never reach this point, we
> inserted the same element " + numberOfInserts + " times");
> {code}
> In the provided code, the failure occurs when the number of inserts reaches 2.
> h1. Expected Result
> Utilize the LRU Cache limited only by the maximum size passed into it, rather
> than by some internal implementation limits.
> h1. Proposed Solution
> Implement a standard LRUCache, say, by leveraging a {{LRUMap}} from Apache
> Commons.
> We may provide the PR later on.
> h1. The Background
> We need to use a dynamic SFTP route (the download parameters depend on some
> configuration passed from the outside). By default, this is impossible, so we
> will have to use {{pollEnrich}}:
> {code:java}
> .pollEnrich().simple(SFTP_DYNAMIC_URI)
> .timeout(RETURN_CURRENT_RESULT_WITHOUT_WAIT)
> {code}
> The pollEnrich takes only one element (see {{GenericFilePollingConsumer}}).
> The file consumer requests from the SFTP endpoint the list of all files, then
> takes the first, then gets the list again and takes the second file, and so
> on.
> The combination of {{InProgressRepository}} and idempotent consumer is used
> to avoid handling the same files again.
> However, every time the SFTP endpoint lists files, the endpoints and polling
> consumers adjust the list in the {{InProgressRepository}}, thus affecting the
> {{SimpleLRUCache}}.
> The number of elements in the cache doesn't grow, however, the number of
> changes grows with almost n^2 speed.
> With the limit of 50k files, the SimpleLRUCache is evicted already on ~600(!)
> files. This leads to an infinite loop while processing the files.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-20850) LRUCache evicts entries unexpectedly
[
https://issues.apache.org/jira/browse/CAMEL-20850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicolas Filotto updated CAMEL-20850:
Component/s: came-core
> LRUCache evicts entries unexpectedly
>
>
> Key: CAMEL-20850
> URL: https://issues.apache.org/jira/browse/CAMEL-20850
> Project: Camel
> Issue Type: Bug
> Components: came-core
>Affects Versions: 4.0.3, 4.2.0
>Reporter: Timur
>Assignee: Nicolas Filotto
>Priority: Minor
>
> h1. Summary
> We encountered an infinite loop while downloading files using the SFTP
> endpoint.
> During our investigation, we discovered the {{InProgressRepository}}
> utilizing the {{SimpleLRUCache}}. This cache incorporates an unconventional
> eviction implementation that involves a changes tracking queue.
> Any attempt to modify the cache, even when putting the same element, results
> in an increase in the cache size, potentially causing eviction to occur even
> for a single element.
> The code is as follows:
> {code:java}
> Map lruCache = LRUCacheFactory.newLRUCache(1, 1);
> int numberOfInserts = 0;
> lruCache.put("key", "value");
> while (lruCache.size() > 0) {
> lruCache.put("key", "value");
> numberOfInserts++;
> }
> throw new IllegalStateException("We should never reach this point, we
> inserted the same element " + numberOfInserts + " times");
> {code}
> In the provided code, the failure occurs when the number of inserts reaches 2.
> h1. Expected Result
> Utilize the LRU Cache limited only by the maximum size passed into it, rather
> than by some internal implementation limits.
> h1. Proposed Solution
> Implement a standard LRUCache, say, by leveraging a {{LRUMap}} from Apache
> Commons.
> We may provide the PR later on.
> h1. The Background
> We need to use a dynamic SFTP route (the download parameters depend on some
> configuration passed from the outside). By default, this is impossible, so we
> will have to use {{pollEnrich}}:
> {code:java}
> .pollEnrich().simple(SFTP_DYNAMIC_URI)
> .timeout(RETURN_CURRENT_RESULT_WITHOUT_WAIT)
> {code}
> The pollEnrich takes only one element (see {{GenericFilePollingConsumer}}).
> The file consumer requests from the SFTP endpoint the list of all files, then
> takes the first, then gets the list again and takes the second file, and so
> on.
> The combination of {{InProgressRepository}} and idempotent consumer is used
> to avoid handling the same files again.
> However, every time the SFTP endpoint lists files, the endpoints and polling
> consumers adjust the list in the {{InProgressRepository}}, thus affecting the
> {{SimpleLRUCache}}.
> The number of elements in the cache doesn't grow, however, the number of
> changes grows with almost n^2 speed.
> With the limit of 50k files, the SimpleLRUCache is evicted already on ~600(!)
> files. This leads to an infinite loop while processing the files.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-20850) LRUCache evicts entries unexpectedly
[
https://issues.apache.org/jira/browse/CAMEL-20850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicolas Filotto updated CAMEL-20850:
Affects Version/s: 4.2.0
4.0.3
> LRUCache evicts entries unexpectedly
>
>
> Key: CAMEL-20850
> URL: https://issues.apache.org/jira/browse/CAMEL-20850
> Project: Camel
> Issue Type: Bug
>Affects Versions: 4.0.3, 4.2.0
>Reporter: Timur
>Assignee: Nicolas Filotto
>Priority: Minor
>
> h1. Summary
> We encountered an infinite loop while downloading files using the SFTP
> endpoint.
> During our investigation, we discovered the {{InProgressRepository}}
> utilizing the {{SimpleLRUCache}}. This cache incorporates an unconventional
> eviction implementation that involves a changes tracking queue.
> Any attempt to modify the cache, even when putting the same element, results
> in an increase in the cache size, potentially causing eviction to occur even
> for a single element.
> The code is as follows:
> {code:java}
> Map lruCache = LRUCacheFactory.newLRUCache(1, 1);
> int numberOfInserts = 0;
> lruCache.put("key", "value");
> while (lruCache.size() > 0) {
> lruCache.put("key", "value");
> numberOfInserts++;
> }
> throw new IllegalStateException("We should never reach this point, we
> inserted the same element " + numberOfInserts + " times");
> {code}
> In the provided code, the failure occurs when the number of inserts reaches 2.
> h1. Expected Result
> Utilize the LRU Cache limited only by the maximum size passed into it, rather
> than by some internal implementation limits.
> h1. Proposed Solution
> Implement a standard LRUCache, say, by leveraging a {{LRUMap}} from Apache
> Commons.
> We may provide the PR later on.
> h1. The Background
> We need to use a dynamic SFTP route (the download parameters depend on some
> configuration passed from the outside). By default, this is impossible, so we
> will have to use {{pollEnrich}}:
> {code:java}
> .pollEnrich().simple(SFTP_DYNAMIC_URI)
> .timeout(RETURN_CURRENT_RESULT_WITHOUT_WAIT)
> {code}
> The pollEnrich takes only one element (see {{GenericFilePollingConsumer}}).
> The file consumer requests from the SFTP endpoint the list of all files, then
> takes the first, then gets the list again and takes the second file, and so
> on.
> The combination of {{InProgressRepository}} and idempotent consumer is used
> to avoid handling the same files again.
> However, every time the SFTP endpoint lists files, the endpoints and polling
> consumers adjust the list in the {{InProgressRepository}}, thus affecting the
> {{SimpleLRUCache}}.
> The number of elements in the cache doesn't grow, however, the number of
> changes grows with almost n^2 speed.
> With the limit of 50k files, the SimpleLRUCache is evicted already on ~600(!)
> files. This leads to an infinite loop while processing the files.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-20850) LRUCache evicts entries unexpectedly
[
https://issues.apache.org/jira/browse/CAMEL-20850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17853193#comment-17853193
]
Nicolas Filotto commented on CAMEL-20850:
-
Thx for reporting let me check
> LRUCache evicts entries unexpectedly
>
>
> Key: CAMEL-20850
> URL: https://issues.apache.org/jira/browse/CAMEL-20850
> Project: Camel
> Issue Type: Bug
>Reporter: Timur
>Priority: Minor
>
> h1. Summary
> We encountered an infinite loop while downloading files using the SFTP
> endpoint.
> During our investigation, we discovered the {{InProgressRepository}}
> utilizing the {{SimpleLRUCache}}. This cache incorporates an unconventional
> eviction implementation that involves a changes tracking queue.
> Any attempt to modify the cache, even when putting the same element, results
> in an increase in the cache size, potentially causing eviction to occur even
> for a single element.
> The code is as follows:
> {code:java}
> Map lruCache = LRUCacheFactory.newLRUCache(1, 1);
> int numberOfInserts = 0;
> lruCache.put("key", "value");
> while (lruCache.size() > 0) {
> lruCache.put("key", "value");
> numberOfInserts++;
> }
> throw new IllegalStateException("We should never reach this point, we
> inserted the same element " + numberOfInserts + " times");
> {code}
> In the provided code, the failure occurs when the number of inserts reaches 2.
> h1. Expected Result
> Utilize the LRU Cache limited only by the maximum size passed into it, rather
> than by some internal implementation limits.
> h1. Proposed Solution
> Implement a standard LRUCache, say, by leveraging a {{LRUMap}} from Apache
> Commons.
> We may provide the PR later on.
> h1. The Background
> We need to use a dynamic SFTP route (the download parameters depend on some
> configuration passed from the outside). By default, this is impossible, so we
> will have to use {{pollEnrich}}:
> {code:java}
> .pollEnrich().simple(SFTP_DYNAMIC_URI)
> .timeout(RETURN_CURRENT_RESULT_WITHOUT_WAIT)
> {code}
> The pollEnrich takes only one element (see {{GenericFilePollingConsumer}}).
> The file consumer requests from the SFTP endpoint the list of all files, then
> takes the first, then gets the list again and takes the second file, and so
> on.
> The combination of {{InProgressRepository}} and idempotent consumer is used
> to avoid handling the same files again.
> However, every time the SFTP endpoint lists files, the endpoints and polling
> consumers adjust the list in the {{InProgressRepository}}, thus affecting the
> {{SimpleLRUCache}}.
> The number of elements in the cache doesn't grow, however, the number of
> changes grows with almost n^2 speed.
> With the limit of 50k files, the SimpleLRUCache is evicted already on ~600(!)
> files. This leads to an infinite loop while processing the files.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (CAMEL-20850) LRUCache evicts entries unexpectedly
[
https://issues.apache.org/jira/browse/CAMEL-20850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicolas Filotto reassigned CAMEL-20850:
---
Assignee: Nicolas Filotto
> LRUCache evicts entries unexpectedly
>
>
> Key: CAMEL-20850
> URL: https://issues.apache.org/jira/browse/CAMEL-20850
> Project: Camel
> Issue Type: Bug
>Reporter: Timur
>Assignee: Nicolas Filotto
>Priority: Minor
>
> h1. Summary
> We encountered an infinite loop while downloading files using the SFTP
> endpoint.
> During our investigation, we discovered the {{InProgressRepository}}
> utilizing the {{SimpleLRUCache}}. This cache incorporates an unconventional
> eviction implementation that involves a changes tracking queue.
> Any attempt to modify the cache, even when putting the same element, results
> in an increase in the cache size, potentially causing eviction to occur even
> for a single element.
> The code is as follows:
> {code:java}
> Map lruCache = LRUCacheFactory.newLRUCache(1, 1);
> int numberOfInserts = 0;
> lruCache.put("key", "value");
> while (lruCache.size() > 0) {
> lruCache.put("key", "value");
> numberOfInserts++;
> }
> throw new IllegalStateException("We should never reach this point, we
> inserted the same element " + numberOfInserts + " times");
> {code}
> In the provided code, the failure occurs when the number of inserts reaches 2.
> h1. Expected Result
> Utilize the LRU Cache limited only by the maximum size passed into it, rather
> than by some internal implementation limits.
> h1. Proposed Solution
> Implement a standard LRUCache, say, by leveraging a {{LRUMap}} from Apache
> Commons.
> We may provide the PR later on.
> h1. The Background
> We need to use a dynamic SFTP route (the download parameters depend on some
> configuration passed from the outside). By default, this is impossible, so we
> will have to use {{pollEnrich}}:
> {code:java}
> .pollEnrich().simple(SFTP_DYNAMIC_URI)
> .timeout(RETURN_CURRENT_RESULT_WITHOUT_WAIT)
> {code}
> The pollEnrich takes only one element (see {{GenericFilePollingConsumer}}).
> The file consumer requests from the SFTP endpoint the list of all files, then
> takes the first, then gets the list again and takes the second file, and so
> on.
> The combination of {{InProgressRepository}} and idempotent consumer is used
> to avoid handling the same files again.
> However, every time the SFTP endpoint lists files, the endpoints and polling
> consumers adjust the list in the {{InProgressRepository}}, thus affecting the
> {{SimpleLRUCache}}.
> The number of elements in the cache doesn't grow, however, the number of
> changes grows with almost n^2 speed.
> With the limit of 50k files, the SimpleLRUCache is evicted already on ~600(!)
> files. This leads to an infinite loop while processing the files.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-20692) camel-cxf - No Payload is logged when the logging feature is enabled
[ https://issues.apache.org/jira/browse/CAMEL-20692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Filotto updated CAMEL-20692: Fix Version/s: 4.6.0 > camel-cxf - No Payload is logged when the logging feature is enabled > > > Key: CAMEL-20692 > URL: https://issues.apache.org/jira/browse/CAMEL-20692 > Project: Camel > Issue Type: Bug > Components: camel-cxf >Affects Versions: 3.22.1 >Reporter: Xilai Dai >Assignee: Nicolas Filotto >Priority: Minor > Fix For: 3.22.2, 4.0.6, 4.4.3, 4.6.0 > > Attachments: test-camel-cxf-logging.zip > > > When start a CXF Soap service via endpoint cxf:// with > loggingFeatureEnabled=true, > for instance > "cxf://http://127.0.0.1:8020/services/BeanAsService?dataFormat=PAYLOAD .. > &loggingFeatureEnabled=true" > The REQ_IN and RESP_OUT messages are logged when calling the Soap service. > But missing the Payload(body) in the messages. (only the > ServiceName/PortName/PortTypeName/Headers are logged) > Attached a demo project can be used to reproduce this issue. > (while the "cxfrs://" endpoint with loggingFeatureEnabled=true is able to > have the Payload logged as expected when calling the service) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-20692) camel-cxf - No Payload is logged when the logging feature is enabled
[ https://issues.apache.org/jira/browse/CAMEL-20692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Filotto updated CAMEL-20692: Fix Version/s: 4.4.3 > camel-cxf - No Payload is logged when the logging feature is enabled > > > Key: CAMEL-20692 > URL: https://issues.apache.org/jira/browse/CAMEL-20692 > Project: Camel > Issue Type: Bug > Components: camel-cxf >Affects Versions: 3.22.1 >Reporter: Xilai Dai >Assignee: Nicolas Filotto >Priority: Minor > Fix For: 3.22.2, 4.0.6, 4.4.3 > > Attachments: test-camel-cxf-logging.zip > > > When start a CXF Soap service via endpoint cxf:// with > loggingFeatureEnabled=true, > for instance > "cxf://http://127.0.0.1:8020/services/BeanAsService?dataFormat=PAYLOAD .. > &loggingFeatureEnabled=true" > The REQ_IN and RESP_OUT messages are logged when calling the Soap service. > But missing the Payload(body) in the messages. (only the > ServiceName/PortName/PortTypeName/Headers are logged) > Attached a demo project can be used to reproduce this issue. > (while the "cxfrs://" endpoint with loggingFeatureEnabled=true is able to > have the Payload logged as expected when calling the service) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-20692) camel-cxf - No Payload is logged when the logging feature is enabled
[ https://issues.apache.org/jira/browse/CAMEL-20692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Filotto updated CAMEL-20692: Fix Version/s: 4.0.6 > camel-cxf - No Payload is logged when the logging feature is enabled > > > Key: CAMEL-20692 > URL: https://issues.apache.org/jira/browse/CAMEL-20692 > Project: Camel > Issue Type: Bug > Components: camel-cxf >Affects Versions: 3.22.1 >Reporter: Xilai Dai >Assignee: Nicolas Filotto >Priority: Minor > Fix For: 3.22.2, 4.0.6 > > Attachments: test-camel-cxf-logging.zip > > > When start a CXF Soap service via endpoint cxf:// with > loggingFeatureEnabled=true, > for instance > "cxf://http://127.0.0.1:8020/services/BeanAsService?dataFormat=PAYLOAD .. > &loggingFeatureEnabled=true" > The REQ_IN and RESP_OUT messages are logged when calling the Soap service. > But missing the Payload(body) in the messages. (only the > ServiceName/PortName/PortTypeName/Headers are logged) > Attached a demo project can be used to reproduce this issue. > (while the "cxfrs://" endpoint with loggingFeatureEnabled=true is able to > have the Payload logged as expected when calling the service) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-20692) camel-cxf - No Payload is logged when the logging feature is enabled
[ https://issues.apache.org/jira/browse/CAMEL-20692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17840714#comment-17840714 ] Nicolas Filotto commented on CAMEL-20692: - Corresponding PRs: * 4.6 https://github.com/apache/camel/pull/13936 * 4.4 https://github.com/apache/camel/pull/13935 * 4.0 https://github.com/apache/camel/pull/13931 * 3.22 https://github.com/apache/camel/pull/13865 > camel-cxf - No Payload is logged when the logging feature is enabled > > > Key: CAMEL-20692 > URL: https://issues.apache.org/jira/browse/CAMEL-20692 > Project: Camel > Issue Type: Bug > Components: camel-cxf >Affects Versions: 3.22.1 >Reporter: Xilai Dai >Assignee: Nicolas Filotto >Priority: Minor > Fix For: 3.22.2 > > Attachments: test-camel-cxf-logging.zip > > > When start a CXF Soap service via endpoint cxf:// with > loggingFeatureEnabled=true, > for instance > "cxf://http://127.0.0.1:8020/services/BeanAsService?dataFormat=PAYLOAD .. > &loggingFeatureEnabled=true" > The REQ_IN and RESP_OUT messages are logged when calling the Soap service. > But missing the Payload(body) in the messages. (only the > ServiceName/PortName/PortTypeName/Headers are logged) > Attached a demo project can be used to reproduce this issue. > (while the "cxfrs://" endpoint with loggingFeatureEnabled=true is able to > have the Payload logged as expected when calling the service) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-20692) camel-cxf - No Payload is logged when the logging feature is enabled
[ https://issues.apache.org/jira/browse/CAMEL-20692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Filotto updated CAMEL-20692: Summary: camel-cxf - No Payload is logged when the logging feature is enabled (was: camel-cxf - No Payload(body) is logged in REQ_IN/RESP_OUT messages when cxf endpoint with loggingFeatureEnabled=true) > camel-cxf - No Payload is logged when the logging feature is enabled > > > Key: CAMEL-20692 > URL: https://issues.apache.org/jira/browse/CAMEL-20692 > Project: Camel > Issue Type: Bug > Components: camel-cxf >Affects Versions: 3.22.1 >Reporter: Xilai Dai >Assignee: Nicolas Filotto >Priority: Minor > Attachments: test-camel-cxf-logging.zip > > > When start a CXF Soap service via endpoint cxf:// with > loggingFeatureEnabled=true, > for instance > "cxf://http://127.0.0.1:8020/services/BeanAsService?dataFormat=PAYLOAD .. > &loggingFeatureEnabled=true" > The REQ_IN and RESP_OUT messages are logged when calling the Soap service. > But missing the Payload(body) in the messages. (only the > ServiceName/PortName/PortTypeName/Headers are logged) > Attached a demo project can be used to reproduce this issue. > (while the "cxfrs://" endpoint with loggingFeatureEnabled=true is able to > have the Payload logged as expected when calling the service) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (CAMEL-20692) camel-cxf - No Payload(body) is logged in REQ_IN/RESP_OUT messages when cxf endpoint with loggingFeatureEnabled=true
[
https://issues.apache.org/jira/browse/CAMEL-20692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17839055#comment-17839055
]
Nicolas Filotto edited comment on CAMEL-20692 at 4/19/24 5:03 PM:
--
Thanks for reporting the issue, I confirm the bug, it is because, in the case
of the CXF endpoint, the logging size limit is set to 0 by default which is not
expected/wanted. As a workaround, you can simply set the [query parameter
{{loggingSizeLimit}}|https://camel.apache.org/components/4.4.x/cxf-component.html#_endpoint_query_option_loggingSizeLimit]
to a specific value knowing that {{-1}} means no limit
was (Author: JIRAUSER285918):
Thanks for reporting the issue, I confirm the bug, it is because, in the case
of the CXF endpoint, the logging size limit is set to 0 by default which is not
expected/wanted. As a workaround, you can simply set the [query parameter
{{loggingSizeLimit}}|https://camel.apache.org/components/4.4.x/cxf-component.html#_endpoint_query_option_loggingSizeLimit]
to a specific value
> camel-cxf - No Payload(body) is logged in REQ_IN/RESP_OUT messages when cxf
> endpoint with loggingFeatureEnabled=true
>
>
> Key: CAMEL-20692
> URL: https://issues.apache.org/jira/browse/CAMEL-20692
> Project: Camel
> Issue Type: Bug
> Components: camel-cxf
>Affects Versions: 3.22.1
>Reporter: Xilai Dai
>Assignee: Nicolas Filotto
>Priority: Minor
> Attachments: test-camel-cxf-logging.zip
>
>
> When start a CXF Soap service via endpoint cxf:// with
> loggingFeatureEnabled=true,
> for instance
> "cxf://http://127.0.0.1:8020/services/BeanAsService?dataFormat=PAYLOAD ..
> &loggingFeatureEnabled=true"
> The REQ_IN and RESP_OUT messages are logged when calling the Soap service.
> But missing the Payload(body) in the messages. (only the
> ServiceName/PortName/PortTypeName/Headers are logged)
> Attached a demo project can be used to reproduce this issue.
> (while the "cxfrs://" endpoint with loggingFeatureEnabled=true is able to
> have the Payload logged as expected when calling the service)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-20692) camel-cxf - No Payload(body) is logged in REQ_IN/RESP_OUT messages when cxf endpoint with loggingFeatureEnabled=true
[
https://issues.apache.org/jira/browse/CAMEL-20692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17839055#comment-17839055
]
Nicolas Filotto commented on CAMEL-20692:
-
Thanks for reporting the issue, I confirm the bug, it is because, in the case
of the CXF endpoint, the logging size limit is set to 0 by default which is not
expected/wanted. As a workaround, you can simply set the [query parameter
{{loggingSizeLimit}}|https://camel.apache.org/components/4.4.x/cxf-component.html#_endpoint_query_option_loggingSizeLimit]
to a specific value
> camel-cxf - No Payload(body) is logged in REQ_IN/RESP_OUT messages when cxf
> endpoint with loggingFeatureEnabled=true
>
>
> Key: CAMEL-20692
> URL: https://issues.apache.org/jira/browse/CAMEL-20692
> Project: Camel
> Issue Type: Bug
> Components: camel-cxf
>Affects Versions: 3.22.1
>Reporter: Xilai Dai
>Assignee: Nicolas Filotto
>Priority: Minor
> Attachments: test-camel-cxf-logging.zip
>
>
> When start a CXF Soap service via endpoint cxf:// with
> loggingFeatureEnabled=true,
> for instance
> "cxf://http://127.0.0.1:8020/services/BeanAsService?dataFormat=PAYLOAD ..
> &loggingFeatureEnabled=true"
> The REQ_IN and RESP_OUT messages are logged when calling the Soap service.
> But missing the Payload(body) in the messages. (only the
> ServiceName/PortName/PortTypeName/Headers are logged)
> Attached a demo project can be used to reproduce this issue.
> (while the "cxfrs://" endpoint with loggingFeatureEnabled=true is able to
> have the Payload logged as expected when calling the service)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (CAMEL-20692) camel-cxf - No Payload(body) is logged in REQ_IN/RESP_OUT messages when cxf endpoint with loggingFeatureEnabled=true
[ https://issues.apache.org/jira/browse/CAMEL-20692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Filotto reassigned CAMEL-20692: --- Assignee: Nicolas Filotto > camel-cxf - No Payload(body) is logged in REQ_IN/RESP_OUT messages when cxf > endpoint with loggingFeatureEnabled=true > > > Key: CAMEL-20692 > URL: https://issues.apache.org/jira/browse/CAMEL-20692 > Project: Camel > Issue Type: Bug > Components: camel-cxf >Affects Versions: 3.22.1 >Reporter: Xilai Dai >Assignee: Nicolas Filotto >Priority: Minor > Attachments: test-camel-cxf-logging.zip > > > When start a CXF Soap service via endpoint cxf:// with > loggingFeatureEnabled=true, > for instance > "cxf://http://127.0.0.1:8020/services/BeanAsService?dataFormat=PAYLOAD .. > &loggingFeatureEnabled=true" > The REQ_IN and RESP_OUT messages are logged when calling the Soap service. > But missing the Payload(body) in the messages. (only the > ServiceName/PortName/PortTypeName/Headers are logged) > Attached a demo project can be used to reproduce this issue. > (while the "cxfrs://" endpoint with loggingFeatureEnabled=true is able to > have the Payload logged as expected when calling the service) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-20551) camel-core: Default registry should not ignore beans in repositories
[
https://issues.apache.org/jira/browse/CAMEL-20551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicolas Filotto resolved CAMEL-20551.
-
Resolution: Fixed
> camel-core: Default registry should not ignore beans in repositories
>
>
> Key: CAMEL-20551
> URL: https://issues.apache.org/jira/browse/CAMEL-20551
> Project: Camel
> Issue Type: Bug
> Components: came-core
>Affects Versions: 4.2.0
>Reporter: Nicolas Filotto
>Assignee: Nicolas Filotto
>Priority: Major
> Fix For: 4.4.2, 4.5.0
>
>
> In case we have several bean repositories defined in the default registry and
> a bean is defined in one of the first bean repositories, the method
> {{findSingleByType}} won't return any result while we expect to retrieve a
> bean.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CAMEL-20551) camel-core: Default registry should not ignore beans in repositories
[
https://issues.apache.org/jira/browse/CAMEL-20551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17825417#comment-17825417
]
Nicolas Filotto edited comment on CAMEL-20551 at 3/12/24 7:24 AM:
--
The corresponding PRs:
* 4.5 https://github.com/apache/camel/pull/13446
* 4.4 https://github.com/apache/camel/pull/13452
was (Author: JIRAUSER285918):
The corresponding PR https://github.com/apache/camel/pull/13446
> camel-core: Default registry should not ignore beans in repositories
>
>
> Key: CAMEL-20551
> URL: https://issues.apache.org/jira/browse/CAMEL-20551
> Project: Camel
> Issue Type: Bug
> Components: came-core
>Affects Versions: 4.2.0
>Reporter: Nicolas Filotto
>Assignee: Nicolas Filotto
>Priority: Major
> Fix For: 4.4.2, 4.5.0
>
>
> In case we have several bean repositories defined in the default registry and
> a bean is defined in one of the first bean repositories, the method
> {{findSingleByType}} won't return any result while we expect to retrieve a
> bean.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-20551) camel-core: Default registry should not ignore beans in repositories
[
https://issues.apache.org/jira/browse/CAMEL-20551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17825417#comment-17825417
]
Nicolas Filotto commented on CAMEL-20551:
-
The corresponding PR https://github.com/apache/camel/pull/13446
> camel-core: Default registry should not ignore beans in repositories
>
>
> Key: CAMEL-20551
> URL: https://issues.apache.org/jira/browse/CAMEL-20551
> Project: Camel
> Issue Type: Bug
> Components: came-core
>Affects Versions: 4.2.0
>Reporter: Nicolas Filotto
>Assignee: Nicolas Filotto
>Priority: Major
> Fix For: 4.4.2, 4.5.0
>
>
> In case we have several bean repositories defined in the default registry and
> a bean is defined in one of the first bean repositories, the method
> {{findSingleByType}} won't return any result while we expect to retrieve a
> bean.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAMEL-20551) camel-core: Default registry should not ignore beans in repositories
Nicolas Filotto created CAMEL-20551:
---
Summary: camel-core: Default registry should not ignore beans in
repositories
Key: CAMEL-20551
URL: https://issues.apache.org/jira/browse/CAMEL-20551
Project: Camel
Issue Type: Bug
Components: came-core
Affects Versions: 4.2.0
Reporter: Nicolas Filotto
Assignee: Nicolas Filotto
Fix For: 4.4.2, 4.5.0
In case we have several bean repositories defined in the default registry and a
bean is defined in one of the first bean repositories, the method
{{findSingleByType}} won't return any result while we expect to retrieve a bean.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-20507) camel-core - Java fluent builder for expression can allow to use enum class directly
[
https://issues.apache.org/jira/browse/CAMEL-20507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17824149#comment-17824149
]
Nicolas Filotto commented on CAMEL-20507:
-
Corresponding PR https://github.com/apache/camel/pull/13398
> camel-core - Java fluent builder for expression can allow to use enum class
> directly
>
>
> Key: CAMEL-20507
> URL: https://issues.apache.org/jira/browse/CAMEL-20507
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
>Reporter: Claus Ibsen
>Assignee: Nicolas Filotto
>Priority: Major
> Fix For: 4.x
>
>
> See this class JsonPathSplitSingleListOptionTest
> (https://github.com/apache/camel/pull/13364)
> var jsonpath =
> expression().jsonpath().option(Option.ALWAYS_RETURN_LIST.name()).expression("$.store.book[0]").end();
> The option is an enum from camel-jsonpath, but the DSL method accepts only a
> String. It would be nice if we could somehow pass in just the enum field,
> without having to call .name(), ala:
> var jsonpath =
> expression().jsonpath().option(Option.ALWAYS_RETURN_LIST).expression("$.store.book[0]").end();
> So we have both a String and an enum field method in the generated fluent
> builder.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (CAMEL-20507) camel-core - Java fluent builder for expression can allow to use enum class directly
[
https://issues.apache.org/jira/browse/CAMEL-20507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicolas Filotto reassigned CAMEL-20507:
---
Assignee: Nicolas Filotto
> camel-core - Java fluent builder for expression can allow to use enum class
> directly
>
>
> Key: CAMEL-20507
> URL: https://issues.apache.org/jira/browse/CAMEL-20507
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
>Reporter: Claus Ibsen
>Assignee: Nicolas Filotto
>Priority: Major
> Fix For: 4.x
>
>
> See this class JsonPathSplitSingleListOptionTest
> (https://github.com/apache/camel/pull/13364)
> var jsonpath =
> expression().jsonpath().option(Option.ALWAYS_RETURN_LIST.name()).expression("$.store.book[0]").end();
> The option is an enum from camel-jsonpath, but the DSL method accepts only a
> String. It would be nice if we could somehow pass in just the enum field,
> without having to call .name(), ala:
> var jsonpath =
> expression().jsonpath().option(Option.ALWAYS_RETURN_LIST).expression("$.store.book[0]").end();
> So we have both a String and an enum field method in the generated fluent
> builder.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-20507) camel-core - Java fluent builder for expression can allow to use enum class directly
[
https://issues.apache.org/jira/browse/CAMEL-20507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17823088#comment-17823088
]
Nicolas Filotto commented on CAMEL-20507:
-
Yes sure, I can have a look into this during my spare time this week if possible
> camel-core - Java fluent builder for expression can allow to use enum class
> directly
>
>
> Key: CAMEL-20507
> URL: https://issues.apache.org/jira/browse/CAMEL-20507
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
>Reporter: Claus Ibsen
>Priority: Major
> Fix For: 4.x
>
>
> See this class JsonPathSplitSingleListOptionTest
> (https://github.com/apache/camel/pull/13364)
> var jsonpath =
> expression().jsonpath().option(Option.ALWAYS_RETURN_LIST.name()).expression("$.store.book[0]").end();
> The option is an enum from camel-jsonpath, but the DSL method accepts only a
> String. It would be nice if we could somehow pass in just the enum field,
> without having to call .name(), ala:
> var jsonpath =
> expression().jsonpath().option(Option.ALWAYS_RETURN_LIST).expression("$.store.book[0]").end();
> So we have both a String and an enum field method in the generated fluent
> builder.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-19161) camel-salesforce - Connection issue when using lazy login
[
https://issues.apache.org/jira/browse/CAMEL-19161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17813530#comment-17813530
]
Nicolas Filotto commented on CAMEL-19161:
-
[~jeremyross] It looks like the fix is only in Camel 4
(https://github.com/apache/camel/commit/595ce85f9d5c74d6413fd7a8233b18cf21781aeb)
so having 3.21.1 included in the fix versions doesn't seem to be correct,
could you please confirm it?
> camel-salesforce - Connection issue when using lazy login
> -
>
> Key: CAMEL-19161
> URL: https://issues.apache.org/jira/browse/CAMEL-19161
> Project: Camel
> Issue Type: Bug
> Components: camel-salesforce
>Affects Versions: 3.11.1
>Reporter: Nicolas Filotto
>Assignee: Jeremy Ross
>Priority: Minor
> Fix For: 3.21.1, 4.0.0
>
>
> When we enable lazy login, we end up with an exception of type:
> {noformat}
> 2023-03-16 16:49:40,743 [main ] WARN SalesforceComponent
> - Missing property packages, getSObject* operations will NOT work without
> property rawPayload=true
> 2023-03-16 16:49:53,432 [main ] INFO SalesforceSession
> - Login at Salesforce loginUrl:
> https://login.salesforce.com/services/oauth2/token
> 2023-03-16 16:50:28,009 [main ] INFO SalesforceSession
> - Login successful
> 2023-03-16 16:50:33,456 [forceHttpClient] WARN SubscriptionHelper
> - Handshake failure: {failure={exception=java.lang.IllegalArgumentException:
> Invalid protocol null, message={ext={replay=true},
> supportedConnectionTypes=[long-polling], channel=/meta/handshake, id=1,
> version=1.0}, connectionType=long-polling}, channel=/meta/handshake, id=1,
> successful=false}
> 2023-03-16 16:50:33,457 [forceHttpClient] INFO SubscriptionHelper
> - Handshaking after unexpected disconnect from Salesforce...
> 2023-03-16 16:50:57,019 [forceHttpClient] WARN SubscriptionHelper
> - Handshake failure: {failure={exception=java.lang.IllegalArgumentException:
> Invalid protocol null, message={ext={replay=true},
> supportedConnectionTypes=[long-polling], channel=/meta/handshake, id=2,
> version=1.0}, connectionType=long-polling}, channel=/meta/handshake, id=2,
> successful=false}
> 2023-03-16 16:51:00,769 [forceHttpClient] WARN SubscriptionHelper
> - Handshake failure: {failure={exception=java.lang.IllegalArgumentException:
> Invalid protocol null, message={ext={replay=true},
> supportedConnectionTypes=[long-polling], channel=/meta/handshake, id=3,
> version=1.0}, connectionType=long-polling}, channel=/meta/handshake, id=3,
> successful=false}
> {noformat}
> After a deeper investigation, it is due to the fact that when [creating the
> {{BayeuxClient}} during
> startup|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#L405],
> it calls {{component.getSession().getInstanceUrl()}} to build the Url used
> by the client to connect but the instance Url is null as long as it not
> connected.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CAMEL-20335) spring-xml build error using `/component-test` on GitHub Actions
[
https://issues.apache.org/jira/browse/CAMEL-20335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicolas Filotto resolved CAMEL-20335.
-
Fix Version/s: 4.4.0
Resolution: Fixed
> spring-xml build error using `/component-test` on GitHub Actions
>
>
> Key: CAMEL-20335
> URL: https://issues.apache.org/jira/browse/CAMEL-20335
> Project: Camel
> Issue Type: Task
> Components: camel-spring-xml
>Affects Versions: 4.3.0
>Reporter: Aurélien Pupier
>Assignee: Nicolas Filotto
>Priority: Major
> Fix For: 4.4.0
>
>
> {noformat}
> [ERROR] [ERROR] Could not find the selected project in the reactor:
> components/camel-spring-xml/target/sources/camel-api/META-INF/maven/org.apache.camel/camel-api
> @
> [ERROR] Could not find the selected project in the reactor:
> components/camel-spring-xml/target/sources/camel-api/META-INF/maven/org.apache.camel/camel-api
> -> [Help 1]
> org.apache.maven.MavenExecutionException: Could not find the selected project
> in the reactor:
> components/camel-spring-xml/target/sources/camel-api/META-INF/maven/org.apache.camel/camel-api
> at
> org.apache.maven.graph.DefaultGraphBuilder.trimSelectedProjects(DefaultGraphBuilder.java:148)
> at
> org.apache.maven.graph.DefaultGraphBuilder.reactorDependencyGraph(DefaultGraphBuilder.java:110)
> at
> org.apache.maven.graph.DefaultGraphBuilder.build(DefaultGraphBuilder.java:78)
> at org.apache.maven.DefaultMaven.buildGraph(DefaultMaven.java:448)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:197)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:173)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:101)
> at org.apache.maven.cli.DaemonMavenCli.execute(DaemonMavenCli.java:694)
> at org.apache.maven.cli.DaemonMavenCli.doMain(DaemonMavenCli.java:240)
> at org.apache.maven.cli.DaemonMavenCli.main(DaemonMavenCli.java:217)
> at org.mvndaemon.mvnd.daemon.Server.handle(Server.java:612)
> at org.mvndaemon.mvnd.daemon.Server.client(Server.java:288)
> at org.mvndaemon.mvnd.daemon.Server.lambda$accept$2(Server.java:250)
> at java.base/java.lang.Thread.run(Thread.java:840)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (CAMEL-20335) spring-xml build error using `/component-test` on GitHub Actions
[
https://issues.apache.org/jira/browse/CAMEL-20335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicolas Filotto reassigned CAMEL-20335:
---
Assignee: Nicolas Filotto
> spring-xml build error using `/component-test` on GitHub Actions
>
>
> Key: CAMEL-20335
> URL: https://issues.apache.org/jira/browse/CAMEL-20335
> Project: Camel
> Issue Type: Task
> Components: camel-spring-xml
>Affects Versions: 4.3.0
>Reporter: Aurélien Pupier
>Assignee: Nicolas Filotto
>Priority: Major
>
> {noformat}
> [ERROR] [ERROR] Could not find the selected project in the reactor:
> components/camel-spring-xml/target/sources/camel-api/META-INF/maven/org.apache.camel/camel-api
> @
> [ERROR] Could not find the selected project in the reactor:
> components/camel-spring-xml/target/sources/camel-api/META-INF/maven/org.apache.camel/camel-api
> -> [Help 1]
> org.apache.maven.MavenExecutionException: Could not find the selected project
> in the reactor:
> components/camel-spring-xml/target/sources/camel-api/META-INF/maven/org.apache.camel/camel-api
> at
> org.apache.maven.graph.DefaultGraphBuilder.trimSelectedProjects(DefaultGraphBuilder.java:148)
> at
> org.apache.maven.graph.DefaultGraphBuilder.reactorDependencyGraph(DefaultGraphBuilder.java:110)
> at
> org.apache.maven.graph.DefaultGraphBuilder.build(DefaultGraphBuilder.java:78)
> at org.apache.maven.DefaultMaven.buildGraph(DefaultMaven.java:448)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:197)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:173)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:101)
> at org.apache.maven.cli.DaemonMavenCli.execute(DaemonMavenCli.java:694)
> at org.apache.maven.cli.DaemonMavenCli.doMain(DaemonMavenCli.java:240)
> at org.apache.maven.cli.DaemonMavenCli.main(DaemonMavenCli.java:217)
> at org.mvndaemon.mvnd.daemon.Server.handle(Server.java:612)
> at org.mvndaemon.mvnd.daemon.Server.client(Server.java:288)
> at org.mvndaemon.mvnd.daemon.Server.lambda$accept$2(Server.java:250)
> at java.base/java.lang.Thread.run(Thread.java:840)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CAMEL-20296) Allow testing through /component-test for projects having `it` folders
[
https://issues.apache.org/jira/browse/CAMEL-20296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicolas Filotto resolved CAMEL-20296.
-
Resolution: Fixed
> Allow testing through /component-test for projects having `it` folders
> --
>
> Key: CAMEL-20296
> URL: https://issues.apache.org/jira/browse/CAMEL-20296
> Project: Camel
> Issue Type: Task
> Components: camel-salesforce, camel-servicenow
>Affects Versions: 4.3.0
>Reporter: Aurélien Pupier
>Assignee: Nicolas Filotto
>Priority: Minor
>
> The /component-test comment on PR is not working for some components. it
> seems that they have src/it folder in common
> {noformat}
> [ERROR] [ERROR] Could not find the selected project in the reactor:
> components/camel-salesforce/camel-salesforce-maven-plugin/src/it/customized-types
> @
> [ERROR] Could not find the selected project in the reactor:
> components/camel-salesforce/camel-salesforce-maven-plugin/src/it/customized-types
> -> [Help 1]
> org.apache.maven.MavenExecutionException: Could not find the selected project
> in the reactor:
> components/camel-salesforce/camel-salesforce-maven-plugin/src/it/customized-types
> at
> org.apache.maven.graph.DefaultGraphBuilder.trimSelectedProjects(DefaultGraphBuilder.java:148)
> at
> org.apache.maven.graph.DefaultGraphBuilder.reactorDependencyGraph(DefaultGraphBuilder.java:110)
> at
> org.apache.maven.graph.DefaultGraphBuilder.build(DefaultGraphBuilder.java:78)
> at org.apache.maven.DefaultMaven.buildGraph(DefaultMaven.java:448)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:197)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:173)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:101)
> at org.apache.maven.cli.DaemonMavenCli.execute(DaemonMavenCli.java:694)
> at org.apache.maven.cli.DaemonMavenCli.doMain(DaemonMavenCli.java:240)
> at org.apache.maven.cli.DaemonMavenCli.main(DaemonMavenCli.java:217)
> at org.mvndaemon.mvnd.daemon.Server.handle(Server.java:612)
> at org.mvndaemon.mvnd.daemon.Server.client(Server.java:288)
> at org.mvndaemon.mvnd.daemon.Server.lambda$accept$2(Server.java:250)
> at java.base/java.lang.Thread.run(Thread.java:840)
> {noformat}
> {noformat}
> [ERROR] [ERROR] Could not find the selected project in the reactor:
> components/camel-servicenow/camel-servicenow-maven-plugin/src/it/simple-it @
> [ERROR] Could not find the selected project in the reactor:
> components/camel-servicenow/camel-servicenow-maven-plugin/src/it/simple-it ->
> [Help 1]
> org.apache.maven.MavenExecutionException: Could not find the selected project
> in the reactor:
> components/camel-servicenow/camel-servicenow-maven-plugin/src/it/simple-it
> at
> org.apache.maven.graph.DefaultGraphBuilder.trimSelectedProjects(DefaultGraphBuilder.java:148)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-20296) Allow testing through /component-test for projects having `it` folders
[
https://issues.apache.org/jira/browse/CAMEL-20296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicolas Filotto updated CAMEL-20296:
Fix Version/s: 4.4.0
> Allow testing through /component-test for projects having `it` folders
> --
>
> Key: CAMEL-20296
> URL: https://issues.apache.org/jira/browse/CAMEL-20296
> Project: Camel
> Issue Type: Task
> Components: camel-salesforce, camel-servicenow
>Affects Versions: 4.3.0
>Reporter: Aurélien Pupier
>Assignee: Nicolas Filotto
>Priority: Minor
> Fix For: 4.4.0
>
>
> The /component-test comment on PR is not working for some components. it
> seems that they have src/it folder in common
> {noformat}
> [ERROR] [ERROR] Could not find the selected project in the reactor:
> components/camel-salesforce/camel-salesforce-maven-plugin/src/it/customized-types
> @
> [ERROR] Could not find the selected project in the reactor:
> components/camel-salesforce/camel-salesforce-maven-plugin/src/it/customized-types
> -> [Help 1]
> org.apache.maven.MavenExecutionException: Could not find the selected project
> in the reactor:
> components/camel-salesforce/camel-salesforce-maven-plugin/src/it/customized-types
> at
> org.apache.maven.graph.DefaultGraphBuilder.trimSelectedProjects(DefaultGraphBuilder.java:148)
> at
> org.apache.maven.graph.DefaultGraphBuilder.reactorDependencyGraph(DefaultGraphBuilder.java:110)
> at
> org.apache.maven.graph.DefaultGraphBuilder.build(DefaultGraphBuilder.java:78)
> at org.apache.maven.DefaultMaven.buildGraph(DefaultMaven.java:448)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:197)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:173)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:101)
> at org.apache.maven.cli.DaemonMavenCli.execute(DaemonMavenCli.java:694)
> at org.apache.maven.cli.DaemonMavenCli.doMain(DaemonMavenCli.java:240)
> at org.apache.maven.cli.DaemonMavenCli.main(DaemonMavenCli.java:217)
> at org.mvndaemon.mvnd.daemon.Server.handle(Server.java:612)
> at org.mvndaemon.mvnd.daemon.Server.client(Server.java:288)
> at org.mvndaemon.mvnd.daemon.Server.lambda$accept$2(Server.java:250)
> at java.base/java.lang.Thread.run(Thread.java:840)
> {noformat}
> {noformat}
> [ERROR] [ERROR] Could not find the selected project in the reactor:
> components/camel-servicenow/camel-servicenow-maven-plugin/src/it/simple-it @
> [ERROR] Could not find the selected project in the reactor:
> components/camel-servicenow/camel-servicenow-maven-plugin/src/it/simple-it ->
> [Help 1]
> org.apache.maven.MavenExecutionException: Could not find the selected project
> in the reactor:
> components/camel-servicenow/camel-servicenow-maven-plugin/src/it/simple-it
> at
> org.apache.maven.graph.DefaultGraphBuilder.trimSelectedProjects(DefaultGraphBuilder.java:148)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (CAMEL-20296) Allow testing through /component-test for projects having `it` folders
[
https://issues.apache.org/jira/browse/CAMEL-20296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicolas Filotto reassigned CAMEL-20296:
---
Assignee: Nicolas Filotto
> Allow testing through /component-test for projects having `it` folders
> --
>
> Key: CAMEL-20296
> URL: https://issues.apache.org/jira/browse/CAMEL-20296
> Project: Camel
> Issue Type: Task
> Components: camel-salesforce, camel-servicenow
>Affects Versions: 4.3.0
>Reporter: Aurélien Pupier
>Assignee: Nicolas Filotto
>Priority: Minor
>
> The /component-test comment on PR is not working for some components. it
> seems that they have src/it folder in common
> {noformat}
> [ERROR] [ERROR] Could not find the selected project in the reactor:
> components/camel-salesforce/camel-salesforce-maven-plugin/src/it/customized-types
> @
> [ERROR] Could not find the selected project in the reactor:
> components/camel-salesforce/camel-salesforce-maven-plugin/src/it/customized-types
> -> [Help 1]
> org.apache.maven.MavenExecutionException: Could not find the selected project
> in the reactor:
> components/camel-salesforce/camel-salesforce-maven-plugin/src/it/customized-types
> at
> org.apache.maven.graph.DefaultGraphBuilder.trimSelectedProjects(DefaultGraphBuilder.java:148)
> at
> org.apache.maven.graph.DefaultGraphBuilder.reactorDependencyGraph(DefaultGraphBuilder.java:110)
> at
> org.apache.maven.graph.DefaultGraphBuilder.build(DefaultGraphBuilder.java:78)
> at org.apache.maven.DefaultMaven.buildGraph(DefaultMaven.java:448)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:197)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:173)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:101)
> at org.apache.maven.cli.DaemonMavenCli.execute(DaemonMavenCli.java:694)
> at org.apache.maven.cli.DaemonMavenCli.doMain(DaemonMavenCli.java:240)
> at org.apache.maven.cli.DaemonMavenCli.main(DaemonMavenCli.java:217)
> at org.mvndaemon.mvnd.daemon.Server.handle(Server.java:612)
> at org.mvndaemon.mvnd.daemon.Server.client(Server.java:288)
> at org.mvndaemon.mvnd.daemon.Server.lambda$accept$2(Server.java:250)
> at java.base/java.lang.Thread.run(Thread.java:840)
> {noformat}
> {noformat}
> [ERROR] [ERROR] Could not find the selected project in the reactor:
> components/camel-servicenow/camel-servicenow-maven-plugin/src/it/simple-it @
> [ERROR] Could not find the selected project in the reactor:
> components/camel-servicenow/camel-servicenow-maven-plugin/src/it/simple-it ->
> [Help 1]
> org.apache.maven.MavenExecutionException: Could not find the selected project
> in the reactor:
> components/camel-servicenow/camel-servicenow-maven-plugin/src/it/simple-it
> at
> org.apache.maven.graph.DefaultGraphBuilder.trimSelectedProjects(DefaultGraphBuilder.java:148)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-20187) Add basic support of virtual threads
[ https://issues.apache.org/jira/browse/CAMEL-20187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17793742#comment-17793742 ] Nicolas Filotto commented on CAMEL-20187: - Here it is https://issues.apache.org/jira/browse/CAMEL-20199 > Add basic support of virtual threads > > > Key: CAMEL-20187 > URL: https://issues.apache.org/jira/browse/CAMEL-20187 > Project: Camel > Issue Type: New Feature >Reporter: Nicolas Filotto >Assignee: Nicolas Filotto >Priority: Major > Fix For: 4.3.0 > > > The idea is to provide basic support for virtual threads. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-20199) Complete support of Virtual Threads
[
https://issues.apache.org/jira/browse/CAMEL-20199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicolas Filotto updated CAMEL-20199:
Description:
For full support of Virtual Threads, several sub-tasks need to be done:
* Avoid Lengthy and Frequent Pinning by replacing synchronized blocks with
ReentrantLocks (use the option {{-Djdk.tracePinnedThreads=ful}} to print stack
traces when a thread blocks while pinned)
* Don't Cache Expensive Reusable Objects in Thread-Local Variables by avoiding
thread locals when possible since when using Virtual Threads, the objects will
never be reused so if the thread-local variables are never reset, it will end
up with an OOME.
* Use Semaphores to Limit Concurrency instead of relying on the size of the
thread pool when applicable
* Allow to expose {{ThreadPerTaskExecutor}} through JMX indeed so far it is
limited to {{ThreadPoolExecutor}}
References https://docs.oracle.com/en/java/javase/21/core/virtual-threads.html
was:
For a full support of Virtual Threads, several sub-tasks need to be done:
* Avoid Lengthy and Frequent Pinning by replacing synchronized blocks with
ReentrantLocks (use the option {{-Djdk.tracePinnedThreads=ful}} to print stack
traces when thread block while pinned)
* Don't Cache Expensive Reusable Objects in Thread-Local Variables by avoiding
thread locals when possible since when using Virtual Threads, the objects will
never be reused so if the thread-local variables are never reset, it will end
up with an OOME.
* Use Semaphores to Limit Concurrency instead of relying on the size of the
thread pool when applicable
* Allow to expose {{ThreadPerTaskExecutor}} through JMX indeed so far it is
limited to {{ThreadPoolExecutor}}
References https://docs.oracle.com/en/java/javase/21/core/virtual-threads.html
> Complete support of Virtual Threads
> ---
>
> Key: CAMEL-20199
> URL: https://issues.apache.org/jira/browse/CAMEL-20199
> Project: Camel
> Issue Type: Improvement
> Components: came-core
>Reporter: Nicolas Filotto
>Priority: Major
>
> For full support of Virtual Threads, several sub-tasks need to be done:
> * Avoid Lengthy and Frequent Pinning by replacing synchronized blocks with
> ReentrantLocks (use the option {{-Djdk.tracePinnedThreads=ful}} to print
> stack traces when a thread blocks while pinned)
> * Don't Cache Expensive Reusable Objects in Thread-Local Variables by
> avoiding thread locals when possible since when using Virtual Threads, the
> objects will never be reused so if the thread-local variables are never
> reset, it will end up with an OOME.
> * Use Semaphores to Limit Concurrency instead of relying on the size of the
> thread pool when applicable
> * Allow to expose {{ThreadPerTaskExecutor}} through JMX indeed so far it is
> limited to {{ThreadPoolExecutor}}
> References https://docs.oracle.com/en/java/javase/21/core/virtual-threads.html
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAMEL-20199) Complete support of Virtual Threads
Nicolas Filotto created CAMEL-20199:
---
Summary: Complete support of Virtual Threads
Key: CAMEL-20199
URL: https://issues.apache.org/jira/browse/CAMEL-20199
Project: Camel
Issue Type: Improvement
Components: came-core
Reporter: Nicolas Filotto
For a full support of Virtual Threads, several sub-tasks need to be done:
* Avoid Lengthy and Frequent Pinning by replacing synchronized blocks with
ReentrantLocks (use the option {{-Djdk.tracePinnedThreads=ful}} to print stack
traces when thread block while pinned)
* Don't Cache Expensive Reusable Objects in Thread-Local Variables by avoiding
thread locals when possible since when using Virtual Threads, the objects will
never be reused so if the thread-local variables are never reset, it will end
up with an OOME.
* Use Semaphores to Limit Concurrency instead of relying on the size of the
thread pool when applicable
* Allow to expose {{ThreadPerTaskExecutor}} through JMX indeed so far it is
limited to {{ThreadPoolExecutor}}
References https://docs.oracle.com/en/java/javase/21/core/virtual-threads.html
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-20187) Add basic support of virtual threads
[ https://issues.apache.org/jira/browse/CAMEL-20187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17793660#comment-17793660 ] Nicolas Filotto commented on CAMEL-20187: - The corresponding PR https://github.com/apache/camel/pull/12292. Let's wait for the result of a Jenkins build before merging it Note that It doesn't cover the replacement of synchronized blocks with reentrant locks nor the review of all thread locals. > Add basic support of virtual threads > > > Key: CAMEL-20187 > URL: https://issues.apache.org/jira/browse/CAMEL-20187 > Project: Camel > Issue Type: New Feature >Reporter: Nicolas Filotto >Assignee: Nicolas Filotto >Priority: Major > Fix For: 4.3.0 > > > The idea is to provide basic support for virtual threads. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-20187) Add basic support of virtual threads
Nicolas Filotto created CAMEL-20187: --- Summary: Add basic support of virtual threads Key: CAMEL-20187 URL: https://issues.apache.org/jira/browse/CAMEL-20187 Project: Camel Issue Type: New Feature Reporter: Nicolas Filotto Assignee: Nicolas Filotto Fix For: 4.3.0 The idea is to provide basic support for virtual threads. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-20152) camel-jetty - OutOfMemoryError with big file upload via multipart
[
https://issues.apache.org/jira/browse/CAMEL-20152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicolas Filotto resolved CAMEL-20152.
-
Fix Version/s: 3.20.9
3.21.3
3.22.0
4.0.4
4.3.0
Resolution: Fixed
> camel-jetty - OutOfMemoryError with big file upload via multipart
> -
>
> Key: CAMEL-20152
> URL: https://issues.apache.org/jira/browse/CAMEL-20152
> Project: Camel
> Issue Type: Bug
> Components: camel-jetty
>Affects Versions: 3.21.2
>Reporter: michael elbaz
>Assignee: Nicolas Filotto
>Priority: Major
> Fix For: 3.20.9, 3.21.3, 3.22.0, 4.0.4, 4.3.0
>
> Attachments: image-2023-11-28-09-12-11-951.png
>
>
> I don't now if is related to jetty (maybe) but when i use camel with jetty
> and i upload a big file using multipart i get:
> {code:java}
> // espace r23:28:50.262 WARN [qtp1616084922-291] /email/myservice
> java.lang.IllegalStateException: java.lang.OutOfMemoryError: Java heap space
> at
> org.eclipse.jetty.http.MultiPartFormInputStream.throwIfError(MultiPartFormInputStream.java:517)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.http.MultiPartFormInputStream.getParts(MultiPartFormInputStream.java:470)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.MultiParts$MultiPartsHttpParser.getParts(MultiParts.java:74)
> ~[!/:9.4.52.v20230823]
> at org.eclipse.jetty.server.Request.getParts(Request.java:2450)
> ~[!/:9.4.52.v20230823]
> at org.eclipse.jetty.server.Request.getParts(Request.java:2420)
> ~[!/:9.4.52.v20230823]
> at
> org.apache.camel.component.jetty.MultiPartFilter.doFilter(MultiPartFilter.java:52)
> ~[?:?]
> at
> org.apache.camel.component.jetty.CamelFilterWrapper.doFilter(CamelFilterWrapper.java:49)
> ~[?:?]
> at
> org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:193) ~[?:?]
> at
> org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1626)
> ~[?:?]
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:552)
> ~[?:?]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1440)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:505)
> ~[?:?]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1355)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> ~[!/:9.4.52.v20230823]
> at org.eclipse.jetty.server.Server.handle(Server.java:516)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:487)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:732)
> ~[!/:9.4.52.v20230823]
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:479)
> [!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:277)
> [!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
> [!/:9.4.52.v20230823]
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105)
> [!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.io.ChannelEndPoint$1.run(ChannelEndPoint.java:104)
> [!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:883)
> [!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1034)
> [!/:9.4.52.v20230823]
> at java.lang.Thread.run(Thread.java:833) [?:?]
> Caused by: java.lang.OutOfMemoryError: Java heap space
> at java.util.Arrays.copyOf(Arrays.java:3537) ~[?:?]
> at
> java.io.ByteArrayOutputStream.ensureCapacity(ByteArrayOutputStream.java:100)
> ~[?:?]
> at
> java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:130) ~[?:?]
> at
> org.eclipse.jetty.http.MultiPartFormInputStream$MultiPart.write(MultiPartFormInputStream.java:178)
> ~[!/:9.4.52.v20230823]
> at
> or
[jira] [Commented] (CAMEL-20152) camel-jetty - OutOfMemoryError with big file upload via multipart
[
https://issues.apache.org/jira/browse/CAMEL-20152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17791015#comment-17791015
]
Nicolas Filotto commented on CAMEL-20152:
-
The corresponding PRs:
* 4.3 https://github.com/apache/camel/pull/12240 (bug fixed by configuration)
* 3.22 https://github.com/apache/camel/pull/12249 (bug fixed by configuration)
* 3.21 https://github.com/apache/camel/pull/12252 (bug fixed by using a default
threshold)
* 3.20 https://github.com/apache/camel/pull/12255 (bug fixed by using a default
threshold)
* 4.0 https://github.com/apache/camel/pull/12256 (bug fixed by using a default
threshold)
> camel-jetty - OutOfMemoryError with big file upload via multipart
> -
>
> Key: CAMEL-20152
> URL: https://issues.apache.org/jira/browse/CAMEL-20152
> Project: Camel
> Issue Type: Bug
> Components: camel-jetty
>Affects Versions: 3.21.2
>Reporter: michael elbaz
>Assignee: Nicolas Filotto
>Priority: Major
> Attachments: image-2023-11-28-09-12-11-951.png
>
>
> I don't now if is related to jetty (maybe) but when i use camel with jetty
> and i upload a big file using multipart i get:
> {code:java}
> // espace r23:28:50.262 WARN [qtp1616084922-291] /email/myservice
> java.lang.IllegalStateException: java.lang.OutOfMemoryError: Java heap space
> at
> org.eclipse.jetty.http.MultiPartFormInputStream.throwIfError(MultiPartFormInputStream.java:517)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.http.MultiPartFormInputStream.getParts(MultiPartFormInputStream.java:470)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.MultiParts$MultiPartsHttpParser.getParts(MultiParts.java:74)
> ~[!/:9.4.52.v20230823]
> at org.eclipse.jetty.server.Request.getParts(Request.java:2450)
> ~[!/:9.4.52.v20230823]
> at org.eclipse.jetty.server.Request.getParts(Request.java:2420)
> ~[!/:9.4.52.v20230823]
> at
> org.apache.camel.component.jetty.MultiPartFilter.doFilter(MultiPartFilter.java:52)
> ~[?:?]
> at
> org.apache.camel.component.jetty.CamelFilterWrapper.doFilter(CamelFilterWrapper.java:49)
> ~[?:?]
> at
> org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:193) ~[?:?]
> at
> org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1626)
> ~[?:?]
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:552)
> ~[?:?]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1440)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:505)
> ~[?:?]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1355)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> ~[!/:9.4.52.v20230823]
> at org.eclipse.jetty.server.Server.handle(Server.java:516)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:487)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:732)
> ~[!/:9.4.52.v20230823]
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:479)
> [!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:277)
> [!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
> [!/:9.4.52.v20230823]
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105)
> [!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.io.ChannelEndPoint$1.run(ChannelEndPoint.java:104)
> [!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:883)
> [!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1034)
> [!/:9.4.52.v20230823]
> at java.lang.Thread.run(Thread.java:833) [?:?]
> Caused by: java.lang.OutOfMemoryError: Java heap space
> at java.util.Arrays.copyOf(Arrays.java:3537) ~[?:?]
> at
> java.io.ByteArrayOutputStream.ensureCapa
[jira] [Comment Edited] (CAMEL-20152) camel-jetty - OutOfMemoryError with big file upload via multipart
[
https://issues.apache.org/jira/browse/CAMEL-20152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17790617#comment-17790617
]
Nicolas Filotto edited comment on CAMEL-20152 at 11/29/23 10:35 AM:
[~acosentino] I don't know what you think of the fix proposal but I think that
it could be backported into the 3.x branch. For 3.20 and 3.21, what I can
propose as a fix is to simply set {{fileSizeThreshold}} to a different default
value, high enough to limit the regressions but not too high to avoid OOME,
something like 10 MB, WDYT?
was (Author: JIRAUSER285918):
[~acosentino] I don't know what you think of the fix proposal but I think that
it could be backported into the 3.x branch. For 3.20 and 3.21, what I can
propose as a fix is to simply set {{fileSizeThreshold}} to a different default
value, high enough to limit the regressions but not too high to avoid OOME,
something like 10 Mbs, WDYT?
> camel-jetty - OutOfMemoryError with big file upload via multipart
> -
>
> Key: CAMEL-20152
> URL: https://issues.apache.org/jira/browse/CAMEL-20152
> Project: Camel
> Issue Type: Bug
> Components: camel-jetty
>Affects Versions: 3.21.2
>Reporter: michael elbaz
>Assignee: Nicolas Filotto
>Priority: Major
> Attachments: image-2023-11-28-09-12-11-951.png
>
>
> I don't now if is related to jetty (maybe) but when i use camel with jetty
> and i upload a big file using multipart i get:
> {code:java}
> // espace r23:28:50.262 WARN [qtp1616084922-291] /email/myservice
> java.lang.IllegalStateException: java.lang.OutOfMemoryError: Java heap space
> at
> org.eclipse.jetty.http.MultiPartFormInputStream.throwIfError(MultiPartFormInputStream.java:517)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.http.MultiPartFormInputStream.getParts(MultiPartFormInputStream.java:470)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.MultiParts$MultiPartsHttpParser.getParts(MultiParts.java:74)
> ~[!/:9.4.52.v20230823]
> at org.eclipse.jetty.server.Request.getParts(Request.java:2450)
> ~[!/:9.4.52.v20230823]
> at org.eclipse.jetty.server.Request.getParts(Request.java:2420)
> ~[!/:9.4.52.v20230823]
> at
> org.apache.camel.component.jetty.MultiPartFilter.doFilter(MultiPartFilter.java:52)
> ~[?:?]
> at
> org.apache.camel.component.jetty.CamelFilterWrapper.doFilter(CamelFilterWrapper.java:49)
> ~[?:?]
> at
> org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:193) ~[?:?]
> at
> org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1626)
> ~[?:?]
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:552)
> ~[?:?]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1440)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:505)
> ~[?:?]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1355)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> ~[!/:9.4.52.v20230823]
> at org.eclipse.jetty.server.Server.handle(Server.java:516)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:487)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:732)
> ~[!/:9.4.52.v20230823]
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:479)
> [!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:277)
> [!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
> [!/:9.4.52.v20230823]
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105)
> [!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.io.ChannelEndPoint$1.run(ChannelEndPoint.java:104)
> [!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:883)
> [!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.util.thread.Que
[jira] [Commented] (CAMEL-20152) camel-jetty - OutOfMemoryError with big file upload via multipart
[
https://issues.apache.org/jira/browse/CAMEL-20152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17790727#comment-17790727
]
Nicolas Filotto commented on CAMEL-20152:
-
The corresponding ticket in the Jetty project
https://github.com/jetty/jetty.project/issues/10936
> camel-jetty - OutOfMemoryError with big file upload via multipart
> -
>
> Key: CAMEL-20152
> URL: https://issues.apache.org/jira/browse/CAMEL-20152
> Project: Camel
> Issue Type: Bug
> Components: camel-jetty
>Affects Versions: 3.21.2
>Reporter: michael elbaz
>Assignee: Nicolas Filotto
>Priority: Major
> Attachments: image-2023-11-28-09-12-11-951.png
>
>
> I don't now if is related to jetty (maybe) but when i use camel with jetty
> and i upload a big file using multipart i get:
> {code:java}
> // espace r23:28:50.262 WARN [qtp1616084922-291] /email/myservice
> java.lang.IllegalStateException: java.lang.OutOfMemoryError: Java heap space
> at
> org.eclipse.jetty.http.MultiPartFormInputStream.throwIfError(MultiPartFormInputStream.java:517)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.http.MultiPartFormInputStream.getParts(MultiPartFormInputStream.java:470)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.MultiParts$MultiPartsHttpParser.getParts(MultiParts.java:74)
> ~[!/:9.4.52.v20230823]
> at org.eclipse.jetty.server.Request.getParts(Request.java:2450)
> ~[!/:9.4.52.v20230823]
> at org.eclipse.jetty.server.Request.getParts(Request.java:2420)
> ~[!/:9.4.52.v20230823]
> at
> org.apache.camel.component.jetty.MultiPartFilter.doFilter(MultiPartFilter.java:52)
> ~[?:?]
> at
> org.apache.camel.component.jetty.CamelFilterWrapper.doFilter(CamelFilterWrapper.java:49)
> ~[?:?]
> at
> org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:193) ~[?:?]
> at
> org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1626)
> ~[?:?]
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:552)
> ~[?:?]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1440)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:505)
> ~[?:?]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1355)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> ~[!/:9.4.52.v20230823]
> at org.eclipse.jetty.server.Server.handle(Server.java:516)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:487)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:732)
> ~[!/:9.4.52.v20230823]
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:479)
> [!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:277)
> [!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
> [!/:9.4.52.v20230823]
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105)
> [!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.io.ChannelEndPoint$1.run(ChannelEndPoint.java:104)
> [!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:883)
> [!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1034)
> [!/:9.4.52.v20230823]
> at java.lang.Thread.run(Thread.java:833) [?:?]
> Caused by: java.lang.OutOfMemoryError: Java heap space
> at java.util.Arrays.copyOf(Arrays.java:3537) ~[?:?]
> at
> java.io.ByteArrayOutputStream.ensureCapacity(ByteArrayOutputStream.java:100)
> ~[?:?]
> at
> java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:130) ~[?:?]
> at
> org.eclipse.jetty.http.MultiPartFormInputStream$MultiPart.write(MultiPartFormInputStream.java:178)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.http.MultiPartFormInputStream$Handler.conten
[jira] [Comment Edited] (CAMEL-20152) camel-jetty - OutOfMemoryError with big file upload via multipart
[
https://issues.apache.org/jira/browse/CAMEL-20152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17790605#comment-17790605
]
Nicolas Filotto edited comment on CAMEL-20152 at 11/28/23 4:42 PM:
---
Here is the PR [https://github.com/apache/camel/pull/12240]
After a deeper analysis, it is due to the fact that the [{{fileSizeThreshold}}
is set to
0|https://github.com/apache/camel/blob/main/components/camel-jetty-common/src/main/java/org/apache/camel/component/jetty/JettyHttpComponent.java#L1153]
by default to have the content stored on disk like [it is mentioned in the
Jakarta
Javadoc|https://github.com/jakartaee/servlet/blob/master/api/src/main/java/jakarta/servlet/MultipartConfigElement.java#L109-L110]
but it is not what the Jetty code does, indeed the [Jetty code expects a value
strictly higher than
0|https://github.com/jetty/jetty.project/blob/jetty-11.0.x/jetty-server/src/main/java/org/eclipse/jetty/server/MultiPartFormInputStream.java#L188].
was (Author: JIRAUSER285918):
Here is the PR [https://github.com/apache/camel/pull/12240]
After a deeper analysis, it is due to the fact that the [{{fileSizeThreshold}}
is set to
0|https://github.com/apache/camel/blob/main/components/camel-jetty-common/src/main/java/org/apache/camel/component/jetty/JettyHttpComponent.java#L1153]
by default to have the content stored on disk like it is mentioned in the
Jetty Javadoc but it is not what the Jetty code does, indeed the [Jetty code
expects a value strictly higher than
0|https://github.com/jetty/jetty.project/blob/jetty-11.0.x/jetty-server/src/main/java/org/eclipse/jetty/server/MultiPartFormInputStream.java#L188].
> camel-jetty - OutOfMemoryError with big file upload via multipart
> -
>
> Key: CAMEL-20152
> URL: https://issues.apache.org/jira/browse/CAMEL-20152
> Project: Camel
> Issue Type: Bug
> Components: camel-jetty
>Affects Versions: 3.21.2
>Reporter: michael elbaz
>Assignee: Nicolas Filotto
>Priority: Major
> Attachments: image-2023-11-28-09-12-11-951.png
>
>
> I don't now if is related to jetty (maybe) but when i use camel with jetty
> and i upload a big file using multipart i get:
> {code:java}
> // espace r23:28:50.262 WARN [qtp1616084922-291] /email/myservice
> java.lang.IllegalStateException: java.lang.OutOfMemoryError: Java heap space
> at
> org.eclipse.jetty.http.MultiPartFormInputStream.throwIfError(MultiPartFormInputStream.java:517)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.http.MultiPartFormInputStream.getParts(MultiPartFormInputStream.java:470)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.MultiParts$MultiPartsHttpParser.getParts(MultiParts.java:74)
> ~[!/:9.4.52.v20230823]
> at org.eclipse.jetty.server.Request.getParts(Request.java:2450)
> ~[!/:9.4.52.v20230823]
> at org.eclipse.jetty.server.Request.getParts(Request.java:2420)
> ~[!/:9.4.52.v20230823]
> at
> org.apache.camel.component.jetty.MultiPartFilter.doFilter(MultiPartFilter.java:52)
> ~[?:?]
> at
> org.apache.camel.component.jetty.CamelFilterWrapper.doFilter(CamelFilterWrapper.java:49)
> ~[?:?]
> at
> org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:193) ~[?:?]
> at
> org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1626)
> ~[?:?]
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:552)
> ~[?:?]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1440)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:505)
> ~[?:?]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1355)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> ~[!/:9.4.52.v20230823]
> at org.eclipse.jetty.server.Server.handle(Server.java:516)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:487)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:732)
> ~[!/:9.4.52.v20230823]
>
[jira] [Comment Edited] (CAMEL-20152) camel-jetty - OutOfMemoryError with big file upload via multipart
[
https://issues.apache.org/jira/browse/CAMEL-20152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17790617#comment-17790617
]
Nicolas Filotto edited comment on CAMEL-20152 at 11/28/23 3:01 PM:
---
[~acosentino] I don't know what you think of the fix proposal but I think that
it could be backported into the 3.x branch. For 3.20 and 3.21, what I can
propose as a fix is to simply set {{fileSizeThreshold}} to a different default
value, high enough to limit the regressions but not too high to avoid OOME,
something like 10 Mbs, WDYT?
was (Author: JIRAUSER285918):
[~acosentino] I don't know what you think of the fix proposal but I think that
it could be backported into the 3.x branch. For 3.20 and 3.21, what I can
propose as fix is to simply set {{fileSizeThreshold}} to a different default
value, high enough to limit the regressions but not to high to avoid OOME,
something like 10 Mbs, WDYT?
> camel-jetty - OutOfMemoryError with big file upload via multipart
> -
>
> Key: CAMEL-20152
> URL: https://issues.apache.org/jira/browse/CAMEL-20152
> Project: Camel
> Issue Type: Bug
> Components: camel-jetty
>Affects Versions: 3.21.2
>Reporter: michael elbaz
>Assignee: Nicolas Filotto
>Priority: Major
> Attachments: image-2023-11-28-09-12-11-951.png
>
>
> I don't now if is related to jetty (maybe) but when i use camel with jetty
> and i upload a big file using multipart i get:
> {code:java}
> // espace r23:28:50.262 WARN [qtp1616084922-291] /email/myservice
> java.lang.IllegalStateException: java.lang.OutOfMemoryError: Java heap space
> at
> org.eclipse.jetty.http.MultiPartFormInputStream.throwIfError(MultiPartFormInputStream.java:517)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.http.MultiPartFormInputStream.getParts(MultiPartFormInputStream.java:470)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.MultiParts$MultiPartsHttpParser.getParts(MultiParts.java:74)
> ~[!/:9.4.52.v20230823]
> at org.eclipse.jetty.server.Request.getParts(Request.java:2450)
> ~[!/:9.4.52.v20230823]
> at org.eclipse.jetty.server.Request.getParts(Request.java:2420)
> ~[!/:9.4.52.v20230823]
> at
> org.apache.camel.component.jetty.MultiPartFilter.doFilter(MultiPartFilter.java:52)
> ~[?:?]
> at
> org.apache.camel.component.jetty.CamelFilterWrapper.doFilter(CamelFilterWrapper.java:49)
> ~[?:?]
> at
> org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:193) ~[?:?]
> at
> org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1626)
> ~[?:?]
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:552)
> ~[?:?]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1440)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:505)
> ~[?:?]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1355)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> ~[!/:9.4.52.v20230823]
> at org.eclipse.jetty.server.Server.handle(Server.java:516)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:487)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:732)
> ~[!/:9.4.52.v20230823]
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:479)
> [!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:277)
> [!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
> [!/:9.4.52.v20230823]
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105)
> [!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.io.ChannelEndPoint$1.run(ChannelEndPoint.java:104)
> [!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:883)
> [!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.util.thread.QueuedT
[jira] [Commented] (CAMEL-20152) camel-jetty - OutOfMemoryError with big file upload via multipart
[
https://issues.apache.org/jira/browse/CAMEL-20152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17790617#comment-17790617
]
Nicolas Filotto commented on CAMEL-20152:
-
[~acosentino] I don't know what you think of the fix proposal but I think that
it could be backported into the 3.x branch. For 3.20 and 3.21, what I can
propose as fix is to simply set {{fileSizeThreshold}} to a different default
value, high enough to limit the regressions but not to high to avoid OOME,
something like 10 Mbs, WDYT?
> camel-jetty - OutOfMemoryError with big file upload via multipart
> -
>
> Key: CAMEL-20152
> URL: https://issues.apache.org/jira/browse/CAMEL-20152
> Project: Camel
> Issue Type: Bug
> Components: camel-jetty
>Affects Versions: 3.21.2
>Reporter: michael elbaz
>Assignee: Nicolas Filotto
>Priority: Major
> Attachments: image-2023-11-28-09-12-11-951.png
>
>
> I don't now if is related to jetty (maybe) but when i use camel with jetty
> and i upload a big file using multipart i get:
> {code:java}
> // espace r23:28:50.262 WARN [qtp1616084922-291] /email/myservice
> java.lang.IllegalStateException: java.lang.OutOfMemoryError: Java heap space
> at
> org.eclipse.jetty.http.MultiPartFormInputStream.throwIfError(MultiPartFormInputStream.java:517)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.http.MultiPartFormInputStream.getParts(MultiPartFormInputStream.java:470)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.MultiParts$MultiPartsHttpParser.getParts(MultiParts.java:74)
> ~[!/:9.4.52.v20230823]
> at org.eclipse.jetty.server.Request.getParts(Request.java:2450)
> ~[!/:9.4.52.v20230823]
> at org.eclipse.jetty.server.Request.getParts(Request.java:2420)
> ~[!/:9.4.52.v20230823]
> at
> org.apache.camel.component.jetty.MultiPartFilter.doFilter(MultiPartFilter.java:52)
> ~[?:?]
> at
> org.apache.camel.component.jetty.CamelFilterWrapper.doFilter(CamelFilterWrapper.java:49)
> ~[?:?]
> at
> org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:193) ~[?:?]
> at
> org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1626)
> ~[?:?]
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:552)
> ~[?:?]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1440)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:505)
> ~[?:?]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1355)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> ~[!/:9.4.52.v20230823]
> at org.eclipse.jetty.server.Server.handle(Server.java:516)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:487)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:732)
> ~[!/:9.4.52.v20230823]
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:479)
> [!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:277)
> [!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
> [!/:9.4.52.v20230823]
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105)
> [!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.io.ChannelEndPoint$1.run(ChannelEndPoint.java:104)
> [!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:883)
> [!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1034)
> [!/:9.4.52.v20230823]
> at java.lang.Thread.run(Thread.java:833) [?:?]
> Caused by: java.lang.OutOfMemoryError: Java heap space
> at java.util.Arrays.copyOf(Arrays.java:3537) ~[?:?]
> at
> java.io.ByteArrayOutputStream.ensureCapacity(ByteArrayOutputStream.java:100)
> ~[?:?]
> at
> java.io.ByteArrayOutputStream.write(ByteArrayOutputStre
[jira] [Comment Edited] (CAMEL-20152) camel-jetty - OutOfMemoryError with big file upload via multipart
[
https://issues.apache.org/jira/browse/CAMEL-20152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17790605#comment-17790605
]
Nicolas Filotto edited comment on CAMEL-20152 at 11/28/23 2:55 PM:
---
Here is the PR [https://github.com/apache/camel/pull/12240]
After a deeper analysis, it is due to the fact that the [{{fileSizeThreshold}}
is set to
0|https://github.com/apache/camel/blob/main/components/camel-jetty-common/src/main/java/org/apache/camel/component/jetty/JettyHttpComponent.java#L1153]
by default to have the content stored on disk like it is mentioned in the
Jetty Javadoc but it is not what the Jetty code does, indeed the [Jetty code
expects a value strictly higher than
0|https://github.com/jetty/jetty.project/blob/jetty-11.0.x/jetty-server/src/main/java/org/eclipse/jetty/server/MultiPartFormInputStream.java#L188].
was (Author: JIRAUSER285918):
Here is the PR [https://github.com/apache/camel/pull/12240]
After a deeper analysis, it is due to the fact that the
{{{}{}}}[fileSizeThreshold is set to
0|https://github.com/apache/camel/blob/main/components/camel-jetty-common/src/main/java/org/apache/camel/component/jetty/JettyHttpComponent.java#L1153]
by default to have the content stored on disk like it is mentioned in the
Jetty Javadoc but it is not what the Jetty code does, indeed the [Jetty code
expects a value strictly higher than
0|https://github.com/jetty/jetty.project/blob/jetty-11.0.x/jetty-server/src/main/java/org/eclipse/jetty/server/MultiPartFormInputStream.java#L188].
> camel-jetty - OutOfMemoryError with big file upload via multipart
> -
>
> Key: CAMEL-20152
> URL: https://issues.apache.org/jira/browse/CAMEL-20152
> Project: Camel
> Issue Type: Bug
> Components: camel-jetty
>Affects Versions: 3.21.2
>Reporter: michael elbaz
>Assignee: Nicolas Filotto
>Priority: Major
> Attachments: image-2023-11-28-09-12-11-951.png
>
>
> I don't now if is related to jetty (maybe) but when i use camel with jetty
> and i upload a big file using multipart i get:
> {code:java}
> // espace r23:28:50.262 WARN [qtp1616084922-291] /email/myservice
> java.lang.IllegalStateException: java.lang.OutOfMemoryError: Java heap space
> at
> org.eclipse.jetty.http.MultiPartFormInputStream.throwIfError(MultiPartFormInputStream.java:517)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.http.MultiPartFormInputStream.getParts(MultiPartFormInputStream.java:470)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.MultiParts$MultiPartsHttpParser.getParts(MultiParts.java:74)
> ~[!/:9.4.52.v20230823]
> at org.eclipse.jetty.server.Request.getParts(Request.java:2450)
> ~[!/:9.4.52.v20230823]
> at org.eclipse.jetty.server.Request.getParts(Request.java:2420)
> ~[!/:9.4.52.v20230823]
> at
> org.apache.camel.component.jetty.MultiPartFilter.doFilter(MultiPartFilter.java:52)
> ~[?:?]
> at
> org.apache.camel.component.jetty.CamelFilterWrapper.doFilter(CamelFilterWrapper.java:49)
> ~[?:?]
> at
> org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:193) ~[?:?]
> at
> org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1626)
> ~[?:?]
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:552)
> ~[?:?]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1440)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:505)
> ~[?:?]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1355)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> ~[!/:9.4.52.v20230823]
> at org.eclipse.jetty.server.Server.handle(Server.java:516)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:487)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:732)
> ~[!/:9.4.52.v20230823]
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:479)
> [!/:9.4.52.v20230823]
> at
> org.ec
[jira] [Comment Edited] (CAMEL-20152) camel-jetty - OutOfMemoryError with big file upload via multipart
[
https://issues.apache.org/jira/browse/CAMEL-20152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17790605#comment-17790605
]
Nicolas Filotto edited comment on CAMEL-20152 at 11/28/23 2:54 PM:
---
Here is the PR [https://github.com/apache/camel/pull/12240]
After a deeper analysis, it is due to the fact that the
{{{}{}}}[fileSizeThreshold is set to
0|https://github.com/apache/camel/blob/main/components/camel-jetty-common/src/main/java/org/apache/camel/component/jetty/JettyHttpComponent.java#L1153]
by default to have the content stored on disk like it is mentioned in the
Jetty Javadoc but it is not what the Jetty code does, indeed the [Jetty code
expects a value strictly higher than
0|https://github.com/jetty/jetty.project/blob/jetty-11.0.x/jetty-server/src/main/java/org/eclipse/jetty/server/MultiPartFormInputStream.java#L188].
was (Author: JIRAUSER285918):
Here is the PR [https://github.com/apache/camel/pull/12240]
After a deeper analysis, it is due to the fact that the {{fileSizeThreshold}}
is set to 0 by default to have the content stored on disk like it is mentioned
in the Jetty Javadoc but it is not what the Jetty code does, indeed the Jetty
code expects a value strictly higher than 0.
> camel-jetty - OutOfMemoryError with big file upload via multipart
> -
>
> Key: CAMEL-20152
> URL: https://issues.apache.org/jira/browse/CAMEL-20152
> Project: Camel
> Issue Type: Bug
> Components: camel-jetty
>Affects Versions: 3.21.2
>Reporter: michael elbaz
>Assignee: Nicolas Filotto
>Priority: Major
> Attachments: image-2023-11-28-09-12-11-951.png
>
>
> I don't now if is related to jetty (maybe) but when i use camel with jetty
> and i upload a big file using multipart i get:
> {code:java}
> // espace r23:28:50.262 WARN [qtp1616084922-291] /email/myservice
> java.lang.IllegalStateException: java.lang.OutOfMemoryError: Java heap space
> at
> org.eclipse.jetty.http.MultiPartFormInputStream.throwIfError(MultiPartFormInputStream.java:517)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.http.MultiPartFormInputStream.getParts(MultiPartFormInputStream.java:470)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.MultiParts$MultiPartsHttpParser.getParts(MultiParts.java:74)
> ~[!/:9.4.52.v20230823]
> at org.eclipse.jetty.server.Request.getParts(Request.java:2450)
> ~[!/:9.4.52.v20230823]
> at org.eclipse.jetty.server.Request.getParts(Request.java:2420)
> ~[!/:9.4.52.v20230823]
> at
> org.apache.camel.component.jetty.MultiPartFilter.doFilter(MultiPartFilter.java:52)
> ~[?:?]
> at
> org.apache.camel.component.jetty.CamelFilterWrapper.doFilter(CamelFilterWrapper.java:49)
> ~[?:?]
> at
> org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:193) ~[?:?]
> at
> org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1626)
> ~[?:?]
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:552)
> ~[?:?]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1440)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:505)
> ~[?:?]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1355)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> ~[!/:9.4.52.v20230823]
> at org.eclipse.jetty.server.Server.handle(Server.java:516)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:487)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:732)
> ~[!/:9.4.52.v20230823]
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:479)
> [!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:277)
> [!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
> [!/:9.4.52.v20230823]
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java
[jira] [Comment Edited] (CAMEL-20152) camel-jetty - OutOfMemoryError with big file upload via multipart
[
https://issues.apache.org/jira/browse/CAMEL-20152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17790605#comment-17790605
]
Nicolas Filotto edited comment on CAMEL-20152 at 11/28/23 2:41 PM:
---
Here is the PR [https://github.com/apache/camel/pull/12240]
After a deeper analysis, it is due to the fact that the {{fileSizeThreshold}}
is set to 0 by default to have the content stored on disk like it is mentioned
in the Jetty Javadoc but it is not what the Jetty code does, indeed the Jetty
code expects a value strictly higher than 0.
was (Author: JIRAUSER285918):
Here is the PR [https://github.com/apache/camel/pull/12240]
After a deeper analysis, it is due to the fact that the {{fileSizeThreshold}}
is set to 0 by default to have the content stored on disk like it is mentioned
in the Jetty Javadoc but it is not what the Jetty does, indeed the Jetty code
expects a value strictly higher than 0.
> camel-jetty - OutOfMemoryError with big file upload via multipart
> -
>
> Key: CAMEL-20152
> URL: https://issues.apache.org/jira/browse/CAMEL-20152
> Project: Camel
> Issue Type: Bug
> Components: camel-jetty
>Affects Versions: 3.21.2
>Reporter: michael elbaz
>Assignee: Nicolas Filotto
>Priority: Major
> Attachments: image-2023-11-28-09-12-11-951.png
>
>
> I don't now if is related to jetty (maybe) but when i use camel with jetty
> and i upload a big file using multipart i get:
> {code:java}
> // espace r23:28:50.262 WARN [qtp1616084922-291] /email/myservice
> java.lang.IllegalStateException: java.lang.OutOfMemoryError: Java heap space
> at
> org.eclipse.jetty.http.MultiPartFormInputStream.throwIfError(MultiPartFormInputStream.java:517)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.http.MultiPartFormInputStream.getParts(MultiPartFormInputStream.java:470)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.MultiParts$MultiPartsHttpParser.getParts(MultiParts.java:74)
> ~[!/:9.4.52.v20230823]
> at org.eclipse.jetty.server.Request.getParts(Request.java:2450)
> ~[!/:9.4.52.v20230823]
> at org.eclipse.jetty.server.Request.getParts(Request.java:2420)
> ~[!/:9.4.52.v20230823]
> at
> org.apache.camel.component.jetty.MultiPartFilter.doFilter(MultiPartFilter.java:52)
> ~[?:?]
> at
> org.apache.camel.component.jetty.CamelFilterWrapper.doFilter(CamelFilterWrapper.java:49)
> ~[?:?]
> at
> org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:193) ~[?:?]
> at
> org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1626)
> ~[?:?]
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:552)
> ~[?:?]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1440)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:505)
> ~[?:?]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1355)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> ~[!/:9.4.52.v20230823]
> at org.eclipse.jetty.server.Server.handle(Server.java:516)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:487)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:732)
> ~[!/:9.4.52.v20230823]
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:479)
> [!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:277)
> [!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
> [!/:9.4.52.v20230823]
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105)
> [!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.io.ChannelEndPoint$1.run(ChannelEndPoint.java:104)
> [!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:883)
> [!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.util.thread.Q
[jira] [Comment Edited] (CAMEL-20152) camel-jetty - OutOfMemoryError with big file upload via multipart
[
https://issues.apache.org/jira/browse/CAMEL-20152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17790605#comment-17790605
]
Nicolas Filotto edited comment on CAMEL-20152 at 11/28/23 2:37 PM:
---
Here is the PR [https://github.com/apache/camel/pull/12240]
After a deeper analysis, it is due to the fact that the {{fileSizeThreshold}}
is set to 0 by default to have the content stored on disk like it is mentioned
in the Jetty Javadoc but it is not what the Jetty does, indeed the Jetty code
expects a value strictly higher than 0.
was (Author: JIRAUSER285918):
Here is the PR [https://github.com/apache/camel/pull/12240]
After a deeper analysis, it is due to the fact that the {{fileSizeThreshold}}
is set to 0 by default to have the content stored into disk like it is
mentioned in the Jetty Javadoc but it is not what the Jetty does, indeed the
Jetty code expects a value strictly higher than 0.
> camel-jetty - OutOfMemoryError with big file upload via multipart
> -
>
> Key: CAMEL-20152
> URL: https://issues.apache.org/jira/browse/CAMEL-20152
> Project: Camel
> Issue Type: Bug
> Components: camel-jetty
>Affects Versions: 3.21.2
>Reporter: michael elbaz
>Assignee: Nicolas Filotto
>Priority: Major
> Attachments: image-2023-11-28-09-12-11-951.png
>
>
> I don't now if is related to jetty (maybe) but when i use camel with jetty
> and i upload a big file using multipart i get:
> {code:java}
> // espace r23:28:50.262 WARN [qtp1616084922-291] /email/myservice
> java.lang.IllegalStateException: java.lang.OutOfMemoryError: Java heap space
> at
> org.eclipse.jetty.http.MultiPartFormInputStream.throwIfError(MultiPartFormInputStream.java:517)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.http.MultiPartFormInputStream.getParts(MultiPartFormInputStream.java:470)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.MultiParts$MultiPartsHttpParser.getParts(MultiParts.java:74)
> ~[!/:9.4.52.v20230823]
> at org.eclipse.jetty.server.Request.getParts(Request.java:2450)
> ~[!/:9.4.52.v20230823]
> at org.eclipse.jetty.server.Request.getParts(Request.java:2420)
> ~[!/:9.4.52.v20230823]
> at
> org.apache.camel.component.jetty.MultiPartFilter.doFilter(MultiPartFilter.java:52)
> ~[?:?]
> at
> org.apache.camel.component.jetty.CamelFilterWrapper.doFilter(CamelFilterWrapper.java:49)
> ~[?:?]
> at
> org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:193) ~[?:?]
> at
> org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1626)
> ~[?:?]
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:552)
> ~[?:?]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1440)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:505)
> ~[?:?]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1355)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> ~[!/:9.4.52.v20230823]
> at org.eclipse.jetty.server.Server.handle(Server.java:516)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:487)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:732)
> ~[!/:9.4.52.v20230823]
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:479)
> [!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:277)
> [!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
> [!/:9.4.52.v20230823]
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105)
> [!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.io.ChannelEndPoint$1.run(ChannelEndPoint.java:104)
> [!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:883)
> [!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.util.thread.Queu
[jira] [Commented] (CAMEL-20152) camel-jetty - OutOfMemoryError with big file upload via multipart
[
https://issues.apache.org/jira/browse/CAMEL-20152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17790605#comment-17790605
]
Nicolas Filotto commented on CAMEL-20152:
-
Here is the PR [https://github.com/apache/camel/pull/12240]
After a deeper analysis, it is due to the fact that the {{fileSizeThreshold}}
is set to 0 by default to have the content stored into disk like it is
mentioned in the Jetty Javadoc but it is not what the Jetty does, indeed the
Jetty code expects a value strictly higher than 0.
> camel-jetty - OutOfMemoryError with big file upload via multipart
> -
>
> Key: CAMEL-20152
> URL: https://issues.apache.org/jira/browse/CAMEL-20152
> Project: Camel
> Issue Type: Bug
> Components: camel-jetty
>Affects Versions: 3.21.2
>Reporter: michael elbaz
>Assignee: Nicolas Filotto
>Priority: Major
> Attachments: image-2023-11-28-09-12-11-951.png
>
>
> I don't now if is related to jetty (maybe) but when i use camel with jetty
> and i upload a big file using multipart i get:
> {code:java}
> // espace r23:28:50.262 WARN [qtp1616084922-291] /email/myservice
> java.lang.IllegalStateException: java.lang.OutOfMemoryError: Java heap space
> at
> org.eclipse.jetty.http.MultiPartFormInputStream.throwIfError(MultiPartFormInputStream.java:517)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.http.MultiPartFormInputStream.getParts(MultiPartFormInputStream.java:470)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.MultiParts$MultiPartsHttpParser.getParts(MultiParts.java:74)
> ~[!/:9.4.52.v20230823]
> at org.eclipse.jetty.server.Request.getParts(Request.java:2450)
> ~[!/:9.4.52.v20230823]
> at org.eclipse.jetty.server.Request.getParts(Request.java:2420)
> ~[!/:9.4.52.v20230823]
> at
> org.apache.camel.component.jetty.MultiPartFilter.doFilter(MultiPartFilter.java:52)
> ~[?:?]
> at
> org.apache.camel.component.jetty.CamelFilterWrapper.doFilter(CamelFilterWrapper.java:49)
> ~[?:?]
> at
> org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:193) ~[?:?]
> at
> org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1626)
> ~[?:?]
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:552)
> ~[?:?]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1440)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:505)
> ~[?:?]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1355)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> ~[!/:9.4.52.v20230823]
> at org.eclipse.jetty.server.Server.handle(Server.java:516)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:487)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:732)
> ~[!/:9.4.52.v20230823]
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:479)
> [!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:277)
> [!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
> [!/:9.4.52.v20230823]
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105)
> [!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.io.ChannelEndPoint$1.run(ChannelEndPoint.java:104)
> [!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:883)
> [!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1034)
> [!/:9.4.52.v20230823]
> at java.lang.Thread.run(Thread.java:833) [?:?]
> Caused by: java.lang.OutOfMemoryError: Java heap space
> at java.util.Arrays.copyOf(Arrays.java:3537) ~[?:?]
> at
> java.io.ByteArrayOutputStream.ensureCapacity(ByteArrayOutputStream.java:100)
> ~[?:?]
> at
> java.io.ByteArrayOutputStream.write(ByteArrayOutput
[jira] [Commented] (CAMEL-20152) OutOfMemoryError
[
https://issues.apache.org/jira/browse/CAMEL-20152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17790438#comment-17790438
]
Nicolas Filotto commented on CAMEL-20152:
-
Thanks for reporting, I confirm there is a bug, let me propose a bug fix
> OutOfMemoryError
>
>
> Key: CAMEL-20152
> URL: https://issues.apache.org/jira/browse/CAMEL-20152
> Project: Camel
> Issue Type: Bug
> Components: camel-jetty
>Affects Versions: 3.21.2
>Reporter: michael elbaz
>Assignee: Nicolas Filotto
>Priority: Major
> Attachments: image-2023-11-28-09-12-11-951.png
>
>
> I don't now if is related to jetty (maybe) but when i use camel with jetty
> and i upload a big file using multipart i get:
> {code:java}
> // espace r23:28:50.262 WARN [qtp1616084922-291] /email/myservice
> java.lang.IllegalStateException: java.lang.OutOfMemoryError: Java heap space
> at
> org.eclipse.jetty.http.MultiPartFormInputStream.throwIfError(MultiPartFormInputStream.java:517)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.http.MultiPartFormInputStream.getParts(MultiPartFormInputStream.java:470)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.MultiParts$MultiPartsHttpParser.getParts(MultiParts.java:74)
> ~[!/:9.4.52.v20230823]
> at org.eclipse.jetty.server.Request.getParts(Request.java:2450)
> ~[!/:9.4.52.v20230823]
> at org.eclipse.jetty.server.Request.getParts(Request.java:2420)
> ~[!/:9.4.52.v20230823]
> at
> org.apache.camel.component.jetty.MultiPartFilter.doFilter(MultiPartFilter.java:52)
> ~[?:?]
> at
> org.apache.camel.component.jetty.CamelFilterWrapper.doFilter(CamelFilterWrapper.java:49)
> ~[?:?]
> at
> org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:193) ~[?:?]
> at
> org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1626)
> ~[?:?]
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:552)
> ~[?:?]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1440)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:505)
> ~[?:?]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1355)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> ~[!/:9.4.52.v20230823]
> at org.eclipse.jetty.server.Server.handle(Server.java:516)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:487)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:732)
> ~[!/:9.4.52.v20230823]
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:479)
> [!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:277)
> [!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
> [!/:9.4.52.v20230823]
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105)
> [!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.io.ChannelEndPoint$1.run(ChannelEndPoint.java:104)
> [!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:883)
> [!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1034)
> [!/:9.4.52.v20230823]
> at java.lang.Thread.run(Thread.java:833) [?:?]
> Caused by: java.lang.OutOfMemoryError: Java heap space
> at java.util.Arrays.copyOf(Arrays.java:3537) ~[?:?]
> at
> java.io.ByteArrayOutputStream.ensureCapacity(ByteArrayOutputStream.java:100)
> ~[?:?]
> at
> java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:130) ~[?:?]
> at
> org.eclipse.jetty.http.MultiPartFormInputStream$MultiPart.write(MultiPartFormInputStream.java:178)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.http.MultiPartFormInputStream$Handler.content(MultiPartFormInputStream.java:741)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.http.MultiPartParser.parseO
[jira] [Assigned] (CAMEL-20152) OutOfMemoryError
[
https://issues.apache.org/jira/browse/CAMEL-20152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicolas Filotto reassigned CAMEL-20152:
---
Assignee: Nicolas Filotto
> OutOfMemoryError
>
>
> Key: CAMEL-20152
> URL: https://issues.apache.org/jira/browse/CAMEL-20152
> Project: Camel
> Issue Type: Bug
> Components: camel-jetty
>Affects Versions: 3.21.2
>Reporter: michael elbaz
>Assignee: Nicolas Filotto
>Priority: Major
> Attachments: image-2023-11-28-09-12-11-951.png
>
>
> I don't now if is related to jetty (maybe) but when i use camel with jetty
> and i upload a big file using multipart i get:
> {code:java}
> // espace r23:28:50.262 WARN [qtp1616084922-291] /email/myservice
> java.lang.IllegalStateException: java.lang.OutOfMemoryError: Java heap space
> at
> org.eclipse.jetty.http.MultiPartFormInputStream.throwIfError(MultiPartFormInputStream.java:517)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.http.MultiPartFormInputStream.getParts(MultiPartFormInputStream.java:470)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.MultiParts$MultiPartsHttpParser.getParts(MultiParts.java:74)
> ~[!/:9.4.52.v20230823]
> at org.eclipse.jetty.server.Request.getParts(Request.java:2450)
> ~[!/:9.4.52.v20230823]
> at org.eclipse.jetty.server.Request.getParts(Request.java:2420)
> ~[!/:9.4.52.v20230823]
> at
> org.apache.camel.component.jetty.MultiPartFilter.doFilter(MultiPartFilter.java:52)
> ~[?:?]
> at
> org.apache.camel.component.jetty.CamelFilterWrapper.doFilter(CamelFilterWrapper.java:49)
> ~[?:?]
> at
> org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:193) ~[?:?]
> at
> org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1626)
> ~[?:?]
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:552)
> ~[?:?]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1440)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:505)
> ~[?:?]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1355)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> ~[!/:9.4.52.v20230823]
> at org.eclipse.jetty.server.Server.handle(Server.java:516)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:487)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:732)
> ~[!/:9.4.52.v20230823]
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:479)
> [!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:277)
> [!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
> [!/:9.4.52.v20230823]
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105)
> [!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.io.ChannelEndPoint$1.run(ChannelEndPoint.java:104)
> [!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:883)
> [!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1034)
> [!/:9.4.52.v20230823]
> at java.lang.Thread.run(Thread.java:833) [?:?]
> Caused by: java.lang.OutOfMemoryError: Java heap space
> at java.util.Arrays.copyOf(Arrays.java:3537) ~[?:?]
> at
> java.io.ByteArrayOutputStream.ensureCapacity(ByteArrayOutputStream.java:100)
> ~[?:?]
> at
> java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:130) ~[?:?]
> at
> org.eclipse.jetty.http.MultiPartFormInputStream$MultiPart.write(MultiPartFormInputStream.java:178)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.http.MultiPartFormInputStream$Handler.content(MultiPartFormInputStream.java:741)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.http.MultiPartParser.parseOctetContent(MultiPartParser.java:645)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.je
[jira] [Updated] (CAMEL-19997) camel-cifs: new component for the Common Internet File System
[ https://issues.apache.org/jira/browse/CAMEL-19997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Filotto updated CAMEL-19997: Fix Version/s: 3.22.0 > camel-cifs: new component for the Common Internet File System > - > > Key: CAMEL-19997 > URL: https://issues.apache.org/jira/browse/CAMEL-19997 > Project: Camel > Issue Type: Improvement >Reporter: Otavio Rodolfo Piske >Assignee: Otavio Rodolfo Piske >Priority: Major > Fix For: 3.22.0, 4.2.0 > > > Implement a component for interacting with the > [SMB|https://en.wikipedia.org/wiki/Server_Message_Block] (aka CIFS) protocol > using the [SMBJ|https://github.com/hierynomus/smbj] project. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-19997) camel-cifs: new component for the Common Internet File System
[ https://issues.apache.org/jira/browse/CAMEL-19997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787935#comment-17787935 ] Nicolas Filotto commented on CAMEL-19997: - The PR to backport it https://github.com/apache/camel/pull/12093 > camel-cifs: new component for the Common Internet File System > - > > Key: CAMEL-19997 > URL: https://issues.apache.org/jira/browse/CAMEL-19997 > Project: Camel > Issue Type: Improvement >Reporter: Otavio Rodolfo Piske >Assignee: Otavio Rodolfo Piske >Priority: Major > Fix For: 4.2.0 > > > Implement a component for interacting with the > [SMB|https://en.wikipedia.org/wiki/Server_Message_Block] (aka CIFS) protocol > using the [SMBJ|https://github.com/hierynomus/smbj] project. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-19997) camel-cifs: new component for the Common Internet File System
[ https://issues.apache.org/jira/browse/CAMEL-19997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787223#comment-17787223 ] Nicolas Filotto commented on CAMEL-19997: - [~orpiske] do you know if this component can be added to Camel 3 too? > camel-cifs: new component for the Common Internet File System > - > > Key: CAMEL-19997 > URL: https://issues.apache.org/jira/browse/CAMEL-19997 > Project: Camel > Issue Type: Improvement >Reporter: Otavio Rodolfo Piske >Assignee: Otavio Rodolfo Piske >Priority: Major > Fix For: 4.2.0 > > > Implement a component for interacting with the > [SMB|https://en.wikipedia.org/wiki/Server_Message_Block] (aka CIFS) protocol > using the [SMBJ|https://github.com/hierynomus/smbj] project. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-20079) EndpointDslMojo generates wrong header names
[ https://issues.apache.org/jira/browse/CAMEL-20079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17783163#comment-17783163 ] Nicolas Filotto commented on CAMEL-20079: - Thx for reporting this issue and submitting a PR for it. Would you mind proposing a backport for all LTS versions (4.0, 3.22, 3.21, 3.20)? > EndpointDslMojo generates wrong header names > > > Key: CAMEL-20079 > URL: https://issues.apache.org/jira/browse/CAMEL-20079 > Project: Camel > Issue Type: Bug > Components: tooling >Affects Versions: 4.0.1, 4.1.0 >Reporter: Karen Lease >Assignee: Karen Lease >Priority: Minor > Fix For: 4.2.0 > > > The method addHeaderNameMethod() removes the "Camel" prefix from the header > name which it uses for the method name, for example "fileName()". But it also > returns this value as the header name which is not correct. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (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:all-tabpanel ] Nicolas Filotto resolved CAMEL-20039. - Resolution: Fixed > 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 >Assignee: Nicolas Filotto >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] [Comment Edited] (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&focusedCommentId=17781384#comment-17781384 ] Nicolas Filotto edited comment on CAMEL-20039 at 11/1/23 8:30 AM: -- Related PRs: * 4.2 [https://github.com/apache/camel/pull/11876] * 4.0 [https://github.com/apache/camel/pull/11881] was (Author: JIRAUSER285918): Related PRs: * 4.2 [https://github.com/apache/camel/pull/11876] > 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 >Assignee: Nicolas Filotto >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&focusedCommentId=17781384#comment-17781384 ] Nicolas Filotto commented on CAMEL-20039: - Related PRs: * 4.2 [https://github.com/apache/camel/pull/11876] > 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 >Assignee: Nicolas Filotto >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&focusedCommentId=17780924#comment-17780924 ] Nicolas Filotto commented on CAMEL-20039: - Yeah indeed, I have 2 accounts, I did not realize that > 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 >Assignee: Nicolas Filotto >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] [Assigned] (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:all-tabpanel ] Nicolas Filotto reassigned CAMEL-20039: --- Assignee: Nicolas Filotto (was: Nicolas Filotto) > 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 >Assignee: Nicolas Filotto >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&focusedCommentId=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] [Comment Edited] (CAMEL-19035) Camel-jsonpath is parsing whole json payload from 3.10.0
[
https://issues.apache.org/jira/browse/CAMEL-19035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1073#comment-1073
]
Nicolas Filotto edited comment on CAMEL-19035 at 10/19/23 7:11 AM:
---
SpringBoot automatically registers an {{ObjectMapper}} so as you register
another {{ObjectMapper}}, Camel finds 2 ObjectMappers instead of one so it
doesn't know which one to use, in that case, it ignores both, and uses a
default one hence the behavior you get.
To fix that you need to avoid registering your own {{ObjectMapper}} and
configure the {{ObjectMapper}} managed by SpringBoot.
There are at least 2 ways to configure the {{ObjectMapper}} managed by
SpringBoot:
1. By configuration: In the {{application.properties}} simply adds
{{spring.jackson.parser.allow-leading-decimal-point-for-numbers=true}}
2. By code: In your class add a method of the following type:
{code:java}
@Bean
public ObjectMapper customJson(){
ObjectMapper om = new com.fasterxml.jackson.databind.ObjectMapper();
om.configure(JsonReadFeature.ALLOW_LEADING_DECIMAL_POINT_FOR_NUMBERS.mappedFeature(),
true);
return om;
}
{code}
was (Author: JIRAUSER285918):
SpringBoot automatically registers an {{ObjectMapper}} so as you register
another {{ObjectMapper}}, Camel finds 2 ObjectMappers instead of one so it
doesn't know which one to use, in that case, it ignores both, and uses a
default one hence the behavior you get.
To fix that you need to avoid registering your own {{ObjectMapper}} and
configure the {{ObjectMapper}} managed by SpringBoot.
There are at least 2 ways to configure the {{ObjectMapper}} managed by
SpringBoot:
1. By configuration: In the {{application.properties}} simply adds
{{spring.jackson.parser.allow-leading-decimal-point-for-numbers=true}}
2. By code: In your class add a method of the following type:
{code:java}
@Bean
public ObjectMapper customJson(){
ObjectMapper om = new
com.fasterxml.jackson.databind.ObjectMapper();
om.configure(JsonReadFeature.ALLOW_LEADING_DECIMAL_POINT_FOR_NUMBERS.mappedFeature(),
true);
return om;
}
{code}
> Camel-jsonpath is parsing whole json payload from 3.10.0
>
>
> Key: CAMEL-19035
> URL: https://issues.apache.org/jira/browse/CAMEL-19035
> Project: Camel
> Issue Type: Bug
> Components: camel-jsonpath
>Affects Versions: 3.10.0
>Reporter: Xilai Dai
>Assignee: Nicolas Filotto
>Priority: Minor
> Attachments: test-jsonpath-springboot.zip, test-jsonpath.zip
>
>
> Given a json payload e.g:
> {code}
> {
> "ABC": "A",
> "VERSION_NO": "BASE",
> "DEF": [
> {
> "GGG": 1,
> "HHH": "N",
> "OOO": [
> {
> "PPP": 1,
> "QQQ": 555.55,
> "RRR": 666.66,
> "SSS": 0,
> "TTT": 777.77
> },
> {
> "PPP": 3,
> "QQQ": .05,
> "RRR": .10,
> "SSS": 0,
> "TTT": .10
> }
> ]
> }
> ]
> }
> {code}
> In case of there is something e.g invalid integer value (.05) in the payload
> - .jsonpath("$.VERSION_NO") works as expected in Camel version less than
> 3.10.0.
> - .jsonpath("$.VERSION_NO") will throw parse exception in Camel version great
> than or equal 3.10.0.
> Investigation shows that this regression was starting happening after
> CAMEL-16389.
> https://github.com/apache/camel/commit/b59a96ddf1ba647b979f937f5bd956bba32173ee
> Now camel-jsonpath is trying to parse whole json payload.
> Attached test-jsonpath.zip for test/reproduce this issue.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-19035) Camel-jsonpath is parsing whole json payload from 3.10.0
[
https://issues.apache.org/jira/browse/CAMEL-19035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1073#comment-1073
]
Nicolas Filotto commented on CAMEL-19035:
-
SpringBoot automatically registers an {{ObjectMapper}} so as you register
another {{ObjectMapper}}, Camel finds 2 ObjectMappers instead of one so it
doesn't know which one to use, in that case, it ignores both, and uses a
default one hence the behavior you get.
To fix that you need to avoid registering your own {{ObjectMapper}} and
configure the {{ObjectMapper}} managed by SpringBoot.
There are at least 2 ways to configure the {{ObjectMapper}} managed by
SpringBoot:
1. By configuration: In the {{application.properties}} simply adds
{{spring.jackson.parser.allow-leading-decimal-point-for-numbers=true}}
2. By code: In your class add a method of the following type:
{code:java}
@Bean
public ObjectMapper customJson(){
ObjectMapper om = new
com.fasterxml.jackson.databind.ObjectMapper();
om.configure(JsonReadFeature.ALLOW_LEADING_DECIMAL_POINT_FOR_NUMBERS.mappedFeature(),
true);
return om;
}
{code}
> Camel-jsonpath is parsing whole json payload from 3.10.0
>
>
> Key: CAMEL-19035
> URL: https://issues.apache.org/jira/browse/CAMEL-19035
> Project: Camel
> Issue Type: Bug
> Components: camel-jsonpath
>Affects Versions: 3.10.0
>Reporter: Xilai Dai
>Assignee: Nicolas Filotto
>Priority: Minor
> Attachments: test-jsonpath-springboot.zip, test-jsonpath.zip
>
>
> Given a json payload e.g:
> {code}
> {
> "ABC": "A",
> "VERSION_NO": "BASE",
> "DEF": [
> {
> "GGG": 1,
> "HHH": "N",
> "OOO": [
> {
> "PPP": 1,
> "QQQ": 555.55,
> "RRR": 666.66,
> "SSS": 0,
> "TTT": 777.77
> },
> {
> "PPP": 3,
> "QQQ": .05,
> "RRR": .10,
> "SSS": 0,
> "TTT": .10
> }
> ]
> }
> ]
> }
> {code}
> In case of there is something e.g invalid integer value (.05) in the payload
> - .jsonpath("$.VERSION_NO") works as expected in Camel version less than
> 3.10.0.
> - .jsonpath("$.VERSION_NO") will throw parse exception in Camel version great
> than or equal 3.10.0.
> Investigation shows that this regression was starting happening after
> CAMEL-16389.
> https://github.com/apache/camel/commit/b59a96ddf1ba647b979f937f5bd956bba32173ee
> Now camel-jsonpath is trying to parse whole json payload.
> Attached test-jsonpath.zip for test/reproduce this issue.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CAMEL-19984) Re-add Camel-Cassandraql Karaf feature
[
https://issues.apache.org/jira/browse/CAMEL-19984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicolas Filotto resolved CAMEL-19984.
-
Resolution: Fixed
> Re-add Camel-Cassandraql Karaf feature
> --
>
> Key: CAMEL-19984
> URL: https://issues.apache.org/jira/browse/CAMEL-19984
> Project: Camel
> Issue Type: Task
> Components: karaf
>Affects Versions: 3.10.0
>Reporter: Nicolas Filotto
>Assignee: Nicolas Filotto
>Priority: Minor
> Fix For: 3.20.8, 3.21.2, 3.22.0
>
>
> The feature was removed by CAMEL-16422 due to a DSE import package that was
> missing because the artifact {{native-protocol}} did not export the version
> expected by {{java-driver-core}}, it is no longer the case so it can be added
> back
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-19984) Re-add Camel-Cassandraql Karaf feature
[
https://issues.apache.org/jira/browse/CAMEL-19984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17774845#comment-17774845
]
Nicolas Filotto commented on CAMEL-19984:
-
The corresponding PRs:
* 3.22 https://github.com/apache/camel-karaf/pull/248
* 3.21 https://github.com/apache/camel-karaf/pull/247
* 3.20 https://github.com/apache/camel-karaf/pull/246
> Re-add Camel-Cassandraql Karaf feature
> --
>
> Key: CAMEL-19984
> URL: https://issues.apache.org/jira/browse/CAMEL-19984
> Project: Camel
> Issue Type: Task
> Components: karaf
>Affects Versions: 3.10.0
>Reporter: Nicolas Filotto
>Assignee: Nicolas Filotto
>Priority: Minor
> Fix For: 3.20.8, 3.21.2, 3.22.0
>
>
> The feature was removed by CAMEL-16422 due to a DSE import package that was
> missing because the artifact {{native-protocol}} did not export the version
> expected by {{java-driver-core}}, it is no longer the case so it can be added
> back
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAMEL-19984) Re-add Camel-Cassandraql Karaf feature
Nicolas Filotto created CAMEL-19984:
---
Summary: Re-add Camel-Cassandraql Karaf feature
Key: CAMEL-19984
URL: https://issues.apache.org/jira/browse/CAMEL-19984
Project: Camel
Issue Type: Task
Components: karaf
Affects Versions: 3.10.0
Reporter: Nicolas Filotto
Assignee: Nicolas Filotto
Fix For: 3.20.8, 3.21.2, 3.22.0
The feature was removed by CAMEL-16422 due to a DSE import package that was
missing because the artifact {{native-protocol}} did not export the version
expected by {{java-driver-core}}, it is no longer the case so it can be added
back
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-19982) camel-jbang - Run with --jvm-debug as last parameter does not work
[ https://issues.apache.org/jira/browse/CAMEL-19982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17774646#comment-17774646 ] Nicolas Filotto commented on CAMEL-19982: - I was not aware of that, maybe we should remove the 4.1.x branch to avoid future missunderstanding > camel-jbang - Run with --jvm-debug as last parameter does not work > -- > > Key: CAMEL-19982 > URL: https://issues.apache.org/jira/browse/CAMEL-19982 > Project: Camel > Issue Type: Bug > Components: camel-jbang >Affects Versions: 4.1.0 >Reporter: Claus Ibsen >Assignee: Nicolas Filotto >Priority: Minor > Fix For: 4.2.0 > > > This does not work > camel run MyKafka.java --jvm-debug > But this works > camel run --jvm-debug MyKafka.java -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (CAMEL-19982) camel-jbang - Run with --jvm-debug as last parameter does not work
[ https://issues.apache.org/jira/browse/CAMEL-19982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17774640#comment-17774640 ] Nicolas Filotto edited comment on CAMEL-19982 at 10/12/23 6:13 PM: --- The corresponding PR https://github.com/apache/camel/pull/11713 was (Author: JIRAUSER285918): The corresponding PRs https://github.com/apache/camel/pull/11713 > camel-jbang - Run with --jvm-debug as last parameter does not work > -- > > Key: CAMEL-19982 > URL: https://issues.apache.org/jira/browse/CAMEL-19982 > Project: Camel > Issue Type: Bug > Components: camel-jbang >Affects Versions: 4.1.0 >Reporter: Claus Ibsen >Assignee: Nicolas Filotto >Priority: Minor > Fix For: 4.2.0 > > > This does not work > camel run MyKafka.java --jvm-debug > But this works > camel run --jvm-debug MyKafka.java -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (CAMEL-19982) camel-jbang - Run with --jvm-debug as last parameter does not work
[ https://issues.apache.org/jira/browse/CAMEL-19982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17774640#comment-17774640 ] Nicolas Filotto edited comment on CAMEL-19982 at 10/12/23 6:13 PM: --- The corresponding PRs https://github.com/apache/camel/pull/11713 was (Author: JIRAUSER285918): The corresponding PRs: * 4.2 https://github.com/apache/camel/pull/11713 * 4.1 https://github.com/apache/camel/pull/11714 > camel-jbang - Run with --jvm-debug as last parameter does not work > -- > > Key: CAMEL-19982 > URL: https://issues.apache.org/jira/browse/CAMEL-19982 > Project: Camel > Issue Type: Bug > Components: camel-jbang >Affects Versions: 4.1.0 >Reporter: Claus Ibsen >Assignee: Nicolas Filotto >Priority: Minor > Fix For: 4.2.0 > > > This does not work > camel run MyKafka.java --jvm-debug > But this works > camel run --jvm-debug MyKafka.java -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-19982) camel-jbang - Run with --jvm-debug as last parameter does not work
[ https://issues.apache.org/jira/browse/CAMEL-19982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Filotto updated CAMEL-19982: Fix Version/s: (was: 4.1.1) > camel-jbang - Run with --jvm-debug as last parameter does not work > -- > > Key: CAMEL-19982 > URL: https://issues.apache.org/jira/browse/CAMEL-19982 > Project: Camel > Issue Type: Bug > Components: camel-jbang >Affects Versions: 4.1.0 >Reporter: Claus Ibsen >Assignee: Nicolas Filotto >Priority: Minor > Fix For: 4.2.0 > > > This does not work > camel run MyKafka.java --jvm-debug > But this works > camel run --jvm-debug MyKafka.java -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-19982) camel-jbang - Run with --jvm-debug as last parameter does not work
[ https://issues.apache.org/jira/browse/CAMEL-19982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Filotto resolved CAMEL-19982. - Fix Version/s: 4.1.1 Resolution: Fixed > camel-jbang - Run with --jvm-debug as last parameter does not work > -- > > Key: CAMEL-19982 > URL: https://issues.apache.org/jira/browse/CAMEL-19982 > Project: Camel > Issue Type: Bug > Components: camel-jbang >Affects Versions: 4.1.0 >Reporter: Claus Ibsen >Assignee: Nicolas Filotto >Priority: Minor > Fix For: 4.1.1, 4.2.0 > > > This does not work > camel run MyKafka.java --jvm-debug > But this works > camel run --jvm-debug MyKafka.java -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (CAMEL-19982) camel-jbang - Run with --jvm-debug as last parameter does not work
[ https://issues.apache.org/jira/browse/CAMEL-19982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17774640#comment-17774640 ] Nicolas Filotto edited comment on CAMEL-19982 at 10/12/23 6:07 PM: --- The corresponding PRs: * 4.2 https://github.com/apache/camel/pull/11713 * 4.1 https://github.com/apache/camel/pull/11714 was (Author: JIRAUSER285918): The corresponding PR https://github.com/apache/camel/pull/11713 > camel-jbang - Run with --jvm-debug as last parameter does not work > -- > > Key: CAMEL-19982 > URL: https://issues.apache.org/jira/browse/CAMEL-19982 > Project: Camel > Issue Type: Bug > Components: camel-jbang >Affects Versions: 4.1.0 >Reporter: Claus Ibsen >Assignee: Nicolas Filotto >Priority: Minor > Fix For: 4.2.0 > > > This does not work > camel run MyKafka.java --jvm-debug > But this works > camel run --jvm-debug MyKafka.java -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-19982) camel-jbang - Run with --jvm-debug as last parameter does not work
[ https://issues.apache.org/jira/browse/CAMEL-19982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17774640#comment-17774640 ] Nicolas Filotto commented on CAMEL-19982: - The corresponding PR https://github.com/apache/camel/pull/11713 > camel-jbang - Run with --jvm-debug as last parameter does not work > -- > > Key: CAMEL-19982 > URL: https://issues.apache.org/jira/browse/CAMEL-19982 > Project: Camel > Issue Type: Bug > Components: camel-jbang >Affects Versions: 4.1.0 >Reporter: Claus Ibsen >Assignee: Nicolas Filotto >Priority: Minor > Fix For: 4.2.0 > > > This does not work > camel run MyKafka.java --jvm-debug > But this works > camel run --jvm-debug MyKafka.java -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-19982) camel-jbang - Run with --jvm-debug as last parameter does not work
[
https://issues.apache.org/jira/browse/CAMEL-19982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17774623#comment-17774623
]
Nicolas Filotto commented on CAMEL-19982:
-
I'm wondering if it is a real bug, indeed, if we have a closer look at the
syntax of the command, the current behavior makes sense:
{noformat}
Usage: camel run [-h] [--background] [--console] [--dev] [--download] [--fresh]
...
[--jvm-debug=]
...
[...]
{noformat}
As you can see the files are after the options not the other way around.
[~davsclaus] WDYT?
> camel-jbang - Run with --jvm-debug as last parameter does not work
> --
>
> Key: CAMEL-19982
> URL: https://issues.apache.org/jira/browse/CAMEL-19982
> Project: Camel
> Issue Type: Bug
> Components: camel-jbang
>Affects Versions: 4.1.0
>Reporter: Claus Ibsen
>Assignee: Nicolas Filotto
>Priority: Minor
> Fix For: 4.2.0
>
>
> This does not work
> camel run MyKafka.java --jvm-debug
> But this works
> camel run --jvm-debug MyKafka.java
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (CAMEL-19982) camel-jbang - Run with --jvm-debug as last parameter does not work
[ https://issues.apache.org/jira/browse/CAMEL-19982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Filotto reassigned CAMEL-19982: --- Assignee: Nicolas Filotto > camel-jbang - Run with --jvm-debug as last parameter does not work > -- > > Key: CAMEL-19982 > URL: https://issues.apache.org/jira/browse/CAMEL-19982 > Project: Camel > Issue Type: Bug > Components: camel-jbang >Affects Versions: 4.1.0 >Reporter: Claus Ibsen >Assignee: Nicolas Filotto >Priority: Minor > Fix For: 4.2.0 > > > This does not work > camel run MyKafka.java --jvm-debug > But this works > camel run --jvm-debug MyKafka.java -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-19950) camel-report-maven-plugin - Use camel-tooling-maven instead of grape
[ https://issues.apache.org/jira/browse/CAMEL-19950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Filotto resolved CAMEL-19950. - Resolution: Fixed > camel-report-maven-plugin - Use camel-tooling-maven instead of grape > > > Key: CAMEL-19950 > URL: https://issues.apache.org/jira/browse/CAMEL-19950 > Project: Camel > Issue Type: Improvement > Components: tooling >Reporter: Claus Ibsen >Assignee: Nicolas Filotto >Priority: Minor > Fix For: 4.1.0 > > > We have one last part where we use grape for downloading > camel-report-maven-plugin, it uses camel-catalog-maven-grape. We may be able > to drop that and use the new camel-tooling-maven instead and there is also > camel-grape - which is an old component - it can maybe be changed or we can > consider deprecating and removing it -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-19950) camel-report-maven-plugin - Use camel-tooling-maven instead of grape
[ https://issues.apache.org/jira/browse/CAMEL-19950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17772233#comment-17772233 ] Nicolas Filotto commented on CAMEL-19950: - The corresponding PR https://github.com/apache/camel/pull/11655 > camel-report-maven-plugin - Use camel-tooling-maven instead of grape > > > Key: CAMEL-19950 > URL: https://issues.apache.org/jira/browse/CAMEL-19950 > Project: Camel > Issue Type: Improvement > Components: tooling >Reporter: Claus Ibsen >Assignee: Nicolas Filotto >Priority: Minor > Fix For: 4.x > > > We have one last part where we use grape for downloading > camel-report-maven-plugin, it uses camel-catalog-maven-grape. We may be able > to drop that and use the new camel-tooling-maven instead and there is also > camel-grape - which is an old component - it can maybe be changed or we can > consider deprecating and removing it -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-19950) camel-report-maven-plugin - Use camel-tooling-maven instead of grape
[ https://issues.apache.org/jira/browse/CAMEL-19950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Filotto updated CAMEL-19950: Fix Version/s: 4.1.0 (was: 4.x) > camel-report-maven-plugin - Use camel-tooling-maven instead of grape > > > Key: CAMEL-19950 > URL: https://issues.apache.org/jira/browse/CAMEL-19950 > Project: Camel > Issue Type: Improvement > Components: tooling >Reporter: Claus Ibsen >Assignee: Nicolas Filotto >Priority: Minor > Fix For: 4.1.0 > > > We have one last part where we use grape for downloading > camel-report-maven-plugin, it uses camel-catalog-maven-grape. We may be able > to drop that and use the new camel-tooling-maven instead and there is also > camel-grape - which is an old component - it can maybe be changed or we can > consider deprecating and removing it -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-19949) camel-jbang - Allow to set a custom remote debugging port
[ https://issues.apache.org/jira/browse/CAMEL-19949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Filotto updated CAMEL-19949: Summary: camel-jbang - Allow to set a custom remote debugging port (was: camel-jbang - Add --jvm-debug-port option) > camel-jbang - Allow to set a custom remote debugging port > - > > Key: CAMEL-19949 > URL: https://issues.apache.org/jira/browse/CAMEL-19949 > Project: Camel > Issue Type: Improvement > Components: camel-jbang >Reporter: Claus Ibsen >Assignee: Nicolas Filotto >Priority: Minor > Fix For: 4.1.0 > > > We use 4004 as hardcoded value, but it would be nice to make it configurable. > For example 5005 is default in IDEA so its quicker to just use that. > You can then set 5005 via camel config set -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-19949) camel-jbang - Add --jvm-debug-port option
[
https://issues.apache.org/jira/browse/CAMEL-19949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17771959#comment-17771959
]
Nicolas Filotto commented on CAMEL-19949:
-
Here is PR proposal https://github.com/apache/camel/pull/11645 that reuses the
existing parameter {{--jvm-debug}} but with the ability to set an integer as
value to define a custom port
> camel-jbang - Add --jvm-debug-port option
> -
>
> Key: CAMEL-19949
> URL: https://issues.apache.org/jira/browse/CAMEL-19949
> Project: Camel
> Issue Type: Improvement
> Components: camel-jbang
>Reporter: Claus Ibsen
>Assignee: Nicolas Filotto
>Priority: Minor
> Fix For: 4.1.0
>
>
> We use 4004 as hardcoded value, but it would be nice to make it configurable.
> For example 5005 is default in IDEA so its quicker to just use that.
> You can then set 5005 via camel config set
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (CAMEL-19950) camel-report-maven-plugin - Use camel-tooling-maven instead of grape
[ https://issues.apache.org/jira/browse/CAMEL-19950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Filotto reassigned CAMEL-19950: --- Assignee: Nicolas Filotto > camel-report-maven-plugin - Use camel-tooling-maven instead of grape > > > Key: CAMEL-19950 > URL: https://issues.apache.org/jira/browse/CAMEL-19950 > Project: Camel > Issue Type: Improvement > Components: tooling >Reporter: Claus Ibsen >Assignee: Nicolas Filotto >Priority: Minor > Fix For: 4.x > > > We have one last part where we use grape for downloading > camel-report-maven-plugin, it uses camel-catalog-maven-grape. We may be able > to drop that and use the new camel-tooling-maven instead and there is also > camel-grape - which is an old component - it can maybe be changed or we can > consider deprecating and removing it -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-19949) camel-jbang - Add --jvm-debug-port option
[ https://issues.apache.org/jira/browse/CAMEL-19949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17771886#comment-17771886 ] Nicolas Filotto commented on CAMEL-19949: - Yeah it is what I'm doing > camel-jbang - Add --jvm-debug-port option > - > > Key: CAMEL-19949 > URL: https://issues.apache.org/jira/browse/CAMEL-19949 > Project: Camel > Issue Type: Improvement > Components: camel-jbang >Reporter: Claus Ibsen >Assignee: Nicolas Filotto >Priority: Minor > Fix For: 4.1.0 > > > We use 4004 as hardcoded value, but it would be nice to make it configurable. > For example 5005 is default in IDEA so its quicker to just use that. > You can then set 5005 via camel config set -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-19949) camel-jbang - Add --jvm-debug-port option
[ https://issues.apache.org/jira/browse/CAMEL-19949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17771878#comment-17771878 ] Nicolas Filotto commented on CAMEL-19949: - JBang supports it but there is a small regression that is fixed in the main branch by https://github.com/jbangdev/jbang/pull/1690 but it is not yet released > camel-jbang - Add --jvm-debug-port option > - > > Key: CAMEL-19949 > URL: https://issues.apache.org/jira/browse/CAMEL-19949 > Project: Camel > Issue Type: Improvement > Components: camel-jbang >Reporter: Claus Ibsen >Assignee: Nicolas Filotto >Priority: Minor > Fix For: 4.1.0 > > > We use 4004 as hardcoded value, but it would be nice to make it configurable. > For example 5005 is default in IDEA so its quicker to just use that. > You can then set 5005 via camel config set -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CAMEL-19949) camel-jbang - Add --jvm-debug-port option
[ https://issues.apache.org/jira/browse/CAMEL-19949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Filotto reassigned CAMEL-19949: --- Assignee: Nicolas Filotto > camel-jbang - Add --jvm-debug-port option > - > > Key: CAMEL-19949 > URL: https://issues.apache.org/jira/browse/CAMEL-19949 > Project: Camel > Issue Type: Improvement > Components: camel-jbang >Reporter: Claus Ibsen >Assignee: Nicolas Filotto >Priority: Minor > Fix For: 4.1.0 > > > We use 4004 as hardcoded value, but it would be nice to make it configurable. > For example 5005 is default in IDEA so its quicker to just use that. > You can then set 5005 via camel config set -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-19950) camel-report-maven-plugin - Use camel-tooling-maven instead of grape
[ https://issues.apache.org/jira/browse/CAMEL-19950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Filotto updated CAMEL-19950: Description: We have one last part where we use grape for downloading camel-report-maven-plugin, it uses camel-catalog-maven-grape. We may be able to drop that and use the new camel-tooling-maven instead and there is also camel-grape - which is an old component - it can maybe be changed or we can consider deprecating and removing it (was: Claus Ibsen: We have one last part where we use grape for downloading camel-report-maven-plugin Claus Ibsen: it uses camel-catalog-maven-grape Claus Ibsen: we may be able to drop that and use the new camel-tooling-maven instead Claus Ibsen: and there is also camel-grape - which is an old component - it can maybe be changed also Claus Ibsen: or we can consider deprecating and removing it) > camel-report-maven-plugin - Use camel-tooling-maven instead of grape > > > Key: CAMEL-19950 > URL: https://issues.apache.org/jira/browse/CAMEL-19950 > Project: Camel > Issue Type: Improvement > Components: tooling >Reporter: Claus Ibsen >Priority: Minor > Fix For: 4.x > > > We have one last part where we use grape for downloading > camel-report-maven-plugin, it uses camel-catalog-maven-grape. We may be able > to drop that and use the new camel-tooling-maven instead and there is also > camel-grape - which is an old component - it can maybe be changed or we can > consider deprecating and removing it -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-19939) camel-jbang - dependency copy - Use camel-tooling-maven
[ https://issues.apache.org/jira/browse/CAMEL-19939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Filotto updated CAMEL-19939: Fix Version/s: 4.1.0 (was: 4.x) > camel-jbang - dependency copy - Use camel-tooling-maven > --- > > Key: CAMEL-19939 > URL: https://issues.apache.org/jira/browse/CAMEL-19939 > Project: Camel > Issue Type: Improvement > Components: camel-jbang >Reporter: Claus Ibsen >Priority: Major > Fix For: 4.1.0 > > > Instead of export and invoking mvn copy dependency plugin, then we can see if > we can use camels own camel-tooling-maven, and resolve dependencies, and > gather urls to the local m2 files, which we can then copy directly from. > We need to include transitive dependencies, to ensure all JARs are included. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CAMEL-19939) camel-jbang - dependency copy - Use camel-tooling-maven
[ https://issues.apache.org/jira/browse/CAMEL-19939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Filotto reassigned CAMEL-19939: --- Assignee: Nicolas Filotto > camel-jbang - dependency copy - Use camel-tooling-maven > --- > > Key: CAMEL-19939 > URL: https://issues.apache.org/jira/browse/CAMEL-19939 > Project: Camel > Issue Type: Improvement > Components: camel-jbang >Reporter: Claus Ibsen >Assignee: Nicolas Filotto >Priority: Major > Fix For: 4.1.0 > > > Instead of export and invoking mvn copy dependency plugin, then we can see if > we can use camels own camel-tooling-maven, and resolve dependencies, and > gather urls to the local m2 files, which we can then copy directly from. > We need to include transitive dependencies, to ensure all JARs are included. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CAMEL-19940) camel-jbang - init should create .camel-jbang folder
[ https://issues.apache.org/jira/browse/CAMEL-19940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Filotto reassigned CAMEL-19940: --- Assignee: Nicolas Filotto > camel-jbang - init should create .camel-jbang folder > > > Key: CAMEL-19940 > URL: https://issues.apache.org/jira/browse/CAMEL-19940 > Project: Camel > Issue Type: Improvement > Components: camel-jbang >Reporter: Claus Ibsen >Assignee: Nicolas Filotto >Priority: Minor > Fix For: 4.0.2, 4.1.0 > > > This folder makes it easier for tooling to know its a camel jbang "project". -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-19871) camel-jooq - Set the proper scope to all test dependencies
[ https://issues.apache.org/jira/browse/CAMEL-19871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Filotto resolved CAMEL-19871. - Resolution: Fixed > camel-jooq - Set the proper scope to all test dependencies > --- > > Key: CAMEL-19871 > URL: https://issues.apache.org/jira/browse/CAMEL-19871 > Project: Camel > Issue Type: Task > Components: camel-joor >Affects Versions: 3.20.6, 3.21.0, 4.0.0 >Reporter: Nicolas Filotto >Assignee: Nicolas Filotto >Priority: Minor > Fix For: 3.20.7, 3.21.1, 3.22.0, 4.0.1, 4.1.0 > > > There are many test dependencies of the camel-joor component for which no > scope has been set which pulls useless dependencies at runtime. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-19871) camel-jooq - Set the proper scope to all test dependencies
[ https://issues.apache.org/jira/browse/CAMEL-19871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17766813#comment-17766813 ] Nicolas Filotto commented on CAMEL-19871: - The corresponding PRs: * 4.1 https://github.com/apache/camel/pull/11455 * 4.0 https://github.com/apache/camel/pull/11465 * 3.22 https://github.com/apache/camel/pull/11466 * 3.21 https://github.com/apache/camel/pull/11467 * 3.20 https://github.com/apache/camel/pull/11468 > camel-jooq - Set the proper scope to all test dependencies > --- > > Key: CAMEL-19871 > URL: https://issues.apache.org/jira/browse/CAMEL-19871 > Project: Camel > Issue Type: Task > Components: camel-joor >Affects Versions: 3.20.6, 3.21.0, 4.0.0 >Reporter: Nicolas Filotto >Assignee: Nicolas Filotto >Priority: Minor > Fix For: 3.20.7, 3.21.1, 3.22.0, 4.0.1, 4.1.0 > > > There are many test dependencies of the camel-joor component for which no > scope has been set which pulls useless dependencies at runtime. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-19871) camel-jooq - Set the proper scope to all test dependencies
[
https://issues.apache.org/jira/browse/CAMEL-19871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17766700#comment-17766700
]
Nicolas Filotto commented on CAMEL-19871:
-
After a deeper analysis, it appears that the job fails because it tries to
generate the Javadoc of the test classes generated by the
{{jooq-codegen-maven}} which is unexpected. This problem is directly addressed
within the context of this ticket.
> camel-jooq - Set the proper scope to all test dependencies
> ---
>
> Key: CAMEL-19871
> URL: https://issues.apache.org/jira/browse/CAMEL-19871
> Project: Camel
> Issue Type: Task
> Components: camel-joor
>Affects Versions: 3.20.6, 3.21.0, 4.0.0
>Reporter: Nicolas Filotto
>Assignee: Nicolas Filotto
>Priority: Minor
> Fix For: 3.20.7, 3.21.1, 3.22.0, 4.0.1, 4.1.0
>
>
> There are many test dependencies of the camel-joor component for which no
> scope has been set which pulls useless dependencies at runtime.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-19875) HealthCheck is broken for KafkaConsumer
[
https://issues.apache.org/jira/browse/CAMEL-19875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17766337#comment-17766337
]
Nicolas Filotto commented on CAMEL-19875:
-
Is-it somehow related to CAMEL-19854?
> HealthCheck is broken for KafkaConsumer
> ---
>
> Key: CAMEL-19875
> URL: https://issues.apache.org/jira/browse/CAMEL-19875
> Project: Camel
> Issue Type: Bug
> Components: camel-kafka
>Affects Versions: 4.0.0
>Reporter: Freeman Yue Fang
>Assignee: Freeman Yue Fang
>Priority: Major
> Fix For: 4.0.1, 4.1.0
>
>
> Since Camel 4.x there is no ComponentsHealthCheckRepository class anymore. So
> the code
> {code}
> healthCheckRepository = HealthCheckHelper.getHealthCheckRepository(
> endpoint.getCamelContext(),
> "components",
> WritableHealthCheckRepository.class);
> {code}
> can't load the HealthCheckRepository
> The current KafkaConsumerHealthCheckIT can't catch this error because it use
> {code}
>final Collection res =
> HealthCheckHelper.invokeReadiness(context);
>final boolean down = res.stream().allMatch(r ->
> r.getState().equals(HealthCheck.State.DOWN));
> Assertions.assertTrue(down, "readiness check");
> {code}
> However as res is an empty List so res.stream().allMatch() always return
> true, so actually can't test the HealthCheck status.
> Use change in this test like
> {code}
> ---
> a/components/camel-kafka/src/test/java/org/apache/camel/component/kafka/integration/health/KafkaConsumerHealthCheckIT.java
> +++
> b/components/camel-kafka/src/test/java/org/apache/camel/component/kafka/integration/health/KafkaConsumerHealthCheckIT.java
> @@ -18,6 +18,7 @@ package org.apache.camel.component.kafka.integration.health;
>
> import java.util.Collection;
> import java.util.Map;
> +import java.util.Optional;
> import java.util.Properties;
> import java.util.concurrent.TimeUnit;
> import java.util.stream.StreamSupport;
> @@ -166,9 +167,18 @@ public class KafkaConsumerHealthCheckIT extends
> KafkaHealthCheckTestSupport {
> serviceShutdown = true;
>
> // health-check readiness should be DOWN
> -final Collection res =
> HealthCheckHelper.invokeReadiness(context);
> -final boolean down = res.stream().allMatch(r ->
> r.getState().equals(HealthCheck.State.DOWN));
> -Assertions.assertTrue(down, "readiness check");
> +await().atMost(20, TimeUnit.SECONDS).untilAsserted(() -> {
> +Collection res2 =
> HealthCheckHelper.invokeReadiness(context);
> +Assertions.assertTrue(res2.size() > 0);
> +Optional down
> += res2.stream().filter(r ->
> r.getState().equals(HealthCheck.State.DOWN)).findFirst();
> +Assertions.assertTrue(down.isPresent());
> +String msg = down.get().getMessage().get();
> +Assertions.assertTrue(msg.contains("KafkaConsumer is not
> ready"));
> +Map map = down.get().getDetails();
> +Assertions.assertEquals(TOPIC, map.get("topic"));
> +Assertions.assertEquals("test-health-it", map.get("route.id"));
> +});
> }
>
> }
> {code}
> can expose this issue
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Reopened] (CAMEL-19871) camel-jooq - Set the proper scope to all test dependencies
[ https://issues.apache.org/jira/browse/CAMEL-19871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Filotto reopened CAMEL-19871: - Those changes cause compilation issues on the CI job that publishes snapshots like [https://ci-builds.apache.org/job/Camel/job/Camel%20Daily%20Snapshot%20Deploy/job/main/461/] , those compilation problems need to be investigated but for now, let's revert all changes to get the snapshots published again. > camel-jooq - Set the proper scope to all test dependencies > --- > > Key: CAMEL-19871 > URL: https://issues.apache.org/jira/browse/CAMEL-19871 > Project: Camel > Issue Type: Task > Components: camel-joor >Affects Versions: 3.20.6, 3.21.0, 4.0.0 >Reporter: Nicolas Filotto >Assignee: Nicolas Filotto >Priority: Minor > Fix For: 3.20.7, 3.21.1, 3.22.0, 4.0.1, 4.1.0 > > > There are many test dependencies of the camel-joor component for which no > scope has been set which pulls useless dependencies at runtime. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-19871) camel-jooq - Set the proper scope to all test dependencies
[ https://issues.apache.org/jira/browse/CAMEL-19871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Filotto resolved CAMEL-19871. - Fix Version/s: 3.20.7 3.21.1 3.22.0 4.0.1 4.1.0 Resolution: Fixed > camel-jooq - Set the proper scope to all test dependencies > --- > > Key: CAMEL-19871 > URL: https://issues.apache.org/jira/browse/CAMEL-19871 > Project: Camel > Issue Type: Task > Components: camel-joor >Affects Versions: 3.20.6, 3.21.0, 4.0.0 >Reporter: Nicolas Filotto >Assignee: Nicolas Filotto >Priority: Minor > Fix For: 3.20.7, 3.21.1, 3.22.0, 4.0.1, 4.1.0 > > > There are many test dependencies of the camel-joor component for which no > scope has been set which pulls useless dependencies at runtime. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-19871) camel-jooq - Set the proper scope to all test dependencies
Nicolas Filotto created CAMEL-19871: --- Summary: camel-jooq - Set the proper scope to all test dependencies Key: CAMEL-19871 URL: https://issues.apache.org/jira/browse/CAMEL-19871 Project: Camel Issue Type: Task Components: camel-joor Affects Versions: 4.0.0, 3.21.0, 3.20.6 Reporter: Nicolas Filotto Assignee: Nicolas Filotto There are many test dependencies of the camel-joor component for which no scope has been set which pulls useless dependencies at runtime. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-19851) spring-boot Allow to configure timeouts natively
[
https://issues.apache.org/jira/browse/CAMEL-19851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicolas Filotto resolved CAMEL-19851.
-
Fix Version/s: 4.0.1
4.1.0
Resolution: Fixed
> spring-boot Allow to configure timeouts natively
>
>
> Key: CAMEL-19851
> URL: https://issues.apache.org/jira/browse/CAMEL-19851
> Project: Camel
> Issue Type: Improvement
> Components: camel-http
>Affects Versions: 4.0.0
> Environment:
>
>Reporter: Valeriy Ak
>Assignee: Nicolas Filotto
>Priority: Major
> Fix For: 4.0.1, 4.1.0
>
>
> In http component we have some properties with type
> org.apache.hc.core5.util.Timeout:
> * camel.component.http.connect-timeout
> * camel.component.http.connection-request-timeout
> * camel.component.http.response-timeout
> * camel.component.http.so-timeout
> We can set this properies by spring boot prop file
> ([documentation|https://camel.apache.org/components/4.0.x/http-component.html#_spring_boot_auto_configuration]).
>
>
> However in current realization it is not posible to set thouse values because
> converter don't create Timeout object, it try to get bean with this name from
> spring context
> [HttpComponentConverter|https://github.com/apache/camel-spring-boot/blob/camel-spring-boot-4.0.x/components-starter/camel-http-starter/src/main/java/org/apache/camel/component/http/springboot/HttpComponentConverter.java#L77]
> , if bean not present it alwayes return null value (withou any excaptions or
> warrnigs(!))
>
> It is not correct behavior - and correct way is convert value to [Duration
> |https://docs.spring.io/spring-boot/docs/current/reference/html/features.html#features.external-config.typesafe-configuration-properties.conversion.durations]and
> then call Timeout.of(duration)
>
> Please fix converter for org.apache.hc.core5.util.Timeout class
>
> Examples:
> {code:java}
> camel:
> component:
> http:
> so-timeout: PT30S
> ---
> bean HttpComponentConfiguration.soTimeout=null
> camel:
> component:
> http:
> so-timeout: 1000
> ---
> Exception on start - Caused by:
> org.springframework.core.convert.ConverterNotFoundException: No converter
> found capable of converting from type [java.lang.Integer] to type
> [org.apache.hc.core5.util.Timeout]{code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-19854) spring-boot - Fix the test KafkaConsumerHealthCheckIT
[
https://issues.apache.org/jira/browse/CAMEL-19854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicolas Filotto updated CAMEL-19854:
Affects Version/s: 4.1.0
> spring-boot - Fix the test KafkaConsumerHealthCheckIT
> -
>
> Key: CAMEL-19854
> URL: https://issues.apache.org/jira/browse/CAMEL-19854
> Project: Camel
> Issue Type: Task
> Components: camel-kafka
>Affects Versions: 4.0.0, 4.1.0
>Reporter: Nicolas Filotto
>Priority: Major
>
> The test {{KafkaConsumerHealthCheckIT}} constantly fails, so it needs to be
> investigated and fixed
> {noformat}
> [ERROR] Errors:
> [ERROR] KafkaConsumerHealthCheckIT.kafkaConsumerHealthCheck:177 »
> ConditionTimeout Assertion condition defined as a
> org.apache.camel.component.kafka.integration.KafkaConsumerHealthCheckIT
> expected: but was: within 20 seconds.
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
