Hi,

I see this message and I tried to do everything to solve this (restart Qmanager, and restart system)  We use MQ Appliance M2001B on IBM V8.0011

AMQ7487: Application acc-sligro-order-sa was preventing log space from being

Ok it has sometihing to do with logging, we use these log configuration:

LogPrimaryFiles = 32
LogSecondaryFiles = 32
Logfilepages = 4096
LogType = Circular.
LogBufferedpages = 0
LogwriteIntegrity = TripleWrite.

Since a very short time (this week) we are putting hundert of messages of 5,5 MB on the system. 
The  AMQ 7487 warning is only send when sending this files. But we HAVE to send/accept  5.5 MB XML files.
By the way its not only a warning it is rolling back messages also like stated in our logfiles.

What must be done to reset logs in memory or anyway that we can continue, or what I have to  change ?
Is there a reset command for this assuming it is allowed to lose all messages on the queues ?

We run for 3 year now with the above logconfig. We have accepted big files before untill 35 MB. That why we use MQ and a thick heavy MQ Appliance system. 
If we want to receive permanently logfiles of 5 MB what need to be changed in the configuration ?

Thanks









------------------------------
Bernard Pittens
Integration Engeneer
Sligro Foodgroup B.V.
Veghel
------------------------------

Hello,
Logs have the default size, which is often too small.
The only solution is to have larger logs. But this requires deleting and then re-creating the Queue Manager.
My recommendation is to use at least :
Logfilepages = 40960
We should also evaluate the possibility of switching to linear logs, this will make things much easier (crtmqm -lla ...)
An alternative would be to increase the number of primary logs from 32 to 250 by modifying the qm.ini and restarting the Queue Manager.

------------------------------
Luc-Michel Demey
DEMEY CONSULTING
------------------------------

Original Message:
Sent: Wed September 23, 2020 01:03 PM
From: Bernard Pittens
Subject: AMQ7487: Application xxx was preventing log space from being released


Hi,

I see this message and I tried to do everything to solve this (restart Qmanager, and restart system)  We use MQ Appliance M2001B on IBM V8.0011

AMQ7487: Application acc-sligro-order-sa was preventing log space from being

Ok it has sometihing to do with logging, we use these log configuration:

LogPrimaryFiles = 32
LogSecondaryFiles = 32
Logfilepages = 4096
LogType = Circular.
LogBufferedpages = 0
LogwriteIntegrity = TripleWrite.

Since a very short time (this week) we are putting hundert of messages of 5,5 MB on the system. 
The  AMQ 7487 warning is only send when sending this files. But we HAVE to send/accept  5.5 MB XML files.
By the way its not only a warning it is rolling back messages also like stated in our logfiles.

What must be done to reset logs in memory or anyway that we can continue, or what I have to  change ?
Is there a reset command for this assuming it is allowed to lose all messages on the queues ?

We run for 3 year now with the above logconfig. We have accepted big files before untill 35 MB. That why we use MQ and a thick heavy MQ Appliance system. 
If we want to receive permanently logfiles of 5 MB what need to be changed in the configuration ?

Thanks









------------------------------
Bernard Pittens
Integration Engeneer
Sligro Foodgroup B.V.
Veghel
------------------------------

Hi,
Sorry I have changed this messages a couple of times this morning.

HI @Anthony Beardsmore maybe you can have a look at this request ?

Thank you Luc-Michel for your answer, increasing the LogPrimary and LogSecundary files  both to 250 solve the problem temporaly.
On 180 files of 5 MB it  gives the same error again, which is strange because it is just approximately 1 GB on storage.
By the way after changing these variables we restarted the Qmanager so the new LogPrimaryFiles and LogSecondaryFiles  should be active.

Ok I have done some research on this:

Please verify this:
(LogprimaryFiles + LogSecondaryPages) *  LogFilepages * 4 kb = Total storage circular logging.
IBM Best practices like it seems and our default  before yesterday:
(32 + 32)  *  4096 * 4kb = 1024 MB (1GB)  
Maximum:
(250+250) * 65535 * 4kb = 131.000 MB (131  GB).
Our Actual  since yesterday:
(250+250) * 4096 * 4kb = 8.000 MB (8  GB).

I think the relation with the circular logging space is there only for messages which are in transit when using programs which use a manual commit for example. 

I mean this:
A MQ program is running and get a message from a queue, does things and after that transaction is done it gives a manual commit. After the manual commit is done the transaction is finished and the data on the circular logging regarding this transaction can be flushed.

Correct ?

When I use a lot of circular logging space by sending big files with programs which are also in transaction modus so with a manual commit then I have a problem, because if circular log space is used by programs which are in transaction modus then the next program can't  write to a queue because the logging is full.

So there is not a dependency with the number of messages on the queue but there is a dependency with the number of messages which are in transaction at the Qmanager.

Am I right about this ??

The strange thing is then that when I run a program and the big messages on the queue increase to 200 messages of 5 MB the error happens.
I can't get my head around that part.

So if I want to increase the circular logging space to use programs with a Manual commit then I have to keep in mind how many space I need for programs which are in transaction or is there also a relation with messages on queue ?

And when I set the values to the max(250,250, 65535) and have 131 GB for circular logging what is the disadvantage of this setting ?
Remember I have M2001B power !

Is there a best practice for my case ?

Sending 8000 files of 5 MB and storing it on the queue's for a couple of hours.
And also about 100.000 small files with an average size  of 10 kb.

I have added the stacktrace below:

Thanks

09/23/20 23:24:24 - Process(277881.13) User(mqsystem) Program(amqzmuc0)
Host(ACCIMQ03) Installation(MQAppliance)
VRMF(8.0.0.11) QMgr(QMAN_ACC)

AMQ7469: Transactions rolled back to release log space.

EXPLANATION:
The log space for the queue manager is becoming full. One or more long-running
transactions have been rolled back to release log space so that the queue
manager can continue to process requests.
ACTION:
Try to ensure that the duration of your transactions is not excessive. Consider
increasing the size of the log to allow transactions to last longer before the
log starts to become full.
-------------------------------------------------------------------------------
09/23/20 23:24:24 - Process(277881.13) User(mqsystem) Program(amqzmuc0)
Host(ACCIMQ03) Installation(MQAppliance)
VRMF(8.0.0.11) QMgr(QMAN_ACC)

