You might find this blog post interesting. It came out of a discussion on the MQ listserver. By @Richard Nikula

https://www.nastel.com/a-philosophical-possibly-even-a-theological-discussion-of-ibm-mqs-maximum-queue-depth/

You might find this blog post interesting. It came out of a discussion on the MQ listserver. By @Richard Nikula

https://www.nastel.com/a-philosophical-possibly-even-a-theological-discussion-of-ibm-mqs-maximum-queue-depth/

You might find this blog post interesting. It came out of a discussion on the MQ listserver. By @Richard Nikula

https://www.nastel.com/a-philosophical-possibly-even-a-theological-discussion-of-ibm-mqs-maximum-queue-depth/

You might find this blog post interesting. It came out of a discussion on the MQ listserver. By @Richard Nikula

https://www.nastel.com/a-philosophical-possibly-even-a-theological-discussion-of-ibm-mqs-maximum-queue-depth/

You might find this blog post interesting. It came out of a discussion on the MQ listserver. By @Richard Nikula

https://www.nastel.com/a-philosophical-possibly-even-a-theological-discussion-of-ibm-mqs-maximum-queue-depth/

You might find this blog post interesting. It came out of a discussion on the MQ listserver. By @Richard Nikula

https://www.nastel.com/a-philosophical-possibly-even-a-theological-discussion-of-ibm-mqs-maximum-queue-depth/

A few thoughts.  

First, I was assuming the the traditional role of a queue as a buffer of messages and wasn't going into models where the queue was acting like persistent storage so your point is valid.  It "should" be empty most of the time.  Except when it is isn't. 

Next point, when describing MQ, I often compare it to email between applications.   Is your email inbox empty right now?  Probably not, but it wasn't that long ago that a daily ritual would be cleaning and archiving mail to avoid people seeing "mailbox is full" messages when sending you mail.  There are still mail limits but the IT has to increase capacity to be able to support the flow required.  MQ is "plumbing" providing a service.  And it needs to be able to provide enough of that service to be valuable.  

So back to my point one and your comment.   Suppose you had an application with a valid reason to store data?  Maybe there is a processing window but orders can arrive before that?  Does the application tell the buyer, the queue is full, try later or do we provide the capacity to avoid it. Of course, the application could have a preorder limit.  But it shouldn't be based on an MQ max queue depth because an MQ admin thought 50,000 was a lot.  But as several people have commented to me directly, it does mean that your petabyte of data could arrive and the plumbing has to work.

You might find this blog post interesting. It came out of a discussion on the MQ listserver. By @Richard Nikula

https://www.nastel.com/a-philosophical-possibly-even-a-theological-discussion-of-ibm-mqs-maximum-queue-depth/

Yes, the application tells the client - queue full - MQRC_Q_FULL
https://www.ibm.com/support/knowledgecenter/SSFKSJ_9.2.0/com.ibm.mq.tro.doc/q041240_.htm

Well, the details can be more complicated:
When a message cannot be delivered, the MCA can process it in several ways. It can try again, it can return-to-sender, or it can put it on the dead-letter queue.
https://www.ibm.com/support/knowledgecenter/SSFKSJ_9.2.0/com.ibm.mq.con.doc/q015720_.htm

When you send an email to a person whose mailbox is full you also get the error message that your email could not be delivered.
Again it depends on the email server if you get an undelivered error message or not.

There is something that does not happen autonomous yet.
If queue_service_interval_high then increase maxdepth from 50,000 to 100,000
Workaround: Tell a shell script to increase maxdepth when a queue gets full

A few thoughts.  

First, I was assuming the the traditional role of a queue as a buffer of messages and wasn't going into models where the queue was acting like persistent storage so your point is valid.  It "should" be empty most of the time.  Except when it is isn't. 

Next point, when describing MQ, I often compare it to email between applications.   Is your email inbox empty right now?  Probably not, but it wasn't that long ago that a daily ritual would be cleaning and archiving mail to avoid people seeing "mailbox is full" messages when sending you mail.  There are still mail limits but the IT has to increase capacity to be able to support the flow required.  MQ is "plumbing" providing a service.  And it needs to be able to provide enough of that service to be valuable.  

