[jira] [Commented] (CAMEL-10238) Camel-salesforce component never tries to reconnect after a disconnect
[
https://issues.apache.org/jira/browse/CAMEL-10238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15448143#comment-15448143
]
Dhiraj Bokde commented on CAMEL-10238:
--
[~rajesh734], I've pushed changes to handle failed CometD handshake to master
and camel-2.17.x. Let me know whether this fixes your problem.
> Camel-salesforce component never tries to reconnect after a disconnect
> --
>
> Key: CAMEL-10238
> URL: https://issues.apache.org/jira/browse/CAMEL-10238
> Project: Camel
> Issue Type: Bug
> Components: camel-salesforce
>Affects Versions: 2.17.2, 2.17.3, 2.18.0
>Reporter: Rajesh A
>Assignee: Dhiraj Bokde
> Attachments: streaming-api-validation-jetty-debug.log
>
>
> My connection to salesforce-streaming api gets disconnect automatically after
> 2 hours. This is because salesforce automatically disconnects the connection
> from server side. However, I was expecting camel-salesforce component to
> reconnect automatically after disconnect. But, it does not reconnect and I do
> not have a hold or a way to reconnect. Seems to be a defect and a blocker to
> me.
> Here is the trace log
> {code}
> [36mo.a.c.c.s.i.s.SubscriptionHelper[0;39m [2m:[0;39m
> [CHANNEL:META_CONNECT]: {clientId=3u9riwg6ag3r5dd3ay86i444f,
> channel=/meta/connect, id=84, successful=true}
> [36morg.cometd.client.BayeuxClient [0;39m [2m:[0;39m Connecting,
> transport
> org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper$3@4e0cc334
> [36morg.cometd.client.BayeuxClient [0;39m [2m:[0;39m Sending
> messages [{clientId=3u9riwg6ag3r5dd3ay86i444f, channel=/meta/connect, id=85,
> connectionType=long-polling}]
> [36mo.a.c.c.s.i.s.SubscriptionHelper$3 [0;39m [2m:[0;39m Received
> messages [{clientId=3u9riwg6ag3r5dd3ay86i444f, channel=/meta/connect, id=85,
> successful=true}]
> [36morg.cometd.client.BayeuxClient [0;39m [2m:[0;39m Processing
> /meta/connect {clientId=3u9riwg6ag3r5dd3ay86i444f, channel=/meta/connect,
> id=85, successful=true}
> [36morg.cometd.client.BayeuxClient [0;39m [2m:[0;39m State update:
> CONNECTED -> CONNECTED
> [36mo.a.c.c.s.i.s.SubscriptionHelper[0;39m [2m:[0;39m
> [CHANNEL:META_CONNECT]: {clientId=3u9riwg6ag3r5dd3ay86i444f,
> channel=/meta/connect, id=85, successful=true}
> [36morg.cometd.client.BayeuxClient [0;39m [2m:[0;39m Connecting,
> transport
> org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper$3@4e0cc334
> [36morg.cometd.client.BayeuxClient [0;39m [2m:[0;39m Sending
> messages [{clientId=3u9riwg6ag3r5dd3ay86i444f, channel=/meta/connect, id=86,
> connectionType=long-polling}]
> [36morg.cometd.client.BayeuxClient [0;39m [2m:[0;39m State update:
> CONNECTED -> UNCONNECTED
> [36morg.cometd.client.BayeuxClient [0;39m [2m:[0;39m Messages failed
> [{clientId=3u9riwg6ag3r5dd3ay86i444f, channel=/meta/connect, id=86,
> connectionType=long-polling}]
> java.io.EOFException: HttpConnectionOverHTTP@12f0e719(l:/10.172.131.200:50574
> <->
> r:my-proxy.com/x.x.x.x:xx,closed=false)[HttpChannelOverHTTP@2a4927(exchange=HttpExchange@6ae1ae35
> req=TERMINATED/null@null
> res=PENDING/null@null)[send=HttpSenderOverHTTP@51fea1e0(req=QUEUED,snd=COMPLETED,failure=null)[HttpGenerator{s=START}],recv=HttpReceiverOverHTTP@44234ce9(rsp=IDLE,failure=null)[HttpParser{s=CLOSED,0
> of -1}]]]
> at
> org.eclipse.jetty.client.http.HttpReceiverOverHTTP.earlyEOF(HttpReceiverOverHTTP.java:277)
> [jetty-client-9.2.14.v20151106.jar:9.2.14.v20151106]
> at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:1309)
> [jetty-http-9.2.14.v20151106.jar:9.2.14.v20151106]
> at
> org.eclipse.jetty.client.http.HttpReceiverOverHTTP.shutdown(HttpReceiverOverHTTP.java:182)
> [jetty-client-9.2.14.v20151106.jar:9.2.14.v20151106]
> at
> org.eclipse.jetty.client.http.HttpReceiverOverHTTP.process(HttpReceiverOverHTTP.java:129)
> [jetty-client-9.2.14.v20151106.jar:9.2.14.v20151106]
> at
> org.eclipse.jetty.client.http.HttpReceiverOverHTTP.receive(HttpReceiverOverHTTP.java:69)
> [jetty-client-9.2.14.v20151106.jar:9.2.14.v20151106]
> at
> org.eclipse.jetty.client.http.HttpChannelOverHTTP.receive(HttpChannelOverHTTP.java:89)
> [jetty-client-9.2.14.v20151106.jar:9.2.14.v20151106]
> at
> org.eclipse.jetty.client.http.HttpConnectionOverHTTP.onFillable(HttpConnectionOverHTTP.java:122)
> [jetty-client-9.2.14.v20151106.jar:9.2.14.v20151106]
> at
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:544)
> [jetty-io-9.2.14.v20151106.jar:9.2.14.v20151106]
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
>
[jira] [Commented] (CAMEL-10224) Upgrade log4j to lg4j2
[
https://issues.apache.org/jira/browse/CAMEL-10224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15448050#comment-15448050
]
Luca Burgazzoli commented on CAMEL-10224:
-
Camel uses slf4j for its logging abstraction then, libraries used by camel may
directly use log4j 1.2 apis.
Running camel-hbase tests without log4j-over-slf4j reports the following error:
{code}
java.lang.NoClassDefFoundError: org/apache/log4j/AppenderSkeleton
Caused by: java.lang.ClassNotFoundException: org.apache.log4j.AppenderSkeleton
{code}
Then how/where is out of our control.
> Upgrade log4j to lg4j2
> --
>
> Key: CAMEL-10224
> URL: https://issues.apache.org/jira/browse/CAMEL-10224
> Project: Camel
> Issue Type: Task
>Reporter: Luca Burgazzoli
>Assignee: Luca Burgazzoli
> Fix For: 2.18.0
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-10241) MockEndpointAndSkip and DirtiesContext not working
[
https://issues.apache.org/jira/browse/CAMEL-10241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15447363#comment-15447363
]
Minh Tran commented on CAMEL-10241:
---
I've found a workaround for the mean time
I removed the @MockendpointAndSkip and added @UseAdviceWith
then modified/added the following beforeTest function
{noformat}
@Configuration
@EnableAutoConfiguration
public static class Config extends SpringRouteBuilder {
@Override
public void configure() throws Exception {
from("direct:a").routeId("a").to("direct:b");
from("direct:b").routeId("b").to("mock:end");
}
}
@Before
public void beforeTest() throws Exception {
context.getRouteDefinition("a").adviceWith(context, new
AdviceWithRouteBuilder() {
@Override
public void configure() throws Exception {
mockEndpointsAndSkip("direct:b");
}
});
context.start();
}
{noformat}
Not as convenient but at least now I can test properly in Spring Boot and have
the ability to mock and skip end points
> MockEndpointAndSkip and DirtiesContext not working
> --
>
> Key: CAMEL-10241
> URL: https://issues.apache.org/jira/browse/CAMEL-10241
> Project: Camel
> Issue Type: Bug
> Components: camel-test
>Affects Versions: 2.17.3
> Environment: java8
> spring boot 1.3.6
>Reporter: Minh Tran
>Priority: Minor
>
> MockEndpointAndSkip does not seem to get re-applied after each test when used
> in conjunction with DirtiesContext. Here is a unit test exhibiting the problem
> {noformat}
> @RunWith(CamelSpringBootJUnit4ClassRunner.class)
> @SpringApplicationConfiguration
> @MockEndpointsAndSkip("direct:b")
> @DirtiesContext(classMode = ClassMode.AFTER_EACH_TEST_METHOD)
> public class MockTest {
> @Produce(uri = "direct:a")
> private ProducerTemplate producer;
> @EndpointInject(uri = "mock:end")
> private MockEndpoint end;
> @EndpointInject(uri = "mock:direct:b")
> private MockEndpoint directB;
> @Autowired
> private CamelContext context;
> @Configuration
> @EnableAutoConfiguration
> public static class Config extends SpringRouteBuilder {
> @Override
> public void configure() throws Exception {
> from("direct:a").to("direct:b");
> from("direct:b").to("mock:end");
> }
> }
> @Test
> public void testMock() throws InterruptedException {
> end.expectedMessageCount(0);
> directB.expectedBodiesReceived("hello");
> producer.sendBody("hello");
> MockEndpoint.assertIsSatisfied(context);
> }
> @Test
> public void testMock2() throws InterruptedException {
> end.expectedMessageCount(0);
> directB.expectedBodiesReceived("hello");
> producer.sendBody("hello");
> MockEndpoint.assertIsSatisfied(context);
> }
> }
> {noformat}
> testMock and testMock2 are exactly the same and if run individually, they
> pass. However if you run both, the second one will always fail. Running them
> both inside eclipse and from maven command line exhibit the same behaviour.
> The error I get is
> {noformat}
> java.lang.AssertionError: mock://end Received message count. Expected: <0>
> but was: <1>
> {noformat}
> Which must mean that the skipping isn’t working. Here’s the tracer output to
> confirm
> {noformat}
> org.apache.camel.processor.interceptor.Tracer -
> ID-minhmac-local-51406-1470352938165-1-2 >>> (route3) from(direct://a) -->
> direct://b <<< Pattern:InOnly,
> Headers:{breadcrumbId=ID-minhmac-local-51406-1470352938165-1-1},
> BodyType:String, Body:hello
> org.apache.camel.processor.interceptor.Tracer -
> ID-minhmac-local-51406-1470352938165-1-2 >>> (route4) direct://b -->
> mock://end <<< Pattern:InOnly,
> Headers:{breadcrumbId=ID-minhmac-local-51406-1470352938165-1-1},
> BodyType:String, Body:hello
> {noformat}
> If you remove the DirtiesContext, then both tests passes. My suspicion is
> that there is a bug when re-applying the MockEndpointAndSkip when the spring
> context is being rebuilt between tests.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-10272) Aggregation is broken due to race condition in ParallelAggregateTask.doAggregateInternal()
[
https://issues.apache.org/jira/browse/CAMEL-10272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15446658#comment-15446658
]
Ushnash Shukla commented on CAMEL-10272:
I'll take a look at this.
> Aggregation is broken due to race condition in
> ParallelAggregateTask.doAggregateInternal()
> --
>
> Key: CAMEL-10272
> URL: https://issues.apache.org/jira/browse/CAMEL-10272
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.16.3, 2.17.3
>Reporter: Peter Keller
>Priority: Critical
>
> Unfortunately, I am not able to provide a (simple) unit test for
> comprehending the problem. Furthermore our (complex) unit tests are not
> determinist due to the root cause of the problem.
> However I tried to analyze the Camel Java code, to work out the problem.
> Please find below my findings.
> h3. Problem
> The {{oldExchange}} is {{null}} more than once in the aggregator if a
> recipient list is processed in parallel.
> h3. Camel route
> In my Camel route, a recipient list is worked of in parallel:
> {code}
> from("direct:start")
> .to("direct:pre")
> .recipientList().method(new MyRecipientListBuilder())
> .stopOnException()
> .aggregationStrategy(new MyAggregationStrategy())
> .parallelProcessing()
> .end()
> .bean(new MyPostProcessor());
> {code}
> Snippet of {{MyAggregationStrategy}}:
> {code}
> @Override
> @SuppressWarnings("unchecked")
> public Exchange aggregate(final Exchange oldExchange, final Exchange
> newExchange) {
> if (oldExchange == null) {
> // this is the case more than once which is not expected!
> }
> // ...
> {code}
> {{oldExchange}} is null more than once which is not expected and which
> contradicts the contract with Camel.
> h3. Analysis
> During the processing, Camel invokes {{MulticastProcessor.process()}}. Here
> the result object {{AtomicExchange}} is created which is shared during the
> whole processing.
> If the processing should be done in parallel (as it is the case for our
> route) then {{MulticastProcessor.doProcessParallel()}} is invoked. Here one
> instance of {{AggregateOnTheFlyTask}} is initialized and
> {{aggregateOnTheFly()}} is invoked *asynchronously* via {{run()}} for
> *every* target in the recipient list.
> In {{aggregateOnTheFly()}}, a new instance of {{ParallelAggregateTask}} is
> generated, and if aggregation is not done in parallel (as it is the case in
> our route), {{ParallelAggregateTask.run()}},
> {{ParallelAggregateTask.doAggregate()}} (this method is synchronized), and
> {{ParallelAggregateTask.doAggregateInternal()}} is invoked:
> {code}
> protected void doAggregateInternal(AggregationStrategy strategy,
> AtomicExchange result, Exchange exchange) {
> if (strategy != null) {
> // prepare the exchanges for aggregation
> Exchange oldExchange = result.get();
> ExchangeHelper.prepareAggregation(oldExchange, exchange);
> result.set(strategy.aggregate(oldExchange, exchange));
> }
> }
> {code}
> However, in {{ParallelAggregateTask.doAggregateInternal()}} there may occur a
> race condition as {{result}} is shared by every instance of
> {{AggregateOnTheFlyTask}} such that {{oldExchange = result.get()}}
> may be {{null}} more than once!
> Note: As a new instance of {{ParallelAggregateTask}} for every target in
> recipient list is created, the {{synchronized}} method
> {{ParallelAggregateTask.doAggregate()}} does not prevent the race condition!
> Does this sounds reasonably?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-10224) Upgrade log4j to lg4j2
[
https://issues.apache.org/jira/browse/CAMEL-10224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15446623#comment-15446623
]
Gary Gregory commented on CAMEL-10224:
--
Hi [~lb]:
Can you specify how you use {{AppenderSkeleton}} and other classes? We have a
little more 1.2 compatibility coming in the next version but not related to
{{AppenderSkeleton}}. The {{log4j-1.2-api}} is where we are keeping all 1.2
related code.
Thank you,
Gary
> Upgrade log4j to lg4j2
> --
>
> Key: CAMEL-10224
> URL: https://issues.apache.org/jira/browse/CAMEL-10224
> Project: Camel
> Issue Type: Task
>Reporter: Luca Burgazzoli
>Assignee: Luca Burgazzoli
> Fix For: 2.18.0
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CAMEL-10238) Camel-salesforce component never tries to reconnect after a disconnect
[
https://issues.apache.org/jira/browse/CAMEL-10238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15445664#comment-15445664
]
Rajesh A edited comment on CAMEL-10238 at 8/29/16 12:05 PM:
Dhiraj, still getting the same issue. I have attached the log here. This is for
version 2.18.0-SNAPSHOT
was (Author: rajesh734):
Dhiraj, still getting the same issue. I have attached the log here.
> Camel-salesforce component never tries to reconnect after a disconnect
> --
>
> Key: CAMEL-10238
> URL: https://issues.apache.org/jira/browse/CAMEL-10238
> Project: Camel
> Issue Type: Bug
> Components: camel-salesforce
>Affects Versions: 2.17.2, 2.17.3, 2.18.0
>Reporter: Rajesh A
>Assignee: Dhiraj Bokde
> Attachments: streaming-api-validation-jetty-debug.log
>
>
> My connection to salesforce-streaming api gets disconnect automatically after
> 2 hours. This is because salesforce automatically disconnects the connection
> from server side. However, I was expecting camel-salesforce component to
> reconnect automatically after disconnect. But, it does not reconnect and I do
> not have a hold or a way to reconnect. Seems to be a defect and a blocker to
> me.
> Here is the trace log
> {code}
> [36mo.a.c.c.s.i.s.SubscriptionHelper[0;39m [2m:[0;39m
> [CHANNEL:META_CONNECT]: {clientId=3u9riwg6ag3r5dd3ay86i444f,
> channel=/meta/connect, id=84, successful=true}
> [36morg.cometd.client.BayeuxClient [0;39m [2m:[0;39m Connecting,
> transport
> org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper$3@4e0cc334
> [36morg.cometd.client.BayeuxClient [0;39m [2m:[0;39m Sending
> messages [{clientId=3u9riwg6ag3r5dd3ay86i444f, channel=/meta/connect, id=85,
> connectionType=long-polling}]
> [36mo.a.c.c.s.i.s.SubscriptionHelper$3 [0;39m [2m:[0;39m Received
> messages [{clientId=3u9riwg6ag3r5dd3ay86i444f, channel=/meta/connect, id=85,
> successful=true}]
> [36morg.cometd.client.BayeuxClient [0;39m [2m:[0;39m Processing
> /meta/connect {clientId=3u9riwg6ag3r5dd3ay86i444f, channel=/meta/connect,
> id=85, successful=true}
> [36morg.cometd.client.BayeuxClient [0;39m [2m:[0;39m State update:
> CONNECTED -> CONNECTED
> [36mo.a.c.c.s.i.s.SubscriptionHelper[0;39m [2m:[0;39m
> [CHANNEL:META_CONNECT]: {clientId=3u9riwg6ag3r5dd3ay86i444f,
> channel=/meta/connect, id=85, successful=true}
> [36morg.cometd.client.BayeuxClient [0;39m [2m:[0;39m Connecting,
> transport
> org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper$3@4e0cc334
> [36morg.cometd.client.BayeuxClient [0;39m [2m:[0;39m Sending
> messages [{clientId=3u9riwg6ag3r5dd3ay86i444f, channel=/meta/connect, id=86,
> connectionType=long-polling}]
> [36morg.cometd.client.BayeuxClient [0;39m [2m:[0;39m State update:
> CONNECTED -> UNCONNECTED
> [36morg.cometd.client.BayeuxClient [0;39m [2m:[0;39m Messages failed
> [{clientId=3u9riwg6ag3r5dd3ay86i444f, channel=/meta/connect, id=86,
> connectionType=long-polling}]
> java.io.EOFException: HttpConnectionOverHTTP@12f0e719(l:/10.172.131.200:50574
> <->
> r:my-proxy.com/x.x.x.x:xx,closed=false)[HttpChannelOverHTTP@2a4927(exchange=HttpExchange@6ae1ae35
> req=TERMINATED/null@null
> res=PENDING/null@null)[send=HttpSenderOverHTTP@51fea1e0(req=QUEUED,snd=COMPLETED,failure=null)[HttpGenerator{s=START}],recv=HttpReceiverOverHTTP@44234ce9(rsp=IDLE,failure=null)[HttpParser{s=CLOSED,0
> of -1}]]]
> at
> org.eclipse.jetty.client.http.HttpReceiverOverHTTP.earlyEOF(HttpReceiverOverHTTP.java:277)
> [jetty-client-9.2.14.v20151106.jar:9.2.14.v20151106]
> at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:1309)
> [jetty-http-9.2.14.v20151106.jar:9.2.14.v20151106]
> at
> org.eclipse.jetty.client.http.HttpReceiverOverHTTP.shutdown(HttpReceiverOverHTTP.java:182)
> [jetty-client-9.2.14.v20151106.jar:9.2.14.v20151106]
> at
> org.eclipse.jetty.client.http.HttpReceiverOverHTTP.process(HttpReceiverOverHTTP.java:129)
> [jetty-client-9.2.14.v20151106.jar:9.2.14.v20151106]
> at
> org.eclipse.jetty.client.http.HttpReceiverOverHTTP.receive(HttpReceiverOverHTTP.java:69)
> [jetty-client-9.2.14.v20151106.jar:9.2.14.v20151106]
> at
> org.eclipse.jetty.client.http.HttpChannelOverHTTP.receive(HttpChannelOverHTTP.java:89)
> [jetty-client-9.2.14.v20151106.jar:9.2.14.v20151106]
> at
> org.eclipse.jetty.client.http.HttpConnectionOverHTTP.onFillable(HttpConnectionOverHTTP.java:122)
> [jetty-client-9.2.14.v20151106.jar:9.2.14.v20151106]
> at
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:544)
> [jetty-io-9.2.14.v20151106.jar:9.2.14.v20151106]
> at
>
[jira] [Updated] (CAMEL-10238) Camel-salesforce component never tries to reconnect after a disconnect
[
https://issues.apache.org/jira/browse/CAMEL-10238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rajesh A updated CAMEL-10238:
-
Attachment: streaming-api-validation-jetty-debug.log
> Camel-salesforce component never tries to reconnect after a disconnect
> --
>
> Key: CAMEL-10238
> URL: https://issues.apache.org/jira/browse/CAMEL-10238
> Project: Camel
> Issue Type: Bug
> Components: camel-salesforce
>Affects Versions: 2.17.2, 2.17.3, 2.18.0
>Reporter: Rajesh A
>Assignee: Dhiraj Bokde
> Attachments: streaming-api-validation-jetty-debug.log
>
>
> My connection to salesforce-streaming api gets disconnect automatically after
> 2 hours. This is because salesforce automatically disconnects the connection
> from server side. However, I was expecting camel-salesforce component to
> reconnect automatically after disconnect. But, it does not reconnect and I do
> not have a hold or a way to reconnect. Seems to be a defect and a blocker to
> me.
> Here is the trace log
> {code}
> [36mo.a.c.c.s.i.s.SubscriptionHelper[0;39m [2m:[0;39m
> [CHANNEL:META_CONNECT]: {clientId=3u9riwg6ag3r5dd3ay86i444f,
> channel=/meta/connect, id=84, successful=true}
> [36morg.cometd.client.BayeuxClient [0;39m [2m:[0;39m Connecting,
> transport
> org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper$3@4e0cc334
> [36morg.cometd.client.BayeuxClient [0;39m [2m:[0;39m Sending
> messages [{clientId=3u9riwg6ag3r5dd3ay86i444f, channel=/meta/connect, id=85,
> connectionType=long-polling}]
> [36mo.a.c.c.s.i.s.SubscriptionHelper$3 [0;39m [2m:[0;39m Received
> messages [{clientId=3u9riwg6ag3r5dd3ay86i444f, channel=/meta/connect, id=85,
> successful=true}]
> [36morg.cometd.client.BayeuxClient [0;39m [2m:[0;39m Processing
> /meta/connect {clientId=3u9riwg6ag3r5dd3ay86i444f, channel=/meta/connect,
> id=85, successful=true}
> [36morg.cometd.client.BayeuxClient [0;39m [2m:[0;39m State update:
> CONNECTED -> CONNECTED
> [36mo.a.c.c.s.i.s.SubscriptionHelper[0;39m [2m:[0;39m
> [CHANNEL:META_CONNECT]: {clientId=3u9riwg6ag3r5dd3ay86i444f,
> channel=/meta/connect, id=85, successful=true}
> [36morg.cometd.client.BayeuxClient [0;39m [2m:[0;39m Connecting,
> transport
> org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper$3@4e0cc334
> [36morg.cometd.client.BayeuxClient [0;39m [2m:[0;39m Sending
> messages [{clientId=3u9riwg6ag3r5dd3ay86i444f, channel=/meta/connect, id=86,
> connectionType=long-polling}]
> [36morg.cometd.client.BayeuxClient [0;39m [2m:[0;39m State update:
> CONNECTED -> UNCONNECTED
> [36morg.cometd.client.BayeuxClient [0;39m [2m:[0;39m Messages failed
> [{clientId=3u9riwg6ag3r5dd3ay86i444f, channel=/meta/connect, id=86,
> connectionType=long-polling}]
> java.io.EOFException: HttpConnectionOverHTTP@12f0e719(l:/10.172.131.200:50574
> <->
> r:my-proxy.com/x.x.x.x:xx,closed=false)[HttpChannelOverHTTP@2a4927(exchange=HttpExchange@6ae1ae35
> req=TERMINATED/null@null
> res=PENDING/null@null)[send=HttpSenderOverHTTP@51fea1e0(req=QUEUED,snd=COMPLETED,failure=null)[HttpGenerator{s=START}],recv=HttpReceiverOverHTTP@44234ce9(rsp=IDLE,failure=null)[HttpParser{s=CLOSED,0
> of -1}]]]
> at
> org.eclipse.jetty.client.http.HttpReceiverOverHTTP.earlyEOF(HttpReceiverOverHTTP.java:277)
> [jetty-client-9.2.14.v20151106.jar:9.2.14.v20151106]
> at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:1309)
> [jetty-http-9.2.14.v20151106.jar:9.2.14.v20151106]
> at
> org.eclipse.jetty.client.http.HttpReceiverOverHTTP.shutdown(HttpReceiverOverHTTP.java:182)
> [jetty-client-9.2.14.v20151106.jar:9.2.14.v20151106]
> at
> org.eclipse.jetty.client.http.HttpReceiverOverHTTP.process(HttpReceiverOverHTTP.java:129)
> [jetty-client-9.2.14.v20151106.jar:9.2.14.v20151106]
> at
> org.eclipse.jetty.client.http.HttpReceiverOverHTTP.receive(HttpReceiverOverHTTP.java:69)
> [jetty-client-9.2.14.v20151106.jar:9.2.14.v20151106]
> at
> org.eclipse.jetty.client.http.HttpChannelOverHTTP.receive(HttpChannelOverHTTP.java:89)
> [jetty-client-9.2.14.v20151106.jar:9.2.14.v20151106]
> at
> org.eclipse.jetty.client.http.HttpConnectionOverHTTP.onFillable(HttpConnectionOverHTTP.java:122)
> [jetty-client-9.2.14.v20151106.jar:9.2.14.v20151106]
> at
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:544)
> [jetty-io-9.2.14.v20151106.jar:9.2.14.v20151106]
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
> [jetty-util-9.2.14.v20151106.jar:9.2.14.v20151106]
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
>
[jira] [Commented] (CAMEL-10238) Camel-salesforce component never tries to reconnect after a disconnect
[
https://issues.apache.org/jira/browse/CAMEL-10238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15445664#comment-15445664
]
Rajesh A commented on CAMEL-10238:
--
Dhiraj, still getting the same issue. I have attached the log here.
> Camel-salesforce component never tries to reconnect after a disconnect
> --
>
> Key: CAMEL-10238
> URL: https://issues.apache.org/jira/browse/CAMEL-10238
> Project: Camel
> Issue Type: Bug
> Components: camel-salesforce
>Affects Versions: 2.17.2, 2.17.3, 2.18.0
>Reporter: Rajesh A
>Assignee: Dhiraj Bokde
> Attachments: streaming-api-validation-jetty-debug.log
>
>
> My connection to salesforce-streaming api gets disconnect automatically after
> 2 hours. This is because salesforce automatically disconnects the connection
> from server side. However, I was expecting camel-salesforce component to
> reconnect automatically after disconnect. But, it does not reconnect and I do
> not have a hold or a way to reconnect. Seems to be a defect and a blocker to
> me.
> Here is the trace log
> {code}
> [36mo.a.c.c.s.i.s.SubscriptionHelper[0;39m [2m:[0;39m
> [CHANNEL:META_CONNECT]: {clientId=3u9riwg6ag3r5dd3ay86i444f,
> channel=/meta/connect, id=84, successful=true}
> [36morg.cometd.client.BayeuxClient [0;39m [2m:[0;39m Connecting,
> transport
> org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper$3@4e0cc334
> [36morg.cometd.client.BayeuxClient [0;39m [2m:[0;39m Sending
> messages [{clientId=3u9riwg6ag3r5dd3ay86i444f, channel=/meta/connect, id=85,
> connectionType=long-polling}]
> [36mo.a.c.c.s.i.s.SubscriptionHelper$3 [0;39m [2m:[0;39m Received
> messages [{clientId=3u9riwg6ag3r5dd3ay86i444f, channel=/meta/connect, id=85,
> successful=true}]
> [36morg.cometd.client.BayeuxClient [0;39m [2m:[0;39m Processing
> /meta/connect {clientId=3u9riwg6ag3r5dd3ay86i444f, channel=/meta/connect,
> id=85, successful=true}
> [36morg.cometd.client.BayeuxClient [0;39m [2m:[0;39m State update:
> CONNECTED -> CONNECTED
> [36mo.a.c.c.s.i.s.SubscriptionHelper[0;39m [2m:[0;39m
> [CHANNEL:META_CONNECT]: {clientId=3u9riwg6ag3r5dd3ay86i444f,
> channel=/meta/connect, id=85, successful=true}
> [36morg.cometd.client.BayeuxClient [0;39m [2m:[0;39m Connecting,
> transport
> org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper$3@4e0cc334
> [36morg.cometd.client.BayeuxClient [0;39m [2m:[0;39m Sending
> messages [{clientId=3u9riwg6ag3r5dd3ay86i444f, channel=/meta/connect, id=86,
> connectionType=long-polling}]
> [36morg.cometd.client.BayeuxClient [0;39m [2m:[0;39m State update:
> CONNECTED -> UNCONNECTED
> [36morg.cometd.client.BayeuxClient [0;39m [2m:[0;39m Messages failed
> [{clientId=3u9riwg6ag3r5dd3ay86i444f, channel=/meta/connect, id=86,
> connectionType=long-polling}]
> java.io.EOFException: HttpConnectionOverHTTP@12f0e719(l:/10.172.131.200:50574
> <->
> r:my-proxy.com/x.x.x.x:xx,closed=false)[HttpChannelOverHTTP@2a4927(exchange=HttpExchange@6ae1ae35
> req=TERMINATED/null@null
> res=PENDING/null@null)[send=HttpSenderOverHTTP@51fea1e0(req=QUEUED,snd=COMPLETED,failure=null)[HttpGenerator{s=START}],recv=HttpReceiverOverHTTP@44234ce9(rsp=IDLE,failure=null)[HttpParser{s=CLOSED,0
> of -1}]]]
> at
> org.eclipse.jetty.client.http.HttpReceiverOverHTTP.earlyEOF(HttpReceiverOverHTTP.java:277)
> [jetty-client-9.2.14.v20151106.jar:9.2.14.v20151106]
> at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:1309)
> [jetty-http-9.2.14.v20151106.jar:9.2.14.v20151106]
> at
> org.eclipse.jetty.client.http.HttpReceiverOverHTTP.shutdown(HttpReceiverOverHTTP.java:182)
> [jetty-client-9.2.14.v20151106.jar:9.2.14.v20151106]
> at
> org.eclipse.jetty.client.http.HttpReceiverOverHTTP.process(HttpReceiverOverHTTP.java:129)
> [jetty-client-9.2.14.v20151106.jar:9.2.14.v20151106]
> at
> org.eclipse.jetty.client.http.HttpReceiverOverHTTP.receive(HttpReceiverOverHTTP.java:69)
> [jetty-client-9.2.14.v20151106.jar:9.2.14.v20151106]
> at
> org.eclipse.jetty.client.http.HttpChannelOverHTTP.receive(HttpChannelOverHTTP.java:89)
> [jetty-client-9.2.14.v20151106.jar:9.2.14.v20151106]
> at
> org.eclipse.jetty.client.http.HttpConnectionOverHTTP.onFillable(HttpConnectionOverHTTP.java:122)
> [jetty-client-9.2.14.v20151106.jar:9.2.14.v20151106]
> at
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:544)
> [jetty-io-9.2.14.v20151106.jar:9.2.14.v20151106]
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
> [jetty-util-9.2.14.v20151106.jar:9.2.14.v20151106]
> at
>
[jira] [Commented] (CAMEL-10224) Upgrade log4j to lg4j2
[ https://issues.apache.org/jira/browse/CAMEL-10224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15445290#comment-15445290 ] Luca Burgazzoli commented on CAMEL-10224: - Hi [~garydgregory] So far we had the following issues: - LOG4J2-905 - some dependencies make use of log4j 1.2 base classes like AppenderSkeleton which are not provided by log4j-1.2-api, so we had to use log4j-over-slf4j as workaround, would be nice if such stuffs would be provided in log4j-1.2-api or better in something like log4j-1.2-compatibility > Upgrade log4j to lg4j2 > -- > > Key: CAMEL-10224 > URL: https://issues.apache.org/jira/browse/CAMEL-10224 > Project: Camel > Issue Type: Task >Reporter: Luca Burgazzoli >Assignee: Luca Burgazzoli > Fix For: 2.18.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-10255) Camel Main - Make it easy to configure property placeholder
[
https://issues.apache.org/jira/browse/CAMEL-10255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-10255.
-
Resolution: Fixed
Assignee: Claus Ibsen
Fix Version/s: 2.18.0
Thanks for the PR
> Camel Main - Make it easy to configure property placeholder
> ---
>
> Key: CAMEL-10255
> URL: https://issues.apache.org/jira/browse/CAMEL-10255
> Project: Camel
> Issue Type: New Feature
> Components: camel-core
>Reporter: Claus Ibsen
>Assignee: Claus Ibsen
> Fix For: 2.18.0
>
>
> So you can use
> Where you can specify one or more locations separated by comma:
> main.setPropertyPlaceholderLocations("myapp.properties");
> See SO
> http://stackoverflow.com/questions/39033103/how-to-access-property-file-in-apache-camel-with-java-dsl
> Today its a bit harder to do, where you either need to use the MainListener
> or to setup the PropertiesComponent from a RouteBuilder configure method, or
> to use the bind which likely is the easiest.
> PropertiesComponent prop = new PropertiesComponent();
> prop.setXXX
> main.bind("properties, prop);
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-10255) Camel Main - Make it easy to configure property placeholder
[
https://issues.apache.org/jira/browse/CAMEL-10255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15445024#comment-15445024
]
ASF GitHub Bot commented on CAMEL-10255:
Github user asfgit closed the pull request at:
https://github.com/apache/camel/pull/1146
> Camel Main - Make it easy to configure property placeholder
> ---
>
> Key: CAMEL-10255
> URL: https://issues.apache.org/jira/browse/CAMEL-10255
> Project: Camel
> Issue Type: New Feature
> Components: camel-core
>Reporter: Claus Ibsen
>
> So you can use
> Where you can specify one or more locations separated by comma:
> main.setPropertyPlaceholderLocations("myapp.properties");
> See SO
> http://stackoverflow.com/questions/39033103/how-to-access-property-file-in-apache-camel-with-java-dsl
> Today its a bit harder to do, where you either need to use the MainListener
> or to setup the PropertiesComponent from a RouteBuilder configure method, or
> to use the bind which likely is the easiest.
> PropertiesComponent prop = new PropertiesComponent();
> prop.setXXX
> main.bind("properties, prop);
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