AMQ7486: Transaction 0.16393 was preventing log space from being released.

EXPLANATION:
A long running transaction was detected. Message AMQ7469 or AMQ7485 has been
issued indicating if the transaction was rolled back or rolled forward in the
log to allow the log space to be released. The internal transaction identifier
is 0.16393 which can be correlated with 'dspmqtrn -a' output. The transaction
started at 22.24.49 2020-09-23 and first wrote to the queue manager recovery
log at 22.24.49 2020-09-23 . The following transaction context may be useful
in identifying the application causing this behaviour: TRANNUM(0.16393) . This
message can be correllated with the previous AMQ7469 or AMQ7485 message in the
queue manager error logs.
ACTION:
Identify the application responsible for the long running unit of work and
ensure this application is creating and completing transactions in a timely
manner. If the application is working as expected it may be appropriate to
increase the size of the queue manager recovery log.
-------------------------------------------------------------------------------
09/23/20 23:24:24 - Process(277881.13) User(mqsystem) Program(amqzmuc0)
Host(ACCIMQ03) Installation(MQAppliance)
VRMF(8.0.0.11) QMgr(QMAN_ACC)

AMQ7487: Application acc-sligro-order-sa was preventing log space from being
released.

EXPLANATION:
A long running transaction was detected, this message is intended to help
identify the application associated with this long running transaction. Message
AMQ7469 or AMQ7485 has been issued indicating if the transaction was rolled
back or rolled forward in the log to allow the log space to be released.
Message AMQ7486 has been issued identifying the transaction context of the
transaction that was rolled back or rolled forwards. The application associated
with this transaction was running with Pid 277990, Tid 87, under application
name acc-sligro-order-sa, and under user identifier sa_mule_mq. The following
application context may also be useful in identifying the application causing
this behaviour: CHANNEL(MUL.SVRCONN) CONNAME(10.107.17.58) APPLDESC(WebSphere
MQ Channel). This message can be correllated with the previous AMQ7486 message
in the queue manager error logs.
ACTION:
Identify the application responsible for the long running unit of work and
ensure this application is creating and completing transactions in a timely
manner. If the application is working as expected it may be appropriate to
increase the size of the queue manager recovery log.
-------------------------------------------------------------------------------
------------------------------
Bernard Pittens
Integration Engeneer
Sligro Foodgroup B.V.
Veghel
------------------------------

Original Message:
Sent: Wed September 23, 2020 01:42 PM
From: Luc-Michel Demey
Subject: AMQ7487: Application xxx was preventing log space from being released

Hello,
Logs have the default size, which is often too small.
The only solution is to have larger logs. But this requires deleting and then re-creating the Queue Manager.
My recommendation is to use at least :
Logfilepages = 40960
We should also evaluate the possibility of switching to linear logs, this will make things much easier (crtmqm -lla ...)
An alternative would be to increase the number of primary logs from 32 to 250 by modifying the qm.ini and restarting the Queue Manager.

------------------------------
Luc-Michel Demey
DEMEY CONSULTING

Original Message:
Sent: Wed September 23, 2020 01:03 PM
From: Bernard Pittens
Subject: AMQ7487: Application xxx was preventing log space from being released


Hi,

I see this message and I tried to do everything to solve this (restart Qmanager, and restart system)  We use MQ Appliance M2001B on IBM V8.0011

AMQ7487: Application acc-sligro-order-sa was preventing log space from being

Ok it has sometihing to do with logging, we use these log configuration:

LogPrimaryFiles = 32
LogSecondaryFiles = 32
Logfilepages = 4096
LogType = Circular.
LogBufferedpages = 0
LogwriteIntegrity = TripleWrite.

Since a very short time (this week) we are putting hundert of messages of 5,5 MB on the system. 
The  AMQ 7487 warning is only send when sending this files. But we HAVE to send/accept  5.5 MB XML files.
By the way its not only a warning it is rolling back messages also like stated in our logfiles.

What must be done to reset logs in memory or anyway that we can continue, or what I have to  change ?
Is there a reset command for this assuming it is allowed to lose all messages on the queues ?

We run for 3 year now with the above logconfig. We have accepted big files before untill 35 MB. That why we use MQ and a thick heavy MQ Appliance system. 
If we want to receive permanently logfiles of 5 MB what need to be changed in the configuration ?

Thanks









------------------------------
Bernard Pittens
Integration Engeneer
Sligro Foodgroup B.V.
Veghel
------------------------------​

Hi Bernard

As I think you've already realised, the issue here isn't so much the size of the messages (though that is relevant) as the duration of the transactions.  As long as any transaction on the oldest log page is still in flight, that log cannot be reused - and this won't just be the transactions for this queue/message type in isolation, but also any other transaction/applications running on the queue manager.   To free up log extents, the queue manager then had to start rolling back the longest running transactions.

Sizing logs appropriately has always been a tricky area of queue manager configuration and we've put quite a bit of effort into trying to improve the knowledge center in this area and give more guidance in recent releases, see for example https://www.ibm.com/support/knowledgecenter/SSFKSJ_latest/com.ibm.mq.con.doc/q018476_.htm - hopefully if you haven't seen it already you'll find that useful.  I think it answers (or confirms the answers you had arrived at for) the questions in your post.

Anthony

------------------------------
Anthony Beardsmore
IBM MQ Development
IBM
------------------------------

Original Message:
Sent: Wed September 23, 2020 06:00 PM
From: Bernard Pittens
Subject: AMQ7487: Application xxx was preventing log space from being released


Hi,
Sorry I have changed this messages a couple of times this morning.

HI @Anthony Beardsmore maybe you can have a look at this request ?

Thank you Luc-Michel for your answer, increasing the LogPrimary and LogSecundary files  both to 250 solve the problem temporaly.
On 180 files of 5 MB it  gives the same error again, which is strange because it is just approximately 1 GB on storage.
By the way after changing these variables we restarted the Qmanager so the new LogPrimaryFiles and LogSecondaryFiles  should be active.

Ok I have done some research on this:

