You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Christian Müller <ch...@gmail.com> on 2012/08/01 23:41:01 UTC
Re: Camel ActiveMQ consumers do not consume after restart
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 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>