[jira] [Commented] (CAMEL-9144) Regression with camel-jackson 2.15.3

2015-09-30 Thread Julien Garcia Gonzalez (JIRA) 

[ 
https://issues.apache.org/jira/browse/CAMEL-9144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14936542#comment-14936542
 ] 

Julien Garcia Gonzalez commented on CAMEL-9144:
---

Hi Claus,

you can find here the sample project: 
https://github.com/juliengarcia/Camel-Example.

Actually the project is in 2.15.3 version and it's not the context is not 
loading when you run the test.

If you change into 2.15.2, the context will load



> Regression with camel-jackson 2.15.3
> 
>
> Key: CAMEL-9144
> URL: https://issues.apache.org/jira/browse/CAMEL-9144
> Project: Camel
>  Issue Type: Bug
>  Components: camel-jackson
>Affects Versions: 2.15.3
>Reporter: Arnaud Deprez
> Fix For: 2.15.4
>
>
> Hi folks,
> Apparently we found a regression with camel and camel-jackson in version 
> 2.15.3.
> The following code : 
> restConfiguration()
> .component("servlet")
> .bindingMode(RestBindingMode.json)
> .contextPath("/adm-replication")
> .port("8181");
> rest("/replication")
> .post("/{cus}/{contractDate}")
> .produces("application/json")
> .consumes("application/json")
> .to("mock:TestRoute");
> produces the following exception by looking for the default json dataformat : 
> org.apache.camel.FailedToCreateRouteException: Failed to create route route1 
> at: >>> RestBinding <<< in route: 
> Route(route1)[[From[rest:post:/replication:/{cus}/{contractD... because of 
> JSon DataFormat json-jackson not found.
> at 
> org.apache.camel.model.RouteDefinition.addRoutes(RouteDefinition.java:1028)
> at 
> org.apache.camel.model.RouteDefinition.addRoutes(RouteDefinition.java:185)
> at 
> org.apache.camel.impl.DefaultCamelContext.startRoute(DefaultCamelContext.java:841)
> at 
> org.apache.camel.impl.DefaultCamelContext.startRouteDefinitions(DefaultCamelContext.java:2911)
> at 
> org.apache.camel.impl.DefaultCamelContext.doStartCamel(DefaultCamelContext.java:2634)
> at 
> org.apache.camel.impl.DefaultCamelContext.access$000(DefaultCamelContext.java:167)
> at 
> org.apache.camel.impl.DefaultCamelContext$2.call(DefaultCamelContext.java:2483)
> at 
> org.apache.camel.impl.DefaultCamelContext$2.call(DefaultCamelContext.java:2479)
> at 
> org.apache.camel.impl.DefaultCamelContext.doWithDefinedClassLoader(DefaultCamelContext.java:2502)
> at 
> org.apache.camel.impl.DefaultCamelContext.doStart(DefaultCamelContext.java:2479)
> at org.apache.camel.support.ServiceSupport.start(ServiceSupport.java:61)
> at 
> org.apache.camel.impl.DefaultCamelContext.start(DefaultCamelContext.java:2448)
> at 
> org.apache.camel.blueprint.BlueprintCamelContext.start(BlueprintCamelContext.java:180)
> at 
> org.apache.camel.test.blueprint.CamelBlueprintTestSupport.setUp(CamelBlueprintTestSupport.java:209)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
> at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
> at 
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:78)
> at 
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:212)
> at

[jira] [Created] (CAMEL-9183) java.lang.IllegalArgumentException: Unsupported namespaces: [http://camel.apache.org/schema/blueprint]

2015-09-30 Thread Charles Moulliard (JIRA) 
Charles Moulliard created CAMEL-9183:


 Summary: java.lang.IllegalArgumentException: Unsupported 
namespaces: [http://camel.apache.org/schema/blueprint]
 Key: CAMEL-9183
 URL: https://issues.apache.org/jira/browse/CAMEL-9183
 Project: Camel
  Issue Type: Bug
  Components: examples
Affects Versions: 2.16.0
Reporter: Charles Moulliard


Version used of Blueprint Web : 1.0

I don't know if this example has ever work - 
https://github.com/apache/camel/blob/master/examples/camel-example-servlet-tomcat-blueprintweb/src/main/resources/META-INF/blueprint.xml
 but this is apparently not the longer case.

When we start mvn jetty:run within the project, we get this error

2015-09-30 10:37:29.054:WARN:/:Failed to startup blueprint container. 
java.lang.IllegalArgumentException: Unsupported namespaces: 
[http://camel.apache.org/schema/blueprint]
java.lang.IllegalArgumentException: Unsupported namespaces: 
[http://camel.apache.org/schema/blueprint]
at 
org.apache.aries.blueprint.container.BlueprintContainerImpl.init(BlueprintContainerImpl.java:99)
at 
org.apache.aries.blueprint.container.BlueprintContainerImpl.(BlueprintContainerImpl.java:73)
at 
org.apache.aries.blueprint.web.BlueprintContextListener.contextInitialized(BlueprintContextListener.java:86)

Why, when the BlueprintContext is created, then it fails to load the camel 
namespace handler

We should upgrade to this version of Blueprint Web :

https://github.com/apache/aries/blob/trunk/blueprint/blueprint-web/src/main/java/org/apache/aries/blueprint/web/BlueprintContextListener.java#L55-L56

which allow to specify :

blueprintNamespaceHandlers OR META-INF/blueprint.handlers

and adapt the example to pass the blueprintNamespaceHandlers



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-9183) java.lang.IllegalArgumentException: Unsupported namespaces: [http://camel.apache.org/schema/blueprint]

2015-09-30 Thread Charles Moulliard (JIRA) 

[ 
https://issues.apache.org/jira/browse/CAMEL-9183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14936689#comment-14936689
 ] 

Charles Moulliard commented on CAMEL-9183:
--

If we upgrade to Aries Blueprint Web 1.1.1 and add also as reference blueprint 
parser 1.3.1, then we will have again the same error as this part of the code 
of Aries Blueprint Web is not able to find the @Namespaces annotation 

{code}
NamespaceHandler nsHandler = (NamespaceHandler)instance;
Namespaces namespaces = 
nsHandler.getClass().getAnnotation(Namespaces.class);
if (namespaces != null) { // WE WILL GET NULL HERE
for (String ns : namespaces.value()) {
nsSet.addNamespace(URI.create(ns), 
nsHandler.getSchemaLocation(ns), nsHandler);   
}
}
{code}

> java.lang.IllegalArgumentException: Unsupported namespaces: 
> [http://camel.apache.org/schema/blueprint]
> --
>
> Key: CAMEL-9183
> URL: https://issues.apache.org/jira/browse/CAMEL-9183
> Project: Camel
>  Issue Type: Bug
>  Components: examples
>Affects Versions: 2.16.0
>Reporter: Charles Moulliard
>
> Version used of Blueprint Web : 1.0
> I don't know if this example has ever work - 
> https://github.com/apache/camel/blob/master/examples/camel-example-servlet-tomcat-blueprintweb/src/main/resources/META-INF/blueprint.xml
>  but this is apparently not the longer case.
> When we start mvn jetty:run within the project, we get this error
> 2015-09-30 10:37:29.054:WARN:/:Failed to startup blueprint container. 
> java.lang.IllegalArgumentException: Unsupported namespaces: 
> [http://camel.apache.org/schema/blueprint]
> java.lang.IllegalArgumentException: Unsupported namespaces: 
> [http://camel.apache.org/schema/blueprint]
>   at 
> org.apache.aries.blueprint.container.BlueprintContainerImpl.init(BlueprintContainerImpl.java:99)
>   at 
> org.apache.aries.blueprint.container.BlueprintContainerImpl.(BlueprintContainerImpl.java:73)
>   at 
> org.apache.aries.blueprint.web.BlueprintContextListener.contextInitialized(BlueprintContextListener.java:86)
> Why, when the BlueprintContext is created, then it fails to load the camel 
> namespace handler
> We should upgrade to this version of Blueprint Web :
> https://github.com/apache/aries/blob/trunk/blueprint/blueprint-web/src/main/java/org/apache/aries/blueprint/web/BlueprintContextListener.java#L55-L56
> which allow to specify :
> blueprintNamespaceHandlers OR META-INF/blueprint.handlers
> and adapt the example to pass the blueprintNamespaceHandlers



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CAMEL-8879) Camel-sjms doesn't treat InOnly and InOut equally

2015-09-30 Thread Jimmy Selgen Nielsen (JIRA) 

 [ 
https://issues.apache.org/jira/browse/CAMEL-8879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jimmy Selgen Nielsen updated CAMEL-8879:

Attachment: camel-sjms.patch

I wrote a patch a few months ago for this issue, and we've been testing it 
internally. It seems to work.

> Camel-sjms doesn't treat InOnly and InOut equally
> -
>
> Key: CAMEL-8879
> URL: https://issues.apache.org/jira/browse/CAMEL-8879
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-sjms
>Affects Versions: 2.15.2
>Reporter: Jimmy Selgen Nielsen
> Attachments: camel-sjms.patch
>
>
> The Camel-sjms component doesn't treat messages being sent to the 
> InOnlyProducer equally to the ones sent to the InOutProducer.
> As far as i can tell, the InOnlyProducer handles messages the correct way, by 
> splitting up the ArrayList> into individual messages, which 
> it then sends. The InOutProducer just calls "JmsMessageHelper.createMessage" 
> with the ArrayList> payload.
> When used with WebSphere MQ, the InOutProducer causes an exception:
> JMSCC0083: An incorrect object of type 
> 'org.apache.camel.component.sjms.BatchMessage' was provided.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CAMEL-9185) Quartz Scheduler unable to recover from a database outage

2015-09-30 Thread Sambit Mohanty (JIRA) 
Sambit Mohanty created CAMEL-9185:
-

 Summary: Quartz Scheduler unable to recover from a database outage
 Key: CAMEL-9185
 URL: https://issues.apache.org/jira/browse/CAMEL-9185
 Project: Camel
  Issue Type: Bug
Reporter: Sambit Mohanty


Hi,

Currently we have an implementation of Camel 2.12.1 and quartz .
The job states are being persisted in the database using the trigger tables.

After a database outage the scheduler is not able to revive and throws jdbc 
connection exception. I have provided a stack trace below. Please what could be 
the resolution steps.

QuartzScheduler_CSAClusteredScheduler-_ClusterManager ERROR o.q.i.j.JobStoreTX 
ClusterManager: Error managing cluster: Failed to obtain DB connection from 
data source 'csaDS': java.sql.SQLException: Could not retrieve datasource via 
JNDI url 'java:comp/env/jdbc/CSA' javax.naming.ConfigurationException: A JNDI 
operation on a "java:" name cannot be completed because the server runtime is 
not able to associate the operation's thread with any J2EE application 
component.  This condition can occur when the JNDI client using the "java:" 
name is not executed on the thread of a server application request.  Make sure 
that a J2EE application does not execute JNDI operations on "java:" names 
within static code blocks or in threads created by that J2EE application.  Such 
code does not necessarily run on the thread of a server application request and 
therefore is not supported by JNDI operations on "java:" names.

org.quartz.JobPersistenceException: Failed to obtain DB connection from data 
source 'csaDS': java.sql.SQLException: Could not retrieve datasource via JNDI 
url 'java:comp/env/jdbc/CSA' javax.naming.ConfigurationException: A JNDI 
operation on a "java:" name cannot be completed because the server runtime is 
not able to associate the operation's thread with any J2EE application 
component.  This condition can occur when the JNDI client using the "java:" 
name is not executed on the thread of a server application request.  Make sure 
that a J2EE application does not execute JNDI operations on "java:" names 
within static code blocks or in threads created by that J2EE application.  Such 
code does not necessarily run on the thread of a server application request and 
therefore is not supported by JNDI operations on "java:" names.

at 
org.quartz.impl.jdbcjobstore.JobStoreSupport.getConnection(JobStoreSupport.java:777)
 ~[quartz-2.2.0.jar:na]

at 
org.quartz.impl.jdbcjobstore.JobStoreTX.getNonManagedTXConnection(JobStoreTX.java:71)
 ~[quartz-2.2.0.jar:na]

at 
org.quartz.impl.jdbcjobstore.JobStoreSupport.doCheckin(JobStoreSupport.java:3213)
 ~[quartz-2.2.0.jar:na]

at 
org.quartz.impl.jdbcjobstore.JobStoreSupport$ClusterManager.manage(JobStoreSupport.java:3836)
 [quartz-2.2.0.jar:na]

at 
org.quartz.impl.jdbcjobstore.JobStoreSupport$ClusterManager.run(JobStoreSupport.java:3873)
 [quartz-2.2.0.jar:na]







--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CAMEL-9185) Quartz Scheduler unable to recover from a database outage

2015-09-30 Thread Claus Ibsen (JIRA) 

 [ 
https://issues.apache.org/jira/browse/CAMEL-9185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen resolved CAMEL-9185.

Resolution: Invalid
  Assignee: Claus Ibsen

Use the mailing list / user forum to get help with this kind of quesiton

> Quartz Scheduler unable to recover from a database outage
> -
>
> Key: CAMEL-9185
> URL: https://issues.apache.org/jira/browse/CAMEL-9185
> Project: Camel
>  Issue Type: Bug
>Reporter: Sambit Mohanty
>Assignee: Claus Ibsen
>
> Hi,
> Currently we have an implementation of Camel 2.12.1 and quartz .
> The job states are being persisted in the database using the trigger tables.
> After a database outage the scheduler is not able to revive and throws jdbc 
> connection exception. I have provided a stack trace below. Please advise what 
> could be the resolution steps.
> ***
> QuartzScheduler_CSAClusteredScheduler-_ClusterManager ERROR 
> o.q.i.j.JobStoreTX ClusterManager: Error managing cluster: Failed to obtain 
> DB connection from data source 'csaDS': java.sql.SQLException: Could not 
> retrieve datasource via JNDI url 'java:comp/env/jdbc/CSA' 
> javax.naming.ConfigurationException: A JNDI operation on a "java:" name 
> cannot be completed because the server runtime is not able to associate the 
> operation's thread with any J2EE application component.  This condition can 
> occur when the JNDI client using the "java:" name is not executed on the 
> thread of a server application request.  Make sure that a J2EE application 
> does not execute JNDI operations on "java:" names within static code blocks 
> or in threads created by that J2EE application.  Such code does not 
> necessarily run on the thread of a server application request and therefore 
> is not supported by JNDI operations on "java:" names.
> org.quartz.JobPersistenceException: Failed to obtain DB connection from data 
> source 'csaDS': java.sql.SQLException: Could not retrieve datasource via JNDI 
> url 'java:comp/env/jdbc/CSA' javax.naming.ConfigurationException: A JNDI 
> operation on a "java:" name cannot be completed because the server runtime is 
> not able to associate the operation's thread with any J2EE application 
> component.  This condition can occur when the JNDI client using the "java:" 
> name is not executed on the thread of a server application request.  Make 
> sure that a J2EE application does not execute JNDI operations on "java:" 
> names within static code blocks or in threads created by that J2EE 
> application.  Such code does not necessarily run on the thread of a server 
> application request and therefore is not supported by JNDI operations on 
> "java:" names.
> at 
> org.quartz.impl.jdbcjobstore.JobStoreSupport.getConnection(JobStoreSupport.java:777)
>  ~[quartz-2.2.0.jar:na]
> at 
> org.quartz.impl.jdbcjobstore.JobStoreTX.getNonManagedTXConnection(JobStoreTX.java:71)
>  ~[quartz-2.2.0.jar:na]
> at 
> org.quartz.impl.jdbcjobstore.JobStoreSupport.doCheckin(JobStoreSupport.java:3213)
>  ~[quartz-2.2.0.jar:na]
> at 
> org.quartz.impl.jdbcjobstore.JobStoreSupport$ClusterManager.manage(JobStoreSupport.java:3836)
>  [quartz-2.2.0.jar:na]
> at 
> org.quartz.impl.jdbcjobstore.JobStoreSupport$ClusterManager.run(JobStoreSupport.java:3873)
>  [quartz-2.2.0.jar:na]
> *



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CAMEL-8890) camel-salesforce-maven-plugin: Unable to generate DTOs due to new encrypted field

2015-09-30 Thread Claus Ibsen (JIRA) 

 [ 
https://issues.apache.org/jira/browse/CAMEL-8890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen resolved CAMEL-8890.

   Resolution: Fixed
Fix Version/s: 2.15.4
   2.16.0

> camel-salesforce-maven-plugin: Unable to generate DTOs due to new encrypted 
> field
> -
>
> Key: CAMEL-8890
> URL: https://issues.apache.org/jira/browse/CAMEL-8890
> Project: Camel
>  Issue Type: Bug
>  Components: camel-salesforce
>Affects Versions: 2.15.2
>Reporter: Simon Delfab
>Assignee: Dhiraj Bokde
> Fix For: 2.16.0, 2.15.4
>
>
> The maven plugin is failing to generate the DTOs. It appears that Salesforce 
> has recently introduced a new boolean field call encrypted to the 
> 'DescribeSObjectResult' object [1,2]
> The fix is to modify the 
> org.apache.camel.component.salesforce.api.dto.SObjectField and add the 
> following:
> private Boolean encrypted;
>public Boolean getEncrypted() {
> return encrypted;
> }
> public void setEncrypted(Boolean encrypted) {
> this.encrypted = encrypted;
> }
> With this change the DTOs are generated. However, not sure if there is 
> anything else which needs to be done.
> Btw, I am surprised that this new field causes a problem because the default 
> API version Camel-Salesforce is configured to is 33.0 and this new field 
> appears in 34.0.
> [1] 
> https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/sforce_api_calls_describesobjects_describesobjectresult.htm#topic-title
> [2] 
> http://releasenotes.docs.salesforce.com/en-us/summer15/release-notes/rn_security_platform_encryption.htm



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CAMEL-9185) Quartz Scheduler unable to recover from a database outage

2015-09-30 Thread Claus Ibsen (JIRA) 

 [ 
https://issues.apache.org/jira/browse/CAMEL-9185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen closed CAMEL-9185.
--

> Quartz Scheduler unable to recover from a database outage
> -
>
> Key: CAMEL-9185
> URL: https://issues.apache.org/jira/browse/CAMEL-9185
> Project: Camel
>  Issue Type: Bug
>Reporter: Sambit Mohanty
>Assignee: Claus Ibsen
>
> Hi,
> Currently we have an implementation of Camel 2.12.1 and quartz .
> The job states are being persisted in the database using the trigger tables.
> After a database outage the scheduler is not able to revive and throws jdbc 
> connection exception. I have provided a stack trace below. Please advise what 
> could be the resolution steps.
> ***
> QuartzScheduler_CSAClusteredScheduler-_ClusterManager ERROR 
> o.q.i.j.JobStoreTX ClusterManager: Error managing cluster: Failed to obtain 
> DB connection from data source 'csaDS': java.sql.SQLException: Could not 
> retrieve datasource via JNDI url 'java:comp/env/jdbc/CSA' 
> javax.naming.ConfigurationException: A JNDI operation on a "java:" name 
> cannot be completed because the server runtime is not able to associate the 
> operation's thread with any J2EE application component.  This condition can 
> occur when the JNDI client using the "java:" name is not executed on the 
> thread of a server application request.  Make sure that a J2EE application 
> does not execute JNDI operations on "java:" names within static code blocks 
> or in threads created by that J2EE application.  Such code does not 
> necessarily run on the thread of a server application request and therefore 
> is not supported by JNDI operations on "java:" names.
> org.quartz.JobPersistenceException: Failed to obtain DB connection from data 
> source 'csaDS': java.sql.SQLException: Could not retrieve datasource via JNDI 
> url 'java:comp/env/jdbc/CSA' javax.naming.ConfigurationException: A JNDI 
> operation on a "java:" name cannot be completed because the server runtime is 
> not able to associate the operation's thread with any J2EE application 
> component.  This condition can occur when the JNDI client using the "java:" 
> name is not executed on the thread of a server application request.  Make 
> sure that a J2EE application does not execute JNDI operations on "java:" 
> names within static code blocks or in threads created by that J2EE 
> application.  Such code does not necessarily run on the thread of a server 
> application request and therefore is not supported by JNDI operations on 
> "java:" names.
> at 
> org.quartz.impl.jdbcjobstore.JobStoreSupport.getConnection(JobStoreSupport.java:777)
>  ~[quartz-2.2.0.jar:na]
> at 
> org.quartz.impl.jdbcjobstore.JobStoreTX.getNonManagedTXConnection(JobStoreTX.java:71)
>  ~[quartz-2.2.0.jar:na]
> at 
> org.quartz.impl.jdbcjobstore.JobStoreSupport.doCheckin(JobStoreSupport.java:3213)
>  ~[quartz-2.2.0.jar:na]
> at 
> org.quartz.impl.jdbcjobstore.JobStoreSupport$ClusterManager.manage(JobStoreSupport.java:3836)
>  [quartz-2.2.0.jar:na]
> at 
> org.quartz.impl.jdbcjobstore.JobStoreSupport$ClusterManager.run(JobStoreSupport.java:3873)
>  [quartz-2.2.0.jar:na]
> *



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CAMEL-9184) Throttler: Rejected message whe rejectExecution=true

2015-09-30 Thread Arno Noordover (JIRA) 
Arno Noordover created CAMEL-9184:
-

 Summary: Throttler: Rejected message whe rejectExecution=true
 Key: CAMEL-9184
 URL: https://issues.apache.org/jira/browse/CAMEL-9184
 Project: Camel
  Issue Type: Bug
  Components: camel-core
Affects Versions: 2.15.3
Reporter: Arno Noordover


When a message gets rejected and rejectExecution is true, the rejected message 
is still assigned to the new time-slot.
When you use the throttler to secure against DOS going to the backend a DOS can 
fill up many time-slots.
I'm not sure whether this behaviour is the expected behaviour. My feeling says 
that the rejected message should not be assigned to a new time-slot.

Maybe the exception should be raised in the synchronized method that determines 
the starting of a new time-slot.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)