Please verify this:
(LogprimaryFiles + LogSecondaryPages) *  LogFilepages * 4 kb = Total storage circular logging.
IBM Best practices like it seems and our default  before yesterday:
(32 + 32)  *  4096 * 4kb = 1024 MB (1GB)  
Maximum:
(250+250) * 65535 * 4kb = 131.000 MB (131  GB).
Our Actual  since yesterday:
(250+250) * 4096 * 4kb = 8.000 MB (8  GB).

I think the relation with the circular logging space is there only for messages which are in transit when using programs which use a manual commit for example. 

I mean this:
A MQ program is running and get a message from a queue, does things and after that transaction is done it gives a manual commit. After the manual commit is done the transaction is finished and the data on the circular logging regarding this transaction can be flushed.

Correct ?

When I use a lot of circular logging space by sending big files with programs which are also in transaction modus so with a manual commit then I have a problem, because if circular log space is used by programs which are in transaction modus then the next program can't  write to a queue because the logging is full.

So there is not a dependency with the number of messages on the queue but there is a dependency with the number of messages which are in transaction at the Qmanager.

Am I right about this ??

The strange thing is then that when I run a program and the big messages on the queue increase to 200 messages of 5 MB the error happens.
I can't get my head around that part.

So if I want to increase the circular logging space to use programs with a Manual commit then I have to keep in mind how many space I need for programs which are in transaction or is there also a relation with messages on queue ?

And when I set the values to the max(250,250, 65535) and have 131 GB for circular logging what is the disadvantage of this setting ?
Remember I have M2001B power !

Is there a best practice for my case ?

Sending 8000 files of 5 MB and storing it on the queue's for a couple of hours.
And also about 100.000 small files with an average size  of 10 kb.

I have added the stacktrace below:

Thanks

09/23/20 23:24:24 - Process(277881.13) User(mqsystem) Program(amqzmuc0)
Host(ACCIMQ03) Installation(MQAppliance)
VRMF(8.0.0.11) QMgr(QMAN_ACC)

AMQ7469: Transactions rolled back to release log space.

EXPLANATION:
The log space for the queue manager is becoming full. One or more long-running
transactions have been rolled back to release log space so that the queue
manager can continue to process requests.
ACTION:
Try to ensure that the duration of your transactions is not excessive. Consider
increasing the size of the log to allow transactions to last longer before the
log starts to become full.
-------------------------------------------------------------------------------
09/23/20 23:24:24 - Process(277881.13) User(mqsystem) Program(amqzmuc0)
Host(ACCIMQ03) Installation(MQAppliance)
VRMF(8.0.0.11) QMgr(QMAN_ACC)

AMQ7486: Transaction 0.16393 was preventing log space from being released.

EXPLANATION:
A long running transaction was detected. Message AMQ7469 or AMQ7485 has been
issued indicating if the transaction was rolled back or rolled forward in the
log to allow the log space to be released. The internal transaction identifier
is 0.16393 which can be correlated with 'dspmqtrn -a' output. The transaction
started at 22.24.49 2020-09-23 and first wrote to the queue manager recovery
log at 22.24.49 2020-09-23 . The following transaction context may be useful
in identifying the application causing this behaviour: TRANNUM(0.16393) . This
message can be correllated with the previous AMQ7469 or AMQ7485 message in the
queue manager error logs.
ACTION:
Identify the application responsible for the long running unit of work and
ensure this application is creating and completing transactions in a timely
manner. If the application is working as expected it may be appropriate to
increase the size of the queue manager recovery log.
-------------------------------------------------------------------------------
09/23/20 23:24:24 - Process(277881.13) User(mqsystem) Program(amqzmuc0)
Host(ACCIMQ03) Installation(MQAppliance)
VRMF(8.0.0.11) QMgr(QMAN_ACC)

AMQ7487: Application acc-sligro-order-sa was preventing log space from being
released.

EXPLANATION:
A long running transaction was detected, this message is intended to help
identify the application associated with this long running transaction. Message
AMQ7469 or AMQ7485 has been issued indicating if the transaction was rolled
back or rolled forward in the log to allow the log space to be released.
Message AMQ7486 has been issued identifying the transaction context of the
transaction that was rolled back or rolled forwards. The application associated
with this transaction was running with Pid 277990, Tid 87, under application
name acc-sligro-order-sa, and under user identifier sa_mule_mq. The following
application context may also be useful in identifying the application causing
this behaviour: CHANNEL(MUL.SVRCONN) CONNAME(10.107.17.58) APPLDESC(WebSphere
MQ Channel). This message can be correllated with the previous AMQ7486 message
in the queue manager error logs.
ACTION:
Identify the application responsible for the long running unit of work and
ensure this application is creating and completing transactions in a timely
manner. If the application is working as expected it may be appropriate to
increase the size of the queue manager recovery log.
-------------------------------------------------------------------------------
------------------------------
Bernard Pittens
Integration Engeneer
Sligro Foodgroup B.V.
Veghel

Original Message:
Sent: Wed September 23, 2020 01:42 PM
From: Luc-Michel Demey
Subject: AMQ7487: Application xxx was preventing log space from being released

Hello,
Logs have the default size, which is often too small.
The only solution is to have larger logs. But this requires deleting and then re-creating the Queue Manager.
My recommendation is to use at least :
Logfilepages = 40960
We should also evaluate the possibility of switching to linear logs, this will make things much easier (crtmqm -lla ...)
An alternative would be to increase the number of primary logs from 32 to 250 by modifying the qm.ini and restarting the Queue Manager.

------------------------------
Luc-Michel Demey
DEMEY CONSULTING

Original Message:
Sent: Wed September 23, 2020 01:03 PM
From: Bernard Pittens
Subject: AMQ7487: Application xxx was preventing log space from being released


Hi,

I see this message and I tried to do everything to solve this (restart Qmanager, and restart system)  We use MQ Appliance M2001B on IBM V8.0011

AMQ7487: Application acc-sligro-order-sa was preventing log space from being

Ok it has sometihing to do with logging, we use these log configuration:

LogPrimaryFiles = 32
LogSecondaryFiles = 32
Logfilepages = 4096
LogType = Circular.
LogBufferedpages = 0
LogwriteIntegrity = TripleWrite.

