[jira] [Commented] (CAMEL-9143) Producers that implement the ServicePoolAware interface cause memory leak due to JMX references
[
https://issues.apache.org/jira/browse/CAMEL-9143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14791696#comment-14791696
]
Claus Ibsen commented on CAMEL-9143:
Thanks for the very detailed report.
> Producers that implement the ServicePoolAware interface cause memory leak due
> to JMX references
> ---
>
> Key: CAMEL-9143
> URL: https://issues.apache.org/jira/browse/CAMEL-9143
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.14.1, 2.14.2, 2.15.0, 2.15.1
>Reporter: Bob Browning
> Fix For: 2.16.0, 2.15.4
>
>
> h4. Description
> Producer instances that implement the ServicePoolAware interface will leak
> memory if their route is stopped, with new producers being leaked every time
> the route is started/stopped.
> Known implementations that are affected are RemoteFileProducer (ftp, sftp)
> and Mina2Producer.
> This is due to the behaviour that the SendProcessor which when the route is
> stopped it shuts down it's `producerCache` instance.
> {code}
> protected void doStop() throws Exception {
> ServiceHelper.stopServices(producerCache, producer);
> }
> {code}
> this in turn calls `stopAndShutdownService(pool)` which will call stop on the
> SharedProducerServicePool instance which is a NOOP however it also calls
> shutdown which effects a stop of the global pool (this stops all the
> registered services and then clears the pool.
> {code}
> protected void doStop() throws Exception {
> // when stopping we intend to shutdown
> ServiceHelper.stopAndShutdownService(pool);
> try {
> ServiceHelper.stopAndShutdownServices(producers.values());
> } finally {
> // ensure producers are removed, and also from JMX
> for (Producer producer : producers.values()) {
> getCamelContext().removeService(producer);
> }
> }
> producers.clear();
> }
> {code}
> However no call to `context.removeService(Producer) is called for the entries
> from the pool only those singleton instances that were in the `producers` map
> hence the JMX `ManagedProducer` that is created when `doGetProducer` invokes
> {code}getCamelContext().addService(answer, false);
> {code} is never removed.
> Since the global pool is empty when the next request to get a producer is
> called a new producer is created, jmx wrapper and all, whilst the old
> instance remains orphaned retaining any objects that pertain to that instance.
> One workaround is for the producer to call
> {code}getEndpoint().getCamelContext().removeService(this){code} in it's stop
> method, however this is fairly obscure and it would probably be better to
> invoke removal of the producer when it is removed from the shared pool.
> Another issue of note is that when a route is shutdown that contains a
> SendProcessor due to the shutdown invocation on the
> SharedProcessorServicePool the global pool is cleared of `everything` and
> remains in `Stopped` state until another route starts it (although it is
> still accessed and used whilst in the `Stopped` state).
> h4. Impact
> For general use where there is no dynamic creation or passivation of routes
> this issue should be minimal, however in our use case where the routes are
> not static, there is a certain amount of recreation of routes as customer
> endpoints change and there is a need to passivate idle routes this causes a
> considerable memory leak (via SFTP in particular).
> h4. Test Case
> {code}
> package org.apache.camel.component;
> import com.google.common.util.concurrent.AtomicLongMap;
> import org.apache.camel.CamelContext;
> import org.apache.camel.Consumer;
> import org.apache.camel.Endpoint;
> import org.apache.camel.Exchange;
> import org.apache.camel.Processor;
> import org.apache.camel.Producer;
> import org.apache.camel.Route;
> import org.apache.camel.Service;
> import org.apache.camel.ServicePoolAware;
> import org.apache.camel.ServiceStatus;
> import org.apache.camel.builder.RouteBuilder;
> import org.apache.camel.impl.DefaultComponent;
> import org.apache.camel.impl.DefaultEndpoint;
> import org.apache.camel.impl.DefaultProducer;
> import org.apache.camel.support.LifecycleStrategySupport;
> import org.apache.camel.support.ServiceSupport;
> import org.apache.camel.test.junit4.CamelTestSupport;
> import org.junit.Test;
> import java.util.Map;
> import static com.google.common.base.Preconditions.checkNotNull;
> /**
> * Test memory behaviour of producers using {@link ServicePoolAware} when
> using JMX.
> */
> public class ServicePoolAwareLeakyTest extends CamelTestSupport {
> private static final String LEAKY_SIEVE_STABLE =
> "leaky://sieve-stable?plugged=true";
>
[jira] [Updated] (CAMEL-9143) Producers that implement the ServicePoolAware interface cause memory leak due to JMX references
[
https://issues.apache.org/jira/browse/CAMEL-9143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-9143:
---
Fix Version/s: 2.15.4
2.16.0
> Producers that implement the ServicePoolAware interface cause memory leak due
> to JMX references
> ---
>
> Key: CAMEL-9143
> URL: https://issues.apache.org/jira/browse/CAMEL-9143
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.14.1, 2.14.2, 2.15.0, 2.15.1
>Reporter: Bob Browning
> Fix For: 2.16.0, 2.15.4
>
>
> h4. Description
> Producer instances that implement the ServicePoolAware interface will leak
> memory if their route is stopped, with new producers being leaked every time
> the route is started/stopped.
> Known implementations that are affected are RemoteFileProducer (ftp, sftp)
> and Mina2Producer.
> This is due to the behaviour that the SendProcessor which when the route is
> stopped it shuts down it's `producerCache` instance.
> {code}
> protected void doStop() throws Exception {
> ServiceHelper.stopServices(producerCache, producer);
> }
> {code}
> this in turn calls `stopAndShutdownService(pool)` which will call stop on the
> SharedProducerServicePool instance which is a NOOP however it also calls
> shutdown which effects a stop of the global pool (this stops all the
> registered services and then clears the pool.
> {code}
> protected void doStop() throws Exception {
> // when stopping we intend to shutdown
> ServiceHelper.stopAndShutdownService(pool);
> try {
> ServiceHelper.stopAndShutdownServices(producers.values());
> } finally {
> // ensure producers are removed, and also from JMX
> for (Producer producer : producers.values()) {
> getCamelContext().removeService(producer);
> }
> }
> producers.clear();
> }
> {code}
> However no call to `context.removeService(Producer) is called for the entries
> from the pool only those singleton instances that were in the `producers` map
> hence the JMX `ManagedProducer` that is created when `doGetProducer` invokes
> {code}getCamelContext().addService(answer, false);
> {code} is never removed.
> Since the global pool is empty when the next request to get a producer is
> called a new producer is created, jmx wrapper and all, whilst the old
> instance remains orphaned retaining any objects that pertain to that instance.
> One workaround is for the producer to call
> {code}getEndpoint().getCamelContext().removeService(this){code} in it's stop
> method, however this is fairly obscure and it would probably be better to
> invoke removal of the producer when it is removed from the shared pool.
> Another issue of note is that when a route is shutdown that contains a
> SendProcessor due to the shutdown invocation on the
> SharedProcessorServicePool the global pool is cleared of `everything` and
> remains in `Stopped` state until another route starts it (although it is
> still accessed and used whilst in the `Stopped` state).
> h4. Impact
> For general use where there is no dynamic creation or passivation of routes
> this issue should be minimal, however in our use case where the routes are
> not static, there is a certain amount of recreation of routes as customer
> endpoints change and there is a need to passivate idle routes this causes a
> considerable memory leak (via SFTP in particular).
> h4. Test Case
> {code}
> package org.apache.camel.component;
> import com.google.common.util.concurrent.AtomicLongMap;
> import org.apache.camel.CamelContext;
> import org.apache.camel.Consumer;
> import org.apache.camel.Endpoint;
> import org.apache.camel.Exchange;
> import org.apache.camel.Processor;
> import org.apache.camel.Producer;
> import org.apache.camel.Route;
> import org.apache.camel.Service;
> import org.apache.camel.ServicePoolAware;
> import org.apache.camel.ServiceStatus;
> import org.apache.camel.builder.RouteBuilder;
> import org.apache.camel.impl.DefaultComponent;
> import org.apache.camel.impl.DefaultEndpoint;
> import org.apache.camel.impl.DefaultProducer;
> import org.apache.camel.support.LifecycleStrategySupport;
> import org.apache.camel.support.ServiceSupport;
> import org.apache.camel.test.junit4.CamelTestSupport;
> import org.junit.Test;
> import java.util.Map;
> import static com.google.common.base.Preconditions.checkNotNull;
> /**
> * Test memory behaviour of producers using {@link ServicePoolAware} when
> using JMX.
> */
> public class ServicePoolAwareLeakyTest extends CamelTestSupport {
> private static final String LEAKY_SIEVE_STABLE =
> "leaky://sieve-stable?plugged=true";
> private static final String
[jira] [Commented] (CAMEL-9070) java.lang.IllegalStateException: SENDING => HEADERS
[
https://issues.apache.org/jira/browse/CAMEL-9070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14791694#comment-14791694
]
Claus Ibsen commented on CAMEL-9070:
Have you tried outside Karaf in plain standalone JVM and also upgraded to a
newer Jetty version?
Also there is some options to configure buffer sizes of headers / body for
jetty.
> java.lang.IllegalStateException: SENDING => HEADERS
> ---
>
> Key: CAMEL-9070
> URL: https://issues.apache.org/jira/browse/CAMEL-9070
> Project: Camel
> Issue Type: Bug
> Components: camel-jetty
>Affects Versions: 2.15.2
> Environment: Karaf 3.0.3
>Reporter: Ralf Steppacher
>
> When using the jetty component in a simple reverse proxy route deployed in
> {{Karaf 3.0.3}} I randomly receive the following Stacktrace:
> {noformat}
> 2015-08-14 10:44:15,931 | WARN | (0x64868d0a)-184 | HttpExchange
> | 117 - org.eclipse.jetty.aggregate.jetty-all-server -
> 8.1.15.v20140411 | | EXCEPTION
> ContentExchange@22d1b2c3=POST//ibb9931:8081/XDS3/repository/repo2#SENDING(1ms)->EXCEPTED(0ms)sent=388ms
> org.apache.camel.CamelExchangeException: JettyClient failed cause by: SENDING
> => HEADERS. Exchange[HttpMessage@0x4b022edc]. Caused by:
> [java.lang.IllegalStateException - SENDING => HEADERS]
> at
> org.apache.camel.component.jetty8.JettyContentExchange8.doTaskCompleted(JettyContentExchange8.java:210)[150:org.apache.camel.camel-jetty8:2.15.2]
> at
> org.apache.camel.component.jetty8.JettyContentExchange8.onException(JettyContentExchange8.java:138)[150:org.apache.camel.camel-jetty8:2.15.2]
> at
> org.apache.camel.component.jetty8.JettyContentExchange8$1.onException(JettyContentExchange8.java:98)[150:org.apache.camel.camel-jetty8:2.15.2]
> at
> org.eclipse.jetty.client.AsyncHttpConnection.handle(AsyncHttpConnection.java:168)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
> at
> org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:696)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
> at
> org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:53)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
> at java.lang.Thread.run(Thread.java:745)[:1.7.0_60]
> Caused by: java.lang.IllegalStateException: SENDING => HEADERS
> at
> org.eclipse.jetty.client.HttpExchange.setStatus(HttpExchange.java:370)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
> at
> org.eclipse.jetty.client.AbstractHttpConnection$Handler.startResponse(AbstractHttpConnection.java:297)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
> at
> org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:489)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
> at
> org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
> at
> org.eclipse.jetty.client.AsyncHttpConnection.handle(AsyncHttpConnection.java:135)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
> ... 5 more
> {noformat}
> I have found (rather old) posts on the web that claim that the behavior is
> related to message size. I am {{POST}}-ing about 6kb of SOAP XML with the
> following headers:
> {noformat}
> POST http://localhost:8080/XDS3/repository/repo2 HTTP/1.1
> Accept-Encoding: gzip,deflate
> Content-Type: multipart/related; type="application/xop+xml";
> start=""; start-info="application/soap+xml";
> action="urn:ihe:iti:2007:RetrieveDocumentSet";
> boundary="=_Part_139_1471895036.1439218177147"
> MIME-Version: 1.0
> Content-Length: 6858
> Host: localhost:8080
> Connection: Keep-Alive
> User-Agent: Apache-HttpClient/4.1.1 (java 1.5)
> {noformat}
> The issue pops up at random but not evenly distributed. It either almost
> always happens or hardly ever. Re-installing my bundle or restarting Karaf
> usually triggers a switch between the two scenarios on some machines. On
> others the error is persistent.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CAMEL-9143) Producers that implement the ServicePoolAware interface cause memory leak due to JMX references
[
https://issues.apache.org/jira/browse/CAMEL-9143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen reassigned CAMEL-9143:
--
Assignee: Claus Ibsen
> Producers that implement the ServicePoolAware interface cause memory leak due
> to JMX references
> ---
>
> Key: CAMEL-9143
> URL: https://issues.apache.org/jira/browse/CAMEL-9143
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.14.1, 2.14.2, 2.15.0, 2.15.1
>Reporter: Bob Browning
>Assignee: Claus Ibsen
> Fix For: 2.16.0, 2.15.4
>
>
> h4. Description
> Producer instances that implement the ServicePoolAware interface will leak
> memory if their route is stopped, with new producers being leaked every time
> the route is started/stopped.
> Known implementations that are affected are RemoteFileProducer (ftp, sftp)
> and Mina2Producer.
> This is due to the behaviour that the SendProcessor which when the route is
> stopped it shuts down it's `producerCache` instance.
> {code}
> protected void doStop() throws Exception {
> ServiceHelper.stopServices(producerCache, producer);
> }
> {code}
> this in turn calls `stopAndShutdownService(pool)` which will call stop on the
> SharedProducerServicePool instance which is a NOOP however it also calls
> shutdown which effects a stop of the global pool (this stops all the
> registered services and then clears the pool.
> {code}
> protected void doStop() throws Exception {
> // when stopping we intend to shutdown
> ServiceHelper.stopAndShutdownService(pool);
> try {
> ServiceHelper.stopAndShutdownServices(producers.values());
> } finally {
> // ensure producers are removed, and also from JMX
> for (Producer producer : producers.values()) {
> getCamelContext().removeService(producer);
> }
> }
> producers.clear();
> }
> {code}
> However no call to `context.removeService(Producer) is called for the entries
> from the pool only those singleton instances that were in the `producers` map
> hence the JMX `ManagedProducer` that is created when `doGetProducer` invokes
> {code}getCamelContext().addService(answer, false);
> {code} is never removed.
> Since the global pool is empty when the next request to get a producer is
> called a new producer is created, jmx wrapper and all, whilst the old
> instance remains orphaned retaining any objects that pertain to that instance.
> One workaround is for the producer to call
> {code}getEndpoint().getCamelContext().removeService(this){code} in it's stop
> method, however this is fairly obscure and it would probably be better to
> invoke removal of the producer when it is removed from the shared pool.
> Another issue of note is that when a route is shutdown that contains a
> SendProcessor due to the shutdown invocation on the
> SharedProcessorServicePool the global pool is cleared of `everything` and
> remains in `Stopped` state until another route starts it (although it is
> still accessed and used whilst in the `Stopped` state).
> h4. Impact
> For general use where there is no dynamic creation or passivation of routes
> this issue should be minimal, however in our use case where the routes are
> not static, there is a certain amount of recreation of routes as customer
> endpoints change and there is a need to passivate idle routes this causes a
> considerable memory leak (via SFTP in particular).
> h4. Test Case
> {code}
> package org.apache.camel.component;
> import com.google.common.util.concurrent.AtomicLongMap;
> import org.apache.camel.CamelContext;
> import org.apache.camel.Consumer;
> import org.apache.camel.Endpoint;
> import org.apache.camel.Exchange;
> import org.apache.camel.Processor;
> import org.apache.camel.Producer;
> import org.apache.camel.Route;
> import org.apache.camel.Service;
> import org.apache.camel.ServicePoolAware;
> import org.apache.camel.ServiceStatus;
> import org.apache.camel.builder.RouteBuilder;
> import org.apache.camel.impl.DefaultComponent;
> import org.apache.camel.impl.DefaultEndpoint;
> import org.apache.camel.impl.DefaultProducer;
> import org.apache.camel.support.LifecycleStrategySupport;
> import org.apache.camel.support.ServiceSupport;
> import org.apache.camel.test.junit4.CamelTestSupport;
> import org.junit.Test;
> import java.util.Map;
> import static com.google.common.base.Preconditions.checkNotNull;
> /**
> * Test memory behaviour of producers using {@link ServicePoolAware} when
> using JMX.
> */
> public class ServicePoolAwareLeakyTest extends CamelTestSupport {
> private static final String LEAKY_SIEVE_STABLE =
> "leaky://sieve-stable?plugged=true";
> private static
[jira] [Commented] (CAMEL-9143) Producers that implement the ServicePoolAware interface cause memory leak due to JMX references
[
https://issues.apache.org/jira/browse/CAMEL-9143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14791767#comment-14791767
]
Claus Ibsen commented on CAMEL-9143:
Your endpoint should not be singleton, or the producer should override
isSingleton and return false.
> Producers that implement the ServicePoolAware interface cause memory leak due
> to JMX references
> ---
>
> Key: CAMEL-9143
> URL: https://issues.apache.org/jira/browse/CAMEL-9143
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.14.1, 2.14.2, 2.15.0, 2.15.1
>Reporter: Bob Browning
>Assignee: Claus Ibsen
> Fix For: 2.16.0, 2.15.4
>
>
> h4. Description
> Producer instances that implement the ServicePoolAware interface will leak
> memory if their route is stopped, with new producers being leaked every time
> the route is started/stopped.
> Known implementations that are affected are RemoteFileProducer (ftp, sftp)
> and Mina2Producer.
> This is due to the behaviour that the SendProcessor which when the route is
> stopped it shuts down it's `producerCache` instance.
> {code}
> protected void doStop() throws Exception {
> ServiceHelper.stopServices(producerCache, producer);
> }
> {code}
> this in turn calls `stopAndShutdownService(pool)` which will call stop on the
> SharedProducerServicePool instance which is a NOOP however it also calls
> shutdown which effects a stop of the global pool (this stops all the
> registered services and then clears the pool.
> {code}
> protected void doStop() throws Exception {
> // when stopping we intend to shutdown
> ServiceHelper.stopAndShutdownService(pool);
> try {
> ServiceHelper.stopAndShutdownServices(producers.values());
> } finally {
> // ensure producers are removed, and also from JMX
> for (Producer producer : producers.values()) {
> getCamelContext().removeService(producer);
> }
> }
> producers.clear();
> }
> {code}
> However no call to `context.removeService(Producer) is called for the entries
> from the pool only those singleton instances that were in the `producers` map
> hence the JMX `ManagedProducer` that is created when `doGetProducer` invokes
> {code}getCamelContext().addService(answer, false);
> {code} is never removed.
> Since the global pool is empty when the next request to get a producer is
> called a new producer is created, jmx wrapper and all, whilst the old
> instance remains orphaned retaining any objects that pertain to that instance.
> One workaround is for the producer to call
> {code}getEndpoint().getCamelContext().removeService(this){code} in it's stop
> method, however this is fairly obscure and it would probably be better to
> invoke removal of the producer when it is removed from the shared pool.
> Another issue of note is that when a route is shutdown that contains a
> SendProcessor due to the shutdown invocation on the
> SharedProcessorServicePool the global pool is cleared of `everything` and
> remains in `Stopped` state until another route starts it (although it is
> still accessed and used whilst in the `Stopped` state).
> h4. Impact
> For general use where there is no dynamic creation or passivation of routes
> this issue should be minimal, however in our use case where the routes are
> not static, there is a certain amount of recreation of routes as customer
> endpoints change and there is a need to passivate idle routes this causes a
> considerable memory leak (via SFTP in particular).
> h4. Test Case
> {code}
> package org.apache.camel.component;
> import com.google.common.util.concurrent.AtomicLongMap;
> import org.apache.camel.CamelContext;
> import org.apache.camel.Consumer;
> import org.apache.camel.Endpoint;
> import org.apache.camel.Exchange;
> import org.apache.camel.Processor;
> import org.apache.camel.Producer;
> import org.apache.camel.Route;
> import org.apache.camel.Service;
> import org.apache.camel.ServicePoolAware;
> import org.apache.camel.ServiceStatus;
> import org.apache.camel.builder.RouteBuilder;
> import org.apache.camel.impl.DefaultComponent;
> import org.apache.camel.impl.DefaultEndpoint;
> import org.apache.camel.impl.DefaultProducer;
> import org.apache.camel.support.LifecycleStrategySupport;
> import org.apache.camel.support.ServiceSupport;
> import org.apache.camel.test.junit4.CamelTestSupport;
> import org.junit.Test;
> import java.util.Map;
> import static com.google.common.base.Preconditions.checkNotNull;
> /**
> * Test memory behaviour of producers using {@link ServicePoolAware} when
> using JMX.
> */
> public class ServicePoolAwareLeakyTest extends CamelTestSupport {
>
[jira] [Commented] (CAMEL-9143) Producers that implement the ServicePoolAware interface cause memory leak due to JMX references
[
https://issues.apache.org/jira/browse/CAMEL-9143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14791797#comment-14791797
]
Claus Ibsen commented on CAMEL-9143:
Though singleton endpoints/producer is possible with servicepoolaware also
though its not so common.
I got a fix and with the test case there is no mbean leaks anymore.
> Producers that implement the ServicePoolAware interface cause memory leak due
> to JMX references
> ---
>
> Key: CAMEL-9143
> URL: https://issues.apache.org/jira/browse/CAMEL-9143
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.14.1, 2.14.2, 2.15.0, 2.15.1
>Reporter: Bob Browning
>Assignee: Claus Ibsen
> Fix For: 2.16.0, 2.15.4
>
>
> h4. Description
> Producer instances that implement the ServicePoolAware interface will leak
> memory if their route is stopped, with new producers being leaked every time
> the route is started/stopped.
> Known implementations that are affected are RemoteFileProducer (ftp, sftp)
> and Mina2Producer.
> This is due to the behaviour that the SendProcessor which when the route is
> stopped it shuts down it's `producerCache` instance.
> {code}
> protected void doStop() throws Exception {
> ServiceHelper.stopServices(producerCache, producer);
> }
> {code}
> this in turn calls `stopAndShutdownService(pool)` which will call stop on the
> SharedProducerServicePool instance which is a NOOP however it also calls
> shutdown which effects a stop of the global pool (this stops all the
> registered services and then clears the pool.
> {code}
> protected void doStop() throws Exception {
> // when stopping we intend to shutdown
> ServiceHelper.stopAndShutdownService(pool);
> try {
> ServiceHelper.stopAndShutdownServices(producers.values());
> } finally {
> // ensure producers are removed, and also from JMX
> for (Producer producer : producers.values()) {
> getCamelContext().removeService(producer);
> }
> }
> producers.clear();
> }
> {code}
> However no call to `context.removeService(Producer) is called for the entries
> from the pool only those singleton instances that were in the `producers` map
> hence the JMX `ManagedProducer` that is created when `doGetProducer` invokes
> {code}getCamelContext().addService(answer, false);
> {code} is never removed.
> Since the global pool is empty when the next request to get a producer is
> called a new producer is created, jmx wrapper and all, whilst the old
> instance remains orphaned retaining any objects that pertain to that instance.
> One workaround is for the producer to call
> {code}getEndpoint().getCamelContext().removeService(this){code} in it's stop
> method, however this is fairly obscure and it would probably be better to
> invoke removal of the producer when it is removed from the shared pool.
> Another issue of note is that when a route is shutdown that contains a
> SendProcessor due to the shutdown invocation on the
> SharedProcessorServicePool the global pool is cleared of `everything` and
> remains in `Stopped` state until another route starts it (although it is
> still accessed and used whilst in the `Stopped` state).
> h4. Impact
> For general use where there is no dynamic creation or passivation of routes
> this issue should be minimal, however in our use case where the routes are
> not static, there is a certain amount of recreation of routes as customer
> endpoints change and there is a need to passivate idle routes this causes a
> considerable memory leak (via SFTP in particular).
> h4. Test Case
> {code}
> package org.apache.camel.component;
> import com.google.common.util.concurrent.AtomicLongMap;
> import org.apache.camel.CamelContext;
> import org.apache.camel.Consumer;
> import org.apache.camel.Endpoint;
> import org.apache.camel.Exchange;
> import org.apache.camel.Processor;
> import org.apache.camel.Producer;
> import org.apache.camel.Route;
> import org.apache.camel.Service;
> import org.apache.camel.ServicePoolAware;
> import org.apache.camel.ServiceStatus;
> import org.apache.camel.builder.RouteBuilder;
> import org.apache.camel.impl.DefaultComponent;
> import org.apache.camel.impl.DefaultEndpoint;
> import org.apache.camel.impl.DefaultProducer;
> import org.apache.camel.support.LifecycleStrategySupport;
> import org.apache.camel.support.ServiceSupport;
> import org.apache.camel.test.junit4.CamelTestSupport;
> import org.junit.Test;
> import java.util.Map;
> import static com.google.common.base.Preconditions.checkNotNull;
> /**
> * Test memory behaviour of producers using {@link ServicePoolAware} when
> using JMX.
> */
>
[jira] [Commented] (CAMEL-9143) Producers that implement the ServicePoolAware interface cause memory leak due to JMX references
[
https://issues.apache.org/jira/browse/CAMEL-9143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14791806#comment-14791806
]
Bob Browning commented on CAMEL-9143:
-
Yes in the TC as the intent was to simulate RemoteFileXxx it should override
singleton as RemoteFileProducer does, but it still causes the leak.
Prospect of the fix sounds good, cheers :)
> Producers that implement the ServicePoolAware interface cause memory leak due
> to JMX references
> ---
>
> Key: CAMEL-9143
> URL: https://issues.apache.org/jira/browse/CAMEL-9143
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.14.1, 2.14.2, 2.15.0, 2.15.1
>Reporter: Bob Browning
>Assignee: Claus Ibsen
> Fix For: 2.16.0, 2.15.4
>
>
> h4. Description
> Producer instances that implement the ServicePoolAware interface will leak
> memory if their route is stopped, with new producers being leaked every time
> the route is started/stopped.
> Known implementations that are affected are RemoteFileProducer (ftp, sftp)
> and Mina2Producer.
> This is due to the behaviour that the SendProcessor which when the route is
> stopped it shuts down it's `producerCache` instance.
> {code}
> protected void doStop() throws Exception {
> ServiceHelper.stopServices(producerCache, producer);
> }
> {code}
> this in turn calls `stopAndShutdownService(pool)` which will call stop on the
> SharedProducerServicePool instance which is a NOOP however it also calls
> shutdown which effects a stop of the global pool (this stops all the
> registered services and then clears the pool.
> {code}
> protected void doStop() throws Exception {
> // when stopping we intend to shutdown
> ServiceHelper.stopAndShutdownService(pool);
> try {
> ServiceHelper.stopAndShutdownServices(producers.values());
> } finally {
> // ensure producers are removed, and also from JMX
> for (Producer producer : producers.values()) {
> getCamelContext().removeService(producer);
> }
> }
> producers.clear();
> }
> {code}
> However no call to `context.removeService(Producer) is called for the entries
> from the pool only those singleton instances that were in the `producers` map
> hence the JMX `ManagedProducer` that is created when `doGetProducer` invokes
> {code}getCamelContext().addService(answer, false);
> {code} is never removed.
> Since the global pool is empty when the next request to get a producer is
> called a new producer is created, jmx wrapper and all, whilst the old
> instance remains orphaned retaining any objects that pertain to that instance.
> One workaround is for the producer to call
> {code}getEndpoint().getCamelContext().removeService(this){code} in it's stop
> method, however this is fairly obscure and it would probably be better to
> invoke removal of the producer when it is removed from the shared pool.
> Another issue of note is that when a route is shutdown that contains a
> SendProcessor due to the shutdown invocation on the
> SharedProcessorServicePool the global pool is cleared of `everything` and
> remains in `Stopped` state until another route starts it (although it is
> still accessed and used whilst in the `Stopped` state).
> h4. Impact
> For general use where there is no dynamic creation or passivation of routes
> this issue should be minimal, however in our use case where the routes are
> not static, there is a certain amount of recreation of routes as customer
> endpoints change and there is a need to passivate idle routes this causes a
> considerable memory leak (via SFTP in particular).
> h4. Test Case
> {code}
> package org.apache.camel.component;
> import com.google.common.util.concurrent.AtomicLongMap;
> import org.apache.camel.CamelContext;
> import org.apache.camel.Consumer;
> import org.apache.camel.Endpoint;
> import org.apache.camel.Exchange;
> import org.apache.camel.Processor;
> import org.apache.camel.Producer;
> import org.apache.camel.Route;
> import org.apache.camel.Service;
> import org.apache.camel.ServicePoolAware;
> import org.apache.camel.ServiceStatus;
> import org.apache.camel.builder.RouteBuilder;
> import org.apache.camel.impl.DefaultComponent;
> import org.apache.camel.impl.DefaultEndpoint;
> import org.apache.camel.impl.DefaultProducer;
> import org.apache.camel.support.LifecycleStrategySupport;
> import org.apache.camel.support.ServiceSupport;
> import org.apache.camel.test.junit4.CamelTestSupport;
> import org.junit.Test;
> import java.util.Map;
> import static com.google.common.base.Preconditions.checkNotNull;
> /**
> * Test memory behaviour of producers using {@link ServicePoolAware} when
[jira] [Created] (CAMEL-9144) Regression with camel-jackson 2.15.3
Arnaud Deprez created CAMEL-9144:
Summary: 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
Hi folks,
Apparently we found a regression with camel and camel-jackson in version 2.15.3.
The following code :
{quote}
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");
{quote}
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 com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:68)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:140)
Caused by: java.lang.IllegalArgumentException: JSon DataFormat json-jackson not
found.
at
org.apache.camel.model.rest.RestBindingDefinition.createProcessor(RestBindingDefinition.java:114)
at
org.apache.camel.model.ProcessorDefinition.makeProcessor(ProcessorDefinition.java:505)
at
[jira] [Resolved] (CAMEL-9143) Producers that implement the ServicePoolAware interface cause memory leak due to JMX references
[
https://issues.apache.org/jira/browse/CAMEL-9143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-9143.
Resolution: Fixed
Fix Version/s: 2.14.4
> Producers that implement the ServicePoolAware interface cause memory leak due
> to JMX references
> ---
>
> Key: CAMEL-9143
> URL: https://issues.apache.org/jira/browse/CAMEL-9143
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.14.1, 2.14.2, 2.15.0, 2.15.1
>Reporter: Bob Browning
>Assignee: Claus Ibsen
> Fix For: 2.16.0, 2.14.4, 2.15.4
>
>
> h4. Description
> Producer instances that implement the ServicePoolAware interface will leak
> memory if their route is stopped, with new producers being leaked every time
> the route is started/stopped.
> Known implementations that are affected are RemoteFileProducer (ftp, sftp)
> and Mina2Producer.
> This is due to the behaviour that the SendProcessor which when the route is
> stopped it shuts down it's `producerCache` instance.
> {code}
> protected void doStop() throws Exception {
> ServiceHelper.stopServices(producerCache, producer);
> }
> {code}
> this in turn calls `stopAndShutdownService(pool)` which will call stop on the
> SharedProducerServicePool instance which is a NOOP however it also calls
> shutdown which effects a stop of the global pool (this stops all the
> registered services and then clears the pool.
> {code}
> protected void doStop() throws Exception {
> // when stopping we intend to shutdown
> ServiceHelper.stopAndShutdownService(pool);
> try {
> ServiceHelper.stopAndShutdownServices(producers.values());
> } finally {
> // ensure producers are removed, and also from JMX
> for (Producer producer : producers.values()) {
> getCamelContext().removeService(producer);
> }
> }
> producers.clear();
> }
> {code}
> However no call to `context.removeService(Producer) is called for the entries
> from the pool only those singleton instances that were in the `producers` map
> hence the JMX `ManagedProducer` that is created when `doGetProducer` invokes
> {code}getCamelContext().addService(answer, false);
> {code} is never removed.
> Since the global pool is empty when the next request to get a producer is
> called a new producer is created, jmx wrapper and all, whilst the old
> instance remains orphaned retaining any objects that pertain to that instance.
> One workaround is for the producer to call
> {code}getEndpoint().getCamelContext().removeService(this){code} in it's stop
> method, however this is fairly obscure and it would probably be better to
> invoke removal of the producer when it is removed from the shared pool.
> Another issue of note is that when a route is shutdown that contains a
> SendProcessor due to the shutdown invocation on the
> SharedProcessorServicePool the global pool is cleared of `everything` and
> remains in `Stopped` state until another route starts it (although it is
> still accessed and used whilst in the `Stopped` state).
> h4. Impact
> For general use where there is no dynamic creation or passivation of routes
> this issue should be minimal, however in our use case where the routes are
> not static, there is a certain amount of recreation of routes as customer
> endpoints change and there is a need to passivate idle routes this causes a
> considerable memory leak (via SFTP in particular).
> h4. Test Case
> {code}
> package org.apache.camel.component;
> import com.google.common.util.concurrent.AtomicLongMap;
> import org.apache.camel.CamelContext;
> import org.apache.camel.Consumer;
> import org.apache.camel.Endpoint;
> import org.apache.camel.Exchange;
> import org.apache.camel.Processor;
> import org.apache.camel.Producer;
> import org.apache.camel.Route;
> import org.apache.camel.Service;
> import org.apache.camel.ServicePoolAware;
> import org.apache.camel.ServiceStatus;
> import org.apache.camel.builder.RouteBuilder;
> import org.apache.camel.impl.DefaultComponent;
> import org.apache.camel.impl.DefaultEndpoint;
> import org.apache.camel.impl.DefaultProducer;
> import org.apache.camel.support.LifecycleStrategySupport;
> import org.apache.camel.support.ServiceSupport;
> import org.apache.camel.test.junit4.CamelTestSupport;
> import org.junit.Test;
> import java.util.Map;
> import static com.google.common.base.Preconditions.checkNotNull;
> /**
> * Test memory behaviour of producers using {@link ServicePoolAware} when
> using JMX.
> */
> public class ServicePoolAwareLeakyTest extends CamelTestSupport {
> private static final String LEAKY_SIEVE_STABLE =
>
[jira] [Commented] (CAMEL-9137) RestBindingDefinition should allow to set Include("NON_NULL") for JsonDataFormat
[
https://issues.apache.org/jira/browse/CAMEL-9137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14802691#comment-14802691
]
Claus Ibsen commented on CAMEL-9137:
There is an include option on the data format you should be able to set to
NOT_NULL.
> RestBindingDefinition should allow to set Include("NON_NULL") for
> JsonDataFormat
>
>
> Key: CAMEL-9137
> URL: https://issues.apache.org/jira/browse/CAMEL-9137
> Project: Camel
> Issue Type: New Feature
> Components: camel-core
>Reporter: Vaclav Chalupa
>
> There is option to set properties from Jackson classes:
> - com.fasterxml.jackson.databind.SerializationFeature
> - com.fasterxml.jackson.databind.DeserializationFeature
> - com.fasterxml.jackson.databind.MapperFeature
> but it is not possible to set JsonInclude.Include.NON_NULL to return only
> non-null json properties.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-9137) RestBindingDefinition should allow to set Include("NON_NULL") for JsonDataFormat
[
https://issues.apache.org/jira/browse/CAMEL-9137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14802788#comment-14802788
]
Vaclav Chalupa commented on CAMEL-9137:
---
You're right, thanks.
> RestBindingDefinition should allow to set Include("NON_NULL") for
> JsonDataFormat
>
>
> Key: CAMEL-9137
> URL: https://issues.apache.org/jira/browse/CAMEL-9137
> Project: Camel
> Issue Type: New Feature
> Components: camel-core
>Reporter: Vaclav Chalupa
>Assignee: Claus Ibsen
>
> There is option to set properties from Jackson classes:
> - com.fasterxml.jackson.databind.SerializationFeature
> - com.fasterxml.jackson.databind.DeserializationFeature
> - com.fasterxml.jackson.databind.MapperFeature
> but it is not possible to set JsonInclude.Include.NON_NULL to return only
> non-null json properties.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-9137) RestBindingDefinition should allow to set Include("NON_NULL") for JsonDataFormat
[
https://issues.apache.org/jira/browse/CAMEL-9137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14802758#comment-14802758
]
Claus Ibsen commented on CAMEL-9137:
Use the dataFormatProperty to configure it
http://camel.apache.org/rest-dsl
> RestBindingDefinition should allow to set Include("NON_NULL") for
> JsonDataFormat
>
>
> Key: CAMEL-9137
> URL: https://issues.apache.org/jira/browse/CAMEL-9137
> Project: Camel
> Issue Type: New Feature
> Components: camel-core
>Reporter: Vaclav Chalupa
>Assignee: Claus Ibsen
>
> There is option to set properties from Jackson classes:
> - com.fasterxml.jackson.databind.SerializationFeature
> - com.fasterxml.jackson.databind.DeserializationFeature
> - com.fasterxml.jackson.databind.MapperFeature
> but it is not possible to set JsonInclude.Include.NON_NULL to return only
> non-null json properties.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-9137) RestBindingDefinition should allow to set Include("NON_NULL") for JsonDataFormat
[
https://issues.apache.org/jira/browse/CAMEL-9137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14802755#comment-14802755
]
Vaclav Chalupa commented on CAMEL-9137:
---
[~davsclaus] Yes, there is the NOT_NULL option, but I do not see any way how
can I obtain the data format used by {{RestBindingDefinition}}.
You have only option {{jsonDataFormat}} name, and then the selected data format
will be created in {{RestBindingDefinition}} for in / out binding:
{code}
117: // this will create a new instance as the name was not already pre-created
118: DataFormat jaxb = context.resolveDataFormat(name);
119: DataFormat outJaxb = context.resolveDataFormat(name);
{code}
So it looks like there is no way how to set the NOT_NULL include option. If I
am right, this issue should not be market as resolved yet.
> RestBindingDefinition should allow to set Include("NON_NULL") for
> JsonDataFormat
>
>
> Key: CAMEL-9137
> URL: https://issues.apache.org/jira/browse/CAMEL-9137
> Project: Camel
> Issue Type: New Feature
> Components: camel-core
>Reporter: Vaclav Chalupa
>Assignee: Claus Ibsen
>
> There is option to set properties from Jackson classes:
> - com.fasterxml.jackson.databind.SerializationFeature
> - com.fasterxml.jackson.databind.DeserializationFeature
> - com.fasterxml.jackson.databind.MapperFeature
> but it is not possible to set JsonInclude.Include.NON_NULL to return only
> non-null json properties.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-9144) Regression with camel-jackson 2.15.3
[
https://issues.apache.org/jira/browse/CAMEL-9144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arnaud Deprez updated CAMEL-9144:
-
Description:
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 com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:68)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:140)
Caused by: java.lang.IllegalArgumentException: JSon DataFormat json-jackson not
found.
at
org.apache.camel.model.rest.RestBindingDefinition.createProcessor(RestBindingDefinition.java:114)
at
org.apache.camel.model.ProcessorDefinition.makeProcessor(ProcessorDefinition.java:505)
at
org.apache.camel.model.ProcessorDefinition.addRoutes(ProcessorDefinition.java:217)
at
org.apache.camel.model.RouteDefinition.addRoutes(RouteDefinition.java:1025)
... 43 more
This exception doesn't occur in 2.15.2
was:
Hi folks,
[jira] [Resolved] (CAMEL-9134) New salesforce login JSON response field is_readonly causes NPE
[
https://issues.apache.org/jira/browse/CAMEL-9134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dhiraj Bokde resolved CAMEL-9134.
-
Resolution: Duplicate
Fix Version/s: 2.15.4
2.16.0
Fixed with PR from CAMEL-9141
> New salesforce login JSON response field is_readonly causes NPE
> ---
>
> Key: CAMEL-9134
> URL: https://issues.apache.org/jira/browse/CAMEL-9134
> Project: Camel
> Issue Type: Bug
> Components: camel-salesforce
>Affects Versions: 2.13.1
> Environment: Linux
>Reporter: Saul Karl
>Assignee: Dhiraj Bokde
> Fix For: 2.16.0, 2.15.4
>
>
> Recently the salesforce sandbox REST API login starts to return an additional
> JSON field "is_readonly" that causes NPE during a Salesforce login session:
> 2015-09-14 16:10:02,374 | INFO | HttpClient-46181 | SalesforceSession
> | 120 - org.apache.camel.camel-salesforce - 2.13.1 | Logging
> clientId: xxxyyyzzz into Salesforce url:
> https://test.salesforce.com/services/oauth2/token
> 2015-09-14 16:10:03,317 | ERROR | HttpClient-46181 |
> SalesforceSecurityListener | 120 - org.apache.camel.camel-salesforce -
> 2.13.1 | { statusCode: 0}
> { { statusCode: 0}, statusCode: 0}
> at
> org.apache.camel.component.salesforce.internal.SalesforceSession.login(SalesforceSession.java:191)[120:org.apache.camel.camel-salesforce:2.13.1]
> at
> org.apache.camel.component.salesforce.internal.client.SalesforceSecurityListener.checkExchangeComplete(SalesforceSecurityListener.java:95)[120:org.apache.camel.camel-salesforce:2.13.1]
> at
> org.apache.camel.component.salesforce.internal.client.SalesforceSecurityListener.onResponseComplete(SalesforceSecurityListener.java:78)[120:org.apache.camel.camel-salesforce:2.13.1]
> at
> org.eclipse.jetty.client.HttpEventListenerWrapper.onResponseComplete(HttpEventListenerWrapper.java:123)[85:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
> at
> org.apache.camel.component.salesforce.internal.client.AbstractClientBase$1.onResponseComplete(AbstractClientBase.java:147)[120:org.apache.camel.camel-salesforce:2.13.1]
> at
> org.eclipse.jetty.client.HttpEventListenerWrapper.onResponseComplete(HttpEventListenerWrapper.java:123)[85:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
> at
> org.eclipse.jetty.client.RedirectListener.onResponseComplete(RedirectListener.java:106)[85:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
> at
> org.eclipse.jetty.client.HttpExchange.setStatus(HttpExchange.java:305)[85:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
> at
> org.eclipse.jetty.client.AbstractHttpConnection$Handler.messageComplete(AbstractHttpConnection.java:340)[85:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
> at
> org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:904)[85:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
> at
> org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)[85:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
> at
> org.eclipse.jetty.client.AsyncHttpConnection.handle(AsyncHttpConnection.java:135)[85:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
> at
> org.eclipse.jetty.io.nio.SslConnection.handle(SslConnection.java:196)[85:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
> at
> org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:696)[85:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
> at
> org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:53)[85:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)[85:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)[85:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
> at java.lang.Thread.run(Thread.java:745)[:1.7.0_79]
> Caused by: org.codehaus.jackson.map.exc.UnrecognizedPropertyException:
> Unrecognized field "is_readonly" (Class
> org.apache.camel.component.salesforce.internal.dto.LoginToken), not marked as
> ignorable
> at [Source: [B@3113fe76; line: 1, column: 147] (through reference chain:
> org.apache.camel.component.salesforce.internal.dto.LoginToken["is_readonly"])
> at
> org.codehaus.jackson.map.exc.UnrecognizedPropertyException.from(UnrecognizedPropertyException.java:53)
> at
>
