[jira] [Updated] (CAMEL-14153) camel-main - Allow to specify constructor parameters
[
https://issues.apache.org/jira/browse/CAMEL-14153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-14153:
Description:
For example when configuring jms with amq/qpid etc then they have constructor
parameters
{code}
camel.component.jms.connection-factory=#class:org.apache.qpid.jms.JmsConnectionFactory("")
{code}
Where ("xxx") are constructor parameters
was:
For example when configuring jms with amq/qpid etc then they have constructor
parameters
{code}
camel.component.jms.connection-factory=#class:xxx("")
{code}
Where ("xxx") are constructor parameters
> camel-main - Allow to specify constructor parameters
>
>
> Key: CAMEL-14153
> URL: https://issues.apache.org/jira/browse/CAMEL-14153
> Project: Camel
> Issue Type: New Feature
> Components: camel-main
>Reporter: Claus Ibsen
>Assignee: Claus Ibsen
>Priority: Major
> Fix For: 3.0.0
>
>
> For example when configuring jms with amq/qpid etc then they have constructor
> parameters
> {code}
> camel.component.jms.connection-factory=#class:org.apache.qpid.jms.JmsConnectionFactory("")
> {code}
> Where ("xxx") are constructor parameters
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CAMEL-14153) camel-main - Allow to specify constructor parameters
Claus Ibsen created CAMEL-14153:
---
Summary: camel-main - Allow to specify constructor parameters
Key: CAMEL-14153
URL: https://issues.apache.org/jira/browse/CAMEL-14153
Project: Camel
Issue Type: New Feature
Components: camel-main
Reporter: Claus Ibsen
Assignee: Claus Ibsen
Fix For: 3.0.0
For example when configuring jms with amq/qpid etc then they have constructor
parameters
{code}
camel.component.jms.connection-factory=#class:xxx("")
{code}
Where ("xxx") are constructor parameters
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CAMEL-14131) documentation - Remove old subversion links from docs
[ https://issues.apache.org/jira/browse/CAMEL-14131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-14131. - Assignee: Claus Ibsen Resolution: Fixed > documentation - Remove old subversion links from docs > - > > Key: CAMEL-14131 > URL: https://issues.apache.org/jira/browse/CAMEL-14131 > Project: Camel > Issue Type: Task > Components: documentation >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Major > Fix For: 3.0.0 > > > Remove old links from when we used subversion > git grep "http://svn; -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-14140) Remove global dependency on outdated guava
[ https://issues.apache.org/jira/browse/CAMEL-14140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16969830#comment-16969830 ] Claus Ibsen commented on CAMEL-14140: - The karaf features are affected and a bunch of them fails, where we need to hardcode them to use older guava versions > Remove global dependency on outdated guava > -- > > Key: CAMEL-14140 > URL: https://issues.apache.org/jira/browse/CAMEL-14140 > Project: Camel > Issue Type: Task > Components: camel-cassandraql >Reporter: Thomas Diesler >Assignee: Thomas Diesler >Priority: Major > Fix For: 3.0.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Currently, camel comes with google-guava-version=19.0 which contains a number > of deprecated APIs that have been removed in 20.x. AFAICS, cassandra-3.x is > the only component that depends on these deprecated guava APIs. This > dependency has been removed in cassandra-4.x, which is currently in alpha. In > WildFly-Camel, I confirmed that it should generally be possible to update to > guava-26.x as long as cassandra can still use 19.x -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CAMEL-14010) Camel-Kafka ConsumerCount drops to 1 (default) from the defined value
[
https://issues.apache.org/jira/browse/CAMEL-14010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-14010.
-
Fix Version/s: 3.0.0.RC3
3.0.0
Resolution: Fixed
> Camel-Kafka ConsumerCount drops to 1 (default) from the defined value
> -
>
> Key: CAMEL-14010
> URL: https://issues.apache.org/jira/browse/CAMEL-14010
> Project: Camel
> Issue Type: Bug
> Components: camel-kafka
>Affects Versions: 2.22.0
>Reporter: Srikant Mantha
>Priority: Major
> Fix For: 3.0.0, 3.0.0.RC3
>
>
> Iam using kafka consumer in our application integrated with Camel.
> We consume the messages and send the data to the server for processing.
> There is one topic "*XYZ*" defined with *30* partitions and I have assigned
> *15* as consumer count on each consumer node (total 2 instances)
> /*** Camel Consumer Configuration ***/
> {code:java}
> kafka.consumersCount=15
> kafka.consumerStreams=15{code}
> {{I see from the logs that when the consumer starts, there are *15* consumer
> threads (lets say on 1 node), which is good as configured.I see from the logs
> that when the consumer starts, there are 15 consumer threads (lets say on 1
> node), which is good as configured.}}
>
>
> {code:java}
> {code}
> {{INFO Camel (camel-1) thread #2 - KafkaConsumer[XYZ]
> [camel.component.kafka.KafkaConsumer(doRun:222)] Subscribing XYZ-Thread 0 to
> topic XYZ }}
> {{INFO Camel (camel-1) thread #3 - KafkaConsumer[XYZ]
> [camel.component.kafka.KafkaConsumer(doRun:222)] Subscribing XYZ-Thread 1 to
> topic XYZ }}
> {{INFO Camel (camel-1) thread #4 - KafkaConsumer[XYZ]
> [camel.component.kafka.KafkaConsumer(doRun:222)] Subscribing XYZ-Thread 2 to
> topic XYZ }}
> {{INFO Camel (camel-1) thread #5 - KafkaConsumer[XYZ]
> [camel.component.kafka.KafkaConsumer(doRun:222)] Subscribing XYZ-Thread 3 to
> topic XYZ }}
> {{INFO Camel (camel-1) thread #6 - KafkaConsumer[XYZ]
> [camel.component.kafka.KafkaConsumer(doRun:222)] Subscribing XYZ-Thread 4 to
> topic XYZ }}
> {{INFO Camel (camel-1) thread #7 - KafkaConsumer[XYZ]
> [camel.component.kafka.KafkaConsumer(doRun:222)] Subscribing XYZ-Thread 5 to
> topic XYZ }}
> {{INFO Camel (camel-1) thread #8 - KafkaConsumer[XYZ]
> [camel.component.kafka.KafkaConsumer(doRun:222)] Subscribing XYZ-Thread 6 to
> topic XYZ }}
> {{INFO Camel (camel-1) thread #9 - KafkaConsumer[XYZ]
> [camel.component.kafka.KafkaConsumer(doRun:222)] Subscribing XYZ-Thread 7 to
> topic XYZ }}
> {{INFO Camel (camel-1) thread #10 - KafkaConsumer[XYZ]
> [camel.component.kafka.KafkaConsumer(doRun:222)] Subscribing XYZ-Thread 8 to
> topic XYZ }}
> {{INFO Camel (camel-1) thread #11 - KafkaConsumer[XYZ]
> [camel.component.kafka.KafkaConsumer(doRun:222)] Subscribing XYZ-Thread 9 to
> topic XYZ }}
> {{INFO Camel (camel-1) thread #12 - KafkaConsumer[XYZ]
> [camel.component.kafka.KafkaConsumer(doRun:222)] Subscribing XYZ-Thread 10 to
> topic XYZ }}
> {{INFO Camel (camel-1) thread #13 - KafkaConsumer[XYZ]
> [camel.component.kafka.KafkaConsumer(doRun:222)] Subscribing XYZ-Thread 11 to
> topic XYZ }}
> {{INFO Camel (camel-1) thread #14 - KafkaConsumer[XYZ]
> [camel.component.kafka.KafkaConsumer(doRun:222)] Subscribing XYZ-Thread 12 to
> topic XYZ }}
> {{INFO Camel (camel-1) thread #15 - KafkaConsumer[XYZ]
> [camel.component.kafka.KafkaConsumer(doRun:222)] Subscribing XYZ-Thread 13 to
> topic XYZ }}
> {{INFO Camel (camel-1) thread #16 - KafkaConsumer[XYZ]
> [camel.component.kafka.KafkaConsumer(doRun:222)] Subscribing XYZ-Thread 14 to
> topic XYZ}}
>
> If server stops responding due to network issue or any other scenario when
> the server is unavailable, then all the kafka consumers starts unsubscribing
> which is again an expected behavior (so far good)
> Note: We have defined the Camel
> {code:java}
> ThrottlingExceptionRoutePolicy {code}
> which does a health check call on the server before sending the consumed
> message.
> Once the server is back and available, *I see that not all 15 consumer
> threads are active*, but only 1 (*I guess this is the default value*).
> From the logs below, I observe that the consumerss are getting subscribed and
> unsubscribed one by one from the topic and finally the application runs with
> only a single consumer count. This is really strange to see.
> {{INFO Camel (camel-1) thread #17 - KafkaConsumer[XYZ]
> [camel.component.kafka.KafkaConsumer(doRun:222)] Subscribing XYZ-Thread 0 to
> topic XYZ }}
> {{INFO [kafka.clients.consumer.ConsumerConfig(logAll:238)] ConsumerConfig
> values: Prints all the consumer config values defined/undefined }}
> {{auto.commit.interval.ms = 5000 }}
> {{auto.offset.reset = latest }}
> {{bootstrap.servers = [ListOfDefinedServers] }}
> {{check.crcs = true }}
>
[jira] [Commented] (CAMEL-13643) Change Spring Boot starters Maven group ID
[
https://issues.apache.org/jira/browse/CAMEL-13643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16969468#comment-16969468
]
Claus Ibsen commented on CAMEL-13643:
-
Ideally we should never have dual releases of -starter JARs as its to massive
pain to maintain so many artifacts. When SB3 comes out, then we upgrade to SB3
in a newer Camel 3.x release and drop SB2 if SB3 is not backwards compatible
(like SB2 and SB1 was not).
So the groupid can be hardcoded to org.apache.camel.springboot.
This change is not trivial, as there are tooling we have built that works with
org.apache.camel as the group id.
> Change Spring Boot starters Maven group ID
> --
>
> Key: CAMEL-13643
> URL: https://issues.apache.org/jira/browse/CAMEL-13643
> Project: Camel
> Issue Type: Task
> Components: camel-spring-boot, camel-spring-boot-starters
>Reporter: Zoran Regvart
>Assignee: Zoran Regvart
>Priority: Major
> Fix For: 3.x
>
>
> In order to allow for different kinds of _starters_ in the future, for
> example different versions of Spring Boot we should change the Maven group ID
> of Spring Boot, currently {{org.apache.camel}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CAMEL-14152) Add RocksDB Aggregator to Camel
[ https://issues.apache.org/jira/browse/CAMEL-14152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16969463#comment-16969463 ] Claus Ibsen commented on CAMEL-14152: - They clearly indicate that its a dual licensed project and has been this for 2 years. So I would says its fine to add this. Also if you search for rocksdb on maven search you see other Apache projects that seems to use it (flink, samza etc) https://search.maven.org/ > Add RocksDB Aggregator to Camel > > > Key: CAMEL-14152 > URL: https://issues.apache.org/jira/browse/CAMEL-14152 > Project: Camel > Issue Type: New Feature >Reporter: Omar Al-Safi >Assignee: Omar Al-Safi >Priority: Minor > Fix For: 3.x > > > Although we have LevelDB Aggregator in Camel, I thought it will be as well > beneficial for users to have as well RocksDB Aggregator. Although RocksDB is > basically based on LevelDB, I think Facebook has done great optimizations on > it to have a good performance on sample data bigger than the machine's RAM. > I can work on it after we release 3.0.0 GA -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CAMEL-14148) exception during first resolve of temporary jms destination causes infinitive wait
[
https://issues.apache.org/jira/browse/CAMEL-14148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-14148.
-
Fix Version/s: 2.24.3
Resolution: Fixed
> exception during first resolve of temporary jms destination causes infinitive
> wait
> --
>
> Key: CAMEL-14148
> URL: https://issues.apache.org/jira/browse/CAMEL-14148
> Project: Camel
> Issue Type: Bug
> Components: camel-jms
>Affects Versions: 2.24.2
>Reporter: Bas Claessen
>Priority: Minor
> Fix For: 2.24.3, 3.0.0, 2.25.0
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> An exception during the first attempt to resolve a temporary destination will
> cause an infinitive wait for next resolve attempts after the exception is
> cleared.
> A likely scenario for this behaviour to occur is when no connection to a jms
> server can be established during startup.
> This bug is caused by not setting the refreshWanted to false when no previous
> destination exists in the
> org.apache.camel.component.jms.reply.TemporaryQueueReplyManager$TemporaryReplyQueueDestinationResolver
> class.
> {code:java}
> public Destination resolveDestinationName(Session session, String
> destinationName, boolean pubSubDomain) throws JMSException {
> // use a temporary queue to gather the reply message
> synchronized (refreshWanted) {
> if (queue == null || refreshWanted.compareAndSet(true, false)) {
> queue = session.createTemporaryQueue();
> setReplyTo(queue);
> if (log.isDebugEnabled()) {
> log.debug("Refreshed Temporary ReplyTo Queue. New queue: {}",
> queue.getQueueName());
> }
> refreshWanted.notifyAll();
> }
> }
> return queue;
> }
> {code}
> When queue == null the refreshWanted.compareAndSet(true, false) is not
> executed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CAMEL-14148) exception during first resolve of temporary jms destination causes infinitive wait
[
https://issues.apache.org/jira/browse/CAMEL-14148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-14148:
Fix Version/s: 2.25.0
3.0.0
> exception during first resolve of temporary jms destination causes infinitive
> wait
> --
>
> Key: CAMEL-14148
> URL: https://issues.apache.org/jira/browse/CAMEL-14148
> Project: Camel
> Issue Type: Bug
> Components: camel-jms
>Affects Versions: 2.24.2
>Reporter: Bas Claessen
>Priority: Minor
> Fix For: 3.0.0, 2.25.0
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> An exception during the first attempt to resolve a temporary destination will
> cause an infinitive wait for next resolve attempts after the exception is
> cleared.
> A likely scenario for this behaviour to occur is when no connection to a jms
> server can be established during startup.
> This bug is caused by not setting the refreshWanted to false when no previous
> destination exists in the
> org.apache.camel.component.jms.reply.TemporaryQueueReplyManager$TemporaryReplyQueueDestinationResolver
> class.
> {code:java}
> public Destination resolveDestinationName(Session session, String
> destinationName, boolean pubSubDomain) throws JMSException {
> // use a temporary queue to gather the reply message
> synchronized (refreshWanted) {
> if (queue == null || refreshWanted.compareAndSet(true, false)) {
> queue = session.createTemporaryQueue();
> setReplyTo(queue);
> if (log.isDebugEnabled()) {
> log.debug("Refreshed Temporary ReplyTo Queue. New queue: {}",
> queue.getQueueName());
> }
> refreshWanted.notifyAll();
> }
> }
> return queue;
> }
> {code}
> When queue == null the refreshWanted.compareAndSet(true, false) is not
> executed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (CAMEL-14148) exception during first resolve of temporary jms destination causes infinitive wait
[
https://issues.apache.org/jira/browse/CAMEL-14148?focusedWorklogId=340054=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-340054
]
ASF GitHub Bot logged work on CAMEL-14148:
--
Author: ASF GitHub Bot
Created on: 07/Nov/19 17:40
Start Date: 07/Nov/19 17:40
Worklog Time Spent: 10m
Work Description: davsclaus commented on pull request #3327: CAMEL-14148
fix (camel-2.x)
URL: https://github.com/apache/camel/pull/3327
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 340054)
Time Spent: 1h 20m (was: 1h 10m)
> exception during first resolve of temporary jms destination causes infinitive
> wait
> --
>
> Key: CAMEL-14148
> URL: https://issues.apache.org/jira/browse/CAMEL-14148
> Project: Camel
> Issue Type: Bug
> Components: camel-jms
>Affects Versions: 2.24.2
>Reporter: Bas Claessen
>Priority: Minor
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> An exception during the first attempt to resolve a temporary destination will
> cause an infinitive wait for next resolve attempts after the exception is
> cleared.
> A likely scenario for this behaviour to occur is when no connection to a jms
> server can be established during startup.
> This bug is caused by not setting the refreshWanted to false when no previous
> destination exists in the
> org.apache.camel.component.jms.reply.TemporaryQueueReplyManager$TemporaryReplyQueueDestinationResolver
> class.
> {code:java}
> public Destination resolveDestinationName(Session session, String
> destinationName, boolean pubSubDomain) throws JMSException {
> // use a temporary queue to gather the reply message
> synchronized (refreshWanted) {
> if (queue == null || refreshWanted.compareAndSet(true, false)) {
> queue = session.createTemporaryQueue();
> setReplyTo(queue);
> if (log.isDebugEnabled()) {
> log.debug("Refreshed Temporary ReplyTo Queue. New queue: {}",
> queue.getQueueName());
> }
> refreshWanted.notifyAll();
> }
> }
> return queue;
> }
> {code}
> When queue == null the refreshWanted.compareAndSet(true, false) is not
> executed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CAMEL-13922) http4 does not recognize part of URI provided with header
[
https://issues.apache.org/jira/browse/CAMEL-13922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16969378#comment-16969378
]
Onder Sezgin commented on CAMEL-13922:
--
the issue is invalid but the expectation is valid at some point. i was fallen
the same trap with similar use cases, it may be an enhancement. if there is no
known stopper.
> http4 does not recognize part of URI provided with header
> -
>
> Key: CAMEL-13922
> URL: https://issues.apache.org/jira/browse/CAMEL-13922
> Project: Camel
> Issue Type: Bug
> Components: camel-http4
>Affects Versions: 2.24.1
>Reporter: Vyacheslav Boyko
>Priority: Major
>
> I'm trying to describe a route with Enrich EIP. It should be done as:
> 1) template producer gives an year (2019, 2012 etc), set it in header and
> push the message into route
> 2) from that endpoint message should be enriched from URI composed by
> template:
> {code:java}
> from("seda:calendar-update-process")
> .setHeader("calendar-uri",
> simple("xmlcalendar.ru/data/ru/${header["+HEADER_YEAR+"]}/calendar.xml"))
> .log(LoggingLevel.WARN, log, "Updating calendar from url:
> ${header.calendar-uri}")
> .enrich("http4:$\\{header.calendar-uri\\}", (oldExchange,
> newExchange) -> {
> oldExchange.getIn().setBody(newExchange.getIn().getBody());
> return oldExchange;
> })
> {code}
> {color:#6a8759}{color}{color:#6a8759}as described on{color}
> [https://camel.apache.org/manual/latest/content-enricher.html] in part named
> 'Using dynamic uris'
>
> But it cannot parse that expression. I get an error:
>
> {code:java}
> org.apache.camel.ResolveEndpointFailedException: Failed to resolve endpoint:
> http4://$%5C%7Bheader.calendar-uri%5C%7D due to: Expected scheme-specific
> part at index 6: http4:
> at
> org.apache.camel.impl.DefaultCamelContext.getEndpoint(DefaultCamelContext.java:753)
> at
> org.apache.camel.util.CamelContextHelper.getMandatoryEndpoint(CamelContextHelper.java:80)
> at
> org.apache.camel.util.ExchangeHelper.resolveEndpoint(ExchangeHelper.java:91)
> at
> org.apache.camel.processor.Enricher.resolveEndpoint(Enricher.java:299)
> at org.apache.camel.processor.Enricher.process(Enricher.java:165)
> at
> org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:548)
> at
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:201)
> at org.apache.camel.processor.Pipeline.process(Pipeline.java:138)
> at org.apache.camel.processor.Pipeline.process(Pipeline.java:101)
> at
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:201)
> at
> org.apache.camel.component.seda.SedaConsumer.sendToConsumers(SedaConsumer.java:298)
> at
> org.apache.camel.component.seda.SedaConsumer.doRun(SedaConsumer.java:210)
> at
> org.apache.camel.component.seda.SedaConsumer.run(SedaConsumer.java:155)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.net.URISyntaxException: Expected scheme-specific part at
> index 6: http4:
> at java.net.URI$Parser.fail(URI.java:2848)
> at java.net.URI$Parser.failExpecting(URI.java:2854)
> at java.net.URI$Parser.parse(URI.java:3057)
> at java.net.URI.(URI.java:673)
> at
> org.apache.camel.component.http4.HttpComponent.createEndpoint(HttpComponent.java:269)
> at
> org.apache.camel.impl.DefaultComponent.createEndpoint(DefaultComponent.java:130)
> at
> org.apache.camel.impl.DefaultCamelContext.getEndpoint(DefaultCamelContext.java:706)
> ... 15 common frames omitted
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CAMEL-13643) Change Spring Boot starters Maven group ID
[
https://issues.apache.org/jira/browse/CAMEL-13643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16969377#comment-16969377
]
Andrea Tarocchi commented on CAMEL-13643:
-
In the interest of not modifying too much things on short notice before camel 3
release, we can keep {{org.apache.camel.springboot}} for sb2 and eventually use
{{org.apache.camel.springboot3}} when/if sb3 will come out.
> Change Spring Boot starters Maven group ID
> --
>
> Key: CAMEL-13643
> URL: https://issues.apache.org/jira/browse/CAMEL-13643
> Project: Camel
> Issue Type: Task
> Components: camel-spring-boot, camel-spring-boot-starters
>Reporter: Zoran Regvart
>Assignee: Zoran Regvart
>Priority: Major
> Fix For: 3.x
>
>
> In order to allow for different kinds of _starters_ in the future, for
> example different versions of Spring Boot we should change the Maven group ID
> of Spring Boot, currently {{org.apache.camel}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CAMEL-14148) exception during first resolve of temporary jms destination causes infinitive wait
[
https://issues.apache.org/jira/browse/CAMEL-14148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16969330#comment-16969330
]
Bas Claessen commented on CAMEL-14148:
--
Added PRs for master and camel-2.x
> exception during first resolve of temporary jms destination causes infinitive
> wait
> --
>
> Key: CAMEL-14148
> URL: https://issues.apache.org/jira/browse/CAMEL-14148
> Project: Camel
> Issue Type: Bug
> Components: camel-jms
>Affects Versions: 2.24.2
>Reporter: Bas Claessen
>Priority: Minor
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> An exception during the first attempt to resolve a temporary destination will
> cause an infinitive wait for next resolve attempts after the exception is
> cleared.
> A likely scenario for this behaviour to occur is when no connection to a jms
> server can be established during startup.
> This bug is caused by not setting the refreshWanted to false when no previous
> destination exists in the
> org.apache.camel.component.jms.reply.TemporaryQueueReplyManager$TemporaryReplyQueueDestinationResolver
> class.
> {code:java}
> public Destination resolveDestinationName(Session session, String
> destinationName, boolean pubSubDomain) throws JMSException {
> // use a temporary queue to gather the reply message
> synchronized (refreshWanted) {
> if (queue == null || refreshWanted.compareAndSet(true, false)) {
> queue = session.createTemporaryQueue();
> setReplyTo(queue);
> if (log.isDebugEnabled()) {
> log.debug("Refreshed Temporary ReplyTo Queue. New queue: {}",
> queue.getQueueName());
> }
> refreshWanted.notifyAll();
> }
> }
> return queue;
> }
> {code}
> When queue == null the refreshWanted.compareAndSet(true, false) is not
> executed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (CAMEL-14148) exception during first resolve of temporary jms destination causes infinitive wait
[
https://issues.apache.org/jira/browse/CAMEL-14148?focusedWorklogId=339985=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-339985
]
ASF GitHub Bot logged work on CAMEL-14148:
--
Author: ASF GitHub Bot
Created on: 07/Nov/19 15:05
Start Date: 07/Nov/19 15:05
Worklog Time Spent: 10m
Work Description: basclaessen commented on pull request #3327:
CAMEL-14148 fix (camel-2.x)
URL: https://github.com/apache/camel/pull/3327
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 339985)
Time Spent: 1h 10m (was: 1h)
> exception during first resolve of temporary jms destination causes infinitive
> wait
> --
>
> Key: CAMEL-14148
> URL: https://issues.apache.org/jira/browse/CAMEL-14148
> Project: Camel
> Issue Type: Bug
> Components: camel-jms
>Affects Versions: 2.24.2
>Reporter: Bas Claessen
>Priority: Minor
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> An exception during the first attempt to resolve a temporary destination will
> cause an infinitive wait for next resolve attempts after the exception is
> cleared.
> A likely scenario for this behaviour to occur is when no connection to a jms
> server can be established during startup.
> This bug is caused by not setting the refreshWanted to false when no previous
> destination exists in the
> org.apache.camel.component.jms.reply.TemporaryQueueReplyManager$TemporaryReplyQueueDestinationResolver
> class.
> {code:java}
> public Destination resolveDestinationName(Session session, String
> destinationName, boolean pubSubDomain) throws JMSException {
> // use a temporary queue to gather the reply message
> synchronized (refreshWanted) {
> if (queue == null || refreshWanted.compareAndSet(true, false)) {
> queue = session.createTemporaryQueue();
> setReplyTo(queue);
> if (log.isDebugEnabled()) {
> log.debug("Refreshed Temporary ReplyTo Queue. New queue: {}",
> queue.getQueueName());
> }
> refreshWanted.notifyAll();
> }
> }
> return queue;
> }
> {code}
> When queue == null the refreshWanted.compareAndSet(true, false) is not
> executed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CAMEL-14152) Add RocksDB Aggregator to Camel
[ https://issues.apache.org/jira/browse/CAMEL-14152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16969324#comment-16969324 ] Jean-Baptiste Onofré commented on CAMEL-14152: -- I would rather add this in camel-extra: https://github.com/camel-extra/camel-extra It's where I added some "non Apache" licensed connector. > Add RocksDB Aggregator to Camel > > > Key: CAMEL-14152 > URL: https://issues.apache.org/jira/browse/CAMEL-14152 > Project: Camel > Issue Type: New Feature >Reporter: Omar Al-Safi >Assignee: Omar Al-Safi >Priority: Minor > Fix For: 3.x > > > Although we have LevelDB Aggregator in Camel, I thought it will be as well > beneficial for users to have as well RocksDB Aggregator. Although RocksDB is > basically based on LevelDB, I think Facebook has done great optimizations on > it to have a good performance on sample data bigger than the machine's RAM. > I can work on it after we release 3.0.0 GA -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-14152) Add RocksDB Aggregator to Camel
[ https://issues.apache.org/jira/browse/CAMEL-14152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16969320#comment-16969320 ] Andrea Cosentino commented on CAMEL-14152: -- I just don't want to create legal trouble, personally I don't like double licensed project, it's not clear what you get, what you can and what you can't do, and so on. Since there is this doubt, I'd prefer to avoid using this kind of projects. [~davsclaus] and other committers and PMC member, what do you think? > Add RocksDB Aggregator to Camel > > > Key: CAMEL-14152 > URL: https://issues.apache.org/jira/browse/CAMEL-14152 > Project: Camel > Issue Type: New Feature >Reporter: Omar Al-Safi >Assignee: Omar Al-Safi >Priority: Minor > Fix For: 3.x > > > Although we have LevelDB Aggregator in Camel, I thought it will be as well > beneficial for users to have as well RocksDB Aggregator. Although RocksDB is > basically based on LevelDB, I think Facebook has done great optimizations on > it to have a good performance on sample data bigger than the machine's RAM. > I can work on it after we release 3.0.0 GA -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-14152) Add RocksDB Aggregator to Camel
[ https://issues.apache.org/jira/browse/CAMEL-14152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16969318#comment-16969318 ] Omar Al-Safi commented on CAMEL-14152: -- interesting they added the Apache 2.0 licence 2 years go https://github.com/facebook/rocksdb/commits/master/LICENSE.Apache > Add RocksDB Aggregator to Camel > > > Key: CAMEL-14152 > URL: https://issues.apache.org/jira/browse/CAMEL-14152 > Project: Camel > Issue Type: New Feature >Reporter: Omar Al-Safi >Assignee: Omar Al-Safi >Priority: Minor > Fix For: 3.x > > > Although we have LevelDB Aggregator in Camel, I thought it will be as well > beneficial for users to have as well RocksDB Aggregator. Although RocksDB is > basically based on LevelDB, I think Facebook has done great optimizations on > it to have a good performance on sample data bigger than the machine's RAM. > I can work on it after we release 3.0.0 GA -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-14152) Add RocksDB Aggregator to Camel
[ https://issues.apache.org/jira/browse/CAMEL-14152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16969317#comment-16969317 ] Omar Al-Safi commented on CAMEL-14152: -- As I see from here: https://github.com/facebook/rocksdb, is a dual licence GPLv2 and Apache 2.0. As I recall, it is as well included in Apache Kafka Streams library https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Streams+Internal+Data+Management#:~:targetText=RocksDB%20is%20just%20used%20as,created%20for%20fault%2Dtolerance%20reasons. > Add RocksDB Aggregator to Camel > > > Key: CAMEL-14152 > URL: https://issues.apache.org/jira/browse/CAMEL-14152 > Project: Camel > Issue Type: New Feature >Reporter: Omar Al-Safi >Assignee: Omar Al-Safi >Priority: Minor > Fix For: 3.x > > > Although we have LevelDB Aggregator in Camel, I thought it will be as well > beneficial for users to have as well RocksDB Aggregator. Although RocksDB is > basically based on LevelDB, I think Facebook has done great optimizations on > it to have a good performance on sample data bigger than the machine's RAM. > I can work on it after we release 3.0.0 GA -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-14152) Add RocksDB Aggregator to Camel
[ https://issues.apache.org/jira/browse/CAMEL-14152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16969315#comment-16969315 ] Andrea Cosentino commented on CAMEL-14152: -- So it cannot be included. > Add RocksDB Aggregator to Camel > > > Key: CAMEL-14152 > URL: https://issues.apache.org/jira/browse/CAMEL-14152 > Project: Camel > Issue Type: New Feature >Reporter: Omar Al-Safi >Assignee: Omar Al-Safi >Priority: Minor > Fix For: 3.x > > > Although we have LevelDB Aggregator in Camel, I thought it will be as well > beneficial for users to have as well RocksDB Aggregator. Although RocksDB is > basically based on LevelDB, I think Facebook has done great optimizations on > it to have a good performance on sample data bigger than the machine's RAM. > I can work on it after we release 3.0.0 GA -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (CAMEL-14152) Add RocksDB Aggregator to Camel
[ https://issues.apache.org/jira/browse/CAMEL-14152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16969314#comment-16969314 ] Andrea Cosentino edited comment on CAMEL-14152 at 11/7/19 2:46 PM: --- Rocksdb is licensed under GNU GPL which is not compatible with ASF [https://www.apache.org/legal/resolved.html#category-x] was (Author: ancosen): Rocksdb is licensed under GNU GPL which is not compatible with ASF [https://www.apache.org/legal/resolved.html#category-x] > Add RocksDB Aggregator to Camel > > > Key: CAMEL-14152 > URL: https://issues.apache.org/jira/browse/CAMEL-14152 > Project: Camel > Issue Type: New Feature >Reporter: Omar Al-Safi >Assignee: Omar Al-Safi >Priority: Minor > Fix For: 3.x > > > Although we have LevelDB Aggregator in Camel, I thought it will be as well > beneficial for users to have as well RocksDB Aggregator. Although RocksDB is > basically based on LevelDB, I think Facebook has done great optimizations on > it to have a good performance on sample data bigger than the machine's RAM. > I can work on it after we release 3.0.0 GA -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-14152) Add RocksDB Aggregator to Camel
[ https://issues.apache.org/jira/browse/CAMEL-14152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16969314#comment-16969314 ] Andrea Cosentino commented on CAMEL-14152: -- Rocksdb is licensed under GNU GPL which is not compatible with ASF [https://www.apache.org/legal/resolved.html#category-x] > Add RocksDB Aggregator to Camel > > > Key: CAMEL-14152 > URL: https://issues.apache.org/jira/browse/CAMEL-14152 > Project: Camel > Issue Type: New Feature >Reporter: Omar Al-Safi >Assignee: Omar Al-Safi >Priority: Minor > Fix For: 3.x > > > Although we have LevelDB Aggregator in Camel, I thought it will be as well > beneficial for users to have as well RocksDB Aggregator. Although RocksDB is > basically based on LevelDB, I think Facebook has done great optimizations on > it to have a good performance on sample data bigger than the machine's RAM. > I can work on it after we release 3.0.0 GA -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CAMEL-14152) Add RocksDB Aggregator to Camel
Omar Al-Safi created CAMEL-14152: Summary: Add RocksDB Aggregator to Camel Key: CAMEL-14152 URL: https://issues.apache.org/jira/browse/CAMEL-14152 Project: Camel Issue Type: New Feature Reporter: Omar Al-Safi Assignee: Omar Al-Safi Fix For: 3.x Although we have LevelDB Aggregator in Camel, I thought it will be as well beneficial for users to have as well RocksDB Aggregator. Although RocksDB is basically based on LevelDB, I think Facebook has done great optimizations on it to have a good performance on sample data bigger than the machine's RAM. I can work on it after we release 3.0.0 GA -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CAMEL-14151) Remove default key from camel-xmlsecurity XML Security Data Format and update the default encryption algorithm
[ https://issues.apache.org/jira/browse/CAMEL-14151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved CAMEL-14151. - Resolution: Fixed > Remove default key from camel-xmlsecurity XML Security Data Format and update > the default encryption algorithm > -- > > Key: CAMEL-14151 > URL: https://issues.apache.org/jira/browse/CAMEL-14151 > Project: Camel > Issue Type: Improvement >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh >Priority: Major > Fix For: 3.0.0 > > > For Camel 3.0.0, we should use the opportunity to get rid of the insecure > default encryption key for the XML Security component. In addition, update > the default encryption algorithm from 3DES to AES-256-GCM. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (CAMEL-14148) exception during first resolve of temporary jms destination causes infinitive wait
[
https://issues.apache.org/jira/browse/CAMEL-14148?focusedWorklogId=339975=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-339975
]
ASF GitHub Bot logged work on CAMEL-14148:
--
Author: ASF GitHub Bot
Created on: 07/Nov/19 14:24
Start Date: 07/Nov/19 14:24
Worklog Time Spent: 10m
Work Description: davsclaus commented on pull request #3326: CAMEL-14148
fix (master)
URL: https://github.com/apache/camel/pull/3326
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 339975)
Time Spent: 1h (was: 50m)
> exception during first resolve of temporary jms destination causes infinitive
> wait
> --
>
> Key: CAMEL-14148
> URL: https://issues.apache.org/jira/browse/CAMEL-14148
> Project: Camel
> Issue Type: Bug
> Components: camel-jms
>Affects Versions: 2.24.2
>Reporter: Bas Claessen
>Priority: Minor
> Time Spent: 1h
> Remaining Estimate: 0h
>
> An exception during the first attempt to resolve a temporary destination will
> cause an infinitive wait for next resolve attempts after the exception is
> cleared.
> A likely scenario for this behaviour to occur is when no connection to a jms
> server can be established during startup.
> This bug is caused by not setting the refreshWanted to false when no previous
> destination exists in the
> org.apache.camel.component.jms.reply.TemporaryQueueReplyManager$TemporaryReplyQueueDestinationResolver
> class.
> {code:java}
> public Destination resolveDestinationName(Session session, String
> destinationName, boolean pubSubDomain) throws JMSException {
> // use a temporary queue to gather the reply message
> synchronized (refreshWanted) {
> if (queue == null || refreshWanted.compareAndSet(true, false)) {
> queue = session.createTemporaryQueue();
> setReplyTo(queue);
> if (log.isDebugEnabled()) {
> log.debug("Refreshed Temporary ReplyTo Queue. New queue: {}",
> queue.getQueueName());
> }
> refreshWanted.notifyAll();
> }
> }
> return queue;
> }
> {code}
> When queue == null the refreshWanted.compareAndSet(true, false) is not
> executed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (CAMEL-14148) exception during first resolve of temporary jms destination causes infinitive wait
[
https://issues.apache.org/jira/browse/CAMEL-14148?focusedWorklogId=339945=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-339945
]
ASF GitHub Bot logged work on CAMEL-14148:
--
Author: ASF GitHub Bot
Created on: 07/Nov/19 13:40
Start Date: 07/Nov/19 13:40
Worklog Time Spent: 10m
Work Description: basclaessen commented on pull request #3326:
CAMEL-14148 fix
URL: https://github.com/apache/camel/pull/3326
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 339945)
Time Spent: 50m (was: 40m)
> exception during first resolve of temporary jms destination causes infinitive
> wait
> --
>
> Key: CAMEL-14148
> URL: https://issues.apache.org/jira/browse/CAMEL-14148
> Project: Camel
> Issue Type: Bug
> Components: camel-jms
>Affects Versions: 2.24.2
>Reporter: Bas Claessen
>Priority: Minor
> Time Spent: 50m
> Remaining Estimate: 0h
>
> An exception during the first attempt to resolve a temporary destination will
> cause an infinitive wait for next resolve attempts after the exception is
> cleared.
> A likely scenario for this behaviour to occur is when no connection to a jms
> server can be established during startup.
> This bug is caused by not setting the refreshWanted to false when no previous
> destination exists in the
> org.apache.camel.component.jms.reply.TemporaryQueueReplyManager$TemporaryReplyQueueDestinationResolver
> class.
> {code:java}
> public Destination resolveDestinationName(Session session, String
> destinationName, boolean pubSubDomain) throws JMSException {
> // use a temporary queue to gather the reply message
> synchronized (refreshWanted) {
> if (queue == null || refreshWanted.compareAndSet(true, false)) {
> queue = session.createTemporaryQueue();
> setReplyTo(queue);
> if (log.isDebugEnabled()) {
> log.debug("Refreshed Temporary ReplyTo Queue. New queue: {}",
> queue.getQueueName());
> }
> refreshWanted.notifyAll();
> }
> }
> return queue;
> }
> {code}
> When queue == null the refreshWanted.compareAndSet(true, false) is not
> executed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CAMEL-14151) Remove default key from camel-xmlsecurity XML Security Data Format and update the default encryption algorithm
Colm O hEigeartaigh created CAMEL-14151: --- Summary: Remove default key from camel-xmlsecurity XML Security Data Format and update the default encryption algorithm Key: CAMEL-14151 URL: https://issues.apache.org/jira/browse/CAMEL-14151 Project: Camel Issue Type: Improvement Reporter: Colm O hEigeartaigh Assignee: Colm O hEigeartaigh Fix For: 3.0.0 For Camel 3.0.0, we should use the opportunity to get rid of the insecure default encryption key for the XML Security component. In addition, update the default encryption algorithm from 3DES to AES-256-GCM. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-14150) Camel-exec: option to hide sensitive information in log
[ https://issues.apache.org/jira/browse/CAMEL-14150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16969214#comment-16969214 ] Jiri Ondrusek commented on CAMEL-14150: --- PR https://github.com/apache/camel/pull/3325 > Camel-exec: option to hide sensitive information in log > --- > > Key: CAMEL-14150 > URL: https://issues.apache.org/jira/browse/CAMEL-14150 > Project: Camel > Issue Type: Improvement > Components: camel-exec >Affects Versions: 3.0.0 >Reporter: Jiri Ondrusek >Assignee: Jiri Ondrusek >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > It's possible, that ExecCommand may contain sensitive information. These > commands are logged on level INFO during route execution. New configuration > parameter should be introduced, which will change the level of the log for > ExecCommand to DEBUG. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (CAMEL-14150) Camel-exec: option to hide sensitive information in log
[ https://issues.apache.org/jira/browse/CAMEL-14150?focusedWorklogId=339917=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-339917 ] ASF GitHub Bot logged work on CAMEL-14150: -- Author: ASF GitHub Bot Created on: 07/Nov/19 12:25 Start Date: 07/Nov/19 12:25 Worklog Time Spent: 10m Work Description: JiriOndrusek commented on pull request #3325: [CAMEL-14150] Camel-exec: option to hide sensitive information in log URL: https://github.com/apache/camel/pull/3325 Issue: https://issues.apache.org/jira/browse/CAMEL-14150 Adds configuration parameter (logCommandsAtLevelDebug) to set legging level DEBUG for logging of executed commands (for the scenario, when commands contains some sensitive information). Default value is false, so there is no change in behavior of parameter is not defined. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 339917) Remaining Estimate: 0h Time Spent: 10m > Camel-exec: option to hide sensitive information in log > --- > > Key: CAMEL-14150 > URL: https://issues.apache.org/jira/browse/CAMEL-14150 > Project: Camel > Issue Type: Improvement > Components: camel-exec >Affects Versions: 3.0.0 >Reporter: Jiri Ondrusek >Assignee: Jiri Ondrusek >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > It's possible, that ExecCommand may contain sensitive information. These > commands are logged on level INFO during route execution. New configuration > parameter should be introduced, which will change the level of the log for > ExecCommand to DEBUG. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (CAMEL-14140) Remove global dependency on outdated guava
[ https://issues.apache.org/jira/browse/CAMEL-14140?focusedWorklogId=339916=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-339916 ] ASF GitHub Bot logged work on CAMEL-14140: -- Author: ASF GitHub Bot Created on: 07/Nov/19 12:24 Start Date: 07/Nov/19 12:24 Worklog Time Spent: 10m Work Description: oscerd commented on pull request #3321: [CAMEL-14140] Remove global dependency on outdated guava URL: https://github.com/apache/camel/pull/3321 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 339916) Time Spent: 20m (was: 10m) > Remove global dependency on outdated guava > -- > > Key: CAMEL-14140 > URL: https://issues.apache.org/jira/browse/CAMEL-14140 > Project: Camel > Issue Type: Task > Components: camel-cassandraql >Reporter: Thomas Diesler >Assignee: Thomas Diesler >Priority: Major > Fix For: 3.0.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Currently, camel comes with google-guava-version=19.0 which contains a number > of deprecated APIs that have been removed in 20.x. AFAICS, cassandra-3.x is > the only component that depends on these deprecated guava APIs. This > dependency has been removed in cassandra-4.x, which is currently in alpha. In > WildFly-Camel, I confirmed that it should generally be possible to update to > guava-26.x as long as cassandra can still use 19.x -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (CAMEL-14148) exception during first resolve of temporary jms destination causes infinitive wait
[
https://issues.apache.org/jira/browse/CAMEL-14148?focusedWorklogId=339907=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-339907
]
ASF GitHub Bot logged work on CAMEL-14148:
--
Author: ASF GitHub Bot
Created on: 07/Nov/19 12:15
Start Date: 07/Nov/19 12:15
Worklog Time Spent: 10m
Work Description: oscerd commented on pull request #3324: CAMEL-14148 fix
URL: https://github.com/apache/camel/pull/3324
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 339907)
Time Spent: 40m (was: 0.5h)
> exception during first resolve of temporary jms destination causes infinitive
> wait
> --
>
> Key: CAMEL-14148
> URL: https://issues.apache.org/jira/browse/CAMEL-14148
> Project: Camel
> Issue Type: Bug
> Components: camel-jms
>Affects Versions: 2.24.2
>Reporter: Bas Claessen
>Priority: Minor
> Time Spent: 40m
> Remaining Estimate: 0h
>
> An exception during the first attempt to resolve a temporary destination will
> cause an infinitive wait for next resolve attempts after the exception is
> cleared.
> A likely scenario for this behaviour to occur is when no connection to a jms
> server can be established during startup.
> This bug is caused by not setting the refreshWanted to false when no previous
> destination exists in the
> org.apache.camel.component.jms.reply.TemporaryQueueReplyManager$TemporaryReplyQueueDestinationResolver
> class.
> {code:java}
> public Destination resolveDestinationName(Session session, String
> destinationName, boolean pubSubDomain) throws JMSException {
> // use a temporary queue to gather the reply message
> synchronized (refreshWanted) {
> if (queue == null || refreshWanted.compareAndSet(true, false)) {
> queue = session.createTemporaryQueue();
> setReplyTo(queue);
> if (log.isDebugEnabled()) {
> log.debug("Refreshed Temporary ReplyTo Queue. New queue: {}",
> queue.getQueueName());
> }
> refreshWanted.notifyAll();
> }
> }
> return queue;
> }
> {code}
> When queue == null the refreshWanted.compareAndSet(true, false) is not
> executed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CAMEL-14150) Camel-exec: option to hide sensitive information in log
[ https://issues.apache.org/jira/browse/CAMEL-14150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiri Ondrusek updated CAMEL-14150: -- Summary: Camel-exec: option to hide sensitive information in log (was: Camel-exec: option to hide sensitive information n log) > Camel-exec: option to hide sensitive information in log > --- > > Key: CAMEL-14150 > URL: https://issues.apache.org/jira/browse/CAMEL-14150 > Project: Camel > Issue Type: Improvement > Components: camel-exec >Affects Versions: 3.0.0 >Reporter: Jiri Ondrusek >Assignee: Jiri Ondrusek >Priority: Minor > > It's possible, that ExecCommand may contain sensitive information. These > commands are logged on level INFO during route execution. New configuration > parameter should be introduced, which will change the level of the log for > ExecCommand to DEBUG. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CAMEL-14150) Camel-exec: option to hide sensitive information n log
Jiri Ondrusek created CAMEL-14150: - Summary: Camel-exec: option to hide sensitive information n log Key: CAMEL-14150 URL: https://issues.apache.org/jira/browse/CAMEL-14150 Project: Camel Issue Type: Improvement Components: camel-exec Affects Versions: 3.0.0 Reporter: Jiri Ondrusek Assignee: Jiri Ondrusek It's possible, that ExecCommand may contain sensitive information. These commands are logged on level INFO during route execution. New configuration parameter should be introduced, which will change the level of the log for ExecCommand to DEBUG. -- This message was sent by Atlassian Jira (v8.3.4#803005)