Since a very short time (this week) we are putting hundert of messages of 5,5 MB on the system. 
The  AMQ 7487 warning is only send when sending this files. But we HAVE to send/accept  5.5 MB XML files.
By the way its not only a warning it is rolling back messages also like stated in our logfiles.

What must be done to reset logs in memory or anyway that we can continue, or what I have to  change ?
Is there a reset command for this assuming it is allowed to lose all messages on the queues ?

We run for 3 year now with the above logconfig. We have accepted big files before untill 35 MB. That why we use MQ and a thick heavy MQ Appliance system. 
If we want to receive permanently logfiles of 5 MB what need to be changed in the configuration ?

Thanks









------------------------------
Bernard Pittens
Integration Engeneer
Sligro Foodgroup B.V.
Veghel
------------------------------​

@Bernard Pittens - one thing I forgot to address is the downside of very large log files.  Aside from consuming a lot of storage, the biggest problem with supporting very large, long running transactions in this way will be if and when you need to restart the queue manager.  Especially on an 'unexpected' restart such as an HA failover, having to replay a huge amount of transaction data from logs may be very expensive and time consuming.  Best practice therefore is to size the logs appropriately to support the largest transactions you require, and discourage applications from 'abusing' this with very long running transactions with many/large messages.

Hope that makes sense,
Anthony​

------------------------------
Anthony Beardsmore
IBM MQ Development
IBM
------------------------------

Original Message:
Sent: Thu September 24, 2020 05:55 AM
From: Anthony Beardsmore
Subject: AMQ7487: Application xxx was preventing log space from being released

Hi Bernard

As I think you've already realised, the issue here isn't so much the size of the messages (though that is relevant) as the duration of the transactions.  As long as any transaction on the oldest log page is still in flight, that log cannot be reused - and this won't just be the transactions for this queue/message type in isolation, but also any other transaction/applications running on the queue manager.   To free up log extents, the queue manager then had to start rolling back the longest running transactions.

Sizing logs appropriately has always been a tricky area of queue manager configuration and we've put quite a bit of effort into trying to improve the knowledge center in this area and give more guidance in recent releases, see for example https://www.ibm.com/support/knowledgecenter/SSFKSJ_latest/com.ibm.mq.con.doc/q018476_.htm - hopefully if you haven't seen it already you'll find that useful.  I think it answers (or confirms the answers you had arrived at for) the questions in your post.

Anthony

------------------------------
Anthony Beardsmore
IBM MQ Development
IBM

Original Message:
Sent: Wed September 23, 2020 06:00 PM
From: Bernard Pittens
Subject: AMQ7487: Application xxx was preventing log space from being released


Hi,
Sorry I have changed this messages a couple of times this morning.

HI @Anthony Beardsmore maybe you can have a look at this request ?

Thank you Luc-Michel for your answer, increasing the LogPrimary and LogSecundary files  both to 250 solve the problem temporaly.
On 180 files of 5 MB it  gives the same error again, which is strange because it is just approximately 1 GB on storage.
By the way after changing these variables we restarted the Qmanager so the new LogPrimaryFiles and LogSecondaryFiles  should be active.

Ok I have done some research on this:

Please verify this:
(LogprimaryFiles + LogSecondaryPages) *  LogFilepages * 4 kb = Total storage circular logging.
IBM Best practices like it seems and our default  before yesterday:
(32 + 32)  *  4096 * 4kb = 1024 MB (1GB)  
Maximum:
(250+250) * 65535 * 4kb = 131.000 MB (131  GB).
Our Actual  since yesterday:
(250+250) * 4096 * 4kb = 8.000 MB (8  GB).

I think the relation with the circular logging space is there only for messages which are in transit when using programs which use a manual commit for example. 

I mean this:
A MQ program is running and get a message from a queue, does things and after that transaction is done it gives a manual commit. After the manual commit is done the transaction is finished and the data on the circular logging regarding this transaction can be flushed.

Correct ?

When I use a lot of circular logging space by sending big files with programs which are also in transaction modus so with a manual commit then I have a problem, because if circular log space is used by programs which are in transaction modus then the next program can't  write to a queue because the logging is full.

So there is not a dependency with the number of messages on the queue but there is a dependency with the number of messages which are in transaction at the Qmanager.

Am I right about this ??

The strange thing is then that when I run a program and the big messages on the queue increase to 200 messages of 5 MB the error happens.
I can't get my head around that part.

So if I want to increase the circular logging space to use programs with a Manual commit then I have to keep in mind how many space I need for programs which are in transaction or is there also a relation with messages on queue ?

And when I set the values to the max(250,250, 65535) and have 131 GB for circular logging what is the disadvantage of this setting ?
Remember I have M2001B power !

Is there a best practice for my case ?

Sending 8000 files of 5 MB and storing it on the queue's for a couple of hours.
And also about 100.000 small files with an average size  of 10 kb.

I have added the stacktrace below:

Thanks

09/23/20 23:24:24 - Process(277881.13) User(mqsystem) Program(amqzmuc0)
Host(ACCIMQ03) Installation(MQAppliance)
VRMF(8.0.0.11) QMgr(QMAN_ACC)

AMQ7469: Transactions rolled back to release log space.

EXPLANATION:
The log space for the queue manager is becoming full. One or more long-running
transactions have been rolled back to release log space so that the queue
manager can continue to process requests.
ACTION:
Try to ensure that the duration of your transactions is not excessive. Consider
increasing the size of the log to allow transactions to last longer before the
log starts to become full.
-------------------------------------------------------------------------------
09/23/20 23:24:24 - Process(277881.13) User(mqsystem) Program(amqzmuc0)
Host(ACCIMQ03) Installation(MQAppliance)
VRMF(8.0.0.11) QMgr(QMAN_ACC)

AMQ7486: Transaction 0.16393 was preventing log space from being released.

