|
TransactionalQueueManager.QueueTransactionContext.poll(QueueInfo queue, long timeout) doesn't use timeout variable
2.x
http://fisheye.codehaus.org/changelog/mule/?cs=10380 http://fisheye.codehaus.org/changelog/mule/?cs=10383 Current state for 2.x - test is disabled 2.x:
Exception stack is: 1. Resource manager has not been started (org.mule.util.xa.ResourceManagerSystemException) org.mule.util.xa.AbstractResourceManager:421 (http://mule.mulesource.org/docs/apidocs/org/mule/util/xa/ResourceManagerSystemException.html ******************************************************************************** Root Exception stack trace: org.mule.util.xa.ResourceManagerSystemException: Resource manager has not been started at org.mule.util.xa.AbstractResourceManager.assureStarted(AbstractResourceManager.java:421) at org.mule.util.xa.AbstractResourceManager.beginTransaction(AbstractResourceManager.java:183) at org.mule.util.xa.DefaultXASession.begin(DefaultXASession.java:69) at org.mule.providers.vm.VMTransaction.doBegin(VMTransaction.java:46) at org.mule.transaction.AbstractTransaction.begin(AbstractTransaction.java:79) at org.mule.transaction.AbstractSingleResourceTransaction.begin(AbstractSingleResourceTransaction.java:40) at org.mule.providers.vm.VMTransactionFactory.beginTransaction(VMTransactionFactory.java:24) at org.mule.transaction.TransactionTemplate.execute(TransactionTemplate.java:86) at org.mule.providers.TransactedPollingMessageReceiver.poll(TransactedPollingMessageReceiver.java:131) at org.mule.providers.PollingReceiverWorker.run(PollingReceiverWorker.java:47) at org.mule.providers.vm.VMMessageReceiver$VMReceiverWorker.run(VMMessageReceiver.java:191) at org.mule.impl.work.WorkerContext.run(WorkerContext.java:310) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1061) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:575) at java.lang.Thread.run(Thread.java:534) We are also seeing this problem while using transacted VM transports in Mule 1.4.3. Anatoli, what's the status of this issue, Do you have a fix in dev? This issue was fixed.
Could you please try 1.4.4 snapshot? Thanks Anatoli, possible to put a patch here? Or the URL for Fisheye for us to build the patch and put here.
2Hassan - fisheye links was publish in the comments
1.x http://fisheye.codehaus.org/changelog/mule/?cs=10366 2L Siraj - Yes, the changes were merged to 2.x. Unfortunately, I got a exception related with Resource manager (see above). As a result the issue is still open For those interested in the patch - follow the FishEye link, it will allow to generate arbitrary patches from a changeset.
Anatoli,
Which test case do you execute to run into the remaining problem or is it fixed by now? -Andreas see test cases description and prev comments
To spare others reading through this issue here's a quick summary:
#1 org.mule.providers.vm.functional.VmTransactionTestCase is the relevant test case currently disabled I'll investigate further and try cleaning up the config first then come back with updates. 1.4.4: this issue was fixed Moving into 2.0.2 as it turns out VM transactions are not working due to QueueManager equality issue in VMConnector and VMTransaction. The logic and maybe even the design appears to have changed with 2.x and MuleManager being MuleContext now. In 1.x there was only a QueueManager singletion started in MuleManager. In 2.x we now have a per VMConnector QueueManager. Also, the QueueManager is never started in 2.x but was in MuleManager as part of start() in 1.x. More details later.
Can someone please confirm that in 1.x we only had a single QueueManager across all VMConnectors but with 2.x a per VMConnector QueueManager is intended.
If the above statement is true there are some observations that I believe need to be resolved: #1 Is MuleContext.getQueueManager() still required or rather obsolete? Please check on DefaultMuleContext.getQueueManager() implementation creating a singleton. If it's in fact still relevant, should at least be started during MuleContext.start()? #2 The current transaction binding while creating the transport specific transaction VMTransaction uses MuleContext's singleton QueueManager instance to set the QueueManager. This in turn leads to a the situation where the VMConnector.getQueueSession() never properly returns a session because it permanently compares its connector specific QueueManager to the singleton constructed in the beginning. #3 Based on #1 and #2 my current conclusion on QueueManager is that the design changed and per VMConnector QueueManagers and hence queues are possible. There are just various places that haven't taken this into account as can be seen in the constructor of VMTransaction when creating the initial binding, missing QueueManager start call, or when the thread bound Transaction is returned in VMConnector.getQueueSession() and then failing with 'tx.hasResource(queueManager)'. The overall challenge here appears to be able to properly manage connector bound QueueManagers through MuleContext without having the connector specific QueueManager available when needed, e.g. in TransactionTemplate.execute() when the transaction gets started with "config.getFactory().beginTransaction(context). I hope someone can shed some more light into these changes for 2.x as they seem to be somewhat inconsistent. Oh, and coming back to the test failures, yes, that's why they are failing at this point: #1 QueueManager not started Thanks in advance, Came across the answer for QueueManager per connector in the linked issue.
Based on my findings I created a new issue on the actual problem
The original issue is fixed, still the tests are failing. I will create a new issue because the reason for failure has moved to a different place in the core.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
MULE-2396