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.zaple...@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.zaple...@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 >>>> >>>> >>>> >>>> >>>> >>> >> >> >