EXPLANATION:
A long running transaction was detected. Message AMQ7469 or AMQ7485 has been
issued indicating if the transaction was rolled back or rolled forward in the
log to allow the log space to be released. The internal transaction identifier
is 0.16393 which can be correlated with 'dspmqtrn -a' output. The transaction
started at 22.24.49 2020-09-23 and first wrote to the queue manager recovery
log at 22.24.49 2020-09-23 . The following transaction context may be useful
in identifying the application causing this behaviour: TRANNUM(0.16393) . This
message can be correllated with the previous AMQ7469 or AMQ7485 message in the
queue manager error logs.
ACTION:
Identify the application responsible for the long running unit of work and
ensure this application is creating and completing transactions in a timely
manner. If the application is working as expected it may be appropriate to
increase the size of the queue manager recovery log.
-------------------------------------------------------------------------------
09/23/20 23:24:24 - Process(277881.13) User(mqsystem) Program(amqzmuc0)
Host(ACCIMQ03) Installation(MQAppliance)
VRMF(8.0.0.11) QMgr(QMAN_ACC)

AMQ7487: Application acc-sligro-order-sa was preventing log space from being
released.

EXPLANATION:
A long running transaction was detected, this message is intended to help
identify the application associated with this long running transaction. Message
AMQ7469 or AMQ7485 has been issued indicating if the transaction was rolled
back or rolled forward in the log to allow the log space to be released.
Message AMQ7486 has been issued identifying the transaction context of the
transaction that was rolled back or rolled forwards. The application associated
with this transaction was running with Pid 277990, Tid 87, under application
name acc-sligro-order-sa, and under user identifier sa_mule_mq. The following
application context may also be useful in identifying the application causing
this behaviour: CHANNEL(MUL.SVRCONN) CONNAME(10.107.17.58) APPLDESC(WebSphere
MQ Channel). This message can be correllated with the previous AMQ7486 message
in the queue manager error logs.
ACTION:
Identify the application responsible for the long running unit of work and
ensure this application is creating and completing transactions in a timely
manner. If the application is working as expected it may be appropriate to
increase the size of the queue manager recovery log.
-------------------------------------------------------------------------------
------------------------------
Bernard Pittens
Integration Engeneer
Sligro Foodgroup B.V.
Veghel

Original Message:
Sent: Wed September 23, 2020 01:42 PM
From: Luc-Michel Demey
Subject: AMQ7487: Application xxx was preventing log space from being released

Hello,
Logs have the default size, which is often too small.
The only solution is to have larger logs. But this requires deleting and then re-creating the Queue Manager.
My recommendation is to use at least :
Logfilepages = 40960
We should also evaluate the possibility of switching to linear logs, this will make things much easier (crtmqm -lla ...)
An alternative would be to increase the number of primary logs from 32 to 250 by modifying the qm.ini and restarting the Queue Manager.

------------------------------
Luc-Michel Demey
DEMEY CONSULTING

Original Message:
Sent: Wed September 23, 2020 01:03 PM
From: Bernard Pittens
Subject: AMQ7487: Application xxx was preventing log space from being released


Hi,

I see this message and I tried to do everything to solve this (restart Qmanager, and restart system)  We use MQ Appliance M2001B on IBM V8.0011

AMQ7487: Application acc-sligro-order-sa was preventing log space from being

Ok it has sometihing to do with logging, we use these log configuration:

LogPrimaryFiles = 32
LogSecondaryFiles = 32
Logfilepages = 4096
LogType = Circular.
LogBufferedpages = 0
LogwriteIntegrity = TripleWrite.

Since a very short time (this week) we are putting hundert of messages of 5,5 MB on the system. 
The  AMQ 7487 warning is only send when sending this files. But we HAVE to send/accept  5.5 MB XML files.
By the way its not only a warning it is rolling back messages also like stated in our logfiles.

What must be done to reset logs in memory or anyway that we can continue, or what I have to  change ?
Is there a reset command for this assuming it is allowed to lose all messages on the queues ?

We run for 3 year now with the above logconfig. We have accepted big files before untill 35 MB. That why we use MQ and a thick heavy MQ Appliance system. 
If we want to receive permanently logfiles of 5 MB what need to be changed in the configuration ?

Thanks









------------------------------
Bernard Pittens
Integration Engeneer
Sligro Foodgroup B.V.
Veghel
------------------------------​

Hello Antony,
To my knowledge, the time to resume a QM after an unexpected stop was more related to the number of uncommitted messages in the queues (in the sense of "sync" between the log and the queues) than to the size of the log.
I had also read (a long time ago) that switching between two log files was consuming, and that it was therefore necessary to privilege large logs.
Was I wrong?

------------------------------
Luc-Michel Demey
DEMEY CONSULTING
lmd@demey-consulting.fr
------------------------------

Original Message:
Sent: Thu September 24, 2020 06:09 AM
From: Anthony Beardsmore
Subject: AMQ7487: Application xxx was preventing log space from being released

@Bernard Pittens - one thing I forgot to address is the downside of very large log files.  Aside from consuming a lot of storage, the biggest problem with supporting very large, long running transactions in this way will be if and when you need to restart the queue manager.  Especially on an 'unexpected' restart such as an HA failover, having to replay a huge amount of transaction data from logs may be very expensive and time consuming.  Best practice therefore is to size the logs appropriately to support the largest transactions you require, and discourage applications from 'abusing' this with very long running transactions with many/large messages.

Hope that makes sense,
Anthony​

------------------------------
Anthony Beardsmore
IBM MQ Development
IBM

Original Message:
Sent: Thu September 24, 2020 05:55 AM
From: Anthony Beardsmore
Subject: AMQ7487: Application xxx was preventing log space from being released

Hi Bernard

As I think you've already realised, the issue here isn't so much the size of the messages (though that is relevant) as the duration of the transactions.  As long as any transaction on the oldest log page is still in flight, that log cannot be reused - and this won't just be the transactions for this queue/message type in isolation, but also any other transaction/applications running on the queue manager.   To free up log extents, the queue manager then had to start rolling back the longest running transactions.

Sizing logs appropriately has always been a tricky area of queue manager configuration and we've put quite a bit of effort into trying to improve the knowledge center in this area and give more guidance in recent releases, see for example https://www.ibm.com/support/knowledgecenter/SSFKSJ_latest/com.ibm.mq.con.doc/q018476_.htm - hopefully if you haven't seen it already you'll find that useful.  I think it answers (or confirms the answers you had arrived at for) the questions in your post.

Anthony

