| Author |
Message
|
| Seshagiri |
 Posted: Sun Oct 16, 2011 2:16 am Post subject: Need suggestion |
 |
|
Apprentice
Joined: 04 Oct 2011
Posts: 42
|
We have installed MQ7 on Solaris.
Here a qmanager by name QMGR is created and has a local queue L1 and has 103 remote queus R1,R2....R103 along with transmission queus(TMQ1,TMQ2....TMQ103).
103 qmanagers(some are on windows 2008 with MQ7 and some on windows 2003server with MQ5) are physically distributed and have remoteq at there side as L1 with transmission queue as QMGR.
These all 103 qmanagers send data to QMGR and so L1 holds lot of data in QMGR on Solaris. We have a processes P1 on Solaris which pools on L1 and processes the information and inserts the data in to oracle and puts acknowledgement message into corresponding remote queue depending on the message received from any of the 103 qmanagers.
Here p1 takes 1000 messages at a time and processes them at once ie it is in some what while loop so here when ack message need to be send we are opening and closing the remote queues(depends on 1000 messages being processed).
Here p1 is using 2phase commit.
Does it make any problem if I open any remote queue and put the message and close but do not commit immediately but commit at batch of 1000. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Sun Oct 16, 2011 5:04 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
First suggestion: Use line breaks when you post! 
Second suggestion: Use PUT1 to send the ack messages and save yourself some calls
Third suggestions: Put the end of the unit of work (the commit) where it makes sense to the data. If that's after 1000 records fine but why 1000? Why not 500? or 5000? How did you arrive at that number?
The "problem" with doing batches of n records is what happens if the n-1 record fails; how long does the rollback take and what do you do with the other records? Is it right they are not processed? It could be they're related to the failing record so should roll out, but could be they're just unlucky enough to be in the same transaction. That's a design question for you, because that 1000 sounds dangerously like "a good number" someone's come up with based on the old file-and-ftp process, where ack messages were built up in files and ftp'd to the 103 destinations on completion.
Fourth suggestion (unrelated): you have 104 queue managers with 104 xmit queues. Consider a cluster to save yourself some work.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Seshagiri |
| Posted: Mon Oct 17, 2011 7:29 am Post subject: |
|
|
Apprentice
Joined: 04 Oct 2011
Posts: 42
|
| Vitor wrote: |
| First suggestion: Use line breaks when you post! . |
Ya sorry for that I will follow your suggestion
| Vitor wrote: |
| Second suggestion: Use PUT1 to send the ack messages and save yourself some calls. |
I cannot use PUT1 because after PUT1 I need to do some DB operations if it fails then I need to rollback the message. But as per my knowledge the PUT1 commits the message.
| Vitor wrote: |
| Third suggestions: Put the end of the unit of work (the commit) where it makes sense to the data. If that's after 1000 records fine but why 1000? Why not 500? or 5000? How did you arrive at that number? . |
This is a configurable parameter we can change it we used it because the queue is flooded with messages by all 103 qmanagers.
| Vitor wrote: |
The "problem" with doing batches of n records is what happens if the n-1 record fails; how long does the rollback take and what do you do with the other records? Is it right they are not processed? It could be they're related to the failing record so should roll out, but could be they're just unlucky enough to be in the same transaction. That's a design question for you, because that 1000 sounds dangerously like "a good number" someone's come up with based on the old file-and-ftp process, where ack messages were built up in files and ftp'd to the 103 destinations on completion.. |
we have handle the failed record and insert it into the database and commit the entire batch. If there is any exception in MQ or database we rollback every thing and stop the process as we are using two-phase commit.
| Vitor wrote: |
Fourth suggestion (unrelated): you have 104 queue managers with 104 xmit queues. Consider a cluster to save yourself some work.. |
Yes you are right we need consider this |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Oct 17, 2011 7:54 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Seshagiri wrote: |
| Vitor wrote: |
| Second suggestion: Use PUT1 to send the ack messages and save yourself some calls. |
I cannot use PUT1 because after PUT1 I need to do some DB operations if it fails then I need to rollback the message. But as per my knowledge the PUT1 commits the message. |
Where did you get this knowledge? Because it's wrong.
| Seshagiri wrote: |
| Vitor wrote: |
| Third suggestions: Put the end of the unit of work (the commit) where it makes sense to the data. If that's after 1000 records fine but why 1000? Why not 500? or 5000? How did you arrive at that number? . |
This is a configurable parameter we can change it we used it because the queue is flooded with messages by all 103 qmanagers. |
This tells me how you set it to 1000 but does not answer my question of why it's set to 1000 rather than 500 or 5000.
| Seshagiri wrote: |
| Vitor wrote: |
The "problem" with doing batches of n records is what happens if the n-1 record fails; how long does the rollback take and what do you do with the other records? Is it right they are not processed? It could be they're related to the failing record so should roll out, but could be they're just unlucky enough to be in the same transaction. That's a design question for you, because that 1000 sounds dangerously like "a good number" someone's come up with based on the old file-and-ftp process, where ack messages were built up in files and ftp'd to the 103 destinations on completion.. |
we have handle the failed record and insert it into the database and commit the entire batch. If there is any exception in MQ or database we rollback every thing and stop the process as we are using two-phase commit. |
Again that's an answer to a different question to the one I asked. I do understand that you'll roll back the entire batch, but this means that (using your current settings) if the 1000th message fails, 999 perfectly processed messages will be rolled back as well.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Seshagiri |
| Posted: Mon Oct 17, 2011 8:11 am Post subject: |
|
|
Apprentice
Joined: 04 Oct 2011
Posts: 42
|
| Vitor wrote: |
| Seshagiri wrote: |
| Vitor wrote: |
| Second suggestion: Use PUT1 to send the ack messages and save yourself some calls. |
I cannot use PUT1 because after PUT1 I need to do some DB operations if it fails then I need to rollback the message. But as per my knowledge the PUT1 commits the message
Where did you get this knowledge? Because it's wrong
... |
|
Then what is difference between PUT1 and PUT
| Vitor wrote: |
| Seshagiri wrote: |
| Vitor wrote: |
Third suggestions: Put the end of the unit of work (the commit) where it makes sense to the data. If that's after 1000 records fine but why 1000? Why not 500? or 5000? How did you arrive at that number?
This is a configurable parameter we can change it we used it because the queue is flooded with messages by all 103 qmanagers. |
This tells me how you set it to 1000 but does not answer my question of why it's set to 1000 rather than 500 or 5000. |
. |
I dont want to get 1 message at time. I want bulk of messages to be retrived from queue that is why using 1000..
| Vitor wrote: |
| Seshagiri wrote: |
| Vitor wrote: |
The "problem" with doing batches of n records is what happens if the n-1 record fails; how long does the rollback take and what do you do with the other records? Is it right they are not processed? It could be they're related to the failing record so should roll out, but could be they're just unlucky enough to be in the same transaction. That's a design question for you, because that 1000 sounds dangerously like "a good number" someone's come up with based on the old file-and-ftp process, where ack messages were built up in files and ftp'd to the 103 destinations on completion. |
we have handle the failed record and insert it into the database and commit the entire batch. If there is any exception in MQ or database we rollback every thing and stop the process as we are using two-phase commit. |
Again that's an answer to a different question to the one I asked. I do understand that you'll roll back the entire batch, but this means that (using your current settings) if the 1000th message fails, 999 perfectly processed messages will be rolled back as well. |
No here if 1000th message is failed(not MQ or DB exception but other exception related to application logic) then it is inserted into the DB and the entire batch is commited.
Last edited by Seshagiri on Mon Oct 17, 2011 8:36 am; edited 1 time in total |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Oct 17, 2011 8:33 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Seshagiri wrote: |
| Then what is difference between PUT1 and PUT. |
The one in the documentation. There's a clue in the name; 
| Seshagiri wrote: |
| I dont want to get 1 message at time. I want bulk of messages to be retrived from queue that is why using 1000. |
Well that's not happening no matter how hard you try is it? You can only read one message at a time from a queue; all you're changing here is how many are hung up waiting to be committed. I repeat my question of why you see 1000 as a good number.
| Seshagiri wrote: |
| No here if 1000th message is failed(not MQ or DB exception but other exception related to application logic) then it is inserted into the DB and the entire batch is commited. |
And if the DB or WMQ fails on the 1000th message (due to a temporary database deadlock or a transmission queue temporially full) then the other 999 messages roll back.
You started off asking if committing in batches of 1000 was a problem. You're now telling me it isn't. If you're that certain, then go in peace and why did you post?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Seshagiri |
| Posted: Mon Oct 17, 2011 8:45 am Post subject: |
|
|
Apprentice
Joined: 04 Oct 2011
Posts: 42
|
| Vitor wrote: |
The one in the documentation. There's a clue in the name; . |
ok. Sorry got the point from docs.
| Vitor wrote: |
Well that's not happening no matter how hard you try is it? You can only read one message at a time from a queue; all you're changing here is how many are hung up waiting to be committed. I repeat my question of why you see 1000 as a good number. |
I hope you are not a programmer. Here I am reading 1000 messages one by one and storing them on heap memory for processing.
| Vitor wrote: |
And if the DB or WMQ fails on the 1000th message (due to a temporary database deadlock or a transmission queue temporially full) then the other 999 messages roll back.
You started off asking if committing in batches of 1000 was a problem. You're now telling me it isn't. If you're that certain, then go in peace and why did you post? |
I never said that there was a problem, but asked you is there going to be problem if I do so. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Oct 17, 2011 9:00 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Seshagiri wrote: |
| I hope you are not a programmer. Here I am reading 1000 messages one by one and storing them on heap memory for processing. |
I've written some code over the years, wouldn't run up memory myself like that and it still doesn't answer my original question. Especially as there's no real advantage to be gained by doing it (but no real problem either).
| Seshagiri wrote: |
| I never said that there was a problem, but asked you is there going to be problem if I do so. |
I've told you what one of the likely problems is. You say that's not a problem. So you're clearly fine.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Oct 17, 2011 9:02 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Also if anyone's been a little careless with the XA configuration it might not go as well as you hope.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Seshagiri |
| Posted: Mon Oct 17, 2011 9:11 am Post subject: |
|
|
Apprentice
Joined: 04 Oct 2011
Posts: 42
|
| Vitor wrote: |
I've written some code over the years, wouldn't run up memory myself like that and it still doesn't answer my original question. Especially as there's no real advantage to be gained by doing it (but no real problem either).. |
ok but you see if I read one message at a time and process it (I am consuming say 8 milliseconds to get message this includes open queue get the message and close the queue) but if I do for more then one message (i.e opening only once geting the 1000 messages and closing the queue once) here I am able to save lot of time. That is why using 1000.
| Vitor wrote: |
I've told you what one of the likely problems is. You say that's not a problem. So you're clearly fine. |
ok got it. I have one thing to ask I am seeing message loss when the sender channel is being reset and more over when again after some time if messages passes through that channel the first message is lost but the subsequent messages are delivered properly. Why is it so? |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Oct 17, 2011 9:17 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Seshagiri wrote: |
| ok but you see if I read one message at a time and process it (I am consuming say 8 milliseconds to get message this includes open queue get the message and close the queue) but if I do for more then one message (i.e opening only once geting the 1000 messages and closing the queue once) here I am able to save lot of time. That is why using 1000. |
The number of times that you OPEN a queue has absolutely nothing to do with how many times you issue a COMMIT.
When reading a queue, you should always open it ONCE, read each message until there are none left, and then CLOSE it once.
You may or may not choose, within that interval, to issue COMMITs for each individual GET or over a set of GETs. But again, that is unrelated to how often you OPEN/CLOSE. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Oct 17, 2011 9:20 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Seshagiri wrote: |
| ok but you see if I read one message at a time and process it (I am consuming say 8 milliseconds to get message this includes open queue get the message and close the queue) but if I do for more then one message (i.e opening only once geting the 1000 messages and closing the queue once) here I am able to save lot of time. That is why using 1000. |
I hope you are not a programmer! Why open and close the queue at all while there are still messages on it? Why not open the queue, read & process the 10000/50000/100000/1000000 messages on it (committing at the correct business processing points) and then close it? Again (and for the last time) I ask how you came up with 1000 and is it anything to do with how many messages you can cram on the heap? 
| Seshagiri wrote: |
| ok got it. I have one thing to ask I am seeing message loss when the sender channel is being reset and more over when again after some time if messages passes through that channel the first message is lost but the subsequent messages are delivered properly. Why is it so? |
Because you're resetting the sender channel. There's no reason to do this unless there's been a catastrophic failure in the channel or someone with admin authority has made a poorly judged change to the system (like issuing a reset channel command when there's no reason). What you're saying with this command is that whatever the channel thinks about the number & state of any messages transferred or in flight, you know best and you want the channel to ignore what it knows and do what you tell it is right.
So you're getting problems because what you're saying is right is not in fact right. Like your code design.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Seshagiri |
| Posted: Mon Oct 17, 2011 9:21 am Post subject: |
|
|
Apprentice
Joined: 04 Oct 2011
Posts: 42
|
| mqjeff wrote: |
| Seshagiri wrote: |
| ok but you see if I read one message at a time and process it (I am consuming say 8 milliseconds to get message this includes open queue get the message and close the queue) but if I do for more then one message (i.e opening only once geting the 1000 messages and closing the queue once) here I am able to save lot of time. That is why using 1000. |
The number of times that you OPEN a queue has absolutely nothing to do with how many times you issue a COMMIT.
When reading a queue, you should always open it ONCE, read each message until there are none left, and then CLOSE it once.
You may or may not choose, within that interval, to issue COMMITs for each individual GET or over a set of GETs. But again, that is unrelated to how often you OPEN/CLOSE. |
Ok got it |
|
| Back to top |
|
|
| Seshagiri |
| Posted: Mon Oct 17, 2011 9:36 am Post subject: |
|
|
Apprentice
Joined: 04 Oct 2011
Posts: 42
|
| Vitor wrote: |
I hope you are not a programmer! Why open and close the queue at all while there are still messages on it? Why not open the queue, read & process the 10000/50000/100000/1000000 messages on it (committing at the correct business processing points) and then close it? Again (and for the last time) I ask how you came up with 1000 and is it anything to do with how many messages you can cram on the heap? . |
I hope you are not getting the point here. The qdepth increases dynamically. So there can be messages less then 1000 or more than 1000. Here if the q depth is more than 1000 say 10000 at a given point the program takes only 1000 to process it but does not take all 10000 to processes them, any how we can open it once and close it once only when all the 10000 gets processed. But if qdepth is zero then why to open and close every time.
| Vitor wrote: |
Because you're resetting the sender channel. There's no reason to do this unless there's been a catastrophic failure in the channel or someone with admin authority has made a poorly judged change to the system (like issuing a reset channel command when there's no reason). What you're saying with this command is that whatever the channel thinks about the number & state of any messages transferred or in flight, you know best and you want the channel to ignore what it knows and do what you tell it is right.
So you're getting problems because what you're saying is right is not in fact right. Like your code design. |
So what is the solution for that even if we stop and start the channel it is going in retry state. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Oct 17, 2011 9:57 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Seshagiri wrote: |
| I hope you are not getting the point here. The qdepth increases dynamically. So there can be messages less then 1000 or more than 1000. Here if the q depth is more than 1000 say 10000 at a given point the program takes only 1000 to process it but does not take all 10000 to processes them, any how we can open it once and close it once only when all the 10000 gets processed. |
Because your code should make no reference to queue depth but open the queue, process the messages and then close it a suitible interval after the last message arrives so as to be sure there are no more. As my most worthy associate points out, this is nothing to do with how many opperations are in a Uow.
| Seshagiri wrote: |
| But if qdepth is zero then why to open and close every time. |
If queue depth is zero, why is your application running?
| Seshagiri wrote: |
So what is the solution for that even if we stop and start the channel it is going in retry state. |
Fix the channel definition(s), and/or the underlying network so that the channel doesn't go into retry. As a first move, try looking in the logs to see why the channel is in retry rather than blindly issuing inappropriate commands that cause more problems than they fix.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