So back to my point one and your comment.   Suppose you had an application with a valid reason to store data?  Maybe there is a processing window but orders can arrive before that?  Does the application tell the buyer, the queue is full, try later or do we provide the capacity to avoid it. Of course, the application could have a preorder limit.  But it shouldn't be based on an MQ max queue depth because an MQ admin thought 50,000 was a lot.  But as several people have commented to me directly, it does mean that your petabyte of data could arrive and the plumbing has to work.

You might find this blog post interesting. It came out of a discussion on the MQ listserver. By @Richard Nikula

https://www.nastel.com/a-philosophical-possibly-even-a-theological-discussion-of-ibm-mqs-maximum-queue-depth/

Yes, the application tells the client - queue full - MQRC_Q_FULL
https://www.ibm.com/support/knowledgecenter/SSFKSJ_9.2.0/com.ibm.mq.tro.doc/q041240_.htm

Well, the details can be more complicated:
When a message cannot be delivered, the MCA can process it in several ways. It can try again, it can return-to-sender, or it can put it on the dead-letter queue.
https://www.ibm.com/support/knowledgecenter/SSFKSJ_9.2.0/com.ibm.mq.con.doc/q015720_.htm

When you send an email to a person whose mailbox is full you also get the error message that your email could not be delivered.
Again it depends on the email server if you get an undelivered error message or not.

There is something that does not happen autonomous yet.
If queue_service_interval_high then increase maxdepth from 50,000 to 100,000
Workaround: Tell a shell script to increase maxdepth when a queue gets full

A few thoughts.  

First, I was assuming the the traditional role of a queue as a buffer of messages and wasn't going into models where the queue was acting like persistent storage so your point is valid.  It "should" be empty most of the time.  Except when it is isn't. 

Next point, when describing MQ, I often compare it to email between applications.   Is your email inbox empty right now?  Probably not, but it wasn't that long ago that a daily ritual would be cleaning and archiving mail to avoid people seeing "mailbox is full" messages when sending you mail.  There are still mail limits but the IT has to increase capacity to be able to support the flow required.  MQ is "plumbing" providing a service.  And it needs to be able to provide enough of that service to be valuable.  

So back to my point one and your comment.   Suppose you had an application with a valid reason to store data?  Maybe there is a processing window but orders can arrive before that?  Does the application tell the buyer, the queue is full, try later or do we provide the capacity to avoid it. Of course, the application could have a preorder limit.  But it shouldn't be based on an MQ max queue depth because an MQ admin thought 50,000 was a lot.  But as several people have commented to me directly, it does mean that your petabyte of data could arrive and the plumbing has to work.

You might find this blog post interesting. It came out of a discussion on the MQ listserver. By @Richard Nikula

https://www.nastel.com/a-philosophical-possibly-even-a-theological-discussion-of-ibm-mqs-maximum-queue-depth/

I wasn't suggesting that increasing the limits meant there were unlimited resources to apply.    i wanted to make the point that the concept of a max depth or even size as a means of controlling the limit was not the most optimal.   There are ways to deal with it. We have had customers automate increasing the limits, but even that seems too "reactive" to me.  A surge of messages can come almost instantly.  Do we really want to explain to the shareholders that we only sold half our pre-order stock because 5000 messages ended up in a queue at one point and that was the max depth.   Or that the order from our top customer happened to be the one that MQ put to the DLQ.  

But i am in more in agreement, that it does require an active management policy to look at usage, more than thresholds but analytics to back it up. 

Thanks for all the great conversation...

Yes, the application tells the client - queue full - MQRC_Q_FULL
https://www.ibm.com/support/knowledgecenter/SSFKSJ_9.2.0/com.ibm.mq.tro.doc/q041240_.htm

Well, the details can be more complicated:
When a message cannot be delivered, the MCA can process it in several ways. It can try again, it can return-to-sender, or it can put it on the dead-letter queue.
https://www.ibm.com/support/knowledgecenter/SSFKSJ_9.2.0/com.ibm.mq.con.doc/q015720_.htm

When you send an email to a person whose mailbox is full you also get the error message that your email could not be delivered.
Again it depends on the email server if you get an undelivered error message or not.

There is something that does not happen autonomous yet.
If queue_service_interval_high then increase maxdepth from 50,000 to 100,000
Workaround: Tell a shell script to increase maxdepth when a queue gets full