------------------------------
Anthony Beardsmore
IBM MQ Development
IBM

Original Message:
Sent: Wed September 23, 2020 06:00 PM
From: Bernard Pittens
Subject: AMQ7487: Application xxx was preventing log space from being released


Hi,
Sorry I have changed this messages a couple of times this morning.

HI @Anthony Beardsmore maybe you can have a look at this request ?

Thank you Luc-Michel for your answer, increasing the LogPrimary and LogSecundary files  both to 250 solve the problem temporaly.
On 180 files of 5 MB it  gives the same error again, which is strange because it is just approximately 1 GB on storage.
By the way after changing these variables we restarted the Qmanager so the new LogPrimaryFiles and LogSecondaryFiles  should be active.

Ok I have done some research on this:

Please verify this:
(LogprimaryFiles + LogSecondaryPages) *  LogFilepages * 4 kb = Total storage circular logging.
IBM Best practices like it seems and our default  before yesterday:
(32 + 32)  *  4096 * 4kb = 1024 MB (1GB)  
Maximum:
(250+250) * 65535 * 4kb = 131.000 MB (131  GB).
Our Actual  since yesterday:
(250+250) * 4096 * 4kb = 8.000 MB (8  GB).

I think the relation with the circular logging space is there only for messages which are in transit when using programs which use a manual commit for example. 

I mean this:
A MQ program is running and get a message from a queue, does things and after that transaction is done it gives a manual commit. After the manual commit is done the transaction is finished and the data on the circular logging regarding this transaction can be flushed.

Correct ?

When I use a lot of circular logging space by sending big files with programs which are also in transaction modus so with a manual commit then I have a problem, because if circular log space is used by programs which are in transaction modus then the next program can't  write to a queue because the logging is full.

So there is not a dependency with the number of messages on the queue but there is a dependency with the number of messages which are in transaction at the Qmanager.

Am I right about this ??

The strange thing is then that when I run a program and the big messages on the queue increase to 200 messages of 5 MB the error happens.
I can't get my head around that part.

So if I want to increase the circular logging space to use programs with a Manual commit then I have to keep in mind how many space I need for programs which are in transaction or is there also a relation with messages on queue ?

And when I set the values to the max(250,250, 65535) and have 131 GB for circular logging what is the disadvantage of this setting ?
Remember I have M2001B power !

Is there a best practice for my case ?

Sending 8000 files of 5 MB and storing it on the queue's for a couple of hours.
And also about 100.000 small files with an average size  of 10 kb.

I have added the stacktrace below:

Thanks

09/23/20 23:24:24 - Process(277881.13) User(mqsystem) Program(amqzmuc0)
Host(ACCIMQ03) Installation(MQAppliance)
VRMF(8.0.0.11) QMgr(QMAN_ACC)

AMQ7469: Transactions rolled back to release log space.

EXPLANATION:
The log space for the queue manager is becoming full. One or more long-running
transactions have been rolled back to release log space so that the queue
manager can continue to process requests.
ACTION:
Try to ensure that the duration of your transactions is not excessive. Consider
increasing the size of the log to allow transactions to last longer before the
log starts to become full.
-------------------------------------------------------------------------------
09/23/20 23:24:24 - Process(277881.13) User(mqsystem) Program(amqzmuc0)
Host(ACCIMQ03) Installation(MQAppliance)
VRMF(8.0.0.11) QMgr(QMAN_ACC)

AMQ7486: Transaction 0.16393 was preventing log space from being released.

EXPLANATION:
A long running transaction was detected. Message AMQ7469 or AMQ7485 has been
issued indicating if the transaction was rolled back or rolled forward in the
log to allow the log space to be released. The internal transaction identifier
is 0.16393 which can be correlated with 'dspmqtrn -a' output. The transaction
started at 22.24.49 2020-09-23 and first wrote to the queue manager recovery
log at 22.24.49 2020-09-23 . The following transaction context may be useful
in identifying the application causing this behaviour: TRANNUM(0.16393) . This
message can be correllated with the previous AMQ7469 or AMQ7485 message in the
queue manager error logs.
ACTION:
Identify the application responsible for the long running unit of work and
ensure this application is creating and completing transactions in a timely
manner. If the application is working as expected it may be appropriate to
increase the size of the queue manager recovery log.
-------------------------------------------------------------------------------
09/23/20 23:24:24 - Process(277881.13) User(mqsystem) Program(amqzmuc0)
Host(ACCIMQ03) Installation(MQAppliance)
VRMF(8.0.0.11) QMgr(QMAN_ACC)

AMQ7487: Application acc-sligro-order-sa was preventing log space from being
released.

EXPLANATION:
A long running transaction was detected, this message is intended to help
identify the application associated with this long running transaction. Message
AMQ7469 or AMQ7485 has been issued indicating if the transaction was rolled
back or rolled forward in the log to allow the log space to be released.
Message AMQ7486 has been issued identifying the transaction context of the
transaction that was rolled back or rolled forwards. The application associated
with this transaction was running with Pid 277990, Tid 87, under application
name acc-sligro-order-sa, and under user identifier sa_mule_mq. The following
application context may also be useful in identifying the application causing
this behaviour: CHANNEL(MUL.SVRCONN) CONNAME(10.107.17.58) APPLDESC(WebSphere
MQ Channel). This message can be correllated with the previous AMQ7486 message
in the queue manager error logs.
ACTION:
Identify the application responsible for the long running unit of work and
ensure this application is creating and completing transactions in a timely
manner. If the application is working as expected it may be appropriate to
increase the size of the queue manager recovery log.
-------------------------------------------------------------------------------
------------------------------
Bernard Pittens
Integration Engeneer
Sligro Foodgroup B.V.
Veghel

Original Message:
Sent: Wed September 23, 2020 01:42 PM
From: Luc-Michel Demey
Subject: AMQ7487: Application xxx was preventing log space from being released

Hello,
Logs have the default size, which is often too small.
The only solution is to have larger logs. But this requires deleting and then re-creating the Queue Manager.
My recommendation is to use at least :
Logfilepages = 40960
We should also evaluate the possibility of switching to linear logs, this will make things much easier (crtmqm -lla ...)
An alternative would be to increase the number of primary logs from 32 to 250 by modifying the qm.ini and restarting the Queue Manager.

