MQ file system got 100% used in one of our queue managers and we found that our system.cluster.transmit queue is occupied the full space so I have deleted the q file.so file system issue got resolved.Now I was trying to delete the transmit local queue using delete qlocal command so I need to create the queue again as my queue got damaged but when I am trying to delete the queue I am getting MQ object is in use and I checked the handles to kill it but it says MQ object got damaged so please help me to how to delete the queue now.
If you are running linear logging you can recreate the damaged object, but in this case that would fill the file system. Instead, temporarily define a new QMgr and then get a copy of its file for the same queue and drop it into the directory where you deleted the file.
As a side note, you might also want to start a new question asking how to delete the messages in the XMitQ without blowing away the file.
Related
One of my nifi nodes/instances is refusing to reconnect to the cluster
Proposed flow is not inheritable by the flow controller and cannot completely replace the current flow due to: Proposed Flow does not contain a Connection with ID 4d2c4e9d-0176-1000-0000-0000310c611f but this instance has data queued in that connection, updateId=307]
Without entering in why this happened, how can I recover from this error? Even if I overwrite the flow.xml.gz file it will refuse to accept it because it knows that there is data queued for that connection.
Can I flush / delete that data somehow?
I had tried to delete/move
flow.xml.gz
flowfile_repository
content_repository
database_repository
But I get the same error on startup, where does Nifi track that connection 4d2c4e9d-0176-1000-0000-0000310c611f had data in this nifi node?
Deleting (back it up first) the flow.xml.gz file should fix it.
Make sure that you are actually moving/deleting the right flox.xml.gz file since it may not be in the default location.
So check the actual location of the flow file at $NIFI_HOME/conf/nifi.properties , look for nifi.flow.configuration.file. Then delete that one (backup first) and the node should be able to reconnect.
I am working on a design where I need to move files from one Storage account to another storage account. And after let's say a week, delete those files.
One file is going to successfully move I can either either send a message to Event Hub or Write a record into SQL DB
For Deletion of files I have two approach.
I have two approach:
Polling
Poll daily for SQL DB entry and then check the last modified timestamp and delete it.
Update the SQL DB entry for the file and reflect that file is deleted.
Event Based
Send a message to event grid as soon as the file is deleted.
However, I am not able to figure out how to wait for 1 week before I delete a file. If I had to delete file immediately I can do upon receiving message.
Have you considered using Service Bus queues with schedule feature? Service Bus queues/topics may be a better fit for delayed processing requirement.
https://learn.microsoft.com/en-us/azure/service-bus-messaging/message-sequencing#scheduled-messages
Unable to restart the queue manager getting error message as AMQ7017 Log not available
Checked the FDC file and getting the error message as AMQ6118 An internal WebSphere MQ error has occurred 7017
We have remounted the file system and log file is also exists but still not able to restart the queue manager
please let us know your suggestions ASAP
The queue manager generates AMQ7017 for different reasons and following are some of the reasons.
The queue manager was not able to find a specific log file
Your update indicates the log file is there.
Problem in accessing the log file
Check the file permissions of the log files and log control file
If you see any FDCs with BADLSN errors, then there is a possibility of
a MQ defect or a file system issue.
Check for any known defects fixed. But in some cases, an APAR fix only
prevents the problem in future and may not fix the current issue in
queue manager restart.
An immediate workaround would be to backup the queue manager and then rebuild or recreate the queue manager or restore from backup. If this not an option then I suggest opening ticket with IBM.
When trying to start a queue manager I get a AMQ7017 Log not available message. I have checked, the LogPath for the queue manager in the mqs.ini file is correct. When the problem started I checked and there were two log files in the log folder for the manager: S000000 and S0000002. I simply copied the first one and renamed the copy to S000001 (with the correct number of zeroes). Still the same error.
How can I fix this issue?
I hope its not a production qmgr. Few options below.
You can restore the missing log file from backup and try to start.
Create a qmgr of the same name (in another machine) with the same qm.ini. Basically the log setting should be the same as this qmgr. Copy the log files from that machine to this qmgr and try to start the qmgr. If it starts, the qmgr might recover the persistent messages from the queue files. This is not recommended by IBM, but works in some situations. If its a non-production qmgr, this is the best way.
recreate the qmgr
i'm working on qmgr migration from 6.0 to 7.0, but i got problem when restoring V6.0 queue manager from 7.0 on windows. After re-installing MQ 6.0, i copied back the previous backup QMGR data and log, and then tried to start up that QMGR, for instance TEST01. However, that command strmqm TEST01 returns with no such QMGR existed.
The restore procedure i refer to is from infor center below
http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/index.jsp
and i backup and restore MQGR data and log through as below:
Backup
copy C:\Program Files (x86)\IBM\WebSphere MQ\Qmgrs\TEST01 under another path
copy C:\Program Files (x86)\IBM\WebSphere MQ\log\TEST01 under another path
Restore
copy above backup folder back to target path
So according to above operation, did i miss anything or do something wrong?
UPDATE:
This issue has been fixed. I forgot backing up the configuration information from the registry and restored it then. That's why MQ cannot recognize my QMGR at the very beginning.
Additionally, I've got another question here:
how to transfer configuration information from the registry to the mqs.ini file?
You are far better off not to migrate QMgrs but rather to create new ones at the new version. Although IBM has always provided an upgrade path, the implementation of certain functionality differs from version to version. For example, on Windows the registry settings in V6 are no longer used in V7.1 and higher. The requirement to upgrade usually comes from the belief that replacing the QMgr somehow loses something.
In fact, this is rarely the case. There is also nothing special about a QMgr that well-designed client applications would need to know its name. The host, port and channel uniquely identify a QMgr for a client application. If the app specifies the QMgr's name and it does not match, the connection fails. But the app can specify a blank QMgr name and the connection will succeed. The QMgr's name is automatically filled into the Reply-To QMgr field so requests are properly handled. The only thing that needs to know the name is a QRemote (which can be repointed) or a local app using bindings mode connection.
That said, to answer your question just performing the upgrade to V7.1 or V7.5 will move the QMgr's settings to the ini file.
this issue has been fixed. i forgot backing up the configuration information from the registry and restored it then. that's why MQ cannot recognize my QMGR at the very beginning.