A few thoughts.  

First, I was assuming the the traditional role of a queue as a buffer of messages and wasn't going into models where the queue was acting like persistent storage so your point is valid.  It "should" be empty most of the time.  Except when it is isn't. 

Next point, when describing MQ, I often compare it to email between applications.   Is your email inbox empty right now?  Probably not, but it wasn't that long ago that a daily ritual would be cleaning and archiving mail to avoid people seeing "mailbox is full" messages when sending you mail.  There are still mail limits but the IT has to increase capacity to be able to support the flow required.  MQ is "plumbing" providing a service.  And it needs to be able to provide enough of that service to be valuable.  

So back to my point one and your comment.   Suppose you had an application with a valid reason to store data?  Maybe there is a processing window but orders can arrive before that?  Does the application tell the buyer, the queue is full, try later or do we provide the capacity to avoid it. Of course, the application could have a preorder limit.  But it shouldn't be based on an MQ max queue depth because an MQ admin thought 50,000 was a lot.  But as several people have commented to me directly, it does mean that your petabyte of data could arrive and the plumbing has to work.

You might find this blog post interesting. It came out of a discussion on the MQ listserver. By @Richard Nikula

https://www.nastel.com/a-philosophical-possibly-even-a-theological-discussion-of-ibm-mqs-maximum-queue-depth/

I wasn't suggesting that increasing the limits meant there were unlimited resources to apply.    i wanted to make the point that the concept of a max depth or even size as a means of controlling the limit was not the most optimal.   There are ways to deal with it. We have had customers automate increasing the limits, but even that seems too "reactive" to me.  A surge of messages can come almost instantly.  Do we really want to explain to the shareholders that we only sold half our pre-order stock because 5000 messages ended up in a queue at one point and that was the max depth.   Or that the order from our top customer happened to be the one that MQ put to the DLQ.  

But i am in more in agreement, that it does require an active management policy to look at usage, more than thresholds but analytics to back it up. 

Thanks for all the great conversation...

Yes, the application tells the client - queue full - MQRC_Q_FULL
https://www.ibm.com/support/knowledgecenter/SSFKSJ_9.2.0/com.ibm.mq.tro.doc/q041240_.htm

Well, the details can be more complicated:
When a message cannot be delivered, the MCA can process it in several ways. It can try again, it can return-to-sender, or it can put it on the dead-letter queue.
https://www.ibm.com/support/knowledgecenter/SSFKSJ_9.2.0/com.ibm.mq.con.doc/q015720_.htm

When you send an email to a person whose mailbox is full you also get the error message that your email could not be delivered.
Again it depends on the email server if you get an undelivered error message or not.

There is something that does not happen autonomous yet.
If queue_service_interval_high then increase maxdepth from 50,000 to 100,000
Workaround: Tell a shell script to increase maxdepth when a queue gets full

A few thoughts.  

First, I was assuming the the traditional role of a queue as a buffer of messages and wasn't going into models where the queue was acting like persistent storage so your point is valid.  It "should" be empty most of the time.  Except when it is isn't. 

Next point, when describing MQ, I often compare it to email between applications.   Is your email inbox empty right now?  Probably not, but it wasn't that long ago that a daily ritual would be cleaning and archiving mail to avoid people seeing "mailbox is full" messages when sending you mail.  There are still mail limits but the IT has to increase capacity to be able to support the flow required.  MQ is "plumbing" providing a service.  And it needs to be able to provide enough of that service to be valuable.  

So back to my point one and your comment.   Suppose you had an application with a valid reason to store data?  Maybe there is a processing window but orders can arrive before that?  Does the application tell the buyer, the queue is full, try later or do we provide the capacity to avoid it. Of course, the application could have a preorder limit.  But it shouldn't be based on an MQ max queue depth because an MQ admin thought 50,000 was a lot.  But as several people have commented to me directly, it does mean that your petabyte of data could arrive and the plumbing has to work.

You might find this blog post interesting. It came out of a discussion on the MQ listserver. By @Richard Nikula

https://www.nastel.com/a-philosophical-possibly-even-a-theological-discussion-of-ibm-mqs-maximum-queue-depth/