------------------------------
Luc-Michel Demey
DEMEY CONSULTING

Original Message:
Sent: Wed September 23, 2020 01:03 PM
From: Bernard Pittens
Subject: AMQ7487: Application xxx was preventing log space from being released


Hi,

I see this message and I tried to do everything to solve this (restart Qmanager, and restart system)  We use MQ Appliance M2001B on IBM V8.0011

AMQ7487: Application acc-sligro-order-sa was preventing log space from being

Ok it has sometihing to do with logging, we use these log configuration:

LogPrimaryFiles = 32
LogSecondaryFiles = 32
Logfilepages = 4096
LogType = Circular.
LogBufferedpages = 0
LogwriteIntegrity = TripleWrite.

Since a very short time (this week) we are putting hundert of messages of 5,5 MB on the system. 
The  AMQ 7487 warning is only send when sending this files. But we HAVE to send/accept  5.5 MB XML files.
By the way its not only a warning it is rolling back messages also like stated in our logfiles.

What must be done to reset logs in memory or anyway that we can continue, or what I have to  change ?
Is there a reset command for this assuming it is allowed to lose all messages on the queues ?

We run for 3 year now with the above logconfig. We have accepted big files before untill 35 MB. That why we use MQ and a thick heavy MQ Appliance system. 
If we want to receive permanently logfiles of 5 MB what need to be changed in the configuration ?

Thanks









------------------------------
Bernard Pittens
Integration Engeneer
Sligro Foodgroup B.V.
Veghel
------------------------------​

Hi Luc-Michel

These factors are all related - if you configure for large number and size of logs but are not actually using them, then no, there probably won't be much impact on restart time.  On the other hand, by doing this you are 'allowing' applications to get themselves in trouble by building up large amounts of uncommitted data, and you may not discover you have an issue until an HA failover at peak business hours of course...

I wrote up a blog entry touching on some of this a while ago, but like a lot of such things it seems to have got buried... I've reposted at https://community.ibm.com/community/user/middleware/blogs/anthony-beardsmore1/2020/09/24/ibmmq-restart-times as I think this is all still accurate (and I hope useful) information.

------------------------------
Anthony Beardsmore
IBM MQ Development
IBM
------------------------------

Original Message:
Sent: Thu September 24, 2020 06:40 AM
From: Luc-Michel Demey
Subject: AMQ7487: Application xxx was preventing log space from being released

Hello Antony,
To my knowledge, the time to resume a QM after an unexpected stop was more related to the number of uncommitted messages in the queues (in the sense of "sync" between the log and the queues) than to the size of the log.
I had also read (a long time ago) that switching between two log files was consuming, and that it was therefore necessary to privilege large logs.
Was I wrong?

------------------------------
Luc-Michel Demey
DEMEY CONSULTING
lmd@demey-consulting.fr

Original Message:
Sent: Thu September 24, 2020 06:09 AM
From: Anthony Beardsmore
Subject: AMQ7487: Application xxx was preventing log space from being released

@Bernard Pittens - one thing I forgot to address is the downside of very large log files.  Aside from consuming a lot of storage, the biggest problem with supporting very large, long running transactions in this way will be if and when you need to restart the queue manager.  Especially on an 'unexpected' restart such as an HA failover, having to replay a huge amount of transaction data from logs may be very expensive and time consuming.  Best practice therefore is to size the logs appropriately to support the largest transactions you require, and discourage applications from 'abusing' this with very long running transactions with many/large messages.

Hope that makes sense,
Anthony​

------------------------------
Anthony Beardsmore
IBM MQ Development
IBM

Original Message:
Sent: Thu September 24, 2020 05:55 AM
From: Anthony Beardsmore
Subject: AMQ7487: Application xxx was preventing log space from being released

Hi Bernard

As I think you've already realised, the issue here isn't so much the size of the messages (though that is relevant) as the duration of the transactions.  As long as any transaction on the oldest log page is still in flight, that log cannot be reused - and this won't just be the transactions for this queue/message type in isolation, but also any other transaction/applications running on the queue manager.   To free up log extents, the queue manager then had to start rolling back the longest running transactions.

Sizing logs appropriately has always been a tricky area of queue manager configuration and we've put quite a bit of effort into trying to improve the knowledge center in this area and give more guidance in recent releases, see for example https://www.ibm.com/support/knowledgecenter/SSFKSJ_latest/com.ibm.mq.con.doc/q018476_.htm - hopefully if you haven't seen it already you'll find that useful.  I think it answers (or confirms the answers you had arrived at for) the questions in your post.

Anthony

------------------------------
Anthony Beardsmore
IBM MQ Development
IBM

Original Message:
Sent: Wed September 23, 2020 06:00 PM
From: Bernard Pittens
Subject: AMQ7487: Application xxx was preventing log space from being released


Hi,
Sorry I have changed this messages a couple of times this morning.

HI @Anthony Beardsmore maybe you can have a look at this request ?

Thank you Luc-Michel for your answer, increasing the LogPrimary and LogSecundary files  both to 250 solve the problem temporaly.
On 180 files of 5 MB it  gives the same error again, which is strange because it is just approximately 1 GB on storage.
By the way after changing these variables we restarted the Qmanager so the new LogPrimaryFiles and LogSecondaryFiles  should be active.

Ok I have done some research on this:

Please verify this:
(LogprimaryFiles + LogSecondaryPages) *  LogFilepages * 4 kb = Total storage circular logging.
IBM Best practices like it seems and our default  before yesterday:
(32 + 32)  *  4096 * 4kb = 1024 MB (1GB)  
Maximum:
(250+250) * 65535 * 4kb = 131.000 MB (131  GB).
Our Actual  since yesterday:
(250+250) * 4096 * 4kb = 8.000 MB (8  GB).

I think the relation with the circular logging space is there only for messages which are in transit when using programs which use a manual commit for example. 

I mean this:
A MQ program is running and get a message from a queue, does things and after that transaction is done it gives a manual commit. After the manual commit is done the transaction is finished and the data on the circular logging regarding this transaction can be flushed.

Correct ?

