| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| How to synchronize queue access from java for testing code. |
« View previous topic :: View next topic » |
| Author |
Message
|
| SoZoneOfSky |
 Posted: Wed Dec 07, 2005 2:43 am Post subject: How to synchronize queue access from java for testing code. |
 |
|
Newbie
Joined: 07 Dec 2005
Posts: 5
Location: Russia
|
Hello all,
The problem I have is related to test code synchronization from java.
I have application on WAS starts to work with database when message arrived. I am trying to test if database data is ok after I sent specific message to configured queue.
WAS listener port removes message from queue just after message processing started. But message processing takes signuficant time and I have to wait in test code until message processigng finished.
Indeed I expected that WAS would not remove message from queue until processing finished. I tried to find out how can I configure that, but failed. Is there a way?
Supposing such a behavior (removing message in beggining by WAS listener port) is normal, I nevertheless belevied that message should return to queue if message processing failed. I couldn't stop server while message was being processed, so I killed WAS process, but no message returned to queue. Is that ok behavior too?
Is there any [good] way to watch from code when processing of specific message from configured queue was finished? Is there something wrong with transactions? I use XA data source in WAS, MQ queue connection factory is also XA enabled in WAS configuration.
To work around I have configured my test code to watch to log file changes, but it is very bad way and I hope there is someboy who can give me a hint how can I go in correct way.
Thanks in advance,
Pavel |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Wed Dec 07, 2005 4:19 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
If you are using two-phase commit, the message on the queue will be removed but still in transaction until the database access has been completed. Once the database transaction either commits or rolls back, then the message on the queue will be committed or rolled back.
If this is not working, then either you are trying to use XA with an MQ Client connection, which doesn't work without a special MQ Client, or you are not configuring your application and your transactions properly. Are you using container managed transactions or bean managed transactions? Remember that bean managed transactions means it's up to you to write the code to commit or roll back.
If you want to know when the MDB has finished doing it's work, one way to accomplish this is to have the MDB send a reply message.
But this gets very tricky, as you end up having to keep several different kinds of transactions open in various places and you have to make sure that you don't leave one open while trying to wait for another to finish.
Another way to do it is to lie back, trust MQ, and not worry about waiting for the MDB to finish processing.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| gorilla |
| Posted: Wed Dec 07, 2005 4:21 am Post subject: |
|
|
Novice
Joined: 17 Nov 2005
Posts: 16
|
I can't answer your real question, but there is something you might be able to use to help understand what's going on if your code takes long enough to execute.
FWIW, if the XA support is properly configured, you certainly should be able to get the result you want. If it looks like your commit/rollback isn't working for this particular program, the first thing to do is see if XA properly set up.
Anyway - a Quick & Dirty way to see part of what's going on: when an MQ message is read under a transaction, the message "disappears" from the queue, but the queue depth MQ reports includes that message. This is because the message is physically there, but rendered "invisible" by MQ.
If you're testing, with only one message, and the program runs slowly, you can see this via something like MQExplorer: the list of messages in the queue may be empty, while you see queue depth = 1.
I know how to automate this with normal Java code outside WAS (the Java API can see the queue depth, and you can count "visible" messages by browsing the whole queue). It might be possible via JMS and/or from WAS, but I've never done it that way.
By the way - this is ok for testing, but remember that if you're running multiple programs, 200 transactions per second through the queue, the queue might be modified during the time it takes to browse it. Even if you automate it, this approach is only ok for testing a single, slow (or slowed down  program. |
|
| Back to top |
|
|
| SoZoneOfSky |
| Posted: Wed Dec 07, 2005 4:48 am Post subject: |
|
|
Newbie
Joined: 07 Dec 2005
Posts: 5
Location: Russia
|
Hello jefflowrey and gorilla,
Thanks for your answers.
The one more problem is that MDB is a part of separate application which must to be used and supported (it is customer requirement). And I have no sources of that.
I use container managed transactions in session bean called from MDB.
And I do not want to send reply messages to check if processing finished, isn't there any other way to receive information if specific queue has open read and/or write transactions for the moment from any process/thread?
Since I have simple test environment(only my application is working with MQ, except test code of course) I tried to do something like following in test java application (from outside WAS):
//---------------
private boolean isQueueEmpty(String queueManagerName, String serverName, int serverPort, String channelName, String queueName) throws MQException {
MQQueueManager queueManager = null;
MQQueue queue = null;
MQEnvironment.hostname = serverName; // host to connect to
MQEnvironment.port = serverPort; // port to connect to.
MQEnvironment.channel = channelName; // the CASE-SENSITIVE
queueManager = new MQQueueManager(queueManagerName);
int openOptions = MQC.MQOO_INPUT_AS_Q_DEF | MQC.MQOO_BROWSE | MQC.MQOO_INQUIRE | MQC.MQOO_FAIL_IF_QUIESCING;
queue = queueManager.accessQueue(
queueName,
openOptions,
null, // default q manager
null, // no dynamic q name
null); // no alternate user id
return queue.getCurrentDepth() == 0;
}
//---------------------
The code above returns true (so, cur depth = 0) while message is being processed, so it didn't help.
So, I feel I should probably ask customer developers support for may be additionnal configuration (XA related) of MDB application.
Thanks again,
Pavel |
|
| Back to top |
|
|
| gorilla |
| Posted: Wed Dec 07, 2005 7:43 am Post subject: |
|
|
Novice
Joined: 17 Nov 2005
Posts: 16
|
Pavel
Sorry - it looks like I gave you a bad suggeston.
I used to use that trick with the MQ API Exerciser and WMQ Explorer with MQ 5.1, and haven't actually tried it out for a long time.
I just tried it on WMQ 5.3, and MQExplorer was returning CurrentDepth=0 when I've done an MQGET under synchpoint. It became visible again after I executed MQBACK.
Unfortunately that probably means that the test program you wrote isn't giving you any useful information. I don't have time right now to test this with Java code, but I'll do it later today.
After my test I'll either add a new entry (if it turns out the queuedepth trick still works) or remove my first post (to erase the evidence of my mistake |
|
| Back to top |
|
|
| SoZoneOfSky |
| Posted: Wed Dec 07, 2005 7:53 am Post subject: |
|
|
Newbie
Joined: 07 Dec 2005
Posts: 5
Location: Russia
|
Hello gorilla,
Code I referenced to I tried before your advice, so it (advice) didn't harm me at all.
Everybody mistakes, but deleting post may help to avoid confusing other people, so I'd remove it asap .
Regards,
Pavel |
|
| Back to top |
|
|
| SoZoneOfSky |
| Posted: Wed Dec 07, 2005 8:31 am Post subject: |
|
|
Newbie
Joined: 07 Dec 2005
Posts: 5
Location: Russia
|
Hello all,
At last I had to configure MDB to reply messages to output queue and watch its queue depth. I didn't want to have it working in that manner, but it seems to be a best solution for now. At least it is better than log file watching .
Best wishes,
Pavel |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Dec 07, 2005 11:55 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Don't know exactly what you are trying to achieve.
We have WMQ 5.3.08 and WAS 5.0.2x running on the same box (AIX) and experience absolutely no problems with XA multiphase commit.
We have ATG Dynamo Messaging System (ATG 5.2) and WMQ 5.3.08 running on Solaris and have problems no end with XA multiphase commit...(ATG related)
Enjoy  |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
