[jira] [Commented] (CAMEL-14470) Camel-github: Switch from egit to kohsuke github-api
[ https://issues.apache.org/jira/browse/CAMEL-14470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17757207#comment-17757207 ] Andrea Cosentino commented on CAMEL-14470: -- I think a new component should be created, but let's gather more opinions > Camel-github: Switch from egit to kohsuke github-api > - > > Key: CAMEL-14470 > URL: https://issues.apache.org/jira/browse/CAMEL-14470 > Project: Camel > Issue Type: Improvement > Components: camel-github >Reporter: Andrea Cosentino >Assignee: Andrea Cosentino >Priority: Major > Fix For: 4.x > > > Egit is not updated from a while, at least the version in mylyn. The > github-api from kohsuke is actually the best Java client out there. So > probably it makes sense to switch. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-16479) Camel-AWS-Kinesis: The consumer should be able to consume from multiple shards at the same time
[ https://issues.apache.org/jira/browse/CAMEL-16479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrea Cosentino resolved CAMEL-16479. -- Fix Version/s: 4.0.0 4.0-RC2 (was: 4.x) Resolution: Fixed > Camel-AWS-Kinesis: The consumer should be able to consume from multiple > shards at the same time > --- > > Key: CAMEL-16479 > URL: https://issues.apache.org/jira/browse/CAMEL-16479 > Project: Camel > Issue Type: New Feature > Components: camel-aws >Reporter: Andrea Cosentino >Assignee: Andrea Cosentino >Priority: Major > Fix For: 4.0.0, 4.0-RC2 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-19768) camel-http - HTTP message body encoded with wrong charset
[ https://issues.apache.org/jira/browse/CAMEL-19768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-19768. - Resolution: Fixed Thanks for reporting and the PR > camel-http - HTTP message body encoded with wrong charset > - > > Key: CAMEL-19768 > URL: https://issues.apache.org/jira/browse/CAMEL-19768 > Project: Camel > Issue Type: Bug > Components: camel-http >Affects Versions: 4.0.0 >Reporter: Michael Pätzold >Priority: Minor > Fix For: 4.0.1, 4.1.0 > > > I was facing an issue during migration from Camel 3 to 4 when routing HTTP > requests that contain JSONs with special characters, e.g. German umlauts. In > my case, this leads to a situation where the receiving Spring Boot service > rejects the request, pointing out it's not readable. That's actually true > since the request header states that the message is in UTF-8 while it > actually is encoded in ISO 8859-1. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-19768) camel-http - HTTP message body encoded with wrong charset
[ https://issues.apache.org/jira/browse/CAMEL-19768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-19768: Fix Version/s: 4.0.1 4.1.0 > camel-http - HTTP message body encoded with wrong charset > - > > Key: CAMEL-19768 > URL: https://issues.apache.org/jira/browse/CAMEL-19768 > Project: Camel > Issue Type: Bug > Components: camel-http >Affects Versions: 4.0.0 >Reporter: Michael Pätzold >Priority: Minor > Fix For: 4.0.1, 4.1.0 > > > I was facing an issue during migration from Camel 3 to 4 when routing HTTP > requests that contain JSONs with special characters, e.g. German umlauts. In > my case, this leads to a situation where the receiving Spring Boot service > rejects the request, pointing out it's not readable. That's actually true > since the request header states that the message is in UTF-8 while it > actually is encoded in ISO 8859-1. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-19771) camel-core-model - RouteConfigurationsDefinition should be id and resource
[ https://issues.apache.org/jira/browse/CAMEL-19771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-19771. - Resolution: Fixed > camel-core-model - RouteConfigurationsDefinition should be id and resource > -- > > Key: CAMEL-19771 > URL: https://issues.apache.org/jira/browse/CAMEL-19771 > Project: Camel > Issue Type: Improvement > Components: camel-core, eip >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Major > Fix For: 4.1.0 > > > The routeConfigurations should like other container definitions (routes, > rests, templates) to be id and resource capable, to make it similar to the > others. > This makes the source generated DSLs and dumpers able to use this. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-19771) camel-core-model - RouteConfigurationsDefinition should be id and resource
Claus Ibsen created CAMEL-19771: --- Summary: camel-core-model - RouteConfigurationsDefinition should be id and resource Key: CAMEL-19771 URL: https://issues.apache.org/jira/browse/CAMEL-19771 Project: Camel Issue Type: Improvement Components: camel-core, eip Reporter: Claus Ibsen Assignee: Claus Ibsen Fix For: 4.1.0 The routeConfigurations should like other container definitions (routes, rests, templates) to be id and resource capable, to make it similar to the others. This makes the source generated DSLs and dumpers able to use this. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-19765) camel-core - SPI for DumpRouteStrategy
[ https://issues.apache.org/jira/browse/CAMEL-19765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-19765. - Resolution: Fixed > camel-core - SPI for DumpRouteStrategy > -- > > Key: CAMEL-19765 > URL: https://issues.apache.org/jira/browse/CAMEL-19765 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Major > Fix For: 4.1.0 > > > So you can plugin custom implementations -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-19748) core: cleanup remaining catches of Throwables
[ https://issues.apache.org/jira/browse/CAMEL-19748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Otavio Rodolfo Piske resolved CAMEL-19748. -- Resolution: Fixed Fixed with the linked PR. > core: cleanup remaining catches of Throwables > - > > Key: CAMEL-19748 > URL: https://issues.apache.org/jira/browse/CAMEL-19748 > Project: Camel > Issue Type: Task >Affects Versions: 4.0.0 >Reporter: Otavio Rodolfo Piske >Assignee: Otavio Rodolfo Piske >Priority: Major > Labels: core > Fix For: 4.1.0 > > > Catching Throwables can be dangerous as it can also catch internal JVM errors > and other problems [that applications should not try to > catch|https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/Error.html]. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-19770) components: cleanup remaining catches of Throwables
Otavio Rodolfo Piske created CAMEL-19770: Summary: components: cleanup remaining catches of Throwables Key: CAMEL-19770 URL: https://issues.apache.org/jira/browse/CAMEL-19770 Project: Camel Issue Type: Task Affects Versions: 4.0.0 Reporter: Otavio Rodolfo Piske Assignee: Otavio Rodolfo Piske Fix For: 4.1.0 Catching Throwables can be dangerous as it can also catch internal JVM errors and other problems [that applications should not try to catch|https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/Error.html]. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-19751) camel-xchange: tests keep hitting the binance API
[
https://issues.apache.org/jira/browse/CAMEL-19751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Otavio Rodolfo Piske resolved CAMEL-19751.
--
Resolution: Fixed
Fixed with the linked PR
> camel-xchange: tests keep hitting the binance API
> -
>
> Key: CAMEL-19751
> URL: https://issues.apache.org/jira/browse/CAMEL-19751
> Project: Camel
> Issue Type: Task
> Components: camel-xchange
>Reporter: Otavio Rodolfo Piske
>Priority: Major
> Fix For: 3.20.7, 3.22.0, 4.0.1, 4.1.0
>
>
> The camel-xchange tests keep hitting the address
> https://fapi.binance.com/fapi/v1/exchangeInfo which both abuse the owner of
> the address and contribute to their flakiness.
> To reproduce:
> 1. Run the tests locally: they are likely to pass
> 2. Block the binance API address (see below)
> 3. Repeat the tests: they should fail with
> {{"org.knowm.xchange.exceptions.ExchangeException: Failed to initialize:
> Connection refused"}}
> To block the address, you can add the following line to {{/etc/hosts}}:
> {code:java}
> 127.0.0.1 fapi.binance.com
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CAMEL-19754) Remove checks for older Java versions
[ https://issues.apache.org/jira/browse/CAMEL-19754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Otavio Rodolfo Piske resolved CAMEL-19754. -- Resolution: Fixed Fixed with the linked PR. > Remove checks for older Java versions > - > > Key: CAMEL-19754 > URL: https://issues.apache.org/jira/browse/CAMEL-19754 > Project: Camel > Issue Type: Task >Reporter: Otavio Rodolfo Piske >Assignee: Otavio Rodolfo Piske >Priority: Major > > As of Camel 4, the code won't even run on anything older than 17, therefore > checking for older Java versions may be unnecessary. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (CAMEL-17318) Add an AWS Timestream component
[ https://issues.apache.org/jira/browse/CAMEL-17318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17756904#comment-17756904 ] Claus Ibsen edited comment on CAMEL-17318 at 8/21/23 1:19 PM: -- We need a camel-spring-boot starter for this new component *DONE* was (Author: davsclaus): We need a camel-spring-boot starter for this new component > Add an AWS Timestream component > --- > > Key: CAMEL-17318 > URL: https://issues.apache.org/jira/browse/CAMEL-17318 > Project: Camel > Issue Type: New Feature > Components: camel-aws2 >Reporter: Andrea Cosentino >Assignee: Andrea Cosentino >Priority: Major > Fix For: 4.1.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-17318) Add an AWS Timestream component
[ https://issues.apache.org/jira/browse/CAMEL-17318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-17318. - Resolution: Fixed > Add an AWS Timestream component > --- > > Key: CAMEL-17318 > URL: https://issues.apache.org/jira/browse/CAMEL-17318 > Project: Camel > Issue Type: New Feature > Components: camel-aws2 >Reporter: Andrea Cosentino >Assignee: Andrea Cosentino >Priority: Major > Fix For: 4.1.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-17318) Add an AWS Timestream component
[ https://issues.apache.org/jira/browse/CAMEL-17318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17756904#comment-17756904 ] Claus Ibsen commented on CAMEL-17318: - We need a camel-spring-boot starter for this new component > Add an AWS Timestream component > --- > > Key: CAMEL-17318 > URL: https://issues.apache.org/jira/browse/CAMEL-17318 > Project: Camel > Issue Type: New Feature > Components: camel-aws2 >Reporter: Andrea Cosentino >Assignee: Andrea Cosentino >Priority: Major > Fix For: 4.1.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-19768) camel-http - HTTP message body encoded with wrong charset
[ https://issues.apache.org/jira/browse/CAMEL-19768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17756900#comment-17756900 ] Claus Ibsen commented on CAMEL-19768: - https://camel.zulipchat.com/#narrow/stream/257298-camel/topic/Camel.204.20JSON.20charset.20issue/near/385945000 > camel-http - HTTP message body encoded with wrong charset > - > > Key: CAMEL-19768 > URL: https://issues.apache.org/jira/browse/CAMEL-19768 > Project: Camel > Issue Type: Bug > Components: camel-http >Affects Versions: 4.0.0 >Reporter: Michael Pätzold >Priority: Minor > > I was facing an issue during migration from Camel 3 to 4 when routing HTTP > requests that contain JSONs with special characters, e.g. German umlauts. In > my case, this leads to a situation where the receiving Spring Boot service > rejects the request, pointing out it's not readable. That's actually true > since the request header states that the message is in UTF-8 while it > actually is encoded in ISO 8859-1. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-19766) Routes loaded with xml-io-dsl don't find associated routeConfiguration
[ https://issues.apache.org/jira/browse/CAMEL-19766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-19766: Priority: Minor (was: Major) > Routes loaded with xml-io-dsl don't find associated routeConfiguration > -- > > Key: CAMEL-19766 > URL: https://issues.apache.org/jira/browse/CAMEL-19766 > Project: Camel > Issue Type: Bug > Components: camel-xml-io >Reporter: Karen Lease >Assignee: Karen Lease >Priority: Minor > Fix For: 3.21.1, 3.22.0, 4.0.1, 4.1.0 > > > If a route defined in XML has a routeConfigurationId, when the route is > loaded, it is not associated with the related routeConfiguration, even though > the configuration is correctly loaded. For an example see > camel-examples/examples/routes-configuration. > The issue is due to a change introduced in the correction for CAMEL-18923. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-19766) Routes loaded with xml-io-dsl don't find associated routeConfiguration
[ https://issues.apache.org/jira/browse/CAMEL-19766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-19766. - Resolution: Fixed > Routes loaded with xml-io-dsl don't find associated routeConfiguration > -- > > Key: CAMEL-19766 > URL: https://issues.apache.org/jira/browse/CAMEL-19766 > Project: Camel > Issue Type: Bug > Components: camel-xml-io >Reporter: Karen Lease >Assignee: Karen Lease >Priority: Minor > Fix For: 3.21.1, 3.22.0, 4.0.1, 4.1.0 > > > If a route defined in XML has a routeConfigurationId, when the route is > loaded, it is not associated with the related routeConfiguration, even though > the configuration is correctly loaded. For an example see > camel-examples/examples/routes-configuration. > The issue is due to a change introduced in the correction for CAMEL-18923. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-19768) camel-http - HTTP message body encoded with wrong charset
[ https://issues.apache.org/jira/browse/CAMEL-19768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-19768: Summary: camel-http - HTTP message body encoded with wrong charset (was: HTTP message body encoded with wrong charset) > camel-http - HTTP message body encoded with wrong charset > - > > Key: CAMEL-19768 > URL: https://issues.apache.org/jira/browse/CAMEL-19768 > Project: Camel > Issue Type: Bug > Components: camel-http >Affects Versions: 4.0.0 >Reporter: Michael Pätzold >Priority: Minor > > I was facing an issue during migration from Camel 3 to 4 when routing HTTP > requests that contain JSONs with special characters, e.g. German umlauts. In > my case, this leads to a situation where the receiving Spring Boot service > rejects the request, pointing out it's not readable. That's actually true > since the request header states that the message is in UTF-8 while it > actually is encoded in ISO 8859-1. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-19768) HTTP message body encoded with wrong charset
[ https://issues.apache.org/jira/browse/CAMEL-19768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-19768: Priority: Minor (was: Critical) > HTTP message body encoded with wrong charset > > > Key: CAMEL-19768 > URL: https://issues.apache.org/jira/browse/CAMEL-19768 > Project: Camel > Issue Type: Bug > Components: camel-http >Affects Versions: 4.0.0 >Reporter: Michael Pätzold >Priority: Minor > > I was facing an issue during migration from Camel 3 to 4 when routing HTTP > requests that contain JSONs with special characters, e.g. German umlauts. In > my case, this leads to a situation where the receiving Spring Boot service > rejects the request, pointing out it's not readable. That's actually true > since the request header states that the message is in UTF-8 while it > actually is encoded in ISO 8859-1. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-19769) Error in karaf
[ https://issues.apache.org/jira/browse/CAMEL-19769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-19769. - Resolution: Invalid camel-karaf only supports Camel 3.x > Error in karaf > -- > > Key: CAMEL-19769 > URL: https://issues.apache.org/jira/browse/CAMEL-19769 > Project: Camel > Issue Type: Bug > Components: came-core >Affects Versions: 4.0.0 >Reporter: Kiryanov Vlad >Priority: Major > > I try to use camel 4.0.0 in Apache Karaf 4.4,3. But i get error in command > repo-add camel 4.0.0 > karaf@root()> repo-add camel 4.0.0 > Adding feature url mvn:org.apache.camel.karaf/apache-camel/4.0.0/xml/features > Error executing command: Error resolving artifact > org.apache.camel.karaf:apache-camel:xml:features:4.0.0: [Could not find > artifact org.apache.camel.karaf:apache-camel:xml:features:4.0.0 in central > (https://repo1.maven.org/maven2/)] : > mvn:org.apache.camel.karaf/apache-camel/4.0.0/xml/features -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-19769) Error in karaf
Kiryanov Vlad created CAMEL-19769: - Summary: Error in karaf Key: CAMEL-19769 URL: https://issues.apache.org/jira/browse/CAMEL-19769 Project: Camel Issue Type: Bug Components: came-core Affects Versions: 4.0.0 Reporter: Kiryanov Vlad I try to use camel 4.0.0 in Apache Karaf 4.4,3. But i get error in command repo-add camel 4.0.0 karaf@root()> repo-add camel 4.0.0 Adding feature url mvn:org.apache.camel.karaf/apache-camel/4.0.0/xml/features Error executing command: Error resolving artifact org.apache.camel.karaf:apache-camel:xml:features:4.0.0: [Could not find artifact org.apache.camel.karaf:apache-camel:xml:features:4.0.0 in central (https://repo1.maven.org/maven2/)] : mvn:org.apache.camel.karaf/apache-camel/4.0.0/xml/features -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-19759) performance: Camel is hanging up during shutdown
[ https://issues.apache.org/jira/browse/CAMEL-19759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17756863#comment-17756863 ] Otavio Rodolfo Piske commented on CAMEL-19759: -- Hi, just sharing some updates from my initial investigation (this is a WIP, so read the comments with a grain of salt). ??With this, my understanding is that if the pool has at least one instance of SinglePool, then the singlePoolEvicted will be cleared twice.?? Yes, it is being called twice. Though, in this case, once it hits the stop, it is NO-OP because the service should have been stopped already (nonetheless, that's still wrong in my book). !called-twice-2.png! !called-twice-1.png! ??I said "It looks like lines 192 and 193 are not needed" and I'm not correct, however, looks like to me it has some cases that the singlePoolEvicted can be cleaned many times. ?? It could be the case, actually. ??Is there a possibility of the cleanUp being called concurrently??? There is! this problem, actually, happens under high load / high concurrency. So, it could be the case. ??Im not saying it is the problem, but if it is calling singlePoolEvicted.remove() concurrently, it has a chance of impacting the singlePoolEvicted.clear(). Make sense??? Yeah, indeed, it makes sense and I think it's worth investigating. > performance: Camel is hanging up during shutdown > > > Key: CAMEL-19759 > URL: https://issues.apache.org/jira/browse/CAMEL-19759 > Project: Camel > Issue Type: Bug >Affects Versions: 3.20.6 >Reporter: Otavio Rodolfo Piske >Assignee: Otavio Rodolfo Piske >Priority: Major > Attachments: called-twice-1.png, called-twice-2.png, dump3.hprof, > jstack-3.20.4.txt, jstack.txt > > > Under high load, Camel is taking a very long time to shutdown. The > investigation points to something happening while the ServicePool is stopping. > Note: this problem is still under investigation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-19759) performance: Camel is hanging up during shutdown
[ https://issues.apache.org/jira/browse/CAMEL-19759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Otavio Rodolfo Piske updated CAMEL-19759: - Attachment: called-twice-2.png called-twice-1.png > performance: Camel is hanging up during shutdown > > > Key: CAMEL-19759 > URL: https://issues.apache.org/jira/browse/CAMEL-19759 > Project: Camel > Issue Type: Bug >Affects Versions: 3.20.6 >Reporter: Otavio Rodolfo Piske >Assignee: Otavio Rodolfo Piske >Priority: Major > Attachments: called-twice-1.png, called-twice-2.png, dump3.hprof, > jstack-3.20.4.txt, jstack.txt > > > Under high load, Camel is taking a very long time to shutdown. The > investigation points to something happening while the ServicePool is stopping. > Note: this problem is still under investigation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-19768) HTTP message body encoded with wrong charset
Michael Pätzold created CAMEL-19768: --- Summary: HTTP message body encoded with wrong charset Key: CAMEL-19768 URL: https://issues.apache.org/jira/browse/CAMEL-19768 Project: Camel Issue Type: Bug Components: camel-http Affects Versions: 4.0.0 Reporter: Michael Pätzold I was facing an issue during migration from Camel 3 to 4 when routing HTTP requests that contain JSONs with special characters, e.g. German umlauts. In my case, this leads to a situation where the receiving Spring Boot service rejects the request, pointing out it's not readable. That's actually true since the request header states that the message is in UTF-8 while it actually is encoded in ISO 8859-1. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (CAMEL-19759) performance: Camel is hanging up during shutdown
[
https://issues.apache.org/jira/browse/CAMEL-19759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17756843#comment-17756843
]
Rhuan Rocha edited comment on CAMEL-19759 at 8/21/23 11:28 AM:
---
Hi [~orpiske]
Line 168 calls the cleanUp for each Pool instance inside the pool.
{code:java}
public void cleanUp() {
if (cache instanceof LRUCache) {
((LRUCache) cache).cleanUp();
}
pool.values().forEach(Pool::cleanUp);
} {code}
However, the SinglePool manipulates the singlePoolEvicted and is cleaning the
map at the cleanupEvicts method.
{code:java}
@Override
public void cleanUp() {
cleanupEvicts();
}
private void cleanupEvicts() {
if (!singlePoolEvicted.isEmpty()) {
for (Map.Entry> entry : singlePoolEvicted.entrySet())
{
Endpoint e = entry.getKey();
Pool p = entry.getValue();
doStop(e);
p.stop();
singlePoolEvicted.remove(e);
}
}
} {code}
With this, my understanding is that if the pool has at least one instance of
SinglePool, then the singlePoolEvicted will be cleared twice.
I said "It looks like lines 192 and 193 are not needed" and I'm not correct,
however, looks like to me it has some cases that the singlePoolEvicted can be
cleaned many times.
I'm uncertain about placing the cleanupEvicts within the SinglePool. It seems
to me that the responsibility for cleaning the singlePoolEvicted should not lie
with the SinglePool.
Is there a possibility of the cleanUp being called concurrently?
I'm not saying it is the problem, but if it is calling
singlePoolEvicted.remove() concureently, it has a chance of impacting the
singlePoolEvicted.clear(). Make sense?
was (Author: JIRAUSER297305):
Hi [~orpiske]
Line 168 calls the cleanUp for each Pool instance inside the pool.
{code:java}
public void cleanUp() {
if (cache instanceof LRUCache) {
((LRUCache) cache).cleanUp();
}
pool.values().forEach(Pool::cleanUp);
} {code}
However, the SinglePool manipulates the singlePoolEvicted and is cleaning the
map at the cleanupEvicts method.
{code:java}
@Override
public void cleanUp() {
cleanupEvicts();
}
private void cleanupEvicts() {
if (!singlePoolEvicted.isEmpty()) {
for (Map.Entry> entry : singlePoolEvicted.entrySet())
{
Endpoint e = entry.getKey();
Pool p = entry.getValue();
doStop(e);
p.stop();
singlePoolEvicted.remove(e);
}
}
} {code}
With this, my understanding is that if the pool has at least one instance of
SinglePool, then the singlePoolEvicted will be cleared twice.
I said "It looks like lines 192 and 193 are not needed" and I'm not correct,
however, looks like to me it has some cases that the singlePoolEvicted can be
cleaned many times.
I'm uncertain about placing the cleanupEvicts within the SinglePool. It seems
to me that the responsibility for cleaning the singlePoolEvicted should not lie
with the SinglePool.
Is there a possibility of the cleanUp being called concurrently?
I'm not saying it is the problem, but if it is calling
singlePoolEvicted.remove(), it has a chance of impacting the
singlePoolEvicted.clear(). Make sense?
> performance: Camel is hanging up during shutdown
>
>
> Key: CAMEL-19759
> URL: https://issues.apache.org/jira/browse/CAMEL-19759
> Project: Camel
> Issue Type: Bug
>Affects Versions: 3.20.6
>Reporter: Otavio Rodolfo Piske
>Assignee: Otavio Rodolfo Piske
>Priority: Major
> Attachments: dump3.hprof, jstack-3.20.4.txt, jstack.txt
>
>
> Under high load, Camel is taking a very long time to shutdown. The
> investigation points to something happening while the ServicePool is stopping.
> Note: this problem is still under investigation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CAMEL-19759) performance: Camel is hanging up during shutdown
[
https://issues.apache.org/jira/browse/CAMEL-19759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17756843#comment-17756843
]
Rhuan Rocha edited comment on CAMEL-19759 at 8/21/23 11:28 AM:
---
Hi [~orpiske]
Line 168 calls the cleanUp for each Pool instance inside the pool.
{code:java}
public void cleanUp() {
if (cache instanceof LRUCache) {
((LRUCache) cache).cleanUp();
}
pool.values().forEach(Pool::cleanUp);
} {code}
However, the SinglePool manipulates the singlePoolEvicted and is cleaning the
map at the cleanupEvicts method.
{code:java}
@Override
public void cleanUp() {
cleanupEvicts();
}
private void cleanupEvicts() {
if (!singlePoolEvicted.isEmpty()) {
for (Map.Entry> entry : singlePoolEvicted.entrySet())
{
Endpoint e = entry.getKey();
Pool p = entry.getValue();
doStop(e);
p.stop();
singlePoolEvicted.remove(e);
}
}
} {code}
With this, my understanding is that if the pool has at least one instance of
SinglePool, then the singlePoolEvicted will be cleared twice.
I said "It looks like lines 192 and 193 are not needed" and I'm not correct,
however, looks like to me it has some cases that the singlePoolEvicted can be
cleaned many times.
I'm uncertain about placing the cleanupEvicts within the SinglePool. It seems
to me that the responsibility for cleaning the singlePoolEvicted should not lie
with the SinglePool.
Is there a possibility of the cleanUp being called concurrently?
I'm not saying it is the problem, but if it is calling
singlePoolEvicted.remove() concurrently, it has a chance of impacting the
singlePoolEvicted.clear(). Make sense?
was (Author: JIRAUSER297305):
Hi [~orpiske]
Line 168 calls the cleanUp for each Pool instance inside the pool.
{code:java}
public void cleanUp() {
if (cache instanceof LRUCache) {
((LRUCache) cache).cleanUp();
}
pool.values().forEach(Pool::cleanUp);
} {code}
However, the SinglePool manipulates the singlePoolEvicted and is cleaning the
map at the cleanupEvicts method.
{code:java}
@Override
public void cleanUp() {
cleanupEvicts();
}
private void cleanupEvicts() {
if (!singlePoolEvicted.isEmpty()) {
for (Map.Entry> entry : singlePoolEvicted.entrySet())
{
Endpoint e = entry.getKey();
Pool p = entry.getValue();
doStop(e);
p.stop();
singlePoolEvicted.remove(e);
}
}
} {code}
With this, my understanding is that if the pool has at least one instance of
SinglePool, then the singlePoolEvicted will be cleared twice.
I said "It looks like lines 192 and 193 are not needed" and I'm not correct,
however, looks like to me it has some cases that the singlePoolEvicted can be
cleaned many times.
I'm uncertain about placing the cleanupEvicts within the SinglePool. It seems
to me that the responsibility for cleaning the singlePoolEvicted should not lie
with the SinglePool.
Is there a possibility of the cleanUp being called concurrently?
I'm not saying it is the problem, but if it is calling
singlePoolEvicted.remove() concureently, it has a chance of impacting the
singlePoolEvicted.clear(). Make sense?
> performance: Camel is hanging up during shutdown
>
>
> Key: CAMEL-19759
> URL: https://issues.apache.org/jira/browse/CAMEL-19759
> Project: Camel
> Issue Type: Bug
>Affects Versions: 3.20.6
>Reporter: Otavio Rodolfo Piske
>Assignee: Otavio Rodolfo Piske
>Priority: Major
> Attachments: dump3.hprof, jstack-3.20.4.txt, jstack.txt
>
>
> Under high load, Camel is taking a very long time to shutdown. The
> investigation points to something happening while the ServicePool is stopping.
> Note: this problem is still under investigation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CAMEL-19759) performance: Camel is hanging up during shutdown
[
https://issues.apache.org/jira/browse/CAMEL-19759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17756843#comment-17756843
]
Rhuan Rocha edited comment on CAMEL-19759 at 8/21/23 11:27 AM:
---
Hi [~orpiske]
Line 168 calls the cleanUp for each Pool instance inside the pool.
{code:java}
public void cleanUp() {
if (cache instanceof LRUCache) {
((LRUCache) cache).cleanUp();
}
pool.values().forEach(Pool::cleanUp);
} {code}
However, the SinglePool manipulates the singlePoolEvicted and is cleaning the
map at the cleanupEvicts method.
{code:java}
@Override
public void cleanUp() {
cleanupEvicts();
}
private void cleanupEvicts() {
if (!singlePoolEvicted.isEmpty()) {
for (Map.Entry> entry : singlePoolEvicted.entrySet())
{
Endpoint e = entry.getKey();
Pool p = entry.getValue();
doStop(e);
p.stop();
singlePoolEvicted.remove(e);
}
}
} {code}
With this, my understanding is that if the pool has at least one instance of
SinglePool, then the singlePoolEvicted will be cleared twice.
I said "It looks like lines 192 and 193 are not needed" and I'm not correct,
however, looks like to me it has some cases that the singlePoolEvicted can be
cleaned many times.
I'm uncertain about placing the cleanupEvicts within the SinglePool. It seems
to me that the responsibility for cleaning the singlePoolEvicted should not lie
with the SinglePool.
Is there a possibility of the cleanUp being called concurrently?
I'm not saying it is the problem, but if it is calling
singlePoolEvicted.remove(), it has a chance of impacting the
singlePoolEvicted.clear(). Make sense?
was (Author: JIRAUSER297305):
Hi [~orpiske]
Line 168 calls the cleanUp for each Pool instance inside the pool.
{code:java}
public void cleanUp() {
if (cache instanceof LRUCache) {
((LRUCache) cache).cleanUp();
}
pool.values().forEach(Pool::cleanUp);
} {code}
However, the SinglePool manipulates the singlePoolEvicted and is cleaning the
map at the cleanupEvicts method.
{code:java}
@Override
public void cleanUp() {
cleanupEvicts();
}
private void cleanupEvicts() {
if (!singlePoolEvicted.isEmpty()) {
for (Map.Entry> entry : singlePoolEvicted.entrySet())
{
Endpoint e = entry.getKey();
Pool p = entry.getValue();
doStop(e);
p.stop();
singlePoolEvicted.remove(e);
}
}
} {code}
With this, my understanding is that if the pool has at least one instance of
SinglePool, then the singlePoolEvicted will be cleared twice.
I said "It looks like lines 192 and 193 are not needed" and I'm not correct,
however, looks like to me it has some cases that the singlePoolEvicted can be
cleaned many times.
I'm uncertain about placing the cleanupEvicts within the SinglePool. It seems
to me that the responsibility for cleaning the singlePoolEvicted should not lie
with the SinglePool.
> performance: Camel is hanging up during shutdown
>
>
> Key: CAMEL-19759
> URL: https://issues.apache.org/jira/browse/CAMEL-19759
> Project: Camel
> Issue Type: Bug
>Affects Versions: 3.20.6
>Reporter: Otavio Rodolfo Piske
>Assignee: Otavio Rodolfo Piske
>Priority: Major
> Attachments: dump3.hprof, jstack-3.20.4.txt, jstack.txt
>
>
> Under high load, Camel is taking a very long time to shutdown. The
> investigation points to something happening while the ServicePool is stopping.
> Note: this problem is still under investigation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CAMEL-19759) performance: Camel is hanging up during shutdown
[
https://issues.apache.org/jira/browse/CAMEL-19759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17756843#comment-17756843
]
Rhuan Rocha edited comment on CAMEL-19759 at 8/21/23 11:21 AM:
---
Hi [~orpiske]
Line 168 calls the cleanUp for each Pool instance inside the pool.
{code:java}
public void cleanUp() {
if (cache instanceof LRUCache) {
((LRUCache) cache).cleanUp();
}
pool.values().forEach(Pool::cleanUp);
} {code}
However, the SinglePool manipulates the singlePoolEvicted and is cleaning the
map at the cleanupEvicts method.
{code:java}
@Override
public void cleanUp() {
cleanupEvicts();
}
private void cleanupEvicts() {
if (!singlePoolEvicted.isEmpty()) {
for (Map.Entry> entry : singlePoolEvicted.entrySet())
{
Endpoint e = entry.getKey();
Pool p = entry.getValue();
doStop(e);
p.stop();
singlePoolEvicted.remove(e);
}
}
} {code}
With this, my understanding is that if the pool has at least one instance of
SinglePool, then the singlePoolEvicted will be cleared twice.
I said "It looks like lines 192 and 193 are not needed" and I'm not correct,
however, looks like to me it has some cases that the singlePoolEvicted can be
cleaned many times.
I'm uncertain about placing the cleanupEvicts within the SinglePool. It seems
to me that the responsibility for cleaning the singlePoolEvicted should not lie
with the SinglePool.
was (Author: JIRAUSER297305):
Hi [~orpiske]
Line 188 calls the cleanUp for each Pool instance inside the pool.
{code:java}
public void cleanUp() {
if (cache instanceof LRUCache) {
((LRUCache) cache).cleanUp();
}
pool.values().forEach(Pool::cleanUp);
} {code}
However, the SinglePool manipulates the singlePoolEvicted and is cleaning the
map at the cleanupEvicts method.
{code:java}
@Override
public void cleanUp() {
cleanupEvicts();
}
private void cleanupEvicts() {
if (!singlePoolEvicted.isEmpty()) {
for (Map.Entry> entry : singlePoolEvicted.entrySet())
{
Endpoint e = entry.getKey();
Pool p = entry.getValue();
doStop(e);
p.stop();
singlePoolEvicted.remove(e);
}
}
} {code}
With this, my understanding is that if the pool has at least one instance of
SinglePool, then the singlePoolEvicted will be cleared twice.
I said "It looks like lines 192 and 193 are not needed" and I'm not correct,
however, looks like to me it has some cases that the singlePoolEvicted can be
cleaned many times.
I'm uncertain about placing the cleanupEvicts within the SinglePool. It seems
to me that the responsibility for cleaning the singlePoolEvicted should not lie
with the SinglePool.
> performance: Camel is hanging up during shutdown
>
>
> Key: CAMEL-19759
> URL: https://issues.apache.org/jira/browse/CAMEL-19759
> Project: Camel
> Issue Type: Bug
>Affects Versions: 3.20.6
>Reporter: Otavio Rodolfo Piske
>Assignee: Otavio Rodolfo Piske
>Priority: Major
> Attachments: dump3.hprof, jstack-3.20.4.txt, jstack.txt
>
>
> Under high load, Camel is taking a very long time to shutdown. The
> investigation points to something happening while the ServicePool is stopping.
> Note: this problem is still under investigation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-19759) performance: Camel is hanging up during shutdown
[
https://issues.apache.org/jira/browse/CAMEL-19759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17756843#comment-17756843
]
Rhuan Rocha commented on CAMEL-19759:
-
Hi [~orpiske]
Line 188 calls the cleanUp for each Pool instance inside the pool.
{code:java}
public void cleanUp() {
if (cache instanceof LRUCache) {
((LRUCache) cache).cleanUp();
}
pool.values().forEach(Pool::cleanUp);
} {code}
However, the SinglePool manipulates the singlePoolEvicted and is cleaning the
map at the cleanupEvicts method.
{code:java}
@Override
public void cleanUp() {
cleanupEvicts();
}
private void cleanupEvicts() {
if (!singlePoolEvicted.isEmpty()) {
for (Map.Entry> entry : singlePoolEvicted.entrySet())
{
Endpoint e = entry.getKey();
Pool p = entry.getValue();
doStop(e);
p.stop();
singlePoolEvicted.remove(e);
}
}
} {code}
With this, my understanding is that if the pool has at least one instance of
SinglePool, then the singlePoolEvicted will be cleared twice.
I said "It looks like lines 192 and 193 are not needed" and I'm not correct,
however, looks like to me it has some cases that the singlePoolEvicted can be
cleaned many times.
I'm uncertain about placing the cleanupEvicts within the SinglePool. It seems
to me that the responsibility for cleaning the singlePoolEvicted should not lie
with the SinglePool.
> performance: Camel is hanging up during shutdown
>
>
> Key: CAMEL-19759
> URL: https://issues.apache.org/jira/browse/CAMEL-19759
> Project: Camel
> Issue Type: Bug
>Affects Versions: 3.20.6
>Reporter: Otavio Rodolfo Piske
>Assignee: Otavio Rodolfo Piske
>Priority: Major
> Attachments: dump3.hprof, jstack-3.20.4.txt, jstack.txt
>
>
> Under high load, Camel is taking a very long time to shutdown. The
> investigation points to something happening while the ServicePool is stopping.
> Note: this problem is still under investigation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-19764) camel-openapi - basic and bearer token
[ https://issues.apache.org/jira/browse/CAMEL-19764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-19764: Fix Version/s: (was: 3.20.7) (was: 3.21.1) (was: 3.22.0) > camel-openapi - basic and bearer token > -- > > Key: CAMEL-19764 > URL: https://issues.apache.org/jira/browse/CAMEL-19764 > Project: Camel > Issue Type: Bug >Reporter: Claus Ibsen >Assignee: Karen Lease >Priority: Major > Fix For: 4.0.1, 4.1.0 > > > https://github.com/apache/camel/pull/10066#issuecomment-1684274569 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-19764) camel-openapi - basic and bearer token
[ https://issues.apache.org/jira/browse/CAMEL-19764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-19764: Affects Version/s: 4.0.0 > camel-openapi - basic and bearer token > -- > > Key: CAMEL-19764 > URL: https://issues.apache.org/jira/browse/CAMEL-19764 > Project: Camel > Issue Type: Bug >Affects Versions: 4.0.0 >Reporter: Claus Ibsen >Assignee: Karen Lease >Priority: Major > Fix For: 4.0.1, 4.1.0 > > > https://github.com/apache/camel/pull/10066#issuecomment-1684274569 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-19764) camel-openapi - basic and bearer token
[ https://issues.apache.org/jira/browse/CAMEL-19764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-19764. - Resolution: Fixed Thanks > camel-openapi - basic and bearer token > -- > > Key: CAMEL-19764 > URL: https://issues.apache.org/jira/browse/CAMEL-19764 > Project: Camel > Issue Type: Bug >Affects Versions: 4.0.0 >Reporter: Claus Ibsen >Assignee: Karen Lease >Priority: Major > Fix For: 4.0.1, 4.1.0 > > > https://github.com/apache/camel/pull/10066#issuecomment-1684274569 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (CAMEL-19764) camel-openapi - basic and bearer token
[ https://issues.apache.org/jira/browse/CAMEL-19764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17756782#comment-17756782 ] Karen Lease edited comment on CAMEL-19764 at 8/21/23 10:17 AM: --- The 3.x branches don't have this issue; it was introduced when I switched from apicurio to swagger in 4.x. was (Author: klease78): Ok. > camel-openapi - basic and bearer token > -- > > Key: CAMEL-19764 > URL: https://issues.apache.org/jira/browse/CAMEL-19764 > Project: Camel > Issue Type: Bug >Reporter: Claus Ibsen >Assignee: Karen Lease >Priority: Major > Fix For: 3.20.7, 3.21.1, 3.22.0, 4.0.1, 4.1.0 > > > https://github.com/apache/camel/pull/10066#issuecomment-1684274569 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-19764) camel-openapi - basic and bearer token
[ https://issues.apache.org/jira/browse/CAMEL-19764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17756782#comment-17756782 ] Karen Lease commented on CAMEL-19764: - Ok. > camel-openapi - basic and bearer token > -- > > Key: CAMEL-19764 > URL: https://issues.apache.org/jira/browse/CAMEL-19764 > Project: Camel > Issue Type: Bug >Reporter: Claus Ibsen >Assignee: Karen Lease >Priority: Major > Fix For: 3.20.7, 3.21.1, 3.22.0, 4.0.1, 4.1.0 > > > https://github.com/apache/camel/pull/10066#issuecomment-1684274569 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-19759) performance: Camel is hanging up during shutdown
[ https://issues.apache.org/jira/browse/CAMEL-19759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17756762#comment-17756762 ] Otavio Rodolfo Piske commented on CAMEL-19759: -- [~rhuanrocha] I am not entirely sure. Why do you think so? > performance: Camel is hanging up during shutdown > > > Key: CAMEL-19759 > URL: https://issues.apache.org/jira/browse/CAMEL-19759 > Project: Camel > Issue Type: Bug >Affects Versions: 3.20.6 >Reporter: Otavio Rodolfo Piske >Assignee: Otavio Rodolfo Piske >Priority: Major > Attachments: dump3.hprof, jstack-3.20.4.txt, jstack.txt > > > Under high load, Camel is taking a very long time to shutdown. The > investigation points to something happening while the ServicePool is stopping. > Note: this problem is still under investigation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-18998) camel-ftp: FromFileToFtpSplitParallelIT tests a hanging up
[ https://issues.apache.org/jira/browse/CAMEL-18998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Otavio Rodolfo Piske updated CAMEL-18998: - Fix Version/s: 4.1.0 (was: Future) > camel-ftp: FromFileToFtpSplitParallelIT tests a hanging up > -- > > Key: CAMEL-18998 > URL: https://issues.apache.org/jira/browse/CAMEL-18998 > Project: Camel > Issue Type: Test >Affects Versions: 4.0-M1 >Reporter: Otavio Rodolfo Piske >Assignee: Nikita_Konovalov >Priority: Major > Labels: easy, help-wanted > Fix For: 4.1.0 > > Attachments: camel-ftp-test.log > > > Since we upgraded to surefire + failsafe M8, some of our tests have started > to hang up. > The logs from a manual execution is attached. > > [^camel-ftp-test.log] > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-19741) camel-sjms: refactor to support concurrent tests
[ https://issues.apache.org/jira/browse/CAMEL-19741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Otavio Rodolfo Piske resolved CAMEL-19741. -- Resolution: Fixed Flakiness seems to have been resolved. > camel-sjms: refactor to support concurrent tests > > > Key: CAMEL-19741 > URL: https://issues.apache.org/jira/browse/CAMEL-19741 > Project: Camel > Issue Type: Task > Components: camel-sjms >Reporter: Otavio Rodolfo Piske >Assignee: Nikita_Konovalov >Priority: Major > Fix For: 4.1.0 > > > We need to make the camel-sjms tests run in parallel. To do so, we need to > rework them to not use the same resources, as such, names of queues, topics, > files and other non-shareable resources need to be adjusted. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-18998) camel-ftp: FromFileToFtpSplitParallelIT tests a hanging up
[ https://issues.apache.org/jira/browse/CAMEL-18998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17756755#comment-17756755 ] Otavio Rodolfo Piske commented on CAMEL-18998: -- We are still looking at the CI, to make sure it is not flaky. We might close it in a few days. > camel-ftp: FromFileToFtpSplitParallelIT tests a hanging up > -- > > Key: CAMEL-18998 > URL: https://issues.apache.org/jira/browse/CAMEL-18998 > Project: Camel > Issue Type: Test >Affects Versions: 4.0-M1 >Reporter: Otavio Rodolfo Piske >Assignee: Nikita_Konovalov >Priority: Major > Labels: easy, help-wanted > Fix For: Future > > Attachments: camel-ftp-test.log > > > Since we upgraded to surefire + failsafe M8, some of our tests have started > to hang up. > The logs from a manual execution is attached. > > [^camel-ftp-test.log] > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-19767) camel-core: test should not catch AssertionError
Nikita_Konovalov created CAMEL-19767:
Summary: camel-core: test should not catch AssertionError
Key: CAMEL-19767
URL: https://issues.apache.org/jira/browse/CAMEL-19767
Project: Camel
Issue Type: Task
Components: camel-core
Reporter: Nikita_Konovalov
Assignee: Nikita_Konovalov
??Regarding the first set of changes ...??
??I think catching an {{AssertionError}} is not an adequate test practice. That
deviates from the actual purpose of the AssertionError which is to indicate
that the test has failed.??
??For now, let's keep the original as is. Let's create a ticket on Apache Jira
to note that this is a bad practice that must be fixed.??
Quoting [~orpiske]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