When I use a lot of circular logging space by sending big files with programs which are also in transaction modus so with a manual commit then I have a problem, because if circular log space is used by programs which are in transaction modus then the next program can't  write to a queue because the logging is full.

So there is not a dependency with the number of messages on the queue but there is a dependency with the number of messages which are in transaction at the Qmanager.

Am I right about this ??

The strange thing is then that when I run a program and the big messages on the queue increase to 200 messages of 5 MB the error happens.
I can't get my head around that part.

So if I want to increase the circular logging space to use programs with a Manual commit then I have to keep in mind how many space I need for programs which are in transaction or is there also a relation with messages on queue ?

And when I set the values to the max(250,250, 65535) and have 131 GB for circular logging what is the disadvantage of this setting ?
Remember I have M2001B power !

Is there a best practice for my case ?

Sending 8000 files of 5 MB and storing it on the queue's for a couple of hours.
And also about 100.000 small files with an average size  of 10 kb.

I have added the stacktrace below:

Thanks

09/23/20 23:24:24 - Process(277881.13) User(mqsystem) Program(amqzmuc0)
Host(ACCIMQ03) Installation(MQAppliance)
VRMF(8.0.0.11) QMgr(QMAN_ACC)

AMQ7469: Transactions rolled back to release log space.

EXPLANATION:
The log space for the queue manager is becoming full. One or more long-running
transactions have been rolled back to release log space so that the queue
manager can continue to process requests.
ACTION:
Try to ensure that the duration of your transactions is not excessive. Consider
increasing the size of the log to allow transactions to last longer before the
log starts to become full.
-------------------------------------------------------------------------------
09/23/20 23:24:24 - Process(277881.13) User(mqsystem) Program(amqzmuc0)
Host(ACCIMQ03) Installation(MQAppliance)
VRMF(8.0.0.11) QMgr(QMAN_ACC)

AMQ7486: Transaction 0.16393 was preventing log space from being released.

EXPLANATION:
A long running transaction was detected. Message AMQ7469 or AMQ7485 has been
issued indicating if the transaction was rolled back or rolled forward in the
log to allow the log space to be released. The internal transaction identifier
is 0.16393 which can be correlated with 'dspmqtrn -a' output. The transaction
started at 22.24.49 2020-09-23 and first wrote to the queue manager recovery
log at 22.24.49 2020-09-23 . The following transaction context may be useful
in identifying the application causing this behaviour: TRANNUM(0.16393) . This
message can be correllated with the previous AMQ7469 or AMQ7485 message in the
queue manager error logs.
ACTION:
Identify the application responsible for the long running unit of work and
ensure this application is creating and completing transactions in a timely
manner. If the application is working as expected it may be appropriate to
increase the size of the queue manager recovery log.
-------------------------------------------------------------------------------
09/23/20 23:24:24 - Process(277881.13) User(mqsystem) Program(amqzmuc0)
Host(ACCIMQ03) Installation(MQAppliance)
VRMF(8.0.0.11) QMgr(QMAN_ACC)

AMQ7487: Application acc-sligro-order-sa was preventing log space from being
released.

EXPLANATION:
A long running transaction was detected, this message is intended to help
identify the application associated with this long running transaction. Message
AMQ7469 or AMQ7485 has been issued indicating if the transaction was rolled
back or rolled forward in the log to allow the log space to be released.
Message AMQ7486 has been issued identifying the transaction context of the
transaction that was rolled back or rolled forwards. The application associated
with this transaction was running with Pid 277990, Tid 87, under application
name acc-sligro-order-sa, and under user identifier sa_mule_mq. The following
application context may also be useful in identifying the application causing
this behaviour: CHANNEL(MUL.SVRCONN) CONNAME(10.107.17.58) APPLDESC(WebSphere
MQ Channel). This message can be correllated with the previous AMQ7486 message
in the queue manager error logs.
ACTION:
Identify the application responsible for the long running unit of work and
ensure this application is creating and completing transactions in a timely
manner. If the application is working as expected it may be appropriate to
increase the size of the queue manager recovery log.
-------------------------------------------------------------------------------
------------------------------
Bernard Pittens
Integration Engeneer
Sligro Foodgroup B.V.
Veghel

Original Message:
Sent: Wed September 23, 2020 01:42 PM
From: Luc-Michel Demey
Subject: AMQ7487: Application xxx was preventing log space from being released

Hello,
Logs have the default size, which is often too small.
The only solution is to have larger logs. But this requires deleting and then re-creating the Queue Manager.
My recommendation is to use at least :
Logfilepages = 40960
We should also evaluate the possibility of switching to linear logs, this will make things much easier (crtmqm -lla ...)
An alternative would be to increase the number of primary logs from 32 to 250 by modifying the qm.ini and restarting the Queue Manager.

------------------------------
Luc-Michel Demey
DEMEY CONSULTING

Original Message:
Sent: Wed September 23, 2020 01:03 PM
From: Bernard Pittens
Subject: AMQ7487: Application xxx was preventing log space from being released


Hi,

I see this message and I tried to do everything to solve this (restart Qmanager, and restart system)  We use MQ Appliance M2001B on IBM V8.0011

AMQ7487: Application acc-sligro-order-sa was preventing log space from being

Ok it has sometihing to do with logging, we use these log configuration:

LogPrimaryFiles = 32
LogSecondaryFiles = 32
Logfilepages = 4096
LogType = Circular.
LogBufferedpages = 0
LogwriteIntegrity = TripleWrite.

Since a very short time (this week) we are putting hundert of messages of 5,5 MB on the system. 
The  AMQ 7487 warning is only send when sending this files. But we HAVE to send/accept  5.5 MB XML files.
By the way its not only a warning it is rolling back messages also like stated in our logfiles.

What must be done to reset logs in memory or anyway that we can continue, or what I have to  change ?
Is there a reset command for this assuming it is allowed to lose all messages on the queues ?

We run for 3 year now with the above logconfig. We have accepted big files before untill 35 MB. That why we use MQ and a thick heavy MQ Appliance system. 
If we want to receive permanently logfiles of 5 MB what need to be changed in the configuration ?

Thanks









------------------------------
Bernard Pittens
Integration Engeneer
Sligro Foodgroup B.V.
Veghel
------------------------------​