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
> <marco.zapletal@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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>