[jira] [Updated] (CAMEL-8947) LevelDBAggregatorRepository redelivers incorrectly
[
https://issues.apache.org/jira/browse/CAMEL-8947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ben O'Day updated CAMEL-8947:
-
Affects Version/s: (was: 2.16)
2.14.1
> LevelDBAggregatorRepository redelivers incorrectly
> --
>
> Key: CAMEL-8947
> URL: https://issues.apache.org/jira/browse/CAMEL-8947
> Project: Camel
> Issue Type: Bug
> Components: camel-leveldb
>Affects Versions: 2.14.1
>Reporter: Ben O'Day
>Assignee: Ben O'Day
> Attachments: LevelDBAggregatorUseLatestTest.patch
>
>
> I'm using an the aggregator with the LevelDBAggregationRepository and seeing
> an incorrect redelivery of a message when using the
> UseLatestAggregationStrategy...
> this very basic route (see attached)...
> from("direct:start")
> .aggregate(constant(true), new
> UseLatestAggregationStrategy())
> .completionSize(2)
>
> .aggregationRepository(repo)
> .to("mock:mock");
> shows the following behavior...
> WARN LevelDBAggregationRepository - Unable to confirm exchangeId
> [ID-localhost-63819-1436483565832-0-6 from repository repo1: Not Found]
> DEBUG LevelDBAggregationRepository - Scanned and found 1 exchange(s) to
> recover (note some of them may already be in progress).
> DEBUG LevelDBAggregationRepository - Recovering exchangeId
> [ID-localhost-63819-1436483565832-0-3] -> Exchange[Message: test1]
> resulting in a duplicate message being processed through the aggregator
> route...
> if the default in-memory repo is used, the test behaves as expected...no
> unnecessary redelivery, etc.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-8971) HazelcastAggregatorRepository redelivers incorrectly
[
https://issues.apache.org/jira/browse/CAMEL-8971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ben O'Day updated CAMEL-8971:
-
Affects Version/s: (was: 2.16)
2.14.1
> HazelcastAggregatorRepository redelivers incorrectly
>
>
> Key: CAMEL-8971
> URL: https://issues.apache.org/jira/browse/CAMEL-8971
> Project: Camel
> Issue Type: Bug
> Components: camel-hazelcast
>Affects Versions: 2.14.1
>Reporter: Ben O'Day
>Assignee: Ben O'Day
>Priority: Minor
> Attachments: HazelcastAggRepo-redelivery-fix.patch
>
>
> seeing an incorrect redelivery of a message when using the
> UseLatestAggregationStrategy...
> this very basic route (see attached)...
> from("direct:start")
> .aggregate(constant(true), new
> UseLatestAggregationStrategy())
> .completionSize(2)
>
> .aggregationRepository(repo)
> .to("mock:mock");
> resulting in a duplicate message being processed through the aggregator
> route...
> if the default in-memory repo is used, the test behaves as expected...no
> unnecessary redelivery, etc.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-8947) LevelDBAggregatorRepository redelivers incorrectly
[
https://issues.apache.org/jira/browse/CAMEL-8947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ben O'Day updated CAMEL-8947:
-
Priority: Major (was: Minor)
> LevelDBAggregatorRepository redelivers incorrectly
> --
>
> Key: CAMEL-8947
> URL: https://issues.apache.org/jira/browse/CAMEL-8947
> Project: Camel
> Issue Type: Bug
> Components: camel-leveldb
>Affects Versions: 2.16
>Reporter: Ben O'Day
>Assignee: Ben O'Day
> Attachments: LevelDBAggregatorUseLatestTest.patch
>
>
> I'm using an the aggregator with the LevelDBAggregationRepository and seeing
> an incorrect redelivery of a message when using the
> UseLatestAggregationStrategy...
> this very basic route (see attached)...
> from("direct:start")
> .aggregate(constant(true), new
> UseLatestAggregationStrategy())
> .completionSize(2)
>
> .aggregationRepository(repo)
> .to("mock:mock");
> shows the following behavior...
> WARN LevelDBAggregationRepository - Unable to confirm exchangeId
> [ID-localhost-63819-1436483565832-0-6 from repository repo1: Not Found]
> DEBUG LevelDBAggregationRepository - Scanned and found 1 exchange(s) to
> recover (note some of them may already be in progress).
> DEBUG LevelDBAggregationRepository - Recovering exchangeId
> [ID-localhost-63819-1436483565832-0-3] -> Exchange[Message: test1]
> resulting in a duplicate message being processed through the aggregator
> route...
> if the default in-memory repo is used, the test behaves as expected...no
> unnecessary redelivery, etc.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-8971) HazelcastAggregatorRepository redelivers incorrectly
[
https://issues.apache.org/jira/browse/CAMEL-8971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14636915#comment-14636915
]
Ben O'Day commented on CAMEL-8971:
--
[~alexlomov] - not sure I follow how this disables recovery, can you clarify?
either way, this very basic unit test using the Hazelcast repo fails w/o my (or
some other) changes...any thoughts on how to address the root cause of the
issue otherwise?
> HazelcastAggregatorRepository redelivers incorrectly
>
>
> Key: CAMEL-8971
> URL: https://issues.apache.org/jira/browse/CAMEL-8971
> Project: Camel
> Issue Type: Bug
> Components: camel-hazelcast
>Affects Versions: 2.16
>Reporter: Ben O'Day
>Assignee: Ben O'Day
>Priority: Minor
> Attachments: HazelcastAggRepo-redelivery-fix.patch
>
>
> seeing an incorrect redelivery of a message when using the
> UseLatestAggregationStrategy...
> this very basic route (see attached)...
> from("direct:start")
> .aggregate(constant(true), new
> UseLatestAggregationStrategy())
> .completionSize(2)
>
> .aggregationRepository(repo)
> .to("mock:mock");
> resulting in a duplicate message being processed through the aggregator
> route...
> if the default in-memory repo is used, the test behaves as expected...no
> unnecessary redelivery, etc.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CAMEL-8971) HazelcastAggregatorRepository redelivers incorrectly
[
https://issues.apache.org/jira/browse/CAMEL-8971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14626851#comment-14626851
]
Ben O'Day edited comment on CAMEL-8971 at 7/14/15 7:51 PM:
---
attached a potential patch to get this repo to work for the simple size based
aggregation route...still investigating
[~alexlomov] - I noticed you contributed the original
HazelcastAggregationRepository...any thoughts on this?
was (Author: boday):
attached a potential patch to get this repo to work for the simple size based
aggregation route...still investigating
> HazelcastAggregatorRepository redelivers incorrectly
>
>
> Key: CAMEL-8971
> URL: https://issues.apache.org/jira/browse/CAMEL-8971
> Project: Camel
> Issue Type: Bug
> Components: camel-hazelcast
>Affects Versions: 2.16
>Reporter: Ben O'Day
>Assignee: Ben O'Day
>Priority: Minor
> Attachments: HazelcastAggRepo-redelivery-fix.patch
>
>
> seeing an incorrect redelivery of a message when using the
> UseLatestAggregationStrategy...
> this very basic route (see attached)...
> from("direct:start")
> .aggregate(constant(true), new
> UseLatestAggregationStrategy())
> .completionSize(2)
>
> .aggregationRepository(repo)
> .to("mock:mock");
> resulting in a duplicate message being processed through the aggregator
> route...
> if the default in-memory repo is used, the test behaves as expected...no
> unnecessary redelivery, etc.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Issue Comment Deleted] (CAMEL-8947) LevelDBAggregatorRepository redelivers incorrectly
[
https://issues.apache.org/jira/browse/CAMEL-8947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ben O'Day updated CAMEL-8947:
-
Comment: was deleted
(was: attached a potential patch to the HazelcastAggregationRepository to get
this to work with my simple unit test...not sure if it breaks something else at
this point, just wanted to throw it out for some feedback...
)
> LevelDBAggregatorRepository redelivers incorrectly
> --
>
> Key: CAMEL-8947
> URL: https://issues.apache.org/jira/browse/CAMEL-8947
> Project: Camel
> Issue Type: Bug
> Components: camel-leveldb
>Affects Versions: 2.16
>Reporter: Ben O'Day
>Assignee: Ben O'Day
>Priority: Minor
> Attachments: LevelDBAggregatorUseLatestTest.patch
>
>
> I'm using an the aggregator with the LevelDBAggregationRepository and seeing
> an incorrect redelivery of a message when using the
> UseLatestAggregationStrategy...
> this very basic route (see attached)...
> from("direct:start")
> .aggregate(constant(true), new
> UseLatestAggregationStrategy())
> .completionSize(2)
>
> .aggregationRepository(repo)
> .to("mock:mock");
> shows the following behavior...
> WARN LevelDBAggregationRepository - Unable to confirm exchangeId
> [ID-localhost-63819-1436483565832-0-6 from repository repo1: Not Found]
> DEBUG LevelDBAggregationRepository - Scanned and found 1 exchange(s) to
> recover (note some of them may already be in progress).
> DEBUG LevelDBAggregationRepository - Recovering exchangeId
> [ID-localhost-63819-1436483565832-0-3] -> Exchange[Message: test1]
> resulting in a duplicate message being processed through the aggregator
> route...
> if the default in-memory repo is used, the test behaves as expected...no
> unnecessary redelivery, etc.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-8971) HazelcastAggregatorRepository redelivers incorrectly
[
https://issues.apache.org/jira/browse/CAMEL-8971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ben O'Day updated CAMEL-8971:
-
Attachment: HazelcastAggRepo-redelivery-fix.patch
attached a potential patch to get this repo to work for the simple size based
aggregation route...still investigating
> HazelcastAggregatorRepository redelivers incorrectly
>
>
> Key: CAMEL-8971
> URL: https://issues.apache.org/jira/browse/CAMEL-8971
> Project: Camel
> Issue Type: Bug
> Components: camel-hazelcast
>Affects Versions: 2.16
>Reporter: Ben O'Day
>Assignee: Ben O'Day
>Priority: Minor
> Attachments: HazelcastAggRepo-redelivery-fix.patch
>
>
> seeing an incorrect redelivery of a message when using the
> UseLatestAggregationStrategy...
> this very basic route (see attached)...
> from("direct:start")
> .aggregate(constant(true), new
> UseLatestAggregationStrategy())
> .completionSize(2)
>
> .aggregationRepository(repo)
> .to("mock:mock");
> resulting in a duplicate message being processed through the aggregator
> route...
> if the default in-memory repo is used, the test behaves as expected...no
> unnecessary redelivery, etc.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Work started] (CAMEL-8971) HazelcastAggregatorRepository redelivers incorrectly
[
https://issues.apache.org/jira/browse/CAMEL-8971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on CAMEL-8971 started by Ben O'Day.
> HazelcastAggregatorRepository redelivers incorrectly
>
>
> Key: CAMEL-8971
> URL: https://issues.apache.org/jira/browse/CAMEL-8971
> Project: Camel
> Issue Type: Bug
> Components: camel-hazelcast
>Affects Versions: 2.16
>Reporter: Ben O'Day
>Assignee: Ben O'Day
>Priority: Minor
>
> seeing an incorrect redelivery of a message when using the
> UseLatestAggregationStrategy...
> this very basic route (see attached)...
> from("direct:start")
> .aggregate(constant(true), new
> UseLatestAggregationStrategy())
> .completionSize(2)
>
> .aggregationRepository(repo)
> .to("mock:mock");
> resulting in a duplicate message being processed through the aggregator
> route...
> if the default in-memory repo is used, the test behaves as expected...no
> unnecessary redelivery, etc.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-8971) HazelcastAggregatorRepository redelivers incorrectly
[
https://issues.apache.org/jira/browse/CAMEL-8971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ben O'Day updated CAMEL-8971:
-
Priority: Minor (was: Major)
> HazelcastAggregatorRepository redelivers incorrectly
>
>
> Key: CAMEL-8971
> URL: https://issues.apache.org/jira/browse/CAMEL-8971
> Project: Camel
> Issue Type: Bug
> Components: camel-hazelcast
>Affects Versions: 2.16
>Reporter: Ben O'Day
>Assignee: Ben O'Day
>Priority: Minor
>
> seeing an incorrect redelivery of a message when using the
> UseLatestAggregationStrategy...
> this very basic route (see attached)...
> from("direct:start")
> .aggregate(constant(true), new
> UseLatestAggregationStrategy())
> .completionSize(2)
>
> .aggregationRepository(repo)
> .to("mock:mock");
> resulting in a duplicate message being processed through the aggregator
> route...
> if the default in-memory repo is used, the test behaves as expected...no
> unnecessary redelivery, etc.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-8971) HazelcastAggregatorRepository redelivers incorrectly
[
https://issues.apache.org/jira/browse/CAMEL-8971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ben O'Day updated CAMEL-8971:
-
Component/s: (was: camel-leveldb)
camel-hazelcast
> HazelcastAggregatorRepository redelivers incorrectly
>
>
> Key: CAMEL-8971
> URL: https://issues.apache.org/jira/browse/CAMEL-8971
> Project: Camel
> Issue Type: Bug
> Components: camel-hazelcast
>Affects Versions: 2.16
>Reporter: Ben O'Day
>Assignee: Ben O'Day
>Priority: Minor
>
> seeing an incorrect redelivery of a message when using the
> UseLatestAggregationStrategy...
> this very basic route (see attached)...
> from("direct:start")
> .aggregate(constant(true), new
> UseLatestAggregationStrategy())
> .completionSize(2)
>
> .aggregationRepository(repo)
> .to("mock:mock");
> resulting in a duplicate message being processed through the aggregator
> route...
> if the default in-memory repo is used, the test behaves as expected...no
> unnecessary redelivery, etc.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-8947) LevelDBAggregatorRepository redelivers incorrectly
[
https://issues.apache.org/jira/browse/CAMEL-8947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ben O'Day updated CAMEL-8947:
-
Priority: Minor (was: Major)
> LevelDBAggregatorRepository redelivers incorrectly
> --
>
> Key: CAMEL-8947
> URL: https://issues.apache.org/jira/browse/CAMEL-8947
> Project: Camel
> Issue Type: Bug
> Components: camel-leveldb
>Affects Versions: 2.16
>Reporter: Ben O'Day
>Assignee: Ben O'Day
>Priority: Minor
> Attachments: LevelDBAggregatorUseLatestTest.patch
>
>
> I'm using an the aggregator with the LevelDBAggregationRepository and seeing
> an incorrect redelivery of a message when using the
> UseLatestAggregationStrategy...
> this very basic route (see attached)...
> from("direct:start")
> .aggregate(constant(true), new
> UseLatestAggregationStrategy())
> .completionSize(2)
>
> .aggregationRepository(repo)
> .to("mock:mock");
> shows the following behavior...
> WARN LevelDBAggregationRepository - Unable to confirm exchangeId
> [ID-localhost-63819-1436483565832-0-6 from repository repo1: Not Found]
> DEBUG LevelDBAggregationRepository - Scanned and found 1 exchange(s) to
> recover (note some of them may already be in progress).
> DEBUG LevelDBAggregationRepository - Recovering exchangeId
> [ID-localhost-63819-1436483565832-0-3] -> Exchange[Message: test1]
> resulting in a duplicate message being processed through the aggregator
> route...
> if the default in-memory repo is used, the test behaves as expected...no
> unnecessary redelivery, etc.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-8971) HazelcastAggregatorRepository redelivers incorrectly
[
https://issues.apache.org/jira/browse/CAMEL-8971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ben O'Day updated CAMEL-8971:
-
Description:
seeing an incorrect redelivery of a message when using the
UseLatestAggregationStrategy...
this very basic route (see attached)...
from("direct:start")
.aggregate(constant(true), new
UseLatestAggregationStrategy())
.completionSize(2)
.aggregationRepository(repo)
.to("mock:mock");
resulting in a duplicate message being processed through the aggregator route...
if the default in-memory repo is used, the test behaves as expected...no
unnecessary redelivery, etc.
was:
I'm using an the aggregator with the LevelDBAggregationRepository and seeing an
incorrect redelivery of a message when using the UseLatestAggregationStrategy...
this very basic route (see attached)...
from("direct:start")
.aggregate(constant(true), new
UseLatestAggregationStrategy())
.completionSize(2)
.aggregationRepository(repo)
.to("mock:mock");
shows the following behavior...
WARN LevelDBAggregationRepository - Unable to confirm exchangeId
[ID-localhost-63819-1436483565832-0-6 from repository repo1: Not Found]
DEBUG LevelDBAggregationRepository - Scanned and found 1 exchange(s) to
recover (note some of them may already be in progress).
DEBUG LevelDBAggregationRepository - Recovering exchangeId
[ID-localhost-63819-1436483565832-0-3] -> Exchange[Message: test1]
resulting in a duplicate message being processed through the aggregator route...
if the default in-memory repo is used, the test behaves as expected...no
unnecessary redelivery, etc.
> HazelcastAggregatorRepository redelivers incorrectly
>
>
> Key: CAMEL-8971
> URL: https://issues.apache.org/jira/browse/CAMEL-8971
> Project: Camel
> Issue Type: Bug
> Components: camel-leveldb
>Affects Versions: 2.16
>Reporter: Ben O'Day
>Assignee: Ben O'Day
>
> seeing an incorrect redelivery of a message when using the
> UseLatestAggregationStrategy...
> this very basic route (see attached)...
> from("direct:start")
> .aggregate(constant(true), new
> UseLatestAggregationStrategy())
> .completionSize(2)
>
> .aggregationRepository(repo)
> .to("mock:mock");
> resulting in a duplicate message being processed through the aggregator
> route...
> if the default in-memory repo is used, the test behaves as expected...no
> unnecessary redelivery, etc.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CAMEL-8971) HazelcastAggregatorRepository redelivers incorrectly
Ben O'Day created CAMEL-8971:
Summary: HazelcastAggregatorRepository redelivers incorrectly
Key: CAMEL-8971
URL: https://issues.apache.org/jira/browse/CAMEL-8971
Project: Camel
Issue Type: Bug
Components: camel-leveldb
Affects Versions: 2.16
Reporter: Ben O'Day
Assignee: Ben O'Day
I'm using an the aggregator with the LevelDBAggregationRepository and seeing an
incorrect redelivery of a message when using the UseLatestAggregationStrategy...
this very basic route (see attached)...
from("direct:start")
.aggregate(constant(true), new
UseLatestAggregationStrategy())
.completionSize(2)
.aggregationRepository(repo)
.to("mock:mock");
shows the following behavior...
WARN LevelDBAggregationRepository - Unable to confirm exchangeId
[ID-localhost-63819-1436483565832-0-6 from repository repo1: Not Found]
DEBUG LevelDBAggregationRepository - Scanned and found 1 exchange(s) to
recover (note some of them may already be in progress).
DEBUG LevelDBAggregationRepository - Recovering exchangeId
[ID-localhost-63819-1436483565832-0-3] -> Exchange[Message: test1]
resulting in a duplicate message being processed through the aggregator route...
if the default in-memory repo is used, the test behaves as expected...no
unnecessary redelivery, etc.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-8947) LevelDBAggregatorRepository redelivers incorrectly
[
https://issues.apache.org/jira/browse/CAMEL-8947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ben O'Day updated CAMEL-8947:
-
Attachment: (was: HazelcastAggRepo-redelivery-fix.patch)
> LevelDBAggregatorRepository redelivers incorrectly
> --
>
> Key: CAMEL-8947
> URL: https://issues.apache.org/jira/browse/CAMEL-8947
> Project: Camel
> Issue Type: Bug
> Components: camel-leveldb
>Affects Versions: 2.16
>Reporter: Ben O'Day
>Assignee: Ben O'Day
> Attachments: LevelDBAggregatorUseLatestTest.patch
>
>
> I'm using an the aggregator with the LevelDBAggregationRepository and seeing
> an incorrect redelivery of a message when using the
> UseLatestAggregationStrategy...
> this very basic route (see attached)...
> from("direct:start")
> .aggregate(constant(true), new
> UseLatestAggregationStrategy())
> .completionSize(2)
>
> .aggregationRepository(repo)
> .to("mock:mock");
> shows the following behavior...
> WARN LevelDBAggregationRepository - Unable to confirm exchangeId
> [ID-localhost-63819-1436483565832-0-6 from repository repo1: Not Found]
> DEBUG LevelDBAggregationRepository - Scanned and found 1 exchange(s) to
> recover (note some of them may already be in progress).
> DEBUG LevelDBAggregationRepository - Recovering exchangeId
> [ID-localhost-63819-1436483565832-0-3] -> Exchange[Message: test1]
> resulting in a duplicate message being processed through the aggregator
> route...
> if the default in-memory repo is used, the test behaves as expected...no
> unnecessary redelivery, etc.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-8947) LevelDBAggregatorRepository redelivers incorrectly
[
https://issues.apache.org/jira/browse/CAMEL-8947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ben O'Day updated CAMEL-8947:
-
Attachment: HazelcastAggRepo-redelivery-fix.patch
attached a potential patch to the HazelcastAggregationRepository to get this to
work with my simple unit test...not sure if it breaks something else at this
point, just wanted to throw it out for some feedback...
> LevelDBAggregatorRepository redelivers incorrectly
> --
>
> Key: CAMEL-8947
> URL: https://issues.apache.org/jira/browse/CAMEL-8947
> Project: Camel
> Issue Type: Bug
> Components: camel-leveldb
>Affects Versions: 2.16
>Reporter: Ben O'Day
>Assignee: Ben O'Day
> Attachments: HazelcastAggRepo-redelivery-fix.patch,
> LevelDBAggregatorUseLatestTest.patch
>
>
> I'm using an the aggregator with the LevelDBAggregationRepository and seeing
> an incorrect redelivery of a message when using the
> UseLatestAggregationStrategy...
> this very basic route (see attached)...
> from("direct:start")
> .aggregate(constant(true), new
> UseLatestAggregationStrategy())
> .completionSize(2)
>
> .aggregationRepository(repo)
> .to("mock:mock");
> shows the following behavior...
> WARN LevelDBAggregationRepository - Unable to confirm exchangeId
> [ID-localhost-63819-1436483565832-0-6 from repository repo1: Not Found]
> DEBUG LevelDBAggregationRepository - Scanned and found 1 exchange(s) to
> recover (note some of them may already be in progress).
> DEBUG LevelDBAggregationRepository - Recovering exchangeId
> [ID-localhost-63819-1436483565832-0-3] -> Exchange[Message: test1]
> resulting in a duplicate message being processed through the aggregator
> route...
> if the default in-memory repo is used, the test behaves as expected...no
> unnecessary redelivery, etc.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Work started] (CAMEL-8947) LevelDBAggregatorRepository redelivers incorrectly
[
https://issues.apache.org/jira/browse/CAMEL-8947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on CAMEL-8947 started by Ben O'Day.
> LevelDBAggregatorRepository redelivers incorrectly
> --
>
> Key: CAMEL-8947
> URL: https://issues.apache.org/jira/browse/CAMEL-8947
> Project: Camel
> Issue Type: Bug
> Components: camel-leveldb
>Affects Versions: 2.16
>Reporter: Ben O'Day
>Assignee: Ben O'Day
> Attachments: LevelDBAggregatorUseLatestTest.patch
>
>
> I'm using an the aggregator with the LevelDBAggregationRepository and seeing
> an incorrect redelivery of a message when using the
> UseLatestAggregationStrategy...
> this very basic route (see attached)...
> from("direct:start")
> .aggregate(constant(true), new
> UseLatestAggregationStrategy())
> .completionSize(2)
>
> .aggregationRepository(repo)
> .to("mock:mock");
> shows the following behavior...
> WARN LevelDBAggregationRepository - Unable to confirm exchangeId
> [ID-localhost-63819-1436483565832-0-6 from repository repo1: Not Found]
> DEBUG LevelDBAggregationRepository - Scanned and found 1 exchange(s) to
> recover (note some of them may already be in progress).
> DEBUG LevelDBAggregationRepository - Recovering exchangeId
> [ID-localhost-63819-1436483565832-0-3] -> Exchange[Message: test1]
> resulting in a duplicate message being processed through the aggregator
> route...
> if the default in-memory repo is used, the test behaves as expected...no
> unnecessary redelivery, etc.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CAMEL-8947) LevelDBAggregatorRepository redelivers incorrectly
[
https://issues.apache.org/jira/browse/CAMEL-8947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ben O'Day reassigned CAMEL-8947:
Assignee: Ben O'Day
> LevelDBAggregatorRepository redelivers incorrectly
> --
>
> Key: CAMEL-8947
> URL: https://issues.apache.org/jira/browse/CAMEL-8947
> Project: Camel
> Issue Type: Bug
> Components: camel-leveldb
>Affects Versions: 2.16
>Reporter: Ben O'Day
>Assignee: Ben O'Day
> Attachments: LevelDBAggregatorUseLatestTest.patch
>
>
> I'm using an the aggregator with the LevelDBAggregationRepository and seeing
> an incorrect redelivery of a message when using the
> UseLatestAggregationStrategy...
> this very basic route (see attached)...
> from("direct:start")
> .aggregate(constant(true), new
> UseLatestAggregationStrategy())
> .completionSize(2)
>
> .aggregationRepository(repo)
> .to("mock:mock");
> shows the following behavior...
> WARN LevelDBAggregationRepository - Unable to confirm exchangeId
> [ID-localhost-63819-1436483565832-0-6 from repository repo1: Not Found]
> DEBUG LevelDBAggregationRepository - Scanned and found 1 exchange(s) to
> recover (note some of them may already be in progress).
> DEBUG LevelDBAggregationRepository - Recovering exchangeId
> [ID-localhost-63819-1436483565832-0-3] -> Exchange[Message: test1]
> resulting in a duplicate message being processed through the aggregator
> route...
> if the default in-memory repo is used, the test behaves as expected...no
> unnecessary redelivery, etc.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-8947) LevelDBAggregatorRepository redelivers incorrectly
[
https://issues.apache.org/jira/browse/CAMEL-8947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14624108#comment-14624108
]
Ben O'Day commented on CAMEL-8947:
--
I'm getting the same results using the HawtDBAggregationRepository and
HazelcastAggregationRepository...seems like there is a bug in
confirming/removing Exchanges from the repo when certain aggregation strategies
are used...
> LevelDBAggregatorRepository redelivers incorrectly
> --
>
> Key: CAMEL-8947
> URL: https://issues.apache.org/jira/browse/CAMEL-8947
> Project: Camel
> Issue Type: Bug
> Components: camel-leveldb
>Affects Versions: 2.16
>Reporter: Ben O'Day
> Attachments: LevelDBAggregatorUseLatestTest.patch
>
>
> I'm using an the aggregator with the LevelDBAggregationRepository and seeing
> an incorrect redelivery of a message when using the
> UseLatestAggregationStrategy...
> this very basic route (see attached)...
> from("direct:start")
> .aggregate(constant(true), new
> UseLatestAggregationStrategy())
> .completionSize(2)
>
> .aggregationRepository(repo)
> .to("mock:mock");
> shows the following behavior...
> WARN LevelDBAggregationRepository - Unable to confirm exchangeId
> [ID-localhost-63819-1436483565832-0-6 from repository repo1: Not Found]
> DEBUG LevelDBAggregationRepository - Scanned and found 1 exchange(s) to
> recover (note some of them may already be in progress).
> DEBUG LevelDBAggregationRepository - Recovering exchangeId
> [ID-localhost-63819-1436483565832-0-3] -> Exchange[Message: test1]
> resulting in a duplicate message being processed through the aggregator
> route...
> if the default in-memory repo is used, the test behaves as expected...no
> unnecessary redelivery, etc.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-8947) LevelDBAggregatorRepository redelivers incorrectly
[
https://issues.apache.org/jira/browse/CAMEL-8947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ben O'Day updated CAMEL-8947:
-
Description:
I'm using an the aggregator with the LevelDBAggregationRepository and seeing an
incorrect redelivery of a message when using the UseLatestAggregationStrategy...
this very basic route (see attached)...
from("direct:start")
.aggregate(constant(true), new
UseLatestAggregationStrategy())
.completionSize(2)
.aggregationRepository(repo)
.to("mock:mock");
shows the following behavior...
WARN LevelDBAggregationRepository - Unable to confirm exchangeId
[ID-localhost-63819-1436483565832-0-6 from repository repo1: Not Found]
DEBUG LevelDBAggregationRepository - Scanned and found 1 exchange(s) to
recover (note some of them may already be in progress).
DEBUG LevelDBAggregationRepository - Recovering exchangeId
[ID-localhost-63819-1436483565832-0-3] -> Exchange[Message: test1]
resulting in a duplicate message being processed through the aggregator route...
if the default in-memory repo is used, the test behaves as expected...no
unnecessary redelivery, etc.
was:
I'm using an the aggregator with the LevelDBAggregationRepository and seeing an
incorrect redelivery of a message when using the UseLatestAggregationStrategy...
attached unit test shows the following behavior:
WARN LevelDBAggregationRepository - Unable to confirm exchangeId
[ID-localhost-63819-1436483565832-0-6 from repository repo1: Not Found]
DEBUG LevelDBAggregationRepository - Scanned and found 1 exchange(s) to
recover (note some of them may already be in progress).
DEBUG LevelDBAggregationRepository - Recovering exchangeId
[ID-localhost-63819-1436483565832-0-3] -> Exchange[Message: test1]
resulting in a duplicate message being processed through the aggregator route...
if the default in-memory repo is used, the test behaves as expected...no
unnecessary redelivery, etc.
> LevelDBAggregatorRepository redelivers incorrectly
> --
>
> Key: CAMEL-8947
> URL: https://issues.apache.org/jira/browse/CAMEL-8947
> Project: Camel
> Issue Type: Bug
> Components: camel-leveldb
>Affects Versions: 2.16
>Reporter: Ben O'Day
> Attachments: LevelDBAggregatorUseLatestTest.patch
>
>
> I'm using an the aggregator with the LevelDBAggregationRepository and seeing
> an incorrect redelivery of a message when using the
> UseLatestAggregationStrategy...
> this very basic route (see attached)...
> from("direct:start")
> .aggregate(constant(true), new
> UseLatestAggregationStrategy())
> .completionSize(2)
>
> .aggregationRepository(repo)
> .to("mock:mock");
> shows the following behavior...
> WARN LevelDBAggregationRepository - Unable to confirm exchangeId
> [ID-localhost-63819-1436483565832-0-6 from repository repo1: Not Found]
> DEBUG LevelDBAggregationRepository - Scanned and found 1 exchange(s) to
> recover (note some of them may already be in progress).
> DEBUG LevelDBAggregationRepository - Recovering exchangeId
> [ID-localhost-63819-1436483565832-0-3] -> Exchange[Message: test1]
> resulting in a duplicate message being processed through the aggregator
> route...
> if the default in-memory repo is used, the test behaves as expected...no
> unnecessary redelivery, etc.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-8947) LevelDBAggregatorRepository redelivers incorrectly
[ https://issues.apache.org/jira/browse/CAMEL-8947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben O'Day updated CAMEL-8947: - Attachment: LevelDBAggregatorUseLatestTest.patch > LevelDBAggregatorRepository redelivers incorrectly > -- > > Key: CAMEL-8947 > URL: https://issues.apache.org/jira/browse/CAMEL-8947 > Project: Camel > Issue Type: Bug > Components: camel-leveldb >Affects Versions: 2.16 >Reporter: Ben O'Day > Attachments: LevelDBAggregatorUseLatestTest.patch > > > I'm using an the aggregator with the LevelDBAggregationRepository and seeing > an incorrect redelivery of a message when using the > UseLatestAggregationStrategy... > attached unit test shows the following behavior: > WARN LevelDBAggregationRepository - Unable to confirm exchangeId > [ID-localhost-63819-1436483565832-0-6 from repository repo1: Not Found] > DEBUG LevelDBAggregationRepository - Scanned and found 1 exchange(s) to > recover (note some of them may already be in progress). > DEBUG LevelDBAggregationRepository - Recovering exchangeId > [ID-localhost-63819-1436483565832-0-3] -> Exchange[Message: test1] > resulting in a duplicate message being processed through the aggregator > route... > if the default in-memory repo is used, the test behaves as expected...no > unnecessary redelivery, etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-8947) LevelDBAggregatorRepository redelivers incorrectly
Ben O'Day created CAMEL-8947: Summary: LevelDBAggregatorRepository redelivers incorrectly Key: CAMEL-8947 URL: https://issues.apache.org/jira/browse/CAMEL-8947 Project: Camel Issue Type: Bug Components: camel-leveldb Affects Versions: 2.16 Reporter: Ben O'Day I'm using an the aggregator with the LevelDBAggregationRepository and seeing an incorrect redelivery of a message when using the UseLatestAggregationStrategy... attached unit test shows the following behavior: WARN LevelDBAggregationRepository - Unable to confirm exchangeId [ID-localhost-63819-1436483565832-0-6 from repository repo1: Not Found] DEBUG LevelDBAggregationRepository - Scanned and found 1 exchange(s) to recover (note some of them may already be in progress). DEBUG LevelDBAggregationRepository - Recovering exchangeId [ID-localhost-63819-1436483565832-0-3] -> Exchange[Message: test1] resulting in a duplicate message being processed through the aggregator route... if the default in-memory repo is used, the test behaves as expected...no unnecessary redelivery, etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-7905) New option to ignore missing consumers on direct endpoints
[
https://issues.apache.org/jira/browse/CAMEL-7905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14391326#comment-14391326
]
Ben O'Day commented on CAMEL-7905:
--
added option to both direct/direct-vm components...they default to 'true' to
maintain current functionality
> New option to ignore missing consumers on direct endpoints
> --
>
> Key: CAMEL-7905
> URL: https://issues.apache.org/jira/browse/CAMEL-7905
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
>Reporter: Daniel
>Assignee: Ben O'Day
>Priority: Minor
> Fix For: 2.16.0
>
>
> Currently a {{DirectConsumerNotAvailableException}} or
> {{DirectVmConsumerNotAvailableException}} is thrown when a message is send
> via a direct endoint and no consumer has been set up for this endpoint.
> In a current scenario I want to use camel to loosely couple two components
> using direct endpoints that _might_ be consumed by some bean. Especially
> there should be no dependency from the producing component to the consuming
> component. However, if there is a consumer, messages send from the producer
> must be consumed synchronously in the same thread to preserve the transaction
> context of the producer. That why I chose {{direct}} for the producer's
> endpoint.
> What is meant by "the messages might be consumed" is that the consuming
> component might not be deployed, when the consumer produces the first
> messages, or perhaps will never be deployed. I know there is the {{block}}
> option for the {{direct}} component but I don't want the producer to wait for
> the consumer as it might take some time (possibly forever) for the consumer
> to be available.
> I think this is a very common scenario for a messaging system and I was
> surprised not to find an easy out-of-the-box way to handle this with camel.
> That's why I think an additional option {{failIfNoConsumers}} (similar to the
> option for the seda component) for the {{direct}} and {{direct-vm}} component
> would be very handy.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (CAMEL-7905) New option to ignore missing consumers on direct endpoints
[
https://issues.apache.org/jira/browse/CAMEL-7905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ben O'Day closed CAMEL-7905.
Resolution: Fixed
> New option to ignore missing consumers on direct endpoints
> --
>
> Key: CAMEL-7905
> URL: https://issues.apache.org/jira/browse/CAMEL-7905
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
>Reporter: Daniel
>Assignee: Ben O'Day
>Priority: Minor
> Fix For: 2.16.0
>
>
> Currently a {{DirectConsumerNotAvailableException}} or
> {{DirectVmConsumerNotAvailableException}} is thrown when a message is send
> via a direct endoint and no consumer has been set up for this endpoint.
> In a current scenario I want to use camel to loosely couple two components
> using direct endpoints that _might_ be consumed by some bean. Especially
> there should be no dependency from the producing component to the consuming
> component. However, if there is a consumer, messages send from the producer
> must be consumed synchronously in the same thread to preserve the transaction
> context of the producer. That why I chose {{direct}} for the producer's
> endpoint.
> What is meant by "the messages might be consumed" is that the consuming
> component might not be deployed, when the consumer produces the first
> messages, or perhaps will never be deployed. I know there is the {{block}}
> option for the {{direct}} component but I don't want the producer to wait for
> the consumer as it might take some time (possibly forever) for the consumer
> to be available.
> I think this is a very common scenario for a messaging system and I was
> surprised not to find an easy out-of-the-box way to handle this with camel.
> That's why I think an additional option {{failIfNoConsumers}} (similar to the
> option for the seda component) for the {{direct}} and {{direct-vm}} component
> would be very handy.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Work started] (CAMEL-7905) New option to ignore missing consumers on direct endpoints
[
https://issues.apache.org/jira/browse/CAMEL-7905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on CAMEL-7905 started by Ben O'Day.
> New option to ignore missing consumers on direct endpoints
> --
>
> Key: CAMEL-7905
> URL: https://issues.apache.org/jira/browse/CAMEL-7905
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
>Reporter: Daniel
>Assignee: Ben O'Day
>Priority: Minor
> Fix For: 2.16.0
>
>
> Currently a {{DirectConsumerNotAvailableException}} or
> {{DirectVmConsumerNotAvailableException}} is thrown when a message is send
> via a direct endoint and no consumer has been set up for this endpoint.
> In a current scenario I want to use camel to loosely couple two components
> using direct endpoints that _might_ be consumed by some bean. Especially
> there should be no dependency from the producing component to the consuming
> component. However, if there is a consumer, messages send from the producer
> must be consumed synchronously in the same thread to preserve the transaction
> context of the producer. That why I chose {{direct}} for the producer's
> endpoint.
> What is meant by "the messages might be consumed" is that the consuming
> component might not be deployed, when the consumer produces the first
> messages, or perhaps will never be deployed. I know there is the {{block}}
> option for the {{direct}} component but I don't want the producer to wait for
> the consumer as it might take some time (possibly forever) for the consumer
> to be available.
> I think this is a very common scenario for a messaging system and I was
> surprised not to find an easy out-of-the-box way to handle this with camel.
> That's why I think an additional option {{failIfNoConsumers}} (similar to the
> option for the seda component) for the {{direct}} and {{direct-vm}} component
> would be very handy.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-7905) New option to ignore missing consumers on direct endpoints
[
https://issues.apache.org/jira/browse/CAMEL-7905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14375350#comment-14375350
]
Ben O'Day commented on CAMEL-7905:
--
yep, that was my take as well...I'll dust off this code and try to get it in
for 2.16.0
> New option to ignore missing consumers on direct endpoints
> --
>
> Key: CAMEL-7905
> URL: https://issues.apache.org/jira/browse/CAMEL-7905
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
>Reporter: Daniel
>Assignee: Ben O'Day
>Priority: Minor
> Fix For: 2.16.0
>
>
> Currently a {{DirectConsumerNotAvailableException}} or
> {{DirectVmConsumerNotAvailableException}} is thrown when a message is send
> via a direct endoint and no consumer has been set up for this endpoint.
> In a current scenario I want to use camel to loosely couple two components
> using direct endpoints that _might_ be consumed by some bean. Especially
> there should be no dependency from the producing component to the consuming
> component. However, if there is a consumer, messages send from the producer
> must be consumed synchronously in the same thread to preserve the transaction
> context of the producer. That why I chose {{direct}} for the producer's
> endpoint.
> What is meant by "the messages might be consumed" is that the consuming
> component might not be deployed, when the consumer produces the first
> messages, or perhaps will never be deployed. I know there is the {{block}}
> option for the {{direct}} component but I don't want the producer to wait for
> the consumer as it might take some time (possibly forever) for the consumer
> to be available.
> I think this is a very common scenario for a messaging system and I was
> surprised not to find an easy out-of-the-box way to handle this with camel.
> That's why I think an additional option {{failIfNoConsumers}} (similar to the
> option for the seda component) for the {{direct}} and {{direct-vm}} component
> would be very handy.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-7905) New option to ignore missing consumers on direct endpoints
[
https://issues.apache.org/jira/browse/CAMEL-7905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ben O'Day updated CAMEL-7905:
-
Estimated Complexity: Moderate (was: Unknown)
> New option to ignore missing consumers on direct endpoints
> --
>
> Key: CAMEL-7905
> URL: https://issues.apache.org/jira/browse/CAMEL-7905
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
>Reporter: Daniel
>Assignee: Ben O'Day
>Priority: Minor
>
> Currently a {{DirectConsumerNotAvailableException}} or
> {{DirectVmConsumerNotAvailableException}} is thrown when a message is send
> via a direct endoint and no consumer has been set up for this endpoint.
> In a current scenario I want to use camel to loosely couple two components
> using direct endpoints that _might_ be consumed by some bean. Especially
> there should be no dependency from the producing component to the consuming
> component. However, if there is a consumer, messages send from the producer
> must be consumed synchronously in the same thread to preserve the transaction
> context of the producer. That why I chose {{direct}} for the producer's
> endpoint.
> What is meant by "the messages might be consumed" is that the consuming
> component might not be deployed, when the consumer produces the first
> messages, or perhaps will never be deployed. I know there is the {{block}}
> option for the {{direct}} component but I don't want the producer to wait for
> the consumer as it might take some time (possibly forever) for the consumer
> to be available.
> I think this is a very common scenario for a messaging system and I was
> surprised not to find an easy out-of-the-box way to handle this with camel.
> That's why I think an additional option {{failIfNoConsumers}} (similar to the
> option for the seda component) for the {{direct}} and {{direct-vm}} component
> would be very handy.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-7905) New option to ignore missing consumers on direct endpoints
[
https://issues.apache.org/jira/browse/CAMEL-7905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ben O'Day updated CAMEL-7905:
-
Component/s: (was: el-core)
> New option to ignore missing consumers on direct endpoints
> --
>
> Key: CAMEL-7905
> URL: https://issues.apache.org/jira/browse/CAMEL-7905
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
>Reporter: Daniel
>Assignee: Ben O'Day
>Priority: Minor
>
> Currently a {{DirectConsumerNotAvailableException}} or
> {{DirectVmConsumerNotAvailableException}} is thrown when a message is send
> via a direct endoint and no consumer has been set up for this endpoint.
> In a current scenario I want to use camel to loosely couple two components
> using direct endpoints that _might_ be consumed by some bean. Especially
> there should be no dependency from the producing component to the consuming
> component. However, if there is a consumer, messages send from the producer
> must be consumed synchronously in the same thread to preserve the transaction
> context of the producer. That why I chose {{direct}} for the producer's
> endpoint.
> What is meant by "the messages might be consumed" is that the consuming
> component might not be deployed, when the consumer produces the first
> messages, or perhaps will never be deployed. I know there is the {{block}}
> option for the {{direct}} component but I don't want the producer to wait for
> the consumer as it might take some time (possibly forever) for the consumer
> to be available.
> I think this is a very common scenario for a messaging system and I was
> surprised not to find an easy out-of-the-box way to handle this with camel.
> That's why I think an additional option {{failIfNoConsumers}} (similar to the
> option for the seda component) for the {{direct}} and {{direct-vm}} component
> would be very handy.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-7905) New option to ignore missing consumers on direct endpoints
[
https://issues.apache.org/jira/browse/CAMEL-7905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14228846#comment-14228846
]
Ben O'Day commented on CAMEL-7905:
--
you can always catch the DirectConsumerNotAvailableException in the producer
and just log/ignore it...otherwise, I agree that it would be easier/cleaner if
a simple option existed to ignore these errors for certain routes, etc...
unless there are any objections, I'll look into adding this option...
> New option to ignore missing consumers on direct endpoints
> --
>
> Key: CAMEL-7905
> URL: https://issues.apache.org/jira/browse/CAMEL-7905
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
>Reporter: Daniel
>
> Currently a {{DirectConsumerNotAvailableException}} or
> {{DirectVmConsumerNotAvailableException}} is thrown when a message is send
> via a direct endoint and no consumer has been set up for this endpoint.
> In a current scenario I want to use camel to loosely couple two components
> using direct endpoints that _might_ be consumed by some bean. Especially
> there should be no dependency from the producing component to the consuming
> component. However, if there is a consumer, messages send from the producer
> must be consumed synchronously in the same thread to preserve the transaction
> context of the producer. That why I chose {{direct}} for the producer's
> endpoint.
> What is meant by "the messages might be consumed" is that the consuming
> component might not be deployed, when the consumer produces the first
> messages, or perhaps will never be deployed. I know there is the {{block}}
> option for the {{direct}} component but I don't want the producer to wait for
> the consumer as it might take some time (possibly forever) for the consumer
> to be available.
> I think this is a very common scenario for a messaging system and I was
> surprised not to find an easy out-of-the-box way to handle this with camel.
> That's why I think an additional option {{failIfNoConsumers}} (similar to the
> option for the seda component) for the {{direct}} and {{direct-vm}} component
> would be very handy.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-7905) New option to ignore missing consumers on direct endpoints
[
https://issues.apache.org/jira/browse/CAMEL-7905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ben O'Day updated CAMEL-7905:
-
Priority: Minor (was: Major)
> New option to ignore missing consumers on direct endpoints
> --
>
> Key: CAMEL-7905
> URL: https://issues.apache.org/jira/browse/CAMEL-7905
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
>Reporter: Daniel
>Assignee: Ben O'Day
>Priority: Minor
>
> Currently a {{DirectConsumerNotAvailableException}} or
> {{DirectVmConsumerNotAvailableException}} is thrown when a message is send
> via a direct endoint and no consumer has been set up for this endpoint.
> In a current scenario I want to use camel to loosely couple two components
> using direct endpoints that _might_ be consumed by some bean. Especially
> there should be no dependency from the producing component to the consuming
> component. However, if there is a consumer, messages send from the producer
> must be consumed synchronously in the same thread to preserve the transaction
> context of the producer. That why I chose {{direct}} for the producer's
> endpoint.
> What is meant by "the messages might be consumed" is that the consuming
> component might not be deployed, when the consumer produces the first
> messages, or perhaps will never be deployed. I know there is the {{block}}
> option for the {{direct}} component but I don't want the producer to wait for
> the consumer as it might take some time (possibly forever) for the consumer
> to be available.
> I think this is a very common scenario for a messaging system and I was
> surprised not to find an easy out-of-the-box way to handle this with camel.
> That's why I think an additional option {{failIfNoConsumers}} (similar to the
> option for the seda component) for the {{direct}} and {{direct-vm}} component
> would be very handy.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CAMEL-7905) New option to ignore missing consumers on direct endpoints
[
https://issues.apache.org/jira/browse/CAMEL-7905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ben O'Day reassigned CAMEL-7905:
Assignee: Ben O'Day
> New option to ignore missing consumers on direct endpoints
> --
>
> Key: CAMEL-7905
> URL: https://issues.apache.org/jira/browse/CAMEL-7905
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
>Reporter: Daniel
>Assignee: Ben O'Day
>
> Currently a {{DirectConsumerNotAvailableException}} or
> {{DirectVmConsumerNotAvailableException}} is thrown when a message is send
> via a direct endoint and no consumer has been set up for this endpoint.
> In a current scenario I want to use camel to loosely couple two components
> using direct endpoints that _might_ be consumed by some bean. Especially
> there should be no dependency from the producing component to the consuming
> component. However, if there is a consumer, messages send from the producer
> must be consumed synchronously in the same thread to preserve the transaction
> context of the producer. That why I chose {{direct}} for the producer's
> endpoint.
> What is meant by "the messages might be consumed" is that the consuming
> component might not be deployed, when the consumer produces the first
> messages, or perhaps will never be deployed. I know there is the {{block}}
> option for the {{direct}} component but I don't want the producer to wait for
> the consumer as it might take some time (possibly forever) for the consumer
> to be available.
> I think this is a very common scenario for a messaging system and I was
> surprised not to find an easy out-of-the-box way to handle this with camel.
> That's why I think an additional option {{failIfNoConsumers}} (similar to the
> option for the seda component) for the {{direct}} and {{direct-vm}} component
> would be very handy.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-7905) New option to ignore missing consumers on direct endpoints
[
https://issues.apache.org/jira/browse/CAMEL-7905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ben O'Day updated CAMEL-7905:
-
Affects Version/s: (was: 2.14.0)
> New option to ignore missing consumers on direct endpoints
> --
>
> Key: CAMEL-7905
> URL: https://issues.apache.org/jira/browse/CAMEL-7905
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
>Reporter: Daniel
>Assignee: Ben O'Day
>Priority: Minor
>
> Currently a {{DirectConsumerNotAvailableException}} or
> {{DirectVmConsumerNotAvailableException}} is thrown when a message is send
> via a direct endoint and no consumer has been set up for this endpoint.
> In a current scenario I want to use camel to loosely couple two components
> using direct endpoints that _might_ be consumed by some bean. Especially
> there should be no dependency from the producing component to the consuming
> component. However, if there is a consumer, messages send from the producer
> must be consumed synchronously in the same thread to preserve the transaction
> context of the producer. That why I chose {{direct}} for the producer's
> endpoint.
> What is meant by "the messages might be consumed" is that the consuming
> component might not be deployed, when the consumer produces the first
> messages, or perhaps will never be deployed. I know there is the {{block}}
> option for the {{direct}} component but I don't want the producer to wait for
> the consumer as it might take some time (possibly forever) for the consumer
> to be available.
> I think this is a very common scenario for a messaging system and I was
> surprised not to find an easy out-of-the-box way to handle this with camel.
> That's why I think an additional option {{failIfNoConsumers}} (similar to the
> option for the seda component) for the {{direct}} and {{direct-vm}} component
> would be very handy.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-7905) New option to ignore missing consumers on direct endpoints
[
https://issues.apache.org/jira/browse/CAMEL-7905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ben O'Day updated CAMEL-7905:
-
Component/s: camel-core
el-core
> New option to ignore missing consumers on direct endpoints
> --
>
> Key: CAMEL-7905
> URL: https://issues.apache.org/jira/browse/CAMEL-7905
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
>Reporter: Daniel
>Assignee: Ben O'Day
>Priority: Minor
>
> Currently a {{DirectConsumerNotAvailableException}} or
> {{DirectVmConsumerNotAvailableException}} is thrown when a message is send
> via a direct endoint and no consumer has been set up for this endpoint.
> In a current scenario I want to use camel to loosely couple two components
> using direct endpoints that _might_ be consumed by some bean. Especially
> there should be no dependency from the producing component to the consuming
> component. However, if there is a consumer, messages send from the producer
> must be consumed synchronously in the same thread to preserve the transaction
> context of the producer. That why I chose {{direct}} for the producer's
> endpoint.
> What is meant by "the messages might be consumed" is that the consuming
> component might not be deployed, when the consumer produces the first
> messages, or perhaps will never be deployed. I know there is the {{block}}
> option for the {{direct}} component but I don't want the producer to wait for
> the consumer as it might take some time (possibly forever) for the consumer
> to be available.
> I think this is a very common scenario for a messaging system and I was
> surprised not to find an easy out-of-the-box way to handle this with camel.
> That's why I think an additional option {{failIfNoConsumers}} (similar to the
> option for the seda component) for the {{direct}} and {{direct-vm}} component
> would be very handy.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-7434) Provide a way to force the completion of a aggregate exchange from an external event
[ https://issues.apache.org/jira/browse/CAMEL-7434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben O'Day updated CAMEL-7434: - Assignee: (was: Ben O'Day) > Provide a way to force the completion of a aggregate exchange from an > external event > > > Key: CAMEL-7434 > URL: https://issues.apache.org/jira/browse/CAMEL-7434 > Project: Camel > Issue Type: New Feature > Components: camel-core, eip >Affects Versions: 2.13.0 >Reporter: Susan Javurek > Fix For: Future > > > There is a way to do this by creating a "trigger" exchange that is handled in > a special way by the aggregation strategy and a completion predicate. But > this solution is quite intrusive and painful to write. > It would actually be much easier if the AggregateProcessor would implement > and expose the following methods: > public void forceCompletionOfGroup(String key) > public Expression getCorrelationExpression() > This way, it becomes possible to control "externally" an aggregator without > having to implement some intrusive logic. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CAMEL-7905) New option to ignore missing consumers on direct endpoints
[
https://issues.apache.org/jira/browse/CAMEL-7905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14228079#comment-14228079
]
Ben O'Day edited comment on CAMEL-7905 at 11/29/14 5:34 AM:
[~dpr] - what should happen to the message that was sent...just throw it away?
a seda producer can create a blocking queue on demand to hold the message until
a consumer comes along. this doesn't work for direct however given the need to
make a synchronous call...hence the block option, etc.
was (Author: boday):
[~dpr] - would should happen to the message that was sent...just throw it away?
a seda producer can create a blocking queue on demand to hold the message
until a consumer comes along. this doesn't work for direct however given the
need to make a synchronous call...hence the block option, etc.
> New option to ignore missing consumers on direct endpoints
> --
>
> Key: CAMEL-7905
> URL: https://issues.apache.org/jira/browse/CAMEL-7905
> Project: Camel
> Issue Type: Improvement
>Affects Versions: 2.14.0
>Reporter: Daniel
>
> Currently a {{DirectConsumerNotAvailableException}} or
> {{DirectVmConsumerNotAvailableException}} is thrown when a message is send
> via a direct endoint and no consumer has been set up for this endpoint.
> In a current scenario I want to use camel to loosely couple two components
> using direct endpoints that _might_ be consumed by some bean. Especially
> there should be no dependency from the producing component to the consuming
> component. However, if there is a consumer, messages send from the producer
> must be consumed synchronously in the same thread to preserve the transaction
> context of the producer. That why I chose {{direct}} for the producer's
> endpoint.
> What is meant by "the messages might be consumed" is that the consuming
> component might not be deployed, when the consumer produces the first
> messages, or perhaps will never be deployed. I know there is the {{block}}
> option for the {{direct}} component but I don't want the producer to wait for
> the consumer as it might take some time (possibly forever) for the consumer
> to be available.
> I think this is a very common scenario for a messaging system and I was
> surprised not to find an easy out-of-the-box way to handle this with camel.
> That's why I think an additional option {{failIfNoConsumers}} (similar to the
> option for the seda component) for the {{direct}} and {{direct-vm}} component
> would be very handy.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-7905) New option to ignore missing consumers on direct endpoints
[
https://issues.apache.org/jira/browse/CAMEL-7905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14228079#comment-14228079
]
Ben O'Day commented on CAMEL-7905:
--
[~dpr] - would should happen to the message that was sent...just throw it away?
a seda producer can create a blocking queue on demand to hold the message
until a consumer comes along. this doesn't work for direct however given the
need to make a synchronous call...hence the block option, etc.
> New option to ignore missing consumers on direct endpoints
> --
>
> Key: CAMEL-7905
> URL: https://issues.apache.org/jira/browse/CAMEL-7905
> Project: Camel
> Issue Type: Improvement
>Affects Versions: 2.14.0
>Reporter: Daniel
>
> Currently a {{DirectConsumerNotAvailableException}} or
> {{DirectVmConsumerNotAvailableException}} is thrown when a message is send
> via a direct endoint and no consumer has been set up for this endpoint.
> In a current scenario I want to use camel to loosely couple two components
> using direct endpoints that _might_ be consumed by some bean. Especially
> there should be no dependency from the producing component to the consuming
> component. However, if there is a consumer, messages send from the producer
> must be consumed synchronously in the same thread to preserve the transaction
> context of the producer. That why I chose {{direct}} for the producer's
> endpoint.
> What is meant by "the messages might be consumed" is that the consuming
> component might not be deployed, when the consumer produces the first
> messages, or perhaps will never be deployed. I know there is the {{block}}
> option for the {{direct}} component but I don't want the producer to wait for
> the consumer as it might take some time (possibly forever) for the consumer
> to be available.
> I think this is a very common scenario for a messaging system and I was
> surprised not to find an easy out-of-the-box way to handle this with camel.
> That's why I think an additional option {{failIfNoConsumers}} (similar to the
> option for the seda component) for the {{direct}} and {{direct-vm}} component
> would be very handy.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-7434) Provide a way to force the completion of a aggregate exchange from an external event
[ https://issues.apache.org/jira/browse/CAMEL-7434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14111808#comment-14111808 ] Ben O'Day commented on CAMEL-7434: -- [~spetrucci], if you have a potential patch for this, attach it and I'll try to work it in...thanks > Provide a way to force the completion of a aggregate exchange from an > external event > > > Key: CAMEL-7434 > URL: https://issues.apache.org/jira/browse/CAMEL-7434 > Project: Camel > Issue Type: New Feature > Components: camel-core, eip >Affects Versions: 2.13.0 >Reporter: Susan Javurek >Assignee: Ben O'Day > Fix For: Future > > > There is a way to do this by creating a "trigger" exchange that is handled in > a special way by the aggregation strategy and a completion predicate. But > this solution is quite intrusive and painful to write. > It would actually be much easier if the AggregateProcessor would implement > and expose the following methods: > public void forceCompletionOfGroup(String key) > public Expression getCorrelationExpression() > This way, it becomes possible to control "externally" an aggregator without > having to implement some intrusive logic. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CAMEL-7448) throttle EIP - unchanged value
[ https://issues.apache.org/jira/browse/CAMEL-7448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben O'Day resolved CAMEL-7448. -- Resolution: Fixed > throttle EIP - unchanged value > -- > > Key: CAMEL-7448 > URL: https://issues.apache.org/jira/browse/CAMEL-7448 > Project: Camel > Issue Type: Bug > Components: camel-core, eip >Affects Versions: 2.13.1 >Reporter: Elvio Caruana >Assignee: Ben O'Day >Priority: Minor > Fix For: 2.13.3, 2.14.0 > > > Throttler Documentation [1] states "If the header is absent, then the > Throttler uses the old value. So that allows you to only provide a header if > the value is to be changed". > however if the expression evaluates to null (header missing from message) the > Throttler throws an exception (Throttler.java:108). > The workaround is to ensure that all messages carry the value (if the value > is the same no changes will take affect). Adding an option to turn this on > and off (e.g. allowNullException) would make it much easier to use (as per > camel-users thread [2]). > [1] http://camel.apache.org/throttler.html > [2] > http://camel.465427.n5.nabble.com/throttle-EIP-unchanged-value-td5751300.html -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CAMEL-7434) Provide a way to force the completion of a aggregate exchange from an external event
[ https://issues.apache.org/jira/browse/CAMEL-7434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14110984#comment-14110984 ] Ben O'Day commented on CAMEL-7434: -- in the short term, I can add the support for a new marker header (AGGREGATION_COMPLETE_FOR_GROUP) which would invoke forceCompletionOfGroup(key)...if this is acceptable. then perhaps log a separate task to add an external controller as Claus suggested...thoughts? > Provide a way to force the completion of a aggregate exchange from an > external event > > > Key: CAMEL-7434 > URL: https://issues.apache.org/jira/browse/CAMEL-7434 > Project: Camel > Issue Type: New Feature > Components: camel-core, eip >Affects Versions: 2.13.0 >Reporter: Susan Javurek >Assignee: Ben O'Day > Fix For: Future > > > There is a way to do this by creating a "trigger" exchange that is handled in > a special way by the aggregation strategy and a completion predicate. But > this solution is quite intrusive and painful to write. > It would actually be much easier if the AggregateProcessor would implement > and expose the following methods: > public void forceCompletionOfGroup(String key) > public Expression getCorrelationExpression() > This way, it becomes possible to control "externally" an aggregator without > having to implement some intrusive logic. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CAMEL-7448) throttle EIP - unchanged value
[ https://issues.apache.org/jira/browse/CAMEL-7448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14110969#comment-14110969 ] Ben O'Day commented on CAMEL-7448: -- I can, I was just waiting for some feedback...does that approach sound alright? > throttle EIP - unchanged value > -- > > Key: CAMEL-7448 > URL: https://issues.apache.org/jira/browse/CAMEL-7448 > Project: Camel > Issue Type: Bug > Components: camel-core, eip >Affects Versions: 2.13.1 >Reporter: Elvio Caruana >Assignee: Ben O'Day >Priority: Minor > Fix For: 2.13.3, 2.14.0 > > > Throttler Documentation [1] states "If the header is absent, then the > Throttler uses the old value. So that allows you to only provide a header if > the value is to be changed". > however if the expression evaluates to null (header missing from message) the > Throttler throws an exception (Throttler.java:108). > The workaround is to ensure that all messages carry the value (if the value > is the same no changes will take affect). Adding an option to turn this on > and off (e.g. allowNullException) would make it much easier to use (as per > camel-users thread [2]). > [1] http://camel.apache.org/throttler.html > [2] > http://camel.465427.n5.nabble.com/throttle-EIP-unchanged-value-td5751300.html -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (CAMEL-7448) throttle EIP - unchanged value
[
https://issues.apache.org/jira/browse/CAMEL-7448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14017359#comment-14017359
]
Ben O'Day edited comment on CAMEL-7448 at 6/9/14 4:14 AM:
--
why not just throw the exception if the expression is null AND
maximumRequestsPerPeriod hasn't been set otherwise (by a previous message,
etc). That would prevent NULL expression evaluations for the first message and
allow for subsequent ones, etc...
something like this in Throttler calculateDelay()...
{code:title=Throttler.java|borderStyle=solid}
Object result = maxRequestsPerPeriodExpression.evaluate(exchange,
Object.class);
//if (result == null) {
if (maximumRequestsPerPeriod == 0 && result == null) {
throw new RuntimeExchangeException("The max requests per period
expression was evaluated as null: " + maxRequestsPerPeriodExpression, exchange);
}
{code}
was (Author: boday):
why not just throw the exception if the expression is null AND
maximumRequestsPerPeriod hasn't been set otherwise (by a previous message,
etc). That would prevent NULL expression evaluations for the first message and
allow for subsequent ones, etc...
something like this in Throttler calculateDelay()...
Object result = maxRequestsPerPeriodExpression.evaluate(exchange,
Object.class);
//if (result == null) {
if (maximumRequestsPerPeriod == 0 && result == null) {
throw new RuntimeExchangeException("The max requests per period
expression was evaluated as null: " + maxRequestsPerPeriodExpression, exchange);
}
> throttle EIP - unchanged value
> --
>
> Key: CAMEL-7448
> URL: https://issues.apache.org/jira/browse/CAMEL-7448
> Project: Camel
> Issue Type: Bug
> Components: camel-core, eip
>Affects Versions: 2.13.1
>Reporter: Elvio Caruana
>Assignee: Ben O'Day
>Priority: Minor
> Fix For: 2.13.2, 2.14.0
>
>
> Throttler Documentation [1] states "If the header is absent, then the
> Throttler uses the old value. So that allows you to only provide a header if
> the value is to be changed".
> however if the expression evaluates to null (header missing from message) the
> Throttler throws an exception (Throttler.java:108).
> The workaround is to ensure that all messages carry the value (if the value
> is the same no changes will take affect). Adding an option to turn this on
> and off (e.g. allowNullException) would make it much easier to use (as per
> camel-users thread [2]).
> [1] http://camel.apache.org/throttler.html
> [2]
> http://camel.465427.n5.nabble.com/throttle-EIP-unchanged-value-td5751300.html
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Comment Edited] (CAMEL-7434) Provide a way to force the completion of a aggregate exchange from an external event
[ https://issues.apache.org/jira/browse/CAMEL-7434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14017378#comment-14017378 ] Ben O'Day edited comment on CAMEL-7434 at 6/4/14 3:31 PM: -- [~sjavurek] - if we added forceCompletionOfGroup(key) on the AggregateProcessor class, how would you invoke it externally? I suppose we could add support for a new marker header (AGGREGATION_COMPLETE_FOR_GROUP) and expect a groupKey as the body of the message to force the completion...though this would still require an explicit message be sent (vs. an API call)...is that what you are looking for? was (Author: boday): [~sjavurek] - if we added forceCompletionOfGroup(key) on the AggregateProcessor class, how would you invoke it externally? > Provide a way to force the completion of a aggregate exchange from an > external event > > > Key: CAMEL-7434 > URL: https://issues.apache.org/jira/browse/CAMEL-7434 > Project: Camel > Issue Type: New Feature > Components: camel-core, eip >Affects Versions: 2.13.0 >Reporter: Susan Javurek >Assignee: Ben O'Day > Fix For: Future > > > There is a way to do this by creating a "trigger" exchange that is handled in > a special way by the aggregation strategy and a completion predicate. But > this solution is quite intrusive and painful to write. > It would actually be much easier if the AggregateProcessor would implement > and expose the following methods: > public void forceCompletionOfGroup(String key) > public Expression getCorrelationExpression() > This way, it becomes possible to control "externally" an aggregator without > having to implement some intrusive logic. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (CAMEL-7434) Provide a way to force the completion of a aggregate exchange from an external event
[ https://issues.apache.org/jira/browse/CAMEL-7434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben O'Day reassigned CAMEL-7434: Assignee: Ben O'Day > Provide a way to force the completion of a aggregate exchange from an > external event > > > Key: CAMEL-7434 > URL: https://issues.apache.org/jira/browse/CAMEL-7434 > Project: Camel > Issue Type: New Feature > Components: camel-core, eip >Affects Versions: 2.13.0 >Reporter: Susan Javurek >Assignee: Ben O'Day > Fix For: Future > > > There is a way to do this by creating a "trigger" exchange that is handled in > a special way by the aggregation strategy and a completion predicate. But > this solution is quite intrusive and painful to write. > It would actually be much easier if the AggregateProcessor would implement > and expose the following methods: > public void forceCompletionOfGroup(String key) > public Expression getCorrelationExpression() > This way, it becomes possible to control "externally" an aggregator without > having to implement some intrusive logic. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CAMEL-7434) Provide a way to force the completion of a aggregate exchange from an external event
[ https://issues.apache.org/jira/browse/CAMEL-7434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14017378#comment-14017378 ] Ben O'Day commented on CAMEL-7434: -- [~sjavurek] - if we added forceCompletionOfGroup(key) on the AggregateProcessor class, how would you invoke it externally? > Provide a way to force the completion of a aggregate exchange from an > external event > > > Key: CAMEL-7434 > URL: https://issues.apache.org/jira/browse/CAMEL-7434 > Project: Camel > Issue Type: New Feature > Components: camel-core, eip >Affects Versions: 2.13.0 >Reporter: Susan Javurek > Fix For: Future > > > There is a way to do this by creating a "trigger" exchange that is handled in > a special way by the aggregation strategy and a completion predicate. But > this solution is quite intrusive and painful to write. > It would actually be much easier if the AggregateProcessor would implement > and expose the following methods: > public void forceCompletionOfGroup(String key) > public Expression getCorrelationExpression() > This way, it becomes possible to control "externally" an aggregator without > having to implement some intrusive logic. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CAMEL-7448) throttle EIP - unchanged value
[
https://issues.apache.org/jira/browse/CAMEL-7448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14017359#comment-14017359
]
Ben O'Day commented on CAMEL-7448:
--
why not just throw the exception if the expression is null AND
maximumRequestsPerPeriod hasn't been set otherwise (by a previous message,
etc). That would prevent NULL expression evaluations for the first message and
allow for subsequent ones, etc...
something like this in Throttler calculateDelay()...
Object result = maxRequestsPerPeriodExpression.evaluate(exchange,
Object.class);
//if (result == null) {
if (maximumRequestsPerPeriod == 0 && result == null) {
throw new RuntimeExchangeException("The max requests per period
expression was evaluated as null: " + maxRequestsPerPeriodExpression, exchange);
}
> throttle EIP - unchanged value
> --
>
> Key: CAMEL-7448
> URL: https://issues.apache.org/jira/browse/CAMEL-7448
> Project: Camel
> Issue Type: Bug
> Components: camel-core, eip
>Affects Versions: 2.13.1
>Reporter: Elvio Caruana
>Priority: Minor
> Fix For: 2.13.2, 2.14.0
>
>
> Throttler Documentation [1] states "If the header is absent, then the
> Throttler uses the old value. So that allows you to only provide a header if
> the value is to be changed".
> however if the expression evaluates to null (header missing from message) the
> Throttler throws an exception (Throttler.java:108).
> The workaround is to ensure that all messages carry the value (if the value
> is the same no changes will take affect). Adding an option to turn this on
> and off (e.g. allowNullException) would make it much easier to use (as per
> camel-users thread [2]).
> [1] http://camel.apache.org/throttler.html
> [2]
> http://camel.465427.n5.nabble.com/throttle-EIP-unchanged-value-td5751300.html
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Assigned] (CAMEL-7448) throttle EIP - unchanged value
[ https://issues.apache.org/jira/browse/CAMEL-7448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben O'Day reassigned CAMEL-7448: Assignee: Ben O'Day > throttle EIP - unchanged value > -- > > Key: CAMEL-7448 > URL: https://issues.apache.org/jira/browse/CAMEL-7448 > Project: Camel > Issue Type: Bug > Components: camel-core, eip >Affects Versions: 2.13.1 >Reporter: Elvio Caruana >Assignee: Ben O'Day >Priority: Minor > Fix For: 2.13.2, 2.14.0 > > > Throttler Documentation [1] states "If the header is absent, then the > Throttler uses the old value. So that allows you to only provide a header if > the value is to be changed". > however if the expression evaluates to null (header missing from message) the > Throttler throws an exception (Throttler.java:108). > The workaround is to ensure that all messages carry the value (if the value > is the same no changes will take affect). Adding an option to turn this on > and off (e.g. allowNullException) would make it much easier to use (as per > camel-users thread [2]). > [1] http://camel.apache.org/throttler.html > [2] > http://camel.465427.n5.nabble.com/throttle-EIP-unchanged-value-td5751300.html -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CAMEL-6665) Recipient list - Delimiter with value false should disable using delimiter
[ https://issues.apache.org/jira/browse/CAMEL-6665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben O'Day updated CAMEL-6665: - Fix Version/s: (was: 2.12.4) > Recipient list - Delimiter with value false should disable using delimiter > -- > > Key: CAMEL-6665 > URL: https://issues.apache.org/jira/browse/CAMEL-6665 > Project: Camel > Issue Type: Improvement > Components: camel-core, eip >Reporter: Claus Ibsen >Assignee: Ben O'Day >Priority: Minor > Fix For: 2.13.0 > > > See SO > http://stackoverflow.com/questions/18409647/suppress-delimiter-option-in-camel-recipient-list > We could allow people to set delimiter to value "false" which should then > turn off using the delimiter. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (CAMEL-6665) Recipient list - Delimiter with value false should disable using delimiter
[ https://issues.apache.org/jira/browse/CAMEL-6665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben O'Day closed CAMEL-6665. Resolution: Fixed > Recipient list - Delimiter with value false should disable using delimiter > -- > > Key: CAMEL-6665 > URL: https://issues.apache.org/jira/browse/CAMEL-6665 > Project: Camel > Issue Type: Improvement > Components: camel-core, eip >Reporter: Claus Ibsen >Assignee: Ben O'Day >Priority: Minor > Fix For: 2.13.0 > > > See SO > http://stackoverflow.com/questions/18409647/suppress-delimiter-option-in-camel-recipient-list > We could allow people to set delimiter to value "false" which should then > turn off using the delimiter. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Reopened] (CAMEL-6665) Recipient list - Delimiter with value false should disable using delimiter
[ https://issues.apache.org/jira/browse/CAMEL-6665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben O'Day reopened CAMEL-6665: -- > Recipient list - Delimiter with value false should disable using delimiter > -- > > Key: CAMEL-6665 > URL: https://issues.apache.org/jira/browse/CAMEL-6665 > Project: Camel > Issue Type: Improvement > Components: camel-core, eip >Reporter: Claus Ibsen >Assignee: Ben O'Day >Priority: Minor > Fix For: 2.12.4, 2.13.0 > > > See SO > http://stackoverflow.com/questions/18409647/suppress-delimiter-option-in-camel-recipient-list > We could allow people to set delimiter to value "false" which should then > turn off using the delimiter. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (CAMEL-6665) Recipient list - Delimiter with value false should disable using delimiter
[ https://issues.apache.org/jira/browse/CAMEL-6665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben O'Day closed CAMEL-6665. Resolution: Fixed > Recipient list - Delimiter with value false should disable using delimiter > -- > > Key: CAMEL-6665 > URL: https://issues.apache.org/jira/browse/CAMEL-6665 > Project: Camel > Issue Type: Improvement > Components: camel-core, eip >Reporter: Claus Ibsen >Assignee: Ben O'Day >Priority: Minor > Fix For: 2.12.4, 2.13.0 > > > See SO > http://stackoverflow.com/questions/18409647/suppress-delimiter-option-in-camel-recipient-list > We could allow people to set delimiter to value "false" which should then > turn off using the delimiter. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CAMEL-6665) Recipient list - Delimiter with value false should disable using delimiter
[ https://issues.apache.org/jira/browse/CAMEL-6665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben O'Day updated CAMEL-6665: - Fix Version/s: (was: Future) 2.13.0 2.12.4 > Recipient list - Delimiter with value false should disable using delimiter > -- > > Key: CAMEL-6665 > URL: https://issues.apache.org/jira/browse/CAMEL-6665 > Project: Camel > Issue Type: Improvement > Components: camel-core, eip >Reporter: Claus Ibsen >Assignee: Ben O'Day >Priority: Minor > Fix For: 2.12.4, 2.13.0 > > > See SO > http://stackoverflow.com/questions/18409647/suppress-delimiter-option-in-camel-recipient-list > We could allow people to set delimiter to value "false" which should then > turn off using the delimiter. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (CAMEL-6665) Recipient list - Delimiter with value false should disable using delimiter
[ https://issues.apache.org/jira/browse/CAMEL-6665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13797459#comment-13797459 ] Ben O'Day edited comment on CAMEL-6665 at 1/21/14 3:42 AM: --- did you want to just check for the String "false" to disable this or add a Boolean API to recipientList? was (Author: boday): so this should just check for the marker String "false", not add a boolean API to recipientList, correct? > Recipient list - Delimiter with value false should disable using delimiter > -- > > Key: CAMEL-6665 > URL: https://issues.apache.org/jira/browse/CAMEL-6665 > Project: Camel > Issue Type: Improvement > Components: camel-core, eip >Reporter: Claus Ibsen >Assignee: Ben O'Day >Priority: Minor > Fix For: Future > > > See SO > http://stackoverflow.com/questions/18409647/suppress-delimiter-option-in-camel-recipient-list > We could allow people to set delimiter to value "false" which should then > turn off using the delimiter. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Closed] (CAMEL-6864) camel-hdfs - split by BYTES or MESSAGES has dependent configs
[ https://issues.apache.org/jira/browse/CAMEL-6864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben O'Day closed CAMEL-6864. > camel-hdfs - split by BYTES or MESSAGES has dependent configs > - > > Key: CAMEL-6864 > URL: https://issues.apache.org/jira/browse/CAMEL-6864 > Project: Camel > Issue Type: Bug > Components: camel-hdfs >Affects Versions: 2.10.4, 2.11.0 >Reporter: Ben O'Day >Assignee: Ben O'Day >Priority: Minor > Fix For: Future > > > per the discussion/changes in CAMEL-5971... > currently, if only the BYTES or MESSAGES split criteria is specified, then > the output stream is closed with every message and creates a new file for > subsequent messages regardless of BYTES/MESSAGES written to the file... > that said, if used along with the IDLE config or by setting the header > HdfsConstants.HDFS_CLOSE=false...it does work fine > so, we should either update the wiki to reflect this (if 'as designed') or > update the HdfsProducer to not close the stream in the absence of the IDLE > config (rely only on the split logic, HdfsConstants.HDFS_CLOSE=true header or > route stop to close the stream) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CAMEL-6864) camel-hdfs - split by BYTES or MESSAGES has dependent configs
[ https://issues.apache.org/jira/browse/CAMEL-6864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben O'Day resolved CAMEL-6864. -- Resolution: Not A Problem alright, will just update the wiki until I get further input on this... > camel-hdfs - split by BYTES or MESSAGES has dependent configs > - > > Key: CAMEL-6864 > URL: https://issues.apache.org/jira/browse/CAMEL-6864 > Project: Camel > Issue Type: Bug > Components: camel-hdfs >Affects Versions: 2.10.4, 2.11.0 >Reporter: Ben O'Day >Assignee: Ben O'Day >Priority: Minor > Fix For: Future > > > per the discussion/changes in CAMEL-5971... > currently, if only the BYTES or MESSAGES split criteria is specified, then > the output stream is closed with every message and creates a new file for > subsequent messages regardless of BYTES/MESSAGES written to the file... > that said, if used along with the IDLE config or by setting the header > HdfsConstants.HDFS_CLOSE=false...it does work fine > so, we should either update the wiki to reflect this (if 'as designed') or > update the HdfsProducer to not close the stream in the absence of the IDLE > config (rely only on the split logic, HdfsConstants.HDFS_CLOSE=true header or > route stop to close the stream) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CAMEL-6864) camel-hdfs - split by BYTES or MESSAGES has dependent configs
[ https://issues.apache.org/jira/browse/CAMEL-6864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13815117#comment-13815117 ] Ben O'Day commented on CAMEL-6864: -- any comments on this...otherwise, I'll just update the wiki to make this bug/feature clear and close this out > camel-hdfs - split by BYTES or MESSAGES has dependent configs > - > > Key: CAMEL-6864 > URL: https://issues.apache.org/jira/browse/CAMEL-6864 > Project: Camel > Issue Type: Bug > Components: camel-hdfs >Affects Versions: 2.10.4, 2.11.0 >Reporter: Ben O'Day >Assignee: Ben O'Day >Priority: Minor > Fix For: Future > > > per the discussion/changes in CAMEL-5971... > currently, if only the BYTES or MESSAGES split criteria is specified, then > the output stream is closed with every message and creates a new file for > subsequent messages regardless of BYTES/MESSAGES written to the file... > that said, if used along with the IDLE config or by setting the header > HdfsConstants.HDFS_CLOSE=false...it does work fine > so, we should either update the wiki to reflect this (if 'as designed') or > update the HdfsProducer to not close the stream in the absence of the IDLE > config (rely only on the split logic, HdfsConstants.HDFS_CLOSE=true header or > route stop to close the stream) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Assigned] (CAMEL-6437) Make HDFS consumer and producer shutdownAware
[ https://issues.apache.org/jira/browse/CAMEL-6437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben O'Day reassigned CAMEL-6437: Assignee: (was: Ben O'Day) > Make HDFS consumer and producer shutdownAware > - > > Key: CAMEL-6437 > URL: https://issues.apache.org/jira/browse/CAMEL-6437 > Project: Camel > Issue Type: New Feature > Components: camel-hdfs >Reporter: Kevin Faro > Labels: hdfs, shutdown > Fix For: Future > > > It would be great to make both the consumer and producer shutdown aware so it > could remove the .opened extension when the route is shutdown. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CAMEL-6867) camel-hdfs - HdfsProducer filename collisions when Producer instance recreated
[ https://issues.apache.org/jira/browse/CAMEL-6867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben O'Day resolved CAMEL-6867. -- Resolution: Fixed > camel-hdfs - HdfsProducer filename collisions when Producer instance recreated > -- > > Key: CAMEL-6867 > URL: https://issues.apache.org/jira/browse/CAMEL-6867 > Project: Camel > Issue Type: Bug > Components: camel-hdfs >Reporter: Ben O'Day >Assignee: Ben O'Day > Fix For: 2.11.3, 2.12.2, 2.13.0 > > > The HdfsProducer uses an instance variable (long splitNum) that is > incremented to create unique output filenames in a given directory (seg0, > seg1, etc). > If the Producer instance is recreated (producer cache limit exceeded, server > restart, etc), the splitNum variable is reset to 0. This results in files > being overwritten when using overwrite=true mode or throwing "The file > already exists" errors when using overwrite=false mode. > We should switch to using a timestamp or some other unique generator to > prevent filename collisions regardless of the Producer instance lifecycle for > the same hdfs directory URL... -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CAMEL-6867) camel-hdfs - HdfsProducer filename collisions when Producer instance recreated
[ https://issues.apache.org/jira/browse/CAMEL-6867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben O'Day updated CAMEL-6867: - Fix Version/s: 2.12.2 2.11.3 > camel-hdfs - HdfsProducer filename collisions when Producer instance recreated > -- > > Key: CAMEL-6867 > URL: https://issues.apache.org/jira/browse/CAMEL-6867 > Project: Camel > Issue Type: Bug > Components: camel-hdfs >Reporter: Ben O'Day >Assignee: Ben O'Day > Fix For: 2.11.3, 2.12.2, 2.13.0 > > > The HdfsProducer uses an instance variable (long splitNum) that is > incremented to create unique output filenames in a given directory (seg0, > seg1, etc). > If the Producer instance is recreated (producer cache limit exceeded, server > restart, etc), the splitNum variable is reset to 0. This results in files > being overwritten when using overwrite=true mode or throwing "The file > already exists" errors when using overwrite=false mode. > We should switch to using a timestamp or some other unique generator to > prevent filename collisions regardless of the Producer instance lifecycle for > the same hdfs directory URL... -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Reopened] (CAMEL-6867) camel-hdfs - HdfsProducer filename collisions when Producer instance recreated
[ https://issues.apache.org/jira/browse/CAMEL-6867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben O'Day reopened CAMEL-6867: -- merging fixes into 2.11.x, 2.12.x branches > camel-hdfs - HdfsProducer filename collisions when Producer instance recreated > -- > > Key: CAMEL-6867 > URL: https://issues.apache.org/jira/browse/CAMEL-6867 > Project: Camel > Issue Type: Bug > Components: camel-hdfs >Reporter: Ben O'Day >Assignee: Ben O'Day > Fix For: 2.13.0 > > > The HdfsProducer uses an instance variable (long splitNum) that is > incremented to create unique output filenames in a given directory (seg0, > seg1, etc). > If the Producer instance is recreated (producer cache limit exceeded, server > restart, etc), the splitNum variable is reset to 0. This results in files > being overwritten when using overwrite=true mode or throwing "The file > already exists" errors when using overwrite=false mode. > We should switch to using a timestamp or some other unique generator to > prevent filename collisions regardless of the Producer instance lifecycle for > the same hdfs directory URL... -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CAMEL-6867) camel-hdfs - HdfsProducer filename collisions when Producer instance recreated
[ https://issues.apache.org/jira/browse/CAMEL-6867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13799648#comment-13799648 ] Ben O'Day commented on CAMEL-6867: -- anyone see an issue with backporting this fix to the 2.10.x, 2.11.x, 2.12.x branches? > camel-hdfs - HdfsProducer filename collisions when Producer instance recreated > -- > > Key: CAMEL-6867 > URL: https://issues.apache.org/jira/browse/CAMEL-6867 > Project: Camel > Issue Type: Bug > Components: camel-hdfs >Reporter: Ben O'Day >Assignee: Ben O'Day > Fix For: 2.13.0 > > > The HdfsProducer uses an instance variable (long splitNum) that is > incremented to create unique output filenames in a given directory (seg0, > seg1, etc). > If the Producer instance is recreated (producer cache limit exceeded, server > restart, etc), the splitNum variable is reset to 0. This results in files > being overwritten when using overwrite=true mode or throwing "The file > already exists" errors when using overwrite=false mode. > We should switch to using a timestamp or some other unique generator to > prevent filename collisions regardless of the Producer instance lifecycle for > the same hdfs directory URL... -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CAMEL-6867) camel-hdfs - HdfsProducer filename collisions when Producer instance recreated
[ https://issues.apache.org/jira/browse/CAMEL-6867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben O'Day resolved CAMEL-6867. -- Resolution: Fixed Fix Version/s: (was: Future) 2.13.0 per discussion, changed the split filename logic to use the UUID generator and removed the "seg" prefix from the filenames thanks to Sergey Kozlovich ([~skozlovich]) for helping find/fix/test this issue > camel-hdfs - HdfsProducer filename collisions when Producer instance recreated > -- > > Key: CAMEL-6867 > URL: https://issues.apache.org/jira/browse/CAMEL-6867 > Project: Camel > Issue Type: Bug > Components: camel-hdfs >Reporter: Ben O'Day >Assignee: Ben O'Day > Fix For: 2.13.0 > > > The HdfsProducer uses an instance variable (long splitNum) that is > incremented to create unique output filenames in a given directory (seg0, > seg1, etc). > If the Producer instance is recreated (producer cache limit exceeded, server > restart, etc), the splitNum variable is reset to 0. This results in files > being overwritten when using overwrite=true mode or throwing "The file > already exists" errors when using overwrite=false mode. > We should switch to using a timestamp or some other unique generator to > prevent filename collisions regardless of the Producer instance lifecycle for > the same hdfs directory URL... -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CAMEL-6867) camel-hdfs - HdfsProducer filename collisions when Producer instance recreated
[ https://issues.apache.org/jira/browse/CAMEL-6867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13798431#comment-13798431 ] Ben O'Day commented on CAMEL-6867: -- the issue with using the messageId is that the connectOnStartup mode creates the initial file stream on startup (no messageId to use in this case). how about if we use the UUID generator from the CamelContext like this: getEndpoint().getCamelContext().getUuidGenerator().generateUuid()? also, any reason to continue to prepend the DEFAULT_SEGMENT_PREFIX with this new approach...the prefix "seg" seems pretty arbitrary and should probably be configurable if we need to keep it... > camel-hdfs - HdfsProducer filename collisions when Producer instance recreated > -- > > Key: CAMEL-6867 > URL: https://issues.apache.org/jira/browse/CAMEL-6867 > Project: Camel > Issue Type: Bug > Components: camel-hdfs >Reporter: Ben O'Day >Assignee: Ben O'Day > Fix For: Future > > > The HdfsProducer uses an instance variable (long splitNum) that is > incremented to create unique output filenames in a given directory (seg0, > seg1, etc). > If the Producer instance is recreated (producer cache limit exceeded, server > restart, etc), the splitNum variable is reset to 0. This results in files > being overwritten when using overwrite=true mode or throwing "The file > already exists" errors when using overwrite=false mode. > We should switch to using a timestamp or some other unique generator to > prevent filename collisions regardless of the Producer instance lifecycle for > the same hdfs directory URL... -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CAMEL-6028) camel-hdfs - Support CamelFileName to write to a new file, when not using split strategy
[ https://issues.apache.org/jira/browse/CAMEL-6028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben O'Day resolved CAMEL-6028. -- Resolution: Fixed added Expression support in Commit: 4c3d1526c9d285e138a16b9fd275171f4255ec65 > camel-hdfs - Support CamelFileName to write to a new file, when not using > split strategy > > > Key: CAMEL-6028 > URL: https://issues.apache.org/jira/browse/CAMEL-6028 > Project: Camel > Issue Type: Improvement > Components: camel-hdfs >Reporter: Claus Ibsen >Assignee: Ben O'Day > Fix For: 2.13.0 > > > When using camel-hdfs to write to files, without using split strategy. Then > the file is always the same which is the file configured on the endpoint. > We should add support for the CamelFileName header so you can give the file a > new name, relative to the endpoint configuration. Then it works more like the > file producer would do. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Reopened] (CAMEL-6028) camel-hdfs - Support CamelFileName to write to a new file, when not using split strategy
[ https://issues.apache.org/jira/browse/CAMEL-6028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben O'Day reopened CAMEL-6028: -- upon review, this probably could use Expression support as well...adding that next > camel-hdfs - Support CamelFileName to write to a new file, when not using > split strategy > > > Key: CAMEL-6028 > URL: https://issues.apache.org/jira/browse/CAMEL-6028 > Project: Camel > Issue Type: Improvement > Components: camel-hdfs >Reporter: Claus Ibsen >Assignee: Ben O'Day > Fix For: 2.13.0 > > > When using camel-hdfs to write to files, without using split strategy. Then > the file is always the same which is the file configured on the endpoint. > We should add support for the CamelFileName header so you can give the file a > new name, relative to the endpoint configuration. Then it works more like the > file producer would do. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CAMEL-6028) camel-hdfs - Support CamelFileName to write to a new file, when not using split strategy
[ https://issues.apache.org/jira/browse/CAMEL-6028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben O'Day resolved CAMEL-6028. -- Resolution: Fixed added support for this in commit: de4cb2b98259fb7c9777e8c0ca79f841956b9994 > camel-hdfs - Support CamelFileName to write to a new file, when not using > split strategy > > > Key: CAMEL-6028 > URL: https://issues.apache.org/jira/browse/CAMEL-6028 > Project: Camel > Issue Type: Improvement > Components: camel-hdfs >Reporter: Claus Ibsen >Assignee: Ben O'Day > Fix For: 2.13.0 > > > When using camel-hdfs to write to files, without using split strategy. Then > the file is always the same which is the file configured on the endpoint. > We should add support for the CamelFileName header so you can give the file a > new name, relative to the endpoint configuration. Then it works more like the > file producer would do. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CAMEL-6028) camel-hdfs - Support CamelFileName to write to a new file, when not using split strategy
[ https://issues.apache.org/jira/browse/CAMEL-6028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben O'Day updated CAMEL-6028: - Fix Version/s: (was: Future) 2.13.0 > camel-hdfs - Support CamelFileName to write to a new file, when not using > split strategy > > > Key: CAMEL-6028 > URL: https://issues.apache.org/jira/browse/CAMEL-6028 > Project: Camel > Issue Type: Improvement > Components: camel-hdfs >Reporter: Claus Ibsen >Assignee: Ben O'Day > Fix For: 2.13.0 > > > When using camel-hdfs to write to files, without using split strategy. Then > the file is always the same which is the file configured on the endpoint. > We should add support for the CamelFileName header so you can give the file a > new name, relative to the endpoint configuration. Then it works more like the > file producer would do. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CAMEL-6665) Recipient list - Delimiter with value false should disable using delimiter
[ https://issues.apache.org/jira/browse/CAMEL-6665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13797459#comment-13797459 ] Ben O'Day commented on CAMEL-6665: -- so this should just check for the marker String "false", not add a boolean API to recipientList, correct? > Recipient list - Delimiter with value false should disable using delimiter > -- > > Key: CAMEL-6665 > URL: https://issues.apache.org/jira/browse/CAMEL-6665 > Project: Camel > Issue Type: Improvement > Components: camel-core, eip >Reporter: Claus Ibsen >Assignee: Ben O'Day >Priority: Minor > Fix For: Future > > > See SO > http://stackoverflow.com/questions/18409647/suppress-delimiter-option-in-camel-recipient-list > We could allow people to set delimiter to value "false" which should then > turn off using the delimiter. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Assigned] (CAMEL-6665) Recipient list - Delimiter with value false should disable using delimiter
[ https://issues.apache.org/jira/browse/CAMEL-6665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben O'Day reassigned CAMEL-6665: Assignee: Ben O'Day > Recipient list - Delimiter with value false should disable using delimiter > -- > > Key: CAMEL-6665 > URL: https://issues.apache.org/jira/browse/CAMEL-6665 > Project: Camel > Issue Type: Improvement > Components: camel-core, eip >Reporter: Claus Ibsen >Assignee: Ben O'Day >Priority: Minor > Fix For: Future > > > See SO > http://stackoverflow.com/questions/18409647/suppress-delimiter-option-in-camel-recipient-list > We could allow people to set delimiter to value "false" which should then > turn off using the delimiter. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CAMEL-6867) camel-hdfs - HdfsProducer filename collisions when Producer instance recreated
[ https://issues.apache.org/jira/browse/CAMEL-6867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13797376#comment-13797376 ] Ben O'Day commented on CAMEL-6867: -- any objection to using System.nanoTime() for the file name unique Id instead of the the long splitNum++? > camel-hdfs - HdfsProducer filename collisions when Producer instance recreated > -- > > Key: CAMEL-6867 > URL: https://issues.apache.org/jira/browse/CAMEL-6867 > Project: Camel > Issue Type: Bug > Components: camel-hdfs >Reporter: Ben O'Day >Assignee: Ben O'Day > Fix For: Future > > > The HdfsProducer uses an instance variable (long splitNum) that is > incremented to create unique output filenames in a given directory (seg0, > seg1, etc). > If the Producer instance is recreated (producer cache limit exceeded, server > restart, etc), the splitNum variable is reset to 0. This results in files > being overwritten when using overwrite=true mode or throwing "The file > already exists" errors when using overwrite=false mode. > We should switch to using a timestamp or some other unique generator to > prevent filename collisions regardless of the Producer instance lifecycle for > the same hdfs directory URL... -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CAMEL-6867) camel-hdfs - HdfsProducer filename collisions when Producer instance recreated
[ https://issues.apache.org/jira/browse/CAMEL-6867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben O'Day updated CAMEL-6867: - Description: The HdfsProducer uses an instance variable (long splitNum) that is incremented to create unique output filenames in a given directory (seg0, seg1, etc). If the Producer instance is recreated (producer cache limit exceeded, server restart, etc), the splitNum variable is reset to 0. This results in files being overwritten when using overwrite=true mode or throwing "The file already exists" errors when using overwrite=false mode. We should switch to using a timestamp or some other unique generator to prevent filename collisions regardless of the Producer instance lifecycle for the same hdfs directory URL... was: The HdfsProducer uses an instance variable (long splitNum) that is incremented to create unique output filenames in a given directory (seq0, seq1, etc). If the Producer instance is recreated (producer cache limit exceeded, server restart, etc), the splitNum variable is reset to 0. This results in files being overwritten when using overwrite=true mode or throwing "The file already exists" errors when using overwrite=false mode. We should switch to using a timestamp or some other unique generator to prevent filename collisions regardless of the Producer instance lifecycle for the same hdfs directory URL... > camel-hdfs - HdfsProducer filename collisions when Producer instance recreated > -- > > Key: CAMEL-6867 > URL: https://issues.apache.org/jira/browse/CAMEL-6867 > Project: Camel > Issue Type: Bug > Components: camel-hdfs >Reporter: Ben O'Day >Assignee: Ben O'Day > Fix For: Future > > > The HdfsProducer uses an instance variable (long splitNum) that is > incremented to create unique output filenames in a given directory (seg0, > seg1, etc). > If the Producer instance is recreated (producer cache limit exceeded, server > restart, etc), the splitNum variable is reset to 0. This results in files > being overwritten when using overwrite=true mode or throwing "The file > already exists" errors when using overwrite=false mode. > We should switch to using a timestamp or some other unique generator to > prevent filename collisions regardless of the Producer instance lifecycle for > the same hdfs directory URL... -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CAMEL-6867) camel-hdfs - HdfsProducer filename collisions when Producer instance recreated
Ben O'Day created CAMEL-6867: Summary: camel-hdfs - HdfsProducer filename collisions when Producer instance recreated Key: CAMEL-6867 URL: https://issues.apache.org/jira/browse/CAMEL-6867 Project: Camel Issue Type: Bug Components: camel-hdfs Reporter: Ben O'Day Assignee: Ben O'Day Fix For: Future The HdfsProducer uses an instance variable (long splitNum) that is incremented to create unique output filenames in a given directory (seq0, seq1, etc). If the Producer instance is recreated (producer cache limit exceeded, server restart, etc), the splitNum variable is reset to 0. This results in files being overwritten when using overwrite=true mode or throwing "The file already exists" errors when using overwrite=false mode. We should switch to using a timestamp or some other unique generator to prevent filename collisions regardless of the Producer instance lifecycle for the same hdfs directory URL... -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CAMEL-6864) camel-hdfs - split by BYTES or MESSAGES has dependent configs
[ https://issues.apache.org/jira/browse/CAMEL-6864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben O'Day updated CAMEL-6864: - Description: per the discussion/changes in CAMEL-5971... currently, if only the BYTES or MESSAGES split criteria is specified, then the output stream is closed with every message and creates a new file for subsequent messages regardless of BYTES/MESSAGES written to the file... that said, if used along with the IDLE config or by setting the header HdfsConstants.HDFS_CLOSE=false...it does work fine so, we should either update the wiki to reflect this (if 'as designed') or update the HdfsProducer to not close the stream in the absence of the IDLE config (rely only on the split logic, HdfsConstants.HDFS_CLOSE=true header or route stop to close the stream) was: per the discussion/changes in CAMEL-5971... currently, if only the BYTES or MESSAGES split criteria are specified (w/o using IDLE or setting HdfsConstants.HDFS_CLOSE=false), then the output stream is closed with every message and creates a new file for subsequent messages regardless of BYTES/MESSAGES written to the file... we should either update the wiki to reflect this (if this is simply 'as designed') or update the HdfsProducer to not close the stream in the absence of the IDLE config (rely only on the split logic, HdfsConstants.HDFS_CLOSE=true header or route stop to close the stream) Summary: camel-hdfs - split by BYTES or MESSAGES has dependent configs (was: camel-hdfs - split by BYTES/MESSAGES only works when IDLE/header is specified) > camel-hdfs - split by BYTES or MESSAGES has dependent configs > - > > Key: CAMEL-6864 > URL: https://issues.apache.org/jira/browse/CAMEL-6864 > Project: Camel > Issue Type: Bug > Components: camel-hdfs >Affects Versions: 2.10.4, 2.11.0 >Reporter: Ben O'Day >Assignee: Ben O'Day >Priority: Minor > Fix For: Future > > > per the discussion/changes in CAMEL-5971... > currently, if only the BYTES or MESSAGES split criteria is specified, then > the output stream is closed with every message and creates a new file for > subsequent messages regardless of BYTES/MESSAGES written to the file... > that said, if used along with the IDLE config or by setting the header > HdfsConstants.HDFS_CLOSE=false...it does work fine > so, we should either update the wiki to reflect this (if 'as designed') or > update the HdfsProducer to not close the stream in the absence of the IDLE > config (rely only on the split logic, HdfsConstants.HDFS_CLOSE=true header or > route stop to close the stream) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CAMEL-6864) camel-hdfs - split by BYTES/MESSAGES only works when IDLE/header is specified
Ben O'Day created CAMEL-6864: Summary: camel-hdfs - split by BYTES/MESSAGES only works when IDLE/header is specified Key: CAMEL-6864 URL: https://issues.apache.org/jira/browse/CAMEL-6864 Project: Camel Issue Type: Bug Components: camel-hdfs Affects Versions: 2.11.0, 2.10.4 Reporter: Ben O'Day Assignee: Ben O'Day Priority: Minor Fix For: Future per the discussion/changes in CAMEL-5971... currently, if only the BYTES or MESSAGES split criteria are specified (w/o using IDLE or setting HdfsConstants.HDFS_CLOSE=false), then the output stream is closed with every message and creates a new file for subsequent messages regardless of BYTES/MESSAGES written to the file... we should either update the wiki to reflect this (if this is simply 'as designed') or update the HdfsProducer to not close the stream in the absence of the IDLE config (rely only on the split logic, HdfsConstants.HDFS_CLOSE=true header or route stop to close the stream) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Assigned] (CAMEL-6028) camel-hdfs - Support CamelFileName to write to a new file, when not using split strategy
[ https://issues.apache.org/jira/browse/CAMEL-6028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben O'Day reassigned CAMEL-6028: Assignee: Ben O'Day > camel-hdfs - Support CamelFileName to write to a new file, when not using > split strategy > > > Key: CAMEL-6028 > URL: https://issues.apache.org/jira/browse/CAMEL-6028 > Project: Camel > Issue Type: Improvement > Components: camel-hdfs >Reporter: Claus Ibsen >Assignee: Ben O'Day > Fix For: Future > > > When using camel-hdfs to write to files, without using split strategy. Then > the file is always the same which is the file configured on the endpoint. > We should add support for the CamelFileName header so you can give the file a > new name, relative to the endpoint configuration. Then it works more like the > file producer would do. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Comment Edited] (CAMEL-6437) Make HDFS consumer and producer shutdownAware
[ https://issues.apache.org/jira/browse/CAMEL-6437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13793389#comment-13793389 ] Ben O'Day edited comment on CAMEL-6437 at 10/14/13 4:37 AM: from the producer perspective, the doStop() already closes any open stream...not sure what else should be done here. on the consumer side, the istream is closed after each poll completes, but given that the poll could be long-lived, should we interrupt it when prepareShutdown is called? any other thoughts/suggestions? was (Author: boday): I'll take a look at this... > Make HDFS consumer and producer shutdownAware > - > > Key: CAMEL-6437 > URL: https://issues.apache.org/jira/browse/CAMEL-6437 > Project: Camel > Issue Type: New Feature > Components: camel-hdfs >Reporter: Kevin Faro >Assignee: Ben O'Day > Labels: hdfs, shutdown > Fix For: Future > > > It would be great to make both the consumer and producer shutdown aware so it > could remove the .opened extension when the route is shutdown. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Assigned] (CAMEL-6437) Make HDFS consumer and producer shutdownAware
[ https://issues.apache.org/jira/browse/CAMEL-6437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben O'Day reassigned CAMEL-6437: Assignee: Ben O'Day I'll take a look at this... > Make HDFS consumer and producer shutdownAware > - > > Key: CAMEL-6437 > URL: https://issues.apache.org/jira/browse/CAMEL-6437 > Project: Camel > Issue Type: New Feature > Components: camel-hdfs >Reporter: Kevin Faro >Assignee: Ben O'Day > Labels: hdfs, shutdown > Fix For: Future > > > It would be great to make both the consumer and producer shutdown aware so it > could remove the .opened extension when the route is shutdown. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Closed] (CAMEL-6618) update camel-lucene to use version 4.4
[ https://issues.apache.org/jira/browse/CAMEL-6618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben O'Day closed CAMEL-6618. Resolution: Duplicate duplicate of CAMEL-5922 > update camel-lucene to use version 4.4 > -- > > Key: CAMEL-6618 > URL: https://issues.apache.org/jira/browse/CAMEL-6618 > Project: Camel > Issue Type: Improvement >Reporter: Ben O'Day >Priority: Minor > > should consider upgrading to newer version of Lucene 4.4...not sure what > other dependencies/timing would be involved in this upgrade, but the > camel-solr and camel-elasticsearch components could also use upgrades to > start using Lucene 4.x APIs... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CAMEL-6612) upgrade camel-elasticsearch to 0.90.3 version
[ https://issues.apache.org/jira/browse/CAMEL-6612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben O'Day reassigned CAMEL-6612: Assignee: (was: Ben O'Day) > upgrade camel-elasticsearch to 0.90.3 version > - > > Key: CAMEL-6612 > URL: https://issues.apache.org/jira/browse/CAMEL-6612 > Project: Camel > Issue Type: Improvement > Components: camel-elasticsearch >Reporter: Ben O'Day >Priority: Minor > > should upgrade to a newer rev when possible... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CAMEL-6613) upgrade camel-solr to use SolrJ 4.4.0
[ https://issues.apache.org/jira/browse/CAMEL-6613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben O'Day reassigned CAMEL-6613: Assignee: (was: Ben O'Day) > upgrade camel-solr to use SolrJ 4.4.0 > - > > Key: CAMEL-6613 > URL: https://issues.apache.org/jira/browse/CAMEL-6613 > Project: Camel > Issue Type: Improvement > Components: camel-solr >Reporter: Ben O'Day >Priority: Minor > Fix For: 2.12.0 > > > should consider supporting newer version of Solr -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAMEL-6612) upgrade camel-elasticsearch to 0.90.3 version
[ https://issues.apache.org/jira/browse/CAMEL-6612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben O'Day updated CAMEL-6612: - Fix Version/s: (was: 2.11.2) > upgrade camel-elasticsearch to 0.90.3 version > - > > Key: CAMEL-6612 > URL: https://issues.apache.org/jira/browse/CAMEL-6612 > Project: Camel > Issue Type: Improvement > Components: camel-elasticsearch >Reporter: Ben O'Day >Assignee: Ben O'Day >Priority: Minor > > should upgrade to a newer rev when possible... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAMEL-6618) update camel-lucene to use version 4.4
[ https://issues.apache.org/jira/browse/CAMEL-6618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben O'Day updated CAMEL-6618: - Summary: update camel-lucene to use version 4.4 (was: update to camel-lucene to use version 4.4) > update camel-lucene to use version 4.4 > -- > > Key: CAMEL-6618 > URL: https://issues.apache.org/jira/browse/CAMEL-6618 > Project: Camel > Issue Type: Improvement >Reporter: Ben O'Day >Priority: Minor > > should consider upgrading to newer version of Lucene 4.4...not sure what > other dependencies/timing would be involved in this upgrade, but the > camel-solr and camel-elasticsearch components could also use upgrades to > start using Lucene 4.x APIs... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CAMEL-6618) update to camel-lucene to use version 4.4
Ben O'Day created CAMEL-6618: Summary: update to camel-lucene to use version 4.4 Key: CAMEL-6618 URL: https://issues.apache.org/jira/browse/CAMEL-6618 Project: Camel Issue Type: Improvement Reporter: Ben O'Day Priority: Minor should consider upgrading to newer version of Lucene 4.4...not sure what other dependencies/timing would be involved in this upgrade, but the camel-solr and camel-elasticsearch components could also use upgrades to start using Lucene 4.x APIs... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CAMEL-6444) Add Ip Parameter
[ https://issues.apache.org/jira/browse/CAMEL-6444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben O'Day resolved CAMEL-6444. -- Resolution: Fixed Fix Version/s: 2.12.0 started with Bart Horre's patch and also added support for an explicit port...thanks for the patch Bart https://git-wip-us.apache.org/repos/asf?p=camel.git;a=commit;h=9ecc122b > Add Ip Parameter > > > Key: CAMEL-6444 > URL: https://issues.apache.org/jira/browse/CAMEL-6444 > Project: Camel > Issue Type: Improvement > Components: camel-elasticsearch >Reporter: Bart Horré >Assignee: Ben O'Day >Priority: Trivial > Fix For: 2.12.0 > > Attachments: patch.txt > > > When the route isn't in the same subnet as the elastic search cluster, it > won't be autodiscovered. If we can pass the ip as a parameter, we would be > able to connect with a TransportClient -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAMEL-6444) Add Ip and Port Parameter
[ https://issues.apache.org/jira/browse/CAMEL-6444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben O'Day updated CAMEL-6444: - Summary: Add Ip and Port Parameter (was: Add Ip Parameter) > Add Ip and Port Parameter > - > > Key: CAMEL-6444 > URL: https://issues.apache.org/jira/browse/CAMEL-6444 > Project: Camel > Issue Type: Improvement > Components: camel-elasticsearch >Reporter: Bart Horré >Assignee: Ben O'Day >Priority: Trivial > Fix For: 2.12.0 > > Attachments: patch.txt > > > When the route isn't in the same subnet as the elastic search cluster, it > won't be autodiscovered. If we can pass the ip as a parameter, we would be > able to connect with a TransportClient -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CAMEL-6613) upgrade camel-solr to use SolrJ 4.4.0
Ben O'Day created CAMEL-6613: Summary: upgrade camel-solr to use SolrJ 4.4.0 Key: CAMEL-6613 URL: https://issues.apache.org/jira/browse/CAMEL-6613 Project: Camel Issue Type: Improvement Components: camel-solr Reporter: Ben O'Day Assignee: Ben O'Day Priority: Minor Fix For: 2.12.0 should consider supporting newer version of Solr -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CAMEL-6612) upgrade camel-elasticsearch to 0.90.3 version
Ben O'Day created CAMEL-6612: Summary: upgrade camel-elasticsearch to 0.90.3 version Key: CAMEL-6612 URL: https://issues.apache.org/jira/browse/CAMEL-6612 Project: Camel Issue Type: Improvement Components: camel-elasticsearch Reporter: Ben O'Day Assignee: Ben O'Day Priority: Minor Fix For: 2.11.2 should upgrade to a newer rev when possible... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CAMEL-6444) Add Ip Parameter
[ https://issues.apache.org/jira/browse/CAMEL-6444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben O'Day reassigned CAMEL-6444: Assignee: Ben O'Day > Add Ip Parameter > > > Key: CAMEL-6444 > URL: https://issues.apache.org/jira/browse/CAMEL-6444 > Project: Camel > Issue Type: Improvement > Components: camel-elasticsearch >Reporter: Bart Horré >Assignee: Ben O'Day >Priority: Trivial > Attachments: patch.txt > > > When the route isn't in the same subnet as the elastic search cluster, it > won't be autodiscovered. If we can pass the ip as a parameter, we would be > able to connect with a TransportClient -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CAMEL-6119) enhance Aggregator to allow forcing completion via a header and include the current message
[ https://issues.apache.org/jira/browse/CAMEL-6119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben O'Day resolved CAMEL-6119. -- Resolution: Fixed r1452002 > enhance Aggregator to allow forcing completion via a header and include the > current message > > > Key: CAMEL-6119 > URL: https://issues.apache.org/jira/browse/CAMEL-6119 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Ben O'Day >Assignee: Ben O'Day >Priority: Minor > Labels: aggregator > Fix For: 2.11.0 > > > add support in the Aggregator EIP for checking for a new header > (AGGREGATION_COMPLETE_ALL_GROUPS_INCLUSIVE) to trigger flushing of all groups > and be inclusive of the current message... > per > http://camel.465427.n5.nabble.com/aggregator-force-completion-with-header-td5728368.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Work started] (CAMEL-6119) enhance Aggregator to allow forcing completion via a header and include the current message
[ https://issues.apache.org/jira/browse/CAMEL-6119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CAMEL-6119 started by Ben O'Day. > enhance Aggregator to allow forcing completion via a header and include the > current message > > > Key: CAMEL-6119 > URL: https://issues.apache.org/jira/browse/CAMEL-6119 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Ben O'Day >Assignee: Ben O'Day >Priority: Minor > Labels: aggregator > Fix For: 2.11.0 > > > add support in the Aggregator EIP for checking for a new header > (AGGREGATION_COMPLETE_ALL_GROUPS_INCLUSIVE) to trigger flushing of all groups > and be inclusive of the current message... > per > http://camel.465427.n5.nabble.com/aggregator-force-completion-with-header-td5728368.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CAMEL-6119) enhance Aggregator to allow forcing completion via a header and include the current message
Ben O'Day created CAMEL-6119: Summary: enhance Aggregator to allow forcing completion via a header and include the current message Key: CAMEL-6119 URL: https://issues.apache.org/jira/browse/CAMEL-6119 Project: Camel Issue Type: Improvement Components: camel-core Reporter: Ben O'Day Assignee: Ben O'Day Priority: Minor Fix For: 2.11.0 add support in the Aggregator EIP for checking for a new header (AGGREGATION_COMPLETE_ALL_GROUPS_INCLUSIVE) to trigger flushing of all groups and be inclusive of the current message... per http://camel.465427.n5.nabble.com/aggregator-force-completion-with-header-td5728368.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CAMEL-5388) Karaf command - ContextInfo - Should have verbose option
[
https://issues.apache.org/jira/browse/CAMEL-5388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ben O'Day resolved CAMEL-5388.
--
Resolution: Fixed
see r1410699
> Karaf command - ContextInfo - Should have verbose option
>
>
> Key: CAMEL-5388
> URL: https://issues.apache.org/jira/browse/CAMEL-5388
> Project: Camel
> Issue Type: Improvement
> Components: karaf
>Reporter: Claus Ibsen
>Assignee: Ben O'Day
>Priority: Minor
> Fix For: 2.11.0
>
>
> The karaf command {{context-info}} lists many things. We should have a
> --verbose option to limit what it display by default. Because it displays all
> the endpoints in use, and if people use dynamic endpoints and whatnot, then
> that list can be very long (up till 1000 by default).
> And besides there is a new endpoint command as well now. So we could either
> - add verbose option
> - not list endpoints anymore
> We should possible add more stats such as
> Number of running routes: 15
> Number of not running routes: 2
> eg to give a quick overview of how many routes is running / not running etc.
> Yes you can use the route-list command for that. But context-info should be a
> nice single command for a good overview of the Camel app.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CAMEL-5388) Karaf command - ContextInfo - Should have verbose option
[
https://issues.apache.org/jira/browse/CAMEL-5388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ben O'Day reassigned CAMEL-5388:
Assignee: Ben O'Day
> Karaf command - ContextInfo - Should have verbose option
>
>
> Key: CAMEL-5388
> URL: https://issues.apache.org/jira/browse/CAMEL-5388
> Project: Camel
> Issue Type: Improvement
> Components: karaf
>Reporter: Claus Ibsen
>Assignee: Ben O'Day
>Priority: Minor
> Fix For: 2.11.0
>
>
> The karaf command {{context-info}} lists many things. We should have a
> --verbose option to limit what it display by default. Because it displays all
> the endpoints in use, and if people use dynamic endpoints and whatnot, then
> that list can be very long (up till 1000 by default).
> And besides there is a new endpoint command as well now. So we could either
> - add verbose option
> - not list endpoints anymore
> We should possible add more stats such as
> Number of running routes: 15
> Number of not running routes: 2
> eg to give a quick overview of how many routes is running / not running etc.
> Yes you can use the route-list command for that. But context-info should be a
> nice single command for a good overview of the Camel app.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CAMEL-5481) add elasticsearch GET & DELETE support
[ https://issues.apache.org/jira/browse/CAMEL-5481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben O'Day resolved CAMEL-5481. -- Resolution: Fixed > add elasticsearch GET & DELETE support > -- > > Key: CAMEL-5481 > URL: https://issues.apache.org/jira/browse/CAMEL-5481 > Project: Camel > Issue Type: New Feature > Components: camel-elasticsearch >Affects Versions: 2.11.0 >Reporter: Ben O'Day >Assignee: Ben O'Day >Priority: Minor > Fix For: 2.11.0 > > > currently only support adding to the index, need to support the GET/DELETE > operations as well -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAMEL-5481) add elasticsearch GET & DELETE support
[ https://issues.apache.org/jira/browse/CAMEL-5481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben O'Day updated CAMEL-5481: - Description: currently only support adding to the index, need to support the GET/DELETE operations as well (was: currently only support adding to the index, need to support the other operations as well) Summary: add elasticsearch GET & DELETE support (was: add elasticsearch GET/DELETE/SEARCH/QUERY support) > add elasticsearch GET & DELETE support > -- > > Key: CAMEL-5481 > URL: https://issues.apache.org/jira/browse/CAMEL-5481 > Project: Camel > Issue Type: New Feature > Components: camel-elasticsearch >Affects Versions: 2.11.0 >Reporter: Ben O'Day >Assignee: Ben O'Day >Priority: Minor > Fix For: 2.11.0 > > > currently only support adding to the index, need to support the GET/DELETE > operations as well -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Work started] (CAMEL-5481) add elasticsearch GET & DELETE support
[ https://issues.apache.org/jira/browse/CAMEL-5481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CAMEL-5481 started by Ben O'Day. > add elasticsearch GET & DELETE support > -- > > Key: CAMEL-5481 > URL: https://issues.apache.org/jira/browse/CAMEL-5481 > Project: Camel > Issue Type: New Feature > Components: camel-elasticsearch >Affects Versions: 2.11.0 >Reporter: Ben O'Day >Assignee: Ben O'Day >Priority: Minor > Fix For: 2.11.0 > > > currently only support adding to the index, need to support the GET/DELETE > operations as well -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAMEL-5481) add elasticsearch GET/DELETE/SEARCH/QUERY support
[ https://issues.apache.org/jira/browse/CAMEL-5481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben O'Day updated CAMEL-5481: - Summary: add elasticsearch GET/DELETE/SEARCH/QUERY support (was: add elasticsearch ADD/DELETE/SEARCH/QUERY support) > add elasticsearch GET/DELETE/SEARCH/QUERY support > - > > Key: CAMEL-5481 > URL: https://issues.apache.org/jira/browse/CAMEL-5481 > Project: Camel > Issue Type: New Feature > Components: camel-elasticsearch >Affects Versions: 2.11.0 >Reporter: Ben O'Day >Assignee: Ben O'Day >Priority: Minor > Fix For: 2.11.0 > > > currently only support adding to the index, need to support the other > operations as well -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CAMEL-5481) add elasticsearch ADD/DELETE/SEARCH/QUERY support
Ben O'Day created CAMEL-5481: Summary: add elasticsearch ADD/DELETE/SEARCH/QUERY support Key: CAMEL-5481 URL: https://issues.apache.org/jira/browse/CAMEL-5481 Project: Camel Issue Type: New Feature Components: camel-elasticsearch Affects Versions: 2.11.0 Reporter: Ben O'Day Assignee: Ben O'Day Priority: Minor Fix For: 2.11.0 currently only support adding to the index, need to support the other operations as well -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAMEL-5219) create camel-elasticsearch component
[ https://issues.apache.org/jira/browse/CAMEL-5219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben O'Day updated CAMEL-5219: - Component/s: camel-elasticsearch > create camel-elasticsearch component > > > Key: CAMEL-5219 > URL: https://issues.apache.org/jira/browse/CAMEL-5219 > Project: Camel > Issue Type: New Feature > Components: camel-elasticsearch >Reporter: Ben O'Day >Assignee: Ben O'Day >Priority: Minor > Fix For: 2.11.0 > > Attachments: CAMEL-5219.patch > > > ElasticSearch support would be a great addition to complement our > camel-lucene and newly added camel-solr component... > I'm working on adding a basic component to start, if there are any specific > features you'd like to see implemented, let me know... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Work started] (CAMEL-5219) create camel-elasticsearch component
[ https://issues.apache.org/jira/browse/CAMEL-5219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CAMEL-5219 started by Ben O'Day. > create camel-elasticsearch component > > > Key: CAMEL-5219 > URL: https://issues.apache.org/jira/browse/CAMEL-5219 > Project: Camel > Issue Type: New Feature >Reporter: Ben O'Day >Assignee: Ben O'Day >Priority: Minor > Fix For: Future > > Attachments: CAMEL-5219.patch > > > ElasticSearch support would be a great addition to complement our > camel-lucene and newly added camel-solr component... > I'm working on adding a basic component to start, if there are any specific > features you'd like to see implemented, let me know... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CAMEL-5219) create camel-elasticsearch component
[ https://issues.apache.org/jira/browse/CAMEL-5219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben O'Day resolved CAMEL-5219. -- Resolution: Fixed Fix Version/s: (was: Future) 2.11.0 initial version committed (r1368312)...docs to come soon > create camel-elasticsearch component > > > Key: CAMEL-5219 > URL: https://issues.apache.org/jira/browse/CAMEL-5219 > Project: Camel > Issue Type: New Feature >Reporter: Ben O'Day >Assignee: Ben O'Day >Priority: Minor > Fix For: 2.11.0 > > Attachments: CAMEL-5219.patch > > > ElasticSearch support would be a great addition to complement our > camel-lucene and newly added camel-solr component... > I'm working on adding a basic component to start, if there are any specific > features you'd like to see implemented, let me know... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-5219) create camel-elasticsearch component
[ https://issues.apache.org/jira/browse/CAMEL-5219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13424677#comment-13424677 ] Ben O'Day commented on CAMEL-5219: -- Cedric, any reason we shouldn't use the latest version of elasticsearch, 0.19.8? I upped it locally and it seems fine so far... > create camel-elasticsearch component > > > Key: CAMEL-5219 > URL: https://issues.apache.org/jira/browse/CAMEL-5219 > Project: Camel > Issue Type: New Feature >Reporter: Ben O'Day >Assignee: Ben O'Day >Priority: Minor > Fix For: Future > > Attachments: CAMEL-5219.patch > > > ElasticSearch support would be a great addition to complement our > camel-lucene and newly added camel-solr component... > I'm working on adding a basic component to start, if there are any specific > features you'd like to see implemented, let me know... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
