[jira] [Commented] (CAMEL-9869) Create Apache Flink Component
[
https://issues.apache.org/jira/browse/CAMEL-9869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15255965#comment-15255965
]
Claus Ibsen commented on CAMEL-9869:
Thanks for the PR. The code has been merged.
Are you working on the datastream mode as well for the producer?
And we would need some documentation to go along with it when its more ready.
We can talk about this later when we get the other bits finished first.
> Create Apache Flink Component
> -
>
> Key: CAMEL-9869
> URL: https://issues.apache.org/jira/browse/CAMEL-9869
> Project: Camel
> Issue Type: New Feature
> Components: camel-flink
>Reporter: Subhobrata Dey
>Assignee: Claus Ibsen
> Fix For: 2.18.0
>
>
> Hello,
> I have created an Apache Flink component for Camel which makes it easier to
> use Flink for analytics. One can use DataSet callbacks with Spring beans/OSGI
> services.
> Using Spring's application context, it can be accessed like
> {noformat}
> @Bean
> public DataSetCallback countLinesContaining() {
> return new DataSetCallback() {
> public Long onDataSet(DataSet dataSet, Object... objects) {
> try {
> dataSet.print();
> return new Long(0);
> } catch (Exception e) {
> return new Long(-1);
> }
> }
> };
> }
> @Bean
> public DataSet myDataSet() {
> final ExecutionEnvironment env =
> ExecutionEnvironment.getExecutionEnvironment();
> DataSet text = env.fromElements(
> "Who's there?",
> "I think I hear them. Stand ho! Who's there?");
> return text;
> }
> {noformat}
> The results can be accessed like
> {noformat}
> Long count =
> template.requestBody("flink:dataSet?dataSet=#myDataSet&dataSetCallback=#countLinesContaining",
> pattern, Long.class);
> {noformat}
> Please review & accept my contribution.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-9869) Create Apache Flink Component
[
https://issues.apache.org/jira/browse/CAMEL-9869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-9869:
---
Component/s: camel-flink
> Create Apache Flink Component
> -
>
> Key: CAMEL-9869
> URL: https://issues.apache.org/jira/browse/CAMEL-9869
> Project: Camel
> Issue Type: New Feature
> Components: camel-flink
>Reporter: Subhobrata Dey
>Assignee: Claus Ibsen
> Fix For: 2.18.0
>
>
> Hello,
> I have created an Apache Flink component for Camel which makes it easier to
> use Flink for analytics. One can use DataSet callbacks with Spring beans/OSGI
> services.
> Using Spring's application context, it can be accessed like
> {noformat}
> @Bean
> public DataSetCallback countLinesContaining() {
> return new DataSetCallback() {
> public Long onDataSet(DataSet dataSet, Object... objects) {
> try {
> dataSet.print();
> return new Long(0);
> } catch (Exception e) {
> return new Long(-1);
> }
> }
> };
> }
> @Bean
> public DataSet myDataSet() {
> final ExecutionEnvironment env =
> ExecutionEnvironment.getExecutionEnvironment();
> DataSet text = env.fromElements(
> "Who's there?",
> "I think I hear them. Stand ho! Who's there?");
> return text;
> }
> {noformat}
> The results can be accessed like
> {noformat}
> Long count =
> template.requestBody("flink:dataSet?dataSet=#myDataSet&dataSetCallback=#countLinesContaining",
> pattern, Long.class);
> {noformat}
> Please review & accept my contribution.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CAMEL-9869) Create Apache Flink Component
[
https://issues.apache.org/jira/browse/CAMEL-9869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen reassigned CAMEL-9869:
--
Assignee: Claus Ibsen
> Create Apache Flink Component
> -
>
> Key: CAMEL-9869
> URL: https://issues.apache.org/jira/browse/CAMEL-9869
> Project: Camel
> Issue Type: New Feature
> Components: camel-flink
>Reporter: Subhobrata Dey
>Assignee: Claus Ibsen
> Fix For: 2.18.0
>
>
> Hello,
> I have created an Apache Flink component for Camel which makes it easier to
> use Flink for analytics. One can use DataSet callbacks with Spring beans/OSGI
> services.
> Using Spring's application context, it can be accessed like
> {noformat}
> @Bean
> public DataSetCallback countLinesContaining() {
> return new DataSetCallback() {
> public Long onDataSet(DataSet dataSet, Object... objects) {
> try {
> dataSet.print();
> return new Long(0);
> } catch (Exception e) {
> return new Long(-1);
> }
> }
> };
> }
> @Bean
> public DataSet myDataSet() {
> final ExecutionEnvironment env =
> ExecutionEnvironment.getExecutionEnvironment();
> DataSet text = env.fromElements(
> "Who's there?",
> "I think I hear them. Stand ho! Who's there?");
> return text;
> }
> {noformat}
> The results can be accessed like
> {noformat}
> Long count =
> template.requestBody("flink:dataSet?dataSet=#myDataSet&dataSetCallback=#countLinesContaining",
> pattern, Long.class);
> {noformat}
> Please review & accept my contribution.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CAMEL-9900) camel-jms - provide option for MessageListenerContainer for reply managers to stop quicker when CamelContext is stopping
[
https://issues.apache.org/jira/browse/CAMEL-9900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Anstey resolved CAMEL-9900.
Resolution: Fixed
> camel-jms - provide option for MessageListenerContainer for reply managers to
> stop quicker when CamelContext is stopping
>
>
> Key: CAMEL-9900
> URL: https://issues.apache.org/jira/browse/CAMEL-9900
> Project: Camel
> Issue Type: Improvement
> Components: camel-jms
>Reporter: Jonathan Anstey
>Assignee: Jonathan Anstey
> Fix For: 2.17.1, 2.18.0
>
>
> CAMEL-7667 included a fix for the DMLC used in JMS consumers to stop quickly
> if the CameContext is already shutting down. This helps avoid spring-jms
> getting into a bad state with a null sharedConnection which has a telling
> stack like:
> {code}
> 2014-08-07 10:33:42,975 [sonnel.records]] ERROR
> ultJmsMessageListenerContainer - Could not refresh JMS Connection for
> destination 'personnel.records' - retrying in 5000 ms. Cause: null
> java.lang.NullPointerException
> at
> org.springframework.jms.listener.AbstractJmsListeningContainer.refreshSharedConnection(AbstractJmsListeningContainer.java:392)
> at
> org.springframework.jms.listener.DefaultMessageListenerContainer.refreshConnectionUntilSuccessful(DefaultMessageListenerContainer.java:885)
> at
> org.springframework.jms.listener.DefaultMessageListenerContainer.recoverAfterListenerSetupFailure(DefaultMessageListenerContainer.java:861)
> at
> org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.run(DefaultMessageListenerContainer.java:1012)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)
> {code}
> This can also occur in the DMLC used for request-reply messaging. We should
> provide an option for this to be enabled because usually this is not an issue
> and you don't mind waiting for a while for replies to come in.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CAMEL-9222) Aggreagator breaks onCompletion semantic if used with parallelProcessing
[
https://issues.apache.org/jira/browse/CAMEL-9222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-9222.
Resolution: Not A Problem
Assignee: Claus Ibsen
You are using an aggregate EIP in the 2nd example which is separate processing
from the original exchange, so the original exchange can complete first.
> Aggreagator breaks onCompletion semantic if used with parallelProcessing
>
>
> Key: CAMEL-9222
> URL: https://issues.apache.org/jira/browse/CAMEL-9222
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.14.3
>Reporter: moritz löser
>Assignee: Claus Ibsen
>
> If using onCompletion (or Routepolicy.onExchangeDone) in a route that splits
> and aggregates onCompletion is called on original exchange before any
> exchange is consumed if parallelProcessing() is set on aggregator definition.
> I created a unit test with a simple route. the tests checks the order of
> calls on the mocks. the call on finish should be last (just (un)comment
> parallelProcessing to see the effect):
> {code:java}
> package de.ml;
> import static org.mockito.Matchers.any;
> import static org.mockito.Mockito.atLeastOnce;
> import static org.mockito.Mockito.doAnswer;
> import static org.mockito.Mockito.inOrder;
> import static org.mockito.Mockito.when;
> import java.util.Arrays;
> import java.util.UUID;
> import org.apache.camel.CamelContext;
> import org.apache.camel.Exchange;
> import org.apache.camel.Processor;
> import org.apache.camel.RoutesBuilder;
> import org.apache.camel.builder.RouteBuilder;
> import org.apache.camel.component.direct.DirectEndpoint;
> import org.apache.camel.component.mock.MockEndpoint;
> import org.apache.camel.impl.DefaultCamelContext;
> import org.apache.camel.processor.aggregate.AggregationStrategy;
> import org.junit.Before;
> import org.junit.Test;
> import org.junit.runner.RunWith;
> import org.mockito.InOrder;
> import org.mockito.Mock;
> import org.mockito.invocation.InvocationOnMock;
> import org.mockito.runners.MockitoJUnitRunner;
> import org.mockito.stubbing.Answer;
> @RunWith(MockitoJUnitRunner.class)
> public class TestAggregator {
> private static final String SIZE = "size";
> private static final String ID = "id";
> private final CamelContext context = new DefaultCamelContext();
> @Mock
> private Processor mockProcessor;
> @Mock
> private Processor mockHeaderProcessor;
> @Mock
> private AggregationStrategy mockAggregator;
> @Mock
> private Processor onFinishMock;
> private DirectEndpoint trigger;
> private MockEndpoint out;
> @Before
> public void prepareMocks() throws Exception {
> when( mockAggregator.aggregate( any( Exchange.class ), any(
> Exchange.class ) ) ).then(
> new Answer() {
> @Override
> public Exchange answer( InvocationOnMock invocation ) throws
> Throwable {
> // always just return old exchange
> return (Exchange) invocation.getArguments()[1];
> }
> } );
> doAnswer( new Answer() {
> @Override
> public Void answer( InvocationOnMock invocation ) throws
> Throwable {
> Exchange exchange = (Exchange) invocation.getArguments()[0];
> exchange.getIn().setHeader( ID, UUID.randomUUID() );
> exchange.getIn().setHeader( SIZE, 1 );
> return null;
> }
> } ).when( mockHeaderProcessor ).process( any( Exchange.class ) );
> }
> @Test
> public void testRoute() throws Exception {
> trigger = context.getEndpoint( "direct:trigger", DirectEndpoint.class
> );
> out = context.getEndpoint( "mock:out", MockEndpoint.class );
> RoutesBuilder testObject = getTestObject();
> context.addRoutes( testObject );
> out.expectedMessageCount( 3 );
> context.start();
> context.createProducerTemplate().sendBody( trigger, Arrays.asList(
> "1a", "1b", "2c" ) );
> out.assertIsSatisfied();
> InOrder order = inOrder( mockHeaderProcessor, mockProcessor,
> onFinishMock );
> order.verify( mockHeaderProcessor, atLeastOnce() ).process( any(
> Exchange.class ) );
> order.verify( mockProcessor, atLeastOnce() ).process( any(
> Exchange.class ) );
> order.verify( onFinishMock ).process( any( Exchange.class ) );
> }
> private RouteBuilder getTestObject() {
> return new RouteBuilder() {
> @Override
> public void configure() throws Exception {
> from(trigger)
> .onCompletion().process(onFinishMock).end()
> .split().body()
> .
[jira] [Resolved] (CAMEL-9647) Camel Circuit Breaker to output Hystrix metrics?
[ https://issues.apache.org/jira/browse/CAMEL-9647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-9647. Resolution: Not A Problem Assignee: Claus Ibsen We have a hystrix EIP you can use now > Camel Circuit Breaker to output Hystrix metrics? > > > Key: CAMEL-9647 > URL: https://issues.apache.org/jira/browse/CAMEL-9647 > Project: Camel > Issue Type: New Feature >Reporter: james strachan >Assignee: Claus Ibsen > Fix For: 2.18.0 > > > It might be nice if the circuit breakers in Apache Camel could expose metrics > to Hystrix so that the Hystrix dashboard could be included to visualise them > http://projects.spring.io/spring-cloud/docs/1.0.3/spring-cloud.html#_hystrix_metrics_stream > Its pretty easy to add the Hystrix dashboard to spring boot apps; and use > Turbine to aggregate them etc -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-9876) Error handling in splitter is broken with version 2.17.0
[
https://issues.apache.org/jira/browse/CAMEL-9876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-9876.
Resolution: Invalid
Assignee: Claus Ibsen
The direct:line route uses the global error handler. You need to either inlined
the direct route in the splitter, or configure the direct route to not use
error handler.
Those other tests should ideally have configured the direct route to not use
any error handler so its controller by the splitter.
{code}
from("direct:start")
.errorHandler(deadLetterChannel("mock:dead").useOriginalMessage()
.maximumRedeliveries(3).redeliveryDelay(0))
.to("mock:a")
// share unit of work in the splitter, which tells Camel to
propagate failures from
// processing the splitted messages back to the result of
the splitter, which allows
// it to act as a combined unit of work
.split(body().tokenize(",")).shareUnitOfWork()
.to("mock:b")
.to("direct:line")
.end()
.to("mock:result");
from("direct:line").errorHandler(noErrorHandler())
.to("log:line")
.process(new MyProcessor())
.to("mock:line");
{code}
> Error handling in splitter is broken with version 2.17.0
>
>
> Key: CAMEL-9876
> URL: https://issues.apache.org/jira/browse/CAMEL-9876
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.17.0
>Reporter: Oliver Holzmann
>Assignee: Claus Ibsen
>
> With version 2.17.0 error handling is not triggering route specific error
> handler any more.
> I changed {{org.apache.camel.processor.SplitSubUnitOfWorkTest}} and defined
> the global error handler as route specific and amended the global error
> handler:
> {code}
> public void configure() throws Exception {
> // START SNIPPET: e1
> errorHandler(deadLetterChannel("mock:log").useOriginalMessage()
> .maximumRedeliveries(3).redeliveryDelay(0));
> from("direct:start")
> .errorHandler(
> deadLetterChannel("mock:dead").useOriginalMessage()
> .maximumRedeliveries(3).redeliveryDelay(0)).to("mock:a")
> .split(body().tokenize(",")).shareUnitOfWork().to("mock:b")
> .to("direct:line").end().to("mock:result");
> from("direct:line").inheritErrorHandler(true).to("log:line")
> .process(new MyProcessor()).to("mock:line");
> // END SNIPPET: e1
> }
> {code}
> The expectation is, that this shouldn't change the test results.
> But {{testError}} fails because {{mock:dead}} is not triggered any more.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-9887) onCompletion not called on Splitter configured with CompletionAwareAggregationStrategy and shareUnitOfWork=true
[
https://issues.apache.org/jira/browse/CAMEL-9887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-9887:
---
Regression: (was: Regression)
> onCompletion not called on Splitter configured with
> CompletionAwareAggregationStrategy and shareUnitOfWork=true
> ---
>
> Key: CAMEL-9887
> URL: https://issues.apache.org/jira/browse/CAMEL-9887
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.17.0
>Reporter: Jerry Williamson
>Assignee: Claus Ibsen
> Fix For: 2.17.1, 2.18.0
>
>
> In 2.17.0, if a Splitter is configured with shareUnitOfWork=true, then its
> AggregationStrategy is now wrapped by a ShareUnitOfWorkAggregationStrategy.
> This causes the following code from *MulticastProcessor.doDone()* to fail to
> invoke onCompletion when the configured strategy implements
> CompletionAwareAggregationStrategy.
> {noformat}
> if (strategy instanceof CompletionAwareAggregationStrategy) {
> ((CompletionAwareAggregationStrategy) strategy).onCompletion(subExchange);
> }
> {noformat}
> It appears the change was a part of CAMEL-9573.
> I haven't completely analyzed the shared unit of work changes but one
> possible approach to fix this would be to have the
> ShareUnitOfWorkAggregationStrategy implement
> CompletionAwareAggregationStrategy and then have its onCompletionMethod
> delegate to the wrapped strategy iff it also implements
> CompletionAwareAggregationStrategy.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CAMEL-9887) onCompletion not called on Splitter configured with CompletionAwareAggregationStrategy and shareUnitOfWork=true
[
https://issues.apache.org/jira/browse/CAMEL-9887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-9887.
Resolution: Fixed
> onCompletion not called on Splitter configured with
> CompletionAwareAggregationStrategy and shareUnitOfWork=true
> ---
>
> Key: CAMEL-9887
> URL: https://issues.apache.org/jira/browse/CAMEL-9887
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.17.0
>Reporter: Jerry Williamson
>Assignee: Claus Ibsen
> Fix For: 2.17.1, 2.18.0
>
>
> In 2.17.0, if a Splitter is configured with shareUnitOfWork=true, then its
> AggregationStrategy is now wrapped by a ShareUnitOfWorkAggregationStrategy.
> This causes the following code from *MulticastProcessor.doDone()* to fail to
> invoke onCompletion when the configured strategy implements
> CompletionAwareAggregationStrategy.
> {noformat}
> if (strategy instanceof CompletionAwareAggregationStrategy) {
> ((CompletionAwareAggregationStrategy) strategy).onCompletion(subExchange);
> }
> {noformat}
> It appears the change was a part of CAMEL-9573.
> I haven't completely analyzed the shared unit of work changes but one
> possible approach to fix this would be to have the
> ShareUnitOfWorkAggregationStrategy implement
> CompletionAwareAggregationStrategy and then have its onCompletionMethod
> delegate to the wrapped strategy iff it also implements
> CompletionAwareAggregationStrategy.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-9887) onCompletion not called on Splitter configured with CompletionAwareAggregationStrategy and shareUnitOfWork=true
[
https://issues.apache.org/jira/browse/CAMEL-9887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-9887:
---
Fix Version/s: 2.18.0
2.17.1
> onCompletion not called on Splitter configured with
> CompletionAwareAggregationStrategy and shareUnitOfWork=true
> ---
>
> Key: CAMEL-9887
> URL: https://issues.apache.org/jira/browse/CAMEL-9887
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.17.0
>Reporter: Jerry Williamson
>Assignee: Claus Ibsen
> Fix For: 2.17.1, 2.18.0
>
>
> In 2.17.0, if a Splitter is configured with shareUnitOfWork=true, then its
> AggregationStrategy is now wrapped by a ShareUnitOfWorkAggregationStrategy.
> This causes the following code from *MulticastProcessor.doDone()* to fail to
> invoke onCompletion when the configured strategy implements
> CompletionAwareAggregationStrategy.
> {noformat}
> if (strategy instanceof CompletionAwareAggregationStrategy) {
> ((CompletionAwareAggregationStrategy) strategy).onCompletion(subExchange);
> }
> {noformat}
> It appears the change was a part of CAMEL-9573.
> I haven't completely analyzed the shared unit of work changes but one
> possible approach to fix this would be to have the
> ShareUnitOfWorkAggregationStrategy implement
> CompletionAwareAggregationStrategy and then have its onCompletionMethod
> delegate to the wrapped strategy iff it also implements
> CompletionAwareAggregationStrategy.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CAMEL-9887) onCompletion not called on Splitter configured with CompletionAwareAggregationStrategy and shareUnitOfWork=true
[
https://issues.apache.org/jira/browse/CAMEL-9887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen reassigned CAMEL-9887:
--
Assignee: Claus Ibsen
> onCompletion not called on Splitter configured with
> CompletionAwareAggregationStrategy and shareUnitOfWork=true
> ---
>
> Key: CAMEL-9887
> URL: https://issues.apache.org/jira/browse/CAMEL-9887
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.17.0
>Reporter: Jerry Williamson
>Assignee: Claus Ibsen
> Fix For: 2.17.1, 2.18.0
>
>
> In 2.17.0, if a Splitter is configured with shareUnitOfWork=true, then its
> AggregationStrategy is now wrapped by a ShareUnitOfWorkAggregationStrategy.
> This causes the following code from *MulticastProcessor.doDone()* to fail to
> invoke onCompletion when the configured strategy implements
> CompletionAwareAggregationStrategy.
> {noformat}
> if (strategy instanceof CompletionAwareAggregationStrategy) {
> ((CompletionAwareAggregationStrategy) strategy).onCompletion(subExchange);
> }
> {noformat}
> It appears the change was a part of CAMEL-9573.
> I haven't completely analyzed the shared unit of work changes but one
> possible approach to fix this would be to have the
> ShareUnitOfWorkAggregationStrategy implement
> CompletionAwareAggregationStrategy and then have its onCompletionMethod
> delegate to the wrapped strategy iff it also implements
> CompletionAwareAggregationStrategy.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CAMEL-9877) InflightRepository - Add browse that can limit per route
[
https://issues.apache.org/jira/browse/CAMEL-9877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-9877.
Resolution: Fixed
> InflightRepository - Add browse that can limit per route
>
>
> Key: CAMEL-9877
> URL: https://issues.apache.org/jira/browse/CAMEL-9877
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
>Reporter: Claus Ibsen
>Assignee: Claus Ibsen
> Fix For: 2.18.0
>
>
> We have a browse that limits per context
> {code}
> browse(int limit, boolean sortByLongestDuration)
> A read-only browser of the InflightRepository.InflightExchanges that are
> currently inflight.
> {code}
> But we need one that limits per route, eg
> {code}
> browse(String routeId, int limit, boolean sortByLongestDuration)
> A read-only browser of the InflightRepository.InflightExchanges that are
> currently inflight on that given route.
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CAMEL-9872) VetoCamelContextStartException with rethrowException=false cases MainSupport class to hang
[ https://issues.apache.org/jira/browse/CAMEL-9872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-9872. Resolution: Fixed Fix Version/s: 2.18.0 > VetoCamelContextStartException with rethrowException=false cases MainSupport > class to hang > -- > > Key: CAMEL-9872 > URL: https://issues.apache.org/jira/browse/CAMEL-9872 > Project: Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 2.17.0 >Reporter: Jimi Hullegård >Assignee: Claus Ibsen >Priority: Minor > Fix For: 2.18.0 > > > Hi, > I just created my own LifecycleStrategy implementation, that performs some > sanity checks on context startup, and throws a VetoCamelContextStartException > if it detects a problem. But since I only want a user friendly error message > to be printed, and no stack trace, I opted to have rethrowException=false. > That caused Camel to abort the start of the context. But it keeps the process > running, instead of letting it terminate. If I use rethrowException=false the > process terminates as expected. > When debugging this in Eclipse, I see that Camel get stuck in the method > waitUntilCompleted() in org.apache.camel.main.MainSupport. > I use Apache Camel 2.17.0, Camel Spring (XML), and start the process using > org.apache.camel.spring.Main. When asking about this behaivor in the user > mailing list, Claus Ibsen hinted that this is a bug that I should report > here. Apparently the Main class doesn't handle the veto properly. > Regards > /Jimi -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-9907) Camel-Infinispan: Exposing cache stats through producer
[ https://issues.apache.org/jira/browse/CAMEL-9907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrea Cosentino resolved CAMEL-9907. - Resolution: Fixed > Camel-Infinispan: Exposing cache stats through producer > --- > > Key: CAMEL-9907 > URL: https://issues.apache.org/jira/browse/CAMEL-9907 > Project: Camel > Issue Type: New Feature > Components: camel-infinispan >Reporter: Andrea Cosentino >Assignee: Andrea Cosentino >Priority: Minor > Fix For: 2.18.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CAMEL-9872) VetoCamelContextStartException with rethrowException=false cases MainSupport class to hang
[ https://issues.apache.org/jira/browse/CAMEL-9872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen reassigned CAMEL-9872: -- Assignee: Claus Ibsen > VetoCamelContextStartException with rethrowException=false cases MainSupport > class to hang > -- > > Key: CAMEL-9872 > URL: https://issues.apache.org/jira/browse/CAMEL-9872 > Project: Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 2.17.0 >Reporter: Jimi Hullegård >Assignee: Claus Ibsen >Priority: Minor > > Hi, > I just created my own LifecycleStrategy implementation, that performs some > sanity checks on context startup, and throws a VetoCamelContextStartException > if it detects a problem. But since I only want a user friendly error message > to be printed, and no stack trace, I opted to have rethrowException=false. > That caused Camel to abort the start of the context. But it keeps the process > running, instead of letting it terminate. If I use rethrowException=false the > process terminates as expected. > When debugging this in Eclipse, I see that Camel get stuck in the method > waitUntilCompleted() in org.apache.camel.main.MainSupport. > I use Apache Camel 2.17.0, Camel Spring (XML), and start the process using > org.apache.camel.spring.Main. When asking about this behaivor in the user > mailing list, Claus Ibsen hinted that this is a bug that I should report > here. Apparently the Main class doesn't handle the veto properly. > Regards > /Jimi -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CAMEL-9877) InflightRepository - Add browse that can limit per route
[
https://issues.apache.org/jira/browse/CAMEL-9877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen reassigned CAMEL-9877:
--
Assignee: Claus Ibsen
> InflightRepository - Add browse that can limit per route
>
>
> Key: CAMEL-9877
> URL: https://issues.apache.org/jira/browse/CAMEL-9877
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
>Reporter: Claus Ibsen
>Assignee: Claus Ibsen
> Fix For: 2.18.0
>
>
> We have a browse that limits per context
> {code}
> browse(int limit, boolean sortByLongestDuration)
> A read-only browser of the InflightRepository.InflightExchanges that are
> currently inflight.
> {code}
> But we need one that limits per route, eg
> {code}
> browse(String routeId, int limit, boolean sortByLongestDuration)
> A read-only browser of the InflightRepository.InflightExchanges that are
> currently inflight on that given route.
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CAMEL-9907) Camel-Infinispan: Exposing cache stats through producer
Andrea Cosentino created CAMEL-9907: --- Summary: Camel-Infinispan: Exposing cache stats through producer Key: CAMEL-9907 URL: https://issues.apache.org/jira/browse/CAMEL-9907 Project: Camel Issue Type: New Feature Components: camel-infinispan Reporter: Andrea Cosentino Assignee: Andrea Cosentino Priority: Minor Fix For: 2.18.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
