best if you try and modify one of the existing junit tests to try and reproduce what you are seeing and raise a jira issue to track it. That will provided the best explanation and the fastest path to a resolution.
On 18 May 2010 15:42, Colin Goodheart-Smithe < colin.goodheartsmi...@detica.com> wrote: > We have a system which uses a combination of a Queue and a Topic. We > create a message on server1 and put this on a Queue. Server2 then > listens on this queue (on a single consumer) and processes the messages > in multiple threads each of which posts a resulting message to a Topic > (multiple producers). There are multiple Servers listening (on durable > subscribers) to this Topic and receiving messages to process further. > The system runs fine in normal operation but the issue comes when we > cancel our process. The method of cancelling is that we receive a > signal to cancel (not from JMS) on each server and on receiving this > signal the servers commit the Session and then close the connections. > When we do this Server1 hangs on the ActiveMQSession.commit() method > (more specifically ResponseCorrelator.request(Object) line 80). > > > > A little more information on our ActiveMQ configuration: > > * Destination Policy: > > <destinationPolicy> > > <policyMap> > > <policyEntries> > > <policyEntry topic=">" producerFlowControl="true" > memoryLimit="8mb" optimizedDispatch="true"> > > <dispatchPolicy> > > > <strictOrderDispatchPolicy /> > > </dispatchPolicy> > > > <pendingDurableSubscriberPolicy> > > > <vmDurableCursor/> > > > </pendingDurableSubscriberPolicy> > > </policyEntry> > > <policyEntry queue=">" producerFlowControl="true" > memoryLimit="8mb" optimizedDispatch="true"> > > <pendingQueuePolicy> > > <vmQueueCursor/> > > </pendingQueuePolicy> > > </policyEntry> > > </policyEntries> > > </policyMap> > > </destinationPolicy> > > * One ActiveMQ broker with no network connectors > * Advisory Support has been turned off > > > > The issue does not appear when flow control is turned off or when flow > control is only turned on for the queues, but we cant run without flow > control on both the queue and topic as the broker gets flooded with > messages and the rate as which the Servers receive messages decreases > massively. > > > > Has anyone seen this issue before/have any suggestions? I have included > a high level overview here so that I didn't end up writing a 10-page > essay but if any more detail is needed I can elaborate further. Also, > if necessary I can try to create a set of test classes to demonstrate > the issue. > > > > > > Thanks for any help in advance > > > > Colin > > > This message should be regarded as confidential. If you have received this > email in error please notify the sender and destroy it immediately. > Statements of intent shall only become binding when confirmed in hard copy > by an authorised signatory. The contents of this email may relate to > dealings with other companies within the Detica Limited group of companies. > > Detica Limited is registered in England under No: 1337451. > > Registered offices: Surrey Research Park, Guildford, Surrey, GU2 7YP, > England. > > -- http://blog.garytully.com Open Source Integration http://fusesource.com
