You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Marco Zapletal <ma...@gmail.com> on 2012/07/20 16:25:51 UTC
Camel ActiveMQ consumers do not consume after restart
Hi folks,
We have an application where we have two Camel contexts (C1, C2) which
exchange messages via two queues (Q1, Q2). These queues are located on
the same ActiveMQ broker. Thereby, the message flow goes as follows:
C1 -> Q1 -> C2
C2 -> Q2 -> C1
C2 uses furthermore some "internal" queues on the AMQ broker, but I
guess they are not relevant to the problem.
The issue we are facing can be described as follows and happens only
when C1 or C2 go down or have to be restarted
- In case, no messages are produced of either C1/C2 while the other one
restarts, everything is fine - i.e., there is no problem with consuming
messages
- In case, messages are produced of either C1/C2 and are put in the
respective queue, during the absence of the other Camel application, we
gonna face problems with consuming messages from the queues.
We have especially tested this scenario by stopping C2. C1 produces
messages to Q1. Then we restart C2 again and (almost) nothing happened.
- By almost I mean, that the context of C2 starts up without errors.
What is also observed is that when we have 1 concurrentConsumer defined
in the AMQ consumer configuration in C2, 1 message is consumed (if 3
concurrentConsumers are defined, 3 messages are consumed). Afterwards,
consumption stops.
- When restarting C2 again, 1 message is consumed from Q1 (in case of 1
concurrentConsumer)
- C2 exposes also two CXF services as producers of routes. Both of the
two routes have one of those "internal" AMQ queues as their final
destination. When we want to access their respective WSDL URL, the
request hangs.
- We have an admin Web application monitoring C2 via JMX. The admin
application hangs due to no response from C2's JMX services (although
the C2 context starts up properly according to the logs).
- Nothing special can be seen in the logs. We examined the logs on DEBUG
level (on Camel as well as on AMQ side) and nothing special could be seen.
- We went back to a rather base config. No transactions, no connection
pools, no caching of consumers/producers. We have experimented with the
prefetch (setting it to 1 or even 0) without success.
- In order to reach proper behavior again, Q1/Q2 (and maybe even the
"internal queues of C2) have to be purged. Then C2 has be to be
restarted again. After this procedure, message passing is back to normal.
Sorry for the long post, but I want to describe the problem as detailed
as possible. Since we have been working on this now for days any help
would be highly appreciated.
Thanks and best regards,
Marco
Re: Camel ActiveMQ consumers do not consume after restart
Posted by Christian Müller <ch...@gmail.com>.
Hello Marco!
Sorry for the late reply. Could you please have a look at the following
unit test, whether it fits your use case. It works with Camel 2.10.3 and
ActiveMQ 5.7.0:
import org.apache.activemq.broker.BrokerService;
import org.apache.activemq.camel.component.ActiveMQComponent;
import org.apache.camel.CamelContext;
import org.apache.camel.ProducerTemplate;
import org.apache.camel.builder.RouteBuilder;
import org.apache.camel.component.mock.MockEndpoint;
import org.apache.camel.impl.DefaultCamelContext;
import org.apache.camel.impl.SimpleRegistry;
import org.junit.After;
import org.junit.Before;
import org.junit.Test;
public class CamelActiveMqRestartTest {
private BrokerService broker;
private SimpleRegistry registry1, registry2;
private CamelContext context1, context2;
private ProducerTemplate template;
@Before
public void setUp() throws Exception {
broker = new BrokerService();
broker.setPersistent(true);
broker.setUseJmx(false);
broker.addConnector("tcp://localhost:61616");
broker.start();
registry1 = new SimpleRegistry();
registry1.put("activemq",
ActiveMQComponent.activeMQComponent("tcp://localhost:61616"));
context1 = new DefaultCamelContext(registry1);
context1.addRoutes(new RouteBuilder() {
public void configure() throws Exception {
from("activemq:queue:q1")
.to("activemq:queue:q2");
}
});
context1.start();
template = context1.createProducerTemplate();
template.start();
registry2 = new SimpleRegistry();
registry2.put("activemq",
ActiveMQComponent.activeMQComponent("tcp://localhost:61616"));
context2 = new DefaultCamelContext(registry2);
context2.addRoutes(new RouteBuilder() {
public void configure() throws Exception {
from("activemq:queue:q2")
.to("mock:end");
}
});
context2.start();
}
@After
public void tearDown() throws Exception {
context2.stop();
template.stop();
context1.stop();
broker.stop();
}
@Test
public void test() throws Exception {
context2.stop();
MockEndpoint mock = (MockEndpoint) context2.getEndpoint("mock:end");
mock.expectedMessageCount(5);
for (int i = 0; i < 5; i++) {
template.sendBody("activemq:queue:q1", "Camel");
}
mock.assertIsNotSatisfied();
context2.start();
mock.assertIsSatisfied();
}
}
Best,
Christian
On Fri, Jul 20, 2012 at 4:25 PM, Marco Zapletal <ma...@gmail.com>wrote:
> C2 again
--
Re: Camel ActiveMQ consumers do not consume after restart
Posted by Charles Moulliard <ch...@gmail.com>.
Marco,
The issue is related to ActiveMQ. So you should discuss this point in
activemq mailing list. Nevertheless, it appears that your subscription to
the queue/topic has disapeared :
public void <http://grepcode.com/file/repo1.maven.org/maven2/org.apache.activemq/activemq-core/5.3.1/org/apache/activemq/broker/region/AbstractRegion.java#>acknowledge(ConsumerBrokerExchange
consumerExchange, MessageAck ack) throws Exception
<http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/java/lang/Exception.java#Exception>
{
358 <http://grepcode.com/file/repo1.maven.org/maven2/org.apache.activemq/activemq-core/5.3.1/org/apache/activemq/broker/region/AbstractRegion.java#358>
<http://grepcode.com/file/repo1.maven.org/maven2/org.apache.activemq/activemq-core/5.3.1/org/apache/activemq/broker/region/AbstractRegion.java#>
Subscription sub = consumerExchange.getSubscription();
359 <http://grepcode.com/file/repo1.maven.org/maven2/org.apache.activemq/activemq-core/5.3.1/org/apache/activemq/broker/region/AbstractRegion.java#359>
<http://grepcode.com/file/repo1.maven.org/maven2/org.apache.activemq/activemq-core/5.3.1/org/apache/activemq/broker/region/AbstractRegion.java#>
if (sub == null) {
360 <http://grepcode.com/file/repo1.maven.org/maven2/org.apache.activemq/activemq-core/5.3.1/org/apache/activemq/broker/region/AbstractRegion.java#360>
<http://grepcode.com/file/repo1.maven.org/maven2/org.apache.activemq/activemq-core/5.3.1/org/apache/activemq/broker/region/AbstractRegion.java#>
sub = subscriptions
<http://grepcode.com/file/repo1.maven.org/maven2/org.apache.activemq/activemq-core/5.3.1/org/apache/activemq/broker/region/AbstractRegion.java#AbstractRegion.0subscriptions>.get(ack.getConsumerId());
361 <http://grepcode.com/file/repo1.maven.org/maven2/org.apache.activemq/activemq-core/5.3.1/org/apache/activemq/broker/region/AbstractRegion.java#361>
<http://grepcode.com/file/repo1.maven.org/maven2/org.apache.activemq/activemq-core/5.3.1/org/apache/activemq/broker/region/AbstractRegion.java#>
if (sub == null) {
362 <http://grepcode.com/file/repo1.maven.org/maven2/org.apache.activemq/activemq-core/5.3.1/org/apache/activemq/broker/region/AbstractRegion.java#362>
<http://grepcode.com/file/repo1.maven.org/maven2/org.apache.activemq/activemq-core/5.3.1/org/apache/activemq/broker/region/AbstractRegion.java#>
if
(!consumerExchange.getConnectionContext().isInRecoveryMode()) {
363 <http://grepcode.com/file/repo1.maven.org/maven2/org.apache.activemq/activemq-core/5.3.1/org/apache/activemq/broker/region/AbstractRegion.java#363>
<http://grepcode.com/file/repo1.maven.org/maven2/org.apache.activemq/activemq-core/5.3.1/org/apache/activemq/broker/region/AbstractRegion.java#>
LOG
<http://grepcode.com/file/repo1.maven.org/maven2/org.apache.activemq/activemq-core/5.3.1/org/apache/activemq/broker/region/AbstractRegion.java#AbstractRegion.0LOG>.warn
<http://grepcode.com/file/repo1.maven.org/maven2/commons-logging/commons-logging/1.1.1/org/apache/commons/logging/Log.java#Log.warn%28java.lang.Object%29>("Ack
for non existent subscription, ack:" + ack);
364 <http://grepcode.com/file/repo1.maven.org/maven2/org.apache.activemq/activemq-core/5.3.1/org/apache/activemq/broker/region/AbstractRegion.java#364>
<http://grepcode.com/file/repo1.maven.org/maven2/org.apache.activemq/activemq-core/5.3.1/org/apache/activemq/broker/region/AbstractRegion.java#>
throw new IllegalArgumentException
<http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/java/lang/IllegalArgumentException.java#IllegalArgumentException>(
365 <http://grepcode.com/file/repo1.maven.org/maven2/org.apache.activemq/activemq-core/5.3.1/org/apache/activemq/broker/region/AbstractRegion.java#365>
<http://grepcode.com/file/repo1.maven.org/maven2/org.apache.activemq/activemq-core/5.3.1/org/apache/activemq/broker/region/AbstractRegion.java#>
"The subscription does not exist: "
366 <http://grepcode.com/file/repo1.maven.org/maven2/org.apache.activemq/activemq-core/5.3.1/org/apache/activemq/broker/region/AbstractRegion.java#366>
<http://grepcode.com/file/repo1.maven.org/maven2/org.apache.activemq/activemq-core/5.3.1/org/apache/activemq/broker/region/AbstractRegion.java#>
+ ack.getConsumerId());
367 <http://grepcode.com/file/repo1.maven.org/maven2/org.apache.activemq/activemq-core/5.3.1/org/apache/activemq/broker/region/AbstractRegion.java#367>
<http://grepcode.com/file/repo1.maven.org/maven2/org.apache.activemq/activemq-core/5.3.1/org/apache/activemq/broker/region/AbstractRegion.java#>
} else {
368 <http://grepcode.com/file/repo1.maven.org/maven2/org.apache.activemq/activemq-core/5.3.1/org/apache/activemq/broker/region/AbstractRegion.java#368>
<http://grepcode.com/file/repo1.maven.org/maven2/org.apache.activemq/activemq-core/5.3.1/org/apache/activemq/broker/region/AbstractRegion.java#>
return;
369 <http://grepcode.com/file/repo1.maven.org/maven2/org.apache.activemq/activemq-core/5.3.1/org/apache/activemq/broker/region/AbstractRegion.java#369>
<http://grepcode.com/file/repo1.maven.org/maven2/org.apache.activemq/activemq-core/5.3.1/org/apache/activemq/broker/region/AbstractRegion.java#>
}
370 <http://grepcode.com/file/repo1.maven.org/maven2/org.apache.activemq/activemq-core/5.3.1/org/apache/activemq/broker/region/AbstractRegion.java#370>
<http://grepcode.com/file/repo1.maven.org/maven2/org.apache.activemq/activemq-core/5.3.1/org/apache/activemq/broker/region/AbstractRegion.java#>
}
371 <http://grepcode.com/file/repo1.maven.org/maven2/org.apache.activemq/activemq-core/5.3.1/org/apache/activemq/broker/region/AbstractRegion.java#371>
<http://grepcode.com/file/repo1.maven.org/maven2/org.apache.activemq/activemq-core/5.3.1/org/apache/activemq/broker/region/AbstractRegion.java#>
consumerExchange.setSubscription(sub);
372 <http://grepcode.com/file/repo1.maven.org/maven2/org.apache.activemq/activemq-core/5.3.1/org/apache/activemq/broker/region/AbstractRegion.java#372>
<http://grepcode.com/file/repo1.maven.org/maven2/org.apache.activemq/activemq-core/5.3.1/org/apache/activemq/broker/region/AbstractRegion.java#>
}
373 <http://grepcode.com/file/repo1.maven.org/maven2/org.apache.activemq/activemq-core/5.3.1/org/apache/activemq/broker/region/AbstractRegion.java#373>
<http://grepcode.com/file/repo1.maven.org/maven2/org.apache.activemq/activemq-core/5.3.1/org/apache/activemq/broker/region/AbstractRegion.java#>
sub.acknowledge(consumerExchange.getConnectionContext(), ack);
374 <http://grepcode.com/file/repo1.maven.org/maven2/org.apache.activemq/activemq-core/5.3.1/org/apache/activemq/broker/region/AbstractRegion.java#374>
<http://grepcode.com/file/repo1.maven.org/maven2/org.apache.activemq/activemq-core/5.3.1/org/apache/activemq/broker/region/AbstractRegion.java#>
}
Regards,
On Tue, Sep 4, 2012 at 9:48 AM, Marco Zapletal <ma...@gmail.com>wrote:
> Hi Christian,
>
> have you been able to reproduce the problem? Is there any way I can
> contribute?
>
> As I have written before, setting the prefetch=0 may circumvent the
> problem. However, when restarting the queue, I receive a bunch of the
> following exception, but this doesn't seem to cause problems...
>
> 2012-08-30 16:20:07,910 | WARN | Async error occurred: java.lang.**IllegalArgumentException:
> The subscription does not exist: ID:ip-127-0-0-1-47409-**1346270540282-1:7:1:30950
> | org.apache.activemq.broker.**TransportConnection.Service | ActiveMQ
> Transport: tcp:///127.0.0.1:48116
> java.lang.**IllegalArgumentException: The subscription does not exist:
> ID:ip-127-0-0-1-47409-**1346270540282-1:7:1:30950
> at org.apache.activemq.broker.**region.AbstractRegion.**
> messagePull(AbstractRegion.**java:433)
> at org.apache.activemq.broker.**region.RegionBroker.**
> messagePull(RegionBroker.java:**537)
> at org.apache.activemq.broker.**BrokerFilter.messagePull(**
> BrokerFilter.java:81)
> at org.apache.activemq.broker.**BrokerFilter.messagePull(**
> BrokerFilter.java:81)
> at org.apache.activemq.broker.**BrokerFilter.messagePull(**
> BrokerFilter.java:81)
> at
>
>
> Best regards,
> Marco
>
>
> On 01.08.2012 23:41, Christian Müller wrote:
>
>> Working on a test case...
>>
>> Best,
>> Christian
>>
>> On Thu, Jul 26, 2012 at 12:27 PM, Marco Zapletal
>> <ma...@gmail.com>**wrote:
>>
>> Sorry Christian, I forgot to mention this:
>>>
>>> We are currently using Camel 2.10 and ActiveMQ 5.6.0. But we have
>>> experienced this problem with ActiveMQ 5.5.1 as well (we can also test it
>>> with earlier version if this may help to find the problem). Before Camel
>>> 2.10 (final) we stayed with 2.10-SNAPSHOT for a long time, so I cannot
>>> confirm that we had this with 2.9 as well.
>>>
>>> I would of course be interested to find the actual reason for this
>>> problem
>>> - I just meant that the prefetch=0 somehow compensated the issue :)
>>>
>>> Thanks and regards,
>>>
>>> Marco
>>>
>>>
>>> On 26.07.2012 00:09, Christian Müller wrote:
>>>
>>> I don't think this was the issue. But without to know which version of
>>>> Camel and ActiveMQ do you use and how your ActiveMQ component is
>>>> configured, I cannot help...
>>>>
>>>> Best,
>>>> Christian
>>>>
>>>> On Wed, Jul 25, 2012 at 6:22 PM, Marco Zapletal <
>>>> marco.zapletal@gmail.com
>>>>
>>>>> **wrote:
>>>>>
>>>>
>>>> For producing messages to AMQ, we are using the InOnly pattern only.
>>>>
>>>>>
>>>>> The routes in C1 look quite easy, one is consuming from the file system
>>>>> and producing to AMQ, the other one is consuming from AMQ and producing
>>>>> to
>>>>> the file system.
>>>>>
>>>>> Within C2, we have now about 20 routes, which basically consume/produce
>>>>> from/to a queue and and process messages within beans.
>>>>>
>>>>> Anyway, it seems that I have solved my problem now: I set the prefetch
>>>>> limit to zero on the connection string and all tests have worked since
>>>>> then
>>>>> (actually I thought I have tried this before by setting the prefetch in
>>>>> the
>>>>> Spring config to 0 ...). Maybe this helps others in the future.
>>>>>
>>>>> Thanks and regards,
>>>>>
>>>>> Marco
>>>>>
>>>>>
>>>>>
>>>>> On 23.07.2012 04:07, Willem Jiang wrote:
>>>>>
>>>>> It could be more easy for us to understand your case by looking at
>>>>> the
>>>>>
>>>>>> routes you have.
>>>>>>
>>>>>> On Sat Jul 21 06:40:34 2012, Christian Müller wrote:
>>>>>>
>>>>>> Which version of Camel and ActiveMQ do you use?
>>>>>>
>>>>>>> Which MEP do you use?
>>>>>>>
>>>>>>> Best,
>>>>>>> Christian
>>>>>>>
>>>>>>> Sent from a mobile device
>>>>>>> Am 20.07.2012 16:26 schrieb "Marco Zapletal" <
>>>>>>> marco.zapletal@gmail.com
>>>>>>>
>>>>>>>> :
>>>>>>>>
>>>>>>>
>>>>>>> Hi folks,
>>>>>>>
>>>>>>>
>>>>>>>> We have an application where we have two Camel contexts (C1, C2)
>>>>>>>> which
>>>>>>>> exchange messages via two queues (Q1, Q2). These queues are located
>>>>>>>> on the
>>>>>>>> same ActiveMQ broker. Thereby, the message flow goes as follows:
>>>>>>>>
>>>>>>>> C1 -> Q1 -> C2
>>>>>>>> C2 -> Q2 -> C1
>>>>>>>>
>>>>>>>> C2 uses furthermore some "internal" queues on the AMQ broker, but I
>>>>>>>> guess
>>>>>>>> they are not relevant to the problem.
>>>>>>>>
>>>>>>>> The issue we are facing can be described as follows and happens only
>>>>>>>> when
>>>>>>>> C1 or C2 go down or have to be restarted
>>>>>>>>
>>>>>>>> - In case, no messages are produced of either C1/C2 while the other
>>>>>>>> one
>>>>>>>> restarts, everything is fine - i.e., there is no problem with
>>>>>>>> consuming
>>>>>>>> messages
>>>>>>>>
>>>>>>>> - In case, messages are produced of either C1/C2 and are put in the
>>>>>>>> respective queue, during the absence of the other Camel application,
>>>>>>>> we
>>>>>>>> gonna face problems with consuming messages from the queues.
>>>>>>>> We have especially tested this scenario by stopping C2. C1 produces
>>>>>>>> messages to Q1. Then we restart C2 again and (almost) nothing
>>>>>>>> happened.
>>>>>>>>
>>>>>>>> - By almost I mean, that the context of C2 starts up without errors.
>>>>>>>> What
>>>>>>>> is also observed is that when we have 1 concurrentConsumer defined
>>>>>>>> in
>>>>>>>> the
>>>>>>>> AMQ consumer configuration in C2, 1 message is consumed (if 3
>>>>>>>> concurrentConsumers are defined, 3 messages are consumed).
>>>>>>>> Afterwards,
>>>>>>>> consumption stops.
>>>>>>>>
>>>>>>>> - When restarting C2 again, 1 message is consumed from Q1 (in case
>>>>>>>> of
>>>>>>>> 1
>>>>>>>> concurrentConsumer)
>>>>>>>>
>>>>>>>> - C2 exposes also two CXF services as producers of routes. Both of
>>>>>>>> the two
>>>>>>>> routes have one of those "internal" AMQ queues as their final
>>>>>>>> destination.
>>>>>>>> When we want to access their respective WSDL URL, the request hangs.
>>>>>>>>
>>>>>>>> - We have an admin Web application monitoring C2 via JMX. The admin
>>>>>>>> application hangs due to no response from C2's JMX services
>>>>>>>> (although
>>>>>>>> the
>>>>>>>> C2 context starts up properly according to the logs).
>>>>>>>>
>>>>>>>> - Nothing special can be seen in the logs. We examined the logs on
>>>>>>>> DEBUG
>>>>>>>> level (on Camel as well as on AMQ side) and nothing special could be
>>>>>>>> seen.
>>>>>>>>
>>>>>>>> - We went back to a rather base config. No transactions, no
>>>>>>>> connection
>>>>>>>> pools, no caching of consumers/producers. We have experimented with
>>>>>>>> the
>>>>>>>> prefetch (setting it to 1 or even 0) without success.
>>>>>>>>
>>>>>>>> - In order to reach proper behavior again, Q1/Q2 (and maybe even the
>>>>>>>> "internal queues of C2) have to be purged. Then C2 has be to be
>>>>>>>> restarted
>>>>>>>> again. After this procedure, message passing is back to normal.
>>>>>>>>
>>>>>>>>
>>>>>>>> Sorry for the long post, but I want to describe the problem as
>>>>>>>> detailed as
>>>>>>>> possible. Since we have been working on this now for days any help
>>>>>>>> would be
>>>>>>>> highly appreciated.
>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks and best regards,
>>>>>>>>
>>>>>>>>
>>>>>>>> Marco
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
--
Charles Moulliard
Apache Committer / Sr. Pr. Consultant at FuseSource.com
Twitter : @cmoulliard
Blog : http://cmoulliard.blogspot.com
Re: Camel ActiveMQ consumers do not consume after restart
Posted by Marco Zapletal <ma...@gmail.com>.
Hi Christian,
have you been able to reproduce the problem? Is there any way I can
contribute?
As I have written before, setting the prefetch=0 may circumvent the
problem. However, when restarting the queue, I receive a bunch of the
following exception, but this doesn't seem to cause problems...
2012-08-30 16:20:07,910 | WARN | Async error occurred:
java.lang.IllegalArgumentException: The subscription does not exist:
ID:ip-127-0-0-1-47409-1346270540282-1:7:1:30950 |
org.apache.activemq.broker.TransportConnection.Service | ActiveMQ
Transport: tcp:///127.0.0.1:48116
java.lang.IllegalArgumentException: The subscription does not exist:
ID:ip-127-0-0-1-47409-1346270540282-1:7:1:30950
at
org.apache.activemq.broker.region.AbstractRegion.messagePull(AbstractRegion.java:433)
at
org.apache.activemq.broker.region.RegionBroker.messagePull(RegionBroker.java:537)
at
org.apache.activemq.broker.BrokerFilter.messagePull(BrokerFilter.java:81)
at
org.apache.activemq.broker.BrokerFilter.messagePull(BrokerFilter.java:81)
at
org.apache.activemq.broker.BrokerFilter.messagePull(BrokerFilter.java:81)
at
Best regards,
Marco
On 01.08.2012 23:41, Christian Müller wrote:
> Working on a test case...
>
> Best,
> Christian
>
> On Thu, Jul 26, 2012 at 12:27 PM, Marco Zapletal
> <ma...@gmail.com>wrote:
>
>> Sorry Christian, I forgot to mention this:
>>
>> We are currently using Camel 2.10 and ActiveMQ 5.6.0. But we have
>> experienced this problem with ActiveMQ 5.5.1 as well (we can also test it
>> with earlier version if this may help to find the problem). Before Camel
>> 2.10 (final) we stayed with 2.10-SNAPSHOT for a long time, so I cannot
>> confirm that we had this with 2.9 as well.
>>
>> I would of course be interested to find the actual reason for this problem
>> - I just meant that the prefetch=0 somehow compensated the issue :)
>>
>> Thanks and regards,
>>
>> Marco
>>
>>
>> On 26.07.2012 00:09, Christian Müller wrote:
>>
>>> I don't think this was the issue. But without to know which version of
>>> Camel and ActiveMQ do you use and how your ActiveMQ component is
>>> configured, I cannot help...
>>>
>>> Best,
>>> Christian
>>>
>>> On Wed, Jul 25, 2012 at 6:22 PM, Marco Zapletal <marco.zapletal@gmail.com
>>>> **wrote:
>>>
>>> For producing messages to AMQ, we are using the InOnly pattern only.
>>>>
>>>> The routes in C1 look quite easy, one is consuming from the file system
>>>> and producing to AMQ, the other one is consuming from AMQ and producing
>>>> to
>>>> the file system.
>>>>
>>>> Within C2, we have now about 20 routes, which basically consume/produce
>>>> from/to a queue and and process messages within beans.
>>>>
>>>> Anyway, it seems that I have solved my problem now: I set the prefetch
>>>> limit to zero on the connection string and all tests have worked since
>>>> then
>>>> (actually I thought I have tried this before by setting the prefetch in
>>>> the
>>>> Spring config to 0 ...). Maybe this helps others in the future.
>>>>
>>>> Thanks and regards,
>>>>
>>>> Marco
>>>>
>>>>
>>>>
>>>> On 23.07.2012 04:07, Willem Jiang wrote:
>>>>
>>>> It could be more easy for us to understand your case by looking at the
>>>>> routes you have.
>>>>>
>>>>> On Sat Jul 21 06:40:34 2012, Christian Müller wrote:
>>>>>
>>>>> Which version of Camel and ActiveMQ do you use?
>>>>>> Which MEP do you use?
>>>>>>
>>>>>> Best,
>>>>>> Christian
>>>>>>
>>>>>> Sent from a mobile device
>>>>>> Am 20.07.2012 16:26 schrieb "Marco Zapletal" <marco.zapletal@gmail.com
>>>>>>> :
>>>>>>
>>>>>> Hi folks,
>>>>>>
>>>>>>>
>>>>>>> We have an application where we have two Camel contexts (C1, C2) which
>>>>>>> exchange messages via two queues (Q1, Q2). These queues are located
>>>>>>> on the
>>>>>>> same ActiveMQ broker. Thereby, the message flow goes as follows:
>>>>>>>
>>>>>>> C1 -> Q1 -> C2
>>>>>>> C2 -> Q2 -> C1
>>>>>>>
>>>>>>> C2 uses furthermore some "internal" queues on the AMQ broker, but I
>>>>>>> guess
>>>>>>> they are not relevant to the problem.
>>>>>>>
>>>>>>> The issue we are facing can be described as follows and happens only
>>>>>>> when
>>>>>>> C1 or C2 go down or have to be restarted
>>>>>>>
>>>>>>> - In case, no messages are produced of either C1/C2 while the other
>>>>>>> one
>>>>>>> restarts, everything is fine - i.e., there is no problem with
>>>>>>> consuming
>>>>>>> messages
>>>>>>>
>>>>>>> - In case, messages are produced of either C1/C2 and are put in the
>>>>>>> respective queue, during the absence of the other Camel application,
>>>>>>> we
>>>>>>> gonna face problems with consuming messages from the queues.
>>>>>>> We have especially tested this scenario by stopping C2. C1 produces
>>>>>>> messages to Q1. Then we restart C2 again and (almost) nothing
>>>>>>> happened.
>>>>>>>
>>>>>>> - By almost I mean, that the context of C2 starts up without errors.
>>>>>>> What
>>>>>>> is also observed is that when we have 1 concurrentConsumer defined in
>>>>>>> the
>>>>>>> AMQ consumer configuration in C2, 1 message is consumed (if 3
>>>>>>> concurrentConsumers are defined, 3 messages are consumed). Afterwards,
>>>>>>> consumption stops.
>>>>>>>
>>>>>>> - When restarting C2 again, 1 message is consumed from Q1 (in case of
>>>>>>> 1
>>>>>>> concurrentConsumer)
>>>>>>>
>>>>>>> - C2 exposes also two CXF services as producers of routes. Both of
>>>>>>> the two
>>>>>>> routes have one of those "internal" AMQ queues as their final
>>>>>>> destination.
>>>>>>> When we want to access their respective WSDL URL, the request hangs.
>>>>>>>
>>>>>>> - We have an admin Web application monitoring C2 via JMX. The admin
>>>>>>> application hangs due to no response from C2's JMX services (although
>>>>>>> the
>>>>>>> C2 context starts up properly according to the logs).
>>>>>>>
>>>>>>> - Nothing special can be seen in the logs. We examined the logs on
>>>>>>> DEBUG
>>>>>>> level (on Camel as well as on AMQ side) and nothing special could be
>>>>>>> seen.
>>>>>>>
>>>>>>> - We went back to a rather base config. No transactions, no connection
>>>>>>> pools, no caching of consumers/producers. We have experimented with
>>>>>>> the
>>>>>>> prefetch (setting it to 1 or even 0) without success.
>>>>>>>
>>>>>>> - In order to reach proper behavior again, Q1/Q2 (and maybe even the
>>>>>>> "internal queues of C2) have to be purged. Then C2 has be to be
>>>>>>> restarted
>>>>>>> again. After this procedure, message passing is back to normal.
>>>>>>>
>>>>>>>
>>>>>>> Sorry for the long post, but I want to describe the problem as
>>>>>>> detailed as
>>>>>>> possible. Since we have been working on this now for days any help
>>>>>>> would be
>>>>>>> highly appreciated.
>>>>>>>
>>>>>>>
>>>>>>> Thanks and best regards,
>>>>>>>
>>>>>>>
>>>>>>> Marco
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
Re: Camel ActiveMQ consumers do not consume after restart
Posted by Christian Müller <ch...@gmail.com>.
Working on a test case...
Best,
Christian
On Thu, Jul 26, 2012 at 12:27 PM, Marco Zapletal
<ma...@gmail.com>wrote:
> Sorry Christian, I forgot to mention this:
>
> We are currently using Camel 2.10 and ActiveMQ 5.6.0. But we have
> experienced this problem with ActiveMQ 5.5.1 as well (we can also test it
> with earlier version if this may help to find the problem). Before Camel
> 2.10 (final) we stayed with 2.10-SNAPSHOT for a long time, so I cannot
> confirm that we had this with 2.9 as well.
>
> I would of course be interested to find the actual reason for this problem
> - I just meant that the prefetch=0 somehow compensated the issue :)
>
> Thanks and regards,
>
> Marco
>
>
> On 26.07.2012 00:09, Christian Müller wrote:
>
>> I don't think this was the issue. But without to know which version of
>> Camel and ActiveMQ do you use and how your ActiveMQ component is
>> configured, I cannot help...
>>
>> Best,
>> Christian
>>
>> On Wed, Jul 25, 2012 at 6:22 PM, Marco Zapletal <marco.zapletal@gmail.com
>> >**wrote:
>>
>> For producing messages to AMQ, we are using the InOnly pattern only.
>>>
>>> The routes in C1 look quite easy, one is consuming from the file system
>>> and producing to AMQ, the other one is consuming from AMQ and producing
>>> to
>>> the file system.
>>>
>>> Within C2, we have now about 20 routes, which basically consume/produce
>>> from/to a queue and and process messages within beans.
>>>
>>> Anyway, it seems that I have solved my problem now: I set the prefetch
>>> limit to zero on the connection string and all tests have worked since
>>> then
>>> (actually I thought I have tried this before by setting the prefetch in
>>> the
>>> Spring config to 0 ...). Maybe this helps others in the future.
>>>
>>> Thanks and regards,
>>>
>>> Marco
>>>
>>>
>>>
>>> On 23.07.2012 04:07, Willem Jiang wrote:
>>>
>>> It could be more easy for us to understand your case by looking at the
>>>> routes you have.
>>>>
>>>> On Sat Jul 21 06:40:34 2012, Christian Müller wrote:
>>>>
>>>> Which version of Camel and ActiveMQ do you use?
>>>>> Which MEP do you use?
>>>>>
>>>>> Best,
>>>>> Christian
>>>>>
>>>>> Sent from a mobile device
>>>>> Am 20.07.2012 16:26 schrieb "Marco Zapletal" <marco.zapletal@gmail.com
>>>>> >:
>>>>>
>>>>> Hi folks,
>>>>>
>>>>>>
>>>>>> We have an application where we have two Camel contexts (C1, C2) which
>>>>>> exchange messages via two queues (Q1, Q2). These queues are located
>>>>>> on the
>>>>>> same ActiveMQ broker. Thereby, the message flow goes as follows:
>>>>>>
>>>>>> C1 -> Q1 -> C2
>>>>>> C2 -> Q2 -> C1
>>>>>>
>>>>>> C2 uses furthermore some "internal" queues on the AMQ broker, but I
>>>>>> guess
>>>>>> they are not relevant to the problem.
>>>>>>
>>>>>> The issue we are facing can be described as follows and happens only
>>>>>> when
>>>>>> C1 or C2 go down or have to be restarted
>>>>>>
>>>>>> - In case, no messages are produced of either C1/C2 while the other
>>>>>> one
>>>>>> restarts, everything is fine - i.e., there is no problem with
>>>>>> consuming
>>>>>> messages
>>>>>>
>>>>>> - In case, messages are produced of either C1/C2 and are put in the
>>>>>> respective queue, during the absence of the other Camel application,
>>>>>> we
>>>>>> gonna face problems with consuming messages from the queues.
>>>>>> We have especially tested this scenario by stopping C2. C1 produces
>>>>>> messages to Q1. Then we restart C2 again and (almost) nothing
>>>>>> happened.
>>>>>>
>>>>>> - By almost I mean, that the context of C2 starts up without errors.
>>>>>> What
>>>>>> is also observed is that when we have 1 concurrentConsumer defined in
>>>>>> the
>>>>>> AMQ consumer configuration in C2, 1 message is consumed (if 3
>>>>>> concurrentConsumers are defined, 3 messages are consumed). Afterwards,
>>>>>> consumption stops.
>>>>>>
>>>>>> - When restarting C2 again, 1 message is consumed from Q1 (in case of
>>>>>> 1
>>>>>> concurrentConsumer)
>>>>>>
>>>>>> - C2 exposes also two CXF services as producers of routes. Both of
>>>>>> the two
>>>>>> routes have one of those "internal" AMQ queues as their final
>>>>>> destination.
>>>>>> When we want to access their respective WSDL URL, the request hangs.
>>>>>>
>>>>>> - We have an admin Web application monitoring C2 via JMX. The admin
>>>>>> application hangs due to no response from C2's JMX services (although
>>>>>> the
>>>>>> C2 context starts up properly according to the logs).
>>>>>>
>>>>>> - Nothing special can be seen in the logs. We examined the logs on
>>>>>> DEBUG
>>>>>> level (on Camel as well as on AMQ side) and nothing special could be
>>>>>> seen.
>>>>>>
>>>>>> - We went back to a rather base config. No transactions, no connection
>>>>>> pools, no caching of consumers/producers. We have experimented with
>>>>>> the
>>>>>> prefetch (setting it to 1 or even 0) without success.
>>>>>>
>>>>>> - In order to reach proper behavior again, Q1/Q2 (and maybe even the
>>>>>> "internal queues of C2) have to be purged. Then C2 has be to be
>>>>>> restarted
>>>>>> again. After this procedure, message passing is back to normal.
>>>>>>
>>>>>>
>>>>>> Sorry for the long post, but I want to describe the problem as
>>>>>> detailed as
>>>>>> possible. Since we have been working on this now for days any help
>>>>>> would be
>>>>>> highly appreciated.
>>>>>>
>>>>>>
>>>>>> Thanks and best regards,
>>>>>>
>>>>>>
>>>>>> Marco
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>
Re: Camel ActiveMQ consumers do not consume after restart
Posted by Marco Zapletal <ma...@gmail.com>.
Sorry Christian, I forgot to mention this:
We are currently using Camel 2.10 and ActiveMQ 5.6.0. But we have
experienced this problem with ActiveMQ 5.5.1 as well (we can also test
it with earlier version if this may help to find the problem). Before
Camel 2.10 (final) we stayed with 2.10-SNAPSHOT for a long time, so I
cannot confirm that we had this with 2.9 as well.
I would of course be interested to find the actual reason for this
problem - I just meant that the prefetch=0 somehow compensated the issue :)
Thanks and regards,
Marco
On 26.07.2012 00:09, Christian Müller wrote:
> I don't think this was the issue. But without to know which version of
> Camel and ActiveMQ do you use and how your ActiveMQ component is
> configured, I cannot help...
>
> Best,
> Christian
>
> On Wed, Jul 25, 2012 at 6:22 PM, Marco Zapletal <ma...@gmail.com>wrote:
>
>> For producing messages to AMQ, we are using the InOnly pattern only.
>>
>> The routes in C1 look quite easy, one is consuming from the file system
>> and producing to AMQ, the other one is consuming from AMQ and producing to
>> the file system.
>>
>> Within C2, we have now about 20 routes, which basically consume/produce
>> from/to a queue and and process messages within beans.
>>
>> Anyway, it seems that I have solved my problem now: I set the prefetch
>> limit to zero on the connection string and all tests have worked since then
>> (actually I thought I have tried this before by setting the prefetch in the
>> Spring config to 0 ...). Maybe this helps others in the future.
>>
>> Thanks and regards,
>>
>> Marco
>>
>>
>>
>> On 23.07.2012 04:07, Willem Jiang wrote:
>>
>>> It could be more easy for us to understand your case by looking at the
>>> routes you have.
>>>
>>> On Sat Jul 21 06:40:34 2012, Christian Müller wrote:
>>>
>>>> Which version of Camel and ActiveMQ do you use?
>>>> Which MEP do you use?
>>>>
>>>> Best,
>>>> Christian
>>>>
>>>> Sent from a mobile device
>>>> Am 20.07.2012 16:26 schrieb "Marco Zapletal" <ma...@gmail.com>:
>>>>
>>>> Hi folks,
>>>>>
>>>>> We have an application where we have two Camel contexts (C1, C2) which
>>>>> exchange messages via two queues (Q1, Q2). These queues are located
>>>>> on the
>>>>> same ActiveMQ broker. Thereby, the message flow goes as follows:
>>>>>
>>>>> C1 -> Q1 -> C2
>>>>> C2 -> Q2 -> C1
>>>>>
>>>>> C2 uses furthermore some "internal" queues on the AMQ broker, but I
>>>>> guess
>>>>> they are not relevant to the problem.
>>>>>
>>>>> The issue we are facing can be described as follows and happens only
>>>>> when
>>>>> C1 or C2 go down or have to be restarted
>>>>>
>>>>> - In case, no messages are produced of either C1/C2 while the other one
>>>>> restarts, everything is fine - i.e., there is no problem with consuming
>>>>> messages
>>>>>
>>>>> - In case, messages are produced of either C1/C2 and are put in the
>>>>> respective queue, during the absence of the other Camel application, we
>>>>> gonna face problems with consuming messages from the queues.
>>>>> We have especially tested this scenario by stopping C2. C1 produces
>>>>> messages to Q1. Then we restart C2 again and (almost) nothing happened.
>>>>>
>>>>> - By almost I mean, that the context of C2 starts up without errors.
>>>>> What
>>>>> is also observed is that when we have 1 concurrentConsumer defined in
>>>>> the
>>>>> AMQ consumer configuration in C2, 1 message is consumed (if 3
>>>>> concurrentConsumers are defined, 3 messages are consumed). Afterwards,
>>>>> consumption stops.
>>>>>
>>>>> - When restarting C2 again, 1 message is consumed from Q1 (in case of 1
>>>>> concurrentConsumer)
>>>>>
>>>>> - C2 exposes also two CXF services as producers of routes. Both of
>>>>> the two
>>>>> routes have one of those "internal" AMQ queues as their final
>>>>> destination.
>>>>> When we want to access their respective WSDL URL, the request hangs.
>>>>>
>>>>> - We have an admin Web application monitoring C2 via JMX. The admin
>>>>> application hangs due to no response from C2's JMX services (although
>>>>> the
>>>>> C2 context starts up properly according to the logs).
>>>>>
>>>>> - Nothing special can be seen in the logs. We examined the logs on DEBUG
>>>>> level (on Camel as well as on AMQ side) and nothing special could be
>>>>> seen.
>>>>>
>>>>> - We went back to a rather base config. No transactions, no connection
>>>>> pools, no caching of consumers/producers. We have experimented with the
>>>>> prefetch (setting it to 1 or even 0) without success.
>>>>>
>>>>> - In order to reach proper behavior again, Q1/Q2 (and maybe even the
>>>>> "internal queues of C2) have to be purged. Then C2 has be to be
>>>>> restarted
>>>>> again. After this procedure, message passing is back to normal.
>>>>>
>>>>>
>>>>> Sorry for the long post, but I want to describe the problem as
>>>>> detailed as
>>>>> possible. Since we have been working on this now for days any help
>>>>> would be
>>>>> highly appreciated.
>>>>>
>>>>>
>>>>> Thanks and best regards,
>>>>>
>>>>>
>>>>> Marco
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
Re: Camel ActiveMQ consumers do not consume after restart
Posted by Christian Müller <ch...@gmail.com>.
I don't think this was the issue. But without to know which version of
Camel and ActiveMQ do you use and how your ActiveMQ component is
configured, I cannot help...
Best,
Christian
On Wed, Jul 25, 2012 at 6:22 PM, Marco Zapletal <ma...@gmail.com>wrote:
> For producing messages to AMQ, we are using the InOnly pattern only.
>
> The routes in C1 look quite easy, one is consuming from the file system
> and producing to AMQ, the other one is consuming from AMQ and producing to
> the file system.
>
> Within C2, we have now about 20 routes, which basically consume/produce
> from/to a queue and and process messages within beans.
>
> Anyway, it seems that I have solved my problem now: I set the prefetch
> limit to zero on the connection string and all tests have worked since then
> (actually I thought I have tried this before by setting the prefetch in the
> Spring config to 0 ...). Maybe this helps others in the future.
>
> Thanks and regards,
>
> Marco
>
>
>
> On 23.07.2012 04:07, Willem Jiang wrote:
>
>> It could be more easy for us to understand your case by looking at the
>> routes you have.
>>
>> On Sat Jul 21 06:40:34 2012, Christian Müller wrote:
>>
>>> Which version of Camel and ActiveMQ do you use?
>>> Which MEP do you use?
>>>
>>> Best,
>>> Christian
>>>
>>> Sent from a mobile device
>>> Am 20.07.2012 16:26 schrieb "Marco Zapletal" <ma...@gmail.com>:
>>>
>>> Hi folks,
>>>>
>>>> We have an application where we have two Camel contexts (C1, C2) which
>>>> exchange messages via two queues (Q1, Q2). These queues are located
>>>> on the
>>>> same ActiveMQ broker. Thereby, the message flow goes as follows:
>>>>
>>>> C1 -> Q1 -> C2
>>>> C2 -> Q2 -> C1
>>>>
>>>> C2 uses furthermore some "internal" queues on the AMQ broker, but I
>>>> guess
>>>> they are not relevant to the problem.
>>>>
>>>> The issue we are facing can be described as follows and happens only
>>>> when
>>>> C1 or C2 go down or have to be restarted
>>>>
>>>> - In case, no messages are produced of either C1/C2 while the other one
>>>> restarts, everything is fine - i.e., there is no problem with consuming
>>>> messages
>>>>
>>>> - In case, messages are produced of either C1/C2 and are put in the
>>>> respective queue, during the absence of the other Camel application, we
>>>> gonna face problems with consuming messages from the queues.
>>>> We have especially tested this scenario by stopping C2. C1 produces
>>>> messages to Q1. Then we restart C2 again and (almost) nothing happened.
>>>>
>>>> - By almost I mean, that the context of C2 starts up without errors.
>>>> What
>>>> is also observed is that when we have 1 concurrentConsumer defined in
>>>> the
>>>> AMQ consumer configuration in C2, 1 message is consumed (if 3
>>>> concurrentConsumers are defined, 3 messages are consumed). Afterwards,
>>>> consumption stops.
>>>>
>>>> - When restarting C2 again, 1 message is consumed from Q1 (in case of 1
>>>> concurrentConsumer)
>>>>
>>>> - C2 exposes also two CXF services as producers of routes. Both of
>>>> the two
>>>> routes have one of those "internal" AMQ queues as their final
>>>> destination.
>>>> When we want to access their respective WSDL URL, the request hangs.
>>>>
>>>> - We have an admin Web application monitoring C2 via JMX. The admin
>>>> application hangs due to no response from C2's JMX services (although
>>>> the
>>>> C2 context starts up properly according to the logs).
>>>>
>>>> - Nothing special can be seen in the logs. We examined the logs on DEBUG
>>>> level (on Camel as well as on AMQ side) and nothing special could be
>>>> seen.
>>>>
>>>> - We went back to a rather base config. No transactions, no connection
>>>> pools, no caching of consumers/producers. We have experimented with the
>>>> prefetch (setting it to 1 or even 0) without success.
>>>>
>>>> - In order to reach proper behavior again, Q1/Q2 (and maybe even the
>>>> "internal queues of C2) have to be purged. Then C2 has be to be
>>>> restarted
>>>> again. After this procedure, message passing is back to normal.
>>>>
>>>>
>>>> Sorry for the long post, but I want to describe the problem as
>>>> detailed as
>>>> possible. Since we have been working on this now for days any help
>>>> would be
>>>> highly appreciated.
>>>>
>>>>
>>>> Thanks and best regards,
>>>>
>>>>
>>>> Marco
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>
Re: Camel ActiveMQ consumers do not consume after restart
Posted by Marco Zapletal <ma...@gmail.com>.
For producing messages to AMQ, we are using the InOnly pattern only.
The routes in C1 look quite easy, one is consuming from the file system
and producing to AMQ, the other one is consuming from AMQ and producing
to the file system.
Within C2, we have now about 20 routes, which basically consume/produce
from/to a queue and and process messages within beans.
Anyway, it seems that I have solved my problem now: I set the prefetch
limit to zero on the connection string and all tests have worked since
then (actually I thought I have tried this before by setting the
prefetch in the Spring config to 0 ...). Maybe this helps others in the
future.
Thanks and regards,
Marco
On 23.07.2012 04:07, Willem Jiang wrote:
> It could be more easy for us to understand your case by looking at the
> routes you have.
>
> On Sat Jul 21 06:40:34 2012, Christian Müller wrote:
>> Which version of Camel and ActiveMQ do you use?
>> Which MEP do you use?
>>
>> Best,
>> Christian
>>
>> Sent from a mobile device
>> Am 20.07.2012 16:26 schrieb "Marco Zapletal" <ma...@gmail.com>:
>>
>>> Hi folks,
>>>
>>> We have an application where we have two Camel contexts (C1, C2) which
>>> exchange messages via two queues (Q1, Q2). These queues are located
>>> on the
>>> same ActiveMQ broker. Thereby, the message flow goes as follows:
>>>
>>> C1 -> Q1 -> C2
>>> C2 -> Q2 -> C1
>>>
>>> C2 uses furthermore some "internal" queues on the AMQ broker, but I
>>> guess
>>> they are not relevant to the problem.
>>>
>>> The issue we are facing can be described as follows and happens only
>>> when
>>> C1 or C2 go down or have to be restarted
>>>
>>> - In case, no messages are produced of either C1/C2 while the other one
>>> restarts, everything is fine - i.e., there is no problem with consuming
>>> messages
>>>
>>> - In case, messages are produced of either C1/C2 and are put in the
>>> respective queue, during the absence of the other Camel application, we
>>> gonna face problems with consuming messages from the queues.
>>> We have especially tested this scenario by stopping C2. C1 produces
>>> messages to Q1. Then we restart C2 again and (almost) nothing happened.
>>>
>>> - By almost I mean, that the context of C2 starts up without errors.
>>> What
>>> is also observed is that when we have 1 concurrentConsumer defined in
>>> the
>>> AMQ consumer configuration in C2, 1 message is consumed (if 3
>>> concurrentConsumers are defined, 3 messages are consumed). Afterwards,
>>> consumption stops.
>>>
>>> - When restarting C2 again, 1 message is consumed from Q1 (in case of 1
>>> concurrentConsumer)
>>>
>>> - C2 exposes also two CXF services as producers of routes. Both of
>>> the two
>>> routes have one of those "internal" AMQ queues as their final
>>> destination.
>>> When we want to access their respective WSDL URL, the request hangs.
>>>
>>> - We have an admin Web application monitoring C2 via JMX. The admin
>>> application hangs due to no response from C2's JMX services (although
>>> the
>>> C2 context starts up properly according to the logs).
>>>
>>> - Nothing special can be seen in the logs. We examined the logs on DEBUG
>>> level (on Camel as well as on AMQ side) and nothing special could be
>>> seen.
>>>
>>> - We went back to a rather base config. No transactions, no connection
>>> pools, no caching of consumers/producers. We have experimented with the
>>> prefetch (setting it to 1 or even 0) without success.
>>>
>>> - In order to reach proper behavior again, Q1/Q2 (and maybe even the
>>> "internal queues of C2) have to be purged. Then C2 has be to be
>>> restarted
>>> again. After this procedure, message passing is back to normal.
>>>
>>>
>>> Sorry for the long post, but I want to describe the problem as
>>> detailed as
>>> possible. Since we have been working on this now for days any help
>>> would be
>>> highly appreciated.
>>>
>>>
>>> Thanks and best regards,
>>>
>>>
>>> Marco
>>>
>>>
>>>
>>>
>>
>
>
Re: Camel ActiveMQ consumers do not consume after restart
Posted by Willem Jiang <wi...@gmail.com>.
It could be more easy for us to understand your case by looking at the
routes you have.
On Sat Jul 21 06:40:34 2012, Christian Müller wrote:
> Which version of Camel and ActiveMQ do you use?
> Which MEP do you use?
>
> Best,
> Christian
>
> Sent from a mobile device
> Am 20.07.2012 16:26 schrieb "Marco Zapletal" <ma...@gmail.com>:
>
>> Hi folks,
>>
>> We have an application where we have two Camel contexts (C1, C2) which
>> exchange messages via two queues (Q1, Q2). These queues are located on the
>> same ActiveMQ broker. Thereby, the message flow goes as follows:
>>
>> C1 -> Q1 -> C2
>> C2 -> Q2 -> C1
>>
>> C2 uses furthermore some "internal" queues on the AMQ broker, but I guess
>> they are not relevant to the problem.
>>
>> The issue we are facing can be described as follows and happens only when
>> C1 or C2 go down or have to be restarted
>>
>> - In case, no messages are produced of either C1/C2 while the other one
>> restarts, everything is fine - i.e., there is no problem with consuming
>> messages
>>
>> - In case, messages are produced of either C1/C2 and are put in the
>> respective queue, during the absence of the other Camel application, we
>> gonna face problems with consuming messages from the queues.
>> We have especially tested this scenario by stopping C2. C1 produces
>> messages to Q1. Then we restart C2 again and (almost) nothing happened.
>>
>> - By almost I mean, that the context of C2 starts up without errors. What
>> is also observed is that when we have 1 concurrentConsumer defined in the
>> AMQ consumer configuration in C2, 1 message is consumed (if 3
>> concurrentConsumers are defined, 3 messages are consumed). Afterwards,
>> consumption stops.
>>
>> - When restarting C2 again, 1 message is consumed from Q1 (in case of 1
>> concurrentConsumer)
>>
>> - C2 exposes also two CXF services as producers of routes. Both of the two
>> routes have one of those "internal" AMQ queues as their final destination.
>> When we want to access their respective WSDL URL, the request hangs.
>>
>> - We have an admin Web application monitoring C2 via JMX. The admin
>> application hangs due to no response from C2's JMX services (although the
>> C2 context starts up properly according to the logs).
>>
>> - Nothing special can be seen in the logs. We examined the logs on DEBUG
>> level (on Camel as well as on AMQ side) and nothing special could be seen.
>>
>> - We went back to a rather base config. No transactions, no connection
>> pools, no caching of consumers/producers. We have experimented with the
>> prefetch (setting it to 1 or even 0) without success.
>>
>> - In order to reach proper behavior again, Q1/Q2 (and maybe even the
>> "internal queues of C2) have to be purged. Then C2 has be to be restarted
>> again. After this procedure, message passing is back to normal.
>>
>>
>> Sorry for the long post, but I want to describe the problem as detailed as
>> possible. Since we have been working on this now for days any help would be
>> highly appreciated.
>>
>>
>> Thanks and best regards,
>>
>>
>> Marco
>>
>>
>>
>>
>
--
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Weibo: willemjiang
Re: Camel ActiveMQ consumers do not consume after restart
Posted by Christian Müller <ch...@gmail.com>.
Which version of Camel and ActiveMQ do you use?
Which MEP do you use?
Best,
Christian
Sent from a mobile device
Am 20.07.2012 16:26 schrieb "Marco Zapletal" <ma...@gmail.com>:
> Hi folks,
>
> We have an application where we have two Camel contexts (C1, C2) which
> exchange messages via two queues (Q1, Q2). These queues are located on the
> same ActiveMQ broker. Thereby, the message flow goes as follows:
>
> C1 -> Q1 -> C2
> C2 -> Q2 -> C1
>
> C2 uses furthermore some "internal" queues on the AMQ broker, but I guess
> they are not relevant to the problem.
>
> The issue we are facing can be described as follows and happens only when
> C1 or C2 go down or have to be restarted
>
> - In case, no messages are produced of either C1/C2 while the other one
> restarts, everything is fine - i.e., there is no problem with consuming
> messages
>
> - In case, messages are produced of either C1/C2 and are put in the
> respective queue, during the absence of the other Camel application, we
> gonna face problems with consuming messages from the queues.
> We have especially tested this scenario by stopping C2. C1 produces
> messages to Q1. Then we restart C2 again and (almost) nothing happened.
>
> - By almost I mean, that the context of C2 starts up without errors. What
> is also observed is that when we have 1 concurrentConsumer defined in the
> AMQ consumer configuration in C2, 1 message is consumed (if 3
> concurrentConsumers are defined, 3 messages are consumed). Afterwards,
> consumption stops.
>
> - When restarting C2 again, 1 message is consumed from Q1 (in case of 1
> concurrentConsumer)
>
> - C2 exposes also two CXF services as producers of routes. Both of the two
> routes have one of those "internal" AMQ queues as their final destination.
> When we want to access their respective WSDL URL, the request hangs.
>
> - We have an admin Web application monitoring C2 via JMX. The admin
> application hangs due to no response from C2's JMX services (although the
> C2 context starts up properly according to the logs).
>
> - Nothing special can be seen in the logs. We examined the logs on DEBUG
> level (on Camel as well as on AMQ side) and nothing special could be seen.
>
> - We went back to a rather base config. No transactions, no connection
> pools, no caching of consumers/producers. We have experimented with the
> prefetch (setting it to 1 or even 0) without success.
>
> - In order to reach proper behavior again, Q1/Q2 (and maybe even the
> "internal queues of C2) have to be purged. Then C2 has be to be restarted
> again. After this procedure, message passing is back to normal.
>
>
> Sorry for the long post, but I want to describe the problem as detailed as
> possible. Since we have been working on this now for days any help would be
> highly appreciated.
>
>
> Thanks and best regards,
>
>
> Marco
>
>
>
>