SMQS scheduler: Queues stuck / block situation

Hi All
we have a Q stuck situation in ECC6.0 (ISU) with the Q name R3AUBUPA*, destination CRM, has status RUNNING. The implication of this is all other Q's get blocked and the this impacts the business operation. Currently we unregister and register the Q's and this clears the blocked Q and the backlogs.
1) The question is anybody aware of a know issue on SMQS or is there a setting / parameter that needs to be set/unset or parameter values that needs tweaking.
2) Also currently we have a dedicated resource to minitor this and address the issue, wonder if anyone has setup an alert in this context ?
Note -
a) All Q's are registered
b) Except for the workflow Q's all are type 3 connections.
c) the Q's are not confined to a server as that is not an option the client desires.
Regards
Srikanth

Hello Srikanth,
Txn:SMQS is used to de-rgister or register the destination.If you dereister/register a destination then data will not/will to that
destination.
You can go through the below set of notes for more details on queue hanlding and SMQS.
685366          Welche Queues sollen in einem CRM System registriert werden?
764081          CRM or R3 Backend is temporarily shut down
356228          qRFC occupies all work processes on the R/3 backend or the C
574774          Outbound queues hang in status STOP
564435          Additional information on CRM System copy
515579                          Customer message in the area: CRM-MW-COM
480543          CRM MW R&R queues in status STARTING (no processing)
580487          Guidelines for deactivating the mass queues CSA_MASS_BUPA
777965          Flow Debugging information through queues
Hope thils helps.
Best Regards,
Shanthala Kudva

Similar Messages

Queues indound blocked

I wanted to ask what can I check on my XI, because I often block queues indound, blocking the process of my interfaces.
thanks
umberto

Hi,
check in RWB and Message Monitoring for specific interface.
or
check in TCode SMQ2 for Inbound Queue monitoring
http://help.sap.com/saphelp_nw70/helpdata/EN/76/e12041c877f623e10000000a155106/frameset.htm
Queue Status in SMQ1 and Table ARFCRSTATE
Use
Depending on the way a Logical Unit of Work (LUW) is processed, an inbound queue, outbound queue or table ARFCRSTATE (status table of the LUWs in the tRFC/qRFC target system) can have different statuses.
Outbound Queue
The following statuses may be displayed in transaction SMQ1:
READY
·        The queue is ready for transmission. This status should only be a temporary status. However, in the following case this status can also be permanent: A queue has been locked manually via transaction SMQ1 or via a program, and then unlocked without being activated at the same time. This queue must be activated explicitly.
RUNNING
·        The first LUW of this queue is currently being processed. If a queue in this status hangs for more than 30 minutes, this may mean that the work process responsible for sending this LUW has been terminated. In this case you can activate this queue again.
Note that activating a queue in status RUNNING may cause a LUW to be executed several times if this LUW is still being processed in the target system at that time. We therefore recommend a waiting time of at least 30 minutes before you reactivate the queue.
EXECUTED
·        The first LUW of this queue has been processed. The system waits for a qRFC-internal confirmation from the target system before processing further LUWs. If a queue in this status hangs for more than 30 minutes, this may mean that the work process responsible for sending this LUW has been terminated. In contrast to status RUNNING, this current LUW has definitely been executed successfully. You can reactivate this queue without any problems. The qRFC Manager will automatically delete the LUW already executed and send the next LUW.
SYSFAIL
·        A serious error occurred in the target system while the first LUW of this queue was executed. The execution was interrupted. When you double-click on this status, the system displays an error text. For more information on this error, see the corresponding short dump in the target system (ST22). No background job is scheduled for a retry and the queue is no longer processed. To solve the problem, information from the affected application is required. See note 335162 for the special error text "connection closed".
CPICERR
·        During transmission or processing of the first LUW in the target system, a network or communication error occurred. When you double-click on this status, the system displays an error text. For more information on this error, see the syslog (SM21), the trace files dev_rd or dev_rfc*. Depending on the definition in transaction SM59 for the destination used, a batch job is scheduled for subsequent sending. Status CPICERR may also exist in the following cases although no communication error occurred: A qRFC application finds out that a LUW cannot be processed any further due to a temporary error in the application and therefore calls the RESTART_OF_BACKGROUNDTASK function module to prompt the qRFC Manager to cancel the execution of this LUW and to repeat this LUW later in accordance with the specification in transaction SM59. In this case, qRFC simulates a communication error with the text "Command to tRFC/qRFC: Execute LUW once again." If this error occurs very often, you must contact the corresponding application.
STOP
·        On this queue or a generic queue (for example BASIS_*) a lock was set explicitly (SMQ1 or programs). Note that the processing of qRFC never locks a queue. After having informed the corresponding application, you can unlock and activate this queue using transaction SMQ1.
WAITSTOP
·        The first LUW of this queue has dependencies to other queues, and at least one of these queues is currently still locked.
WAITING
·        The first LUW of this queue has dependencies to other queues, and at least one of these queues currently still contains other LUWs with higher priorities.
NOSEND
·        LUWs of this queue are never sent but retrieved by a special application. These queues are only used internally at SAP (BW or CRM during communication with Mobile Clients). Even if a LUW has been read by the corresponding application (BW, CRM), this status does not change. This LUW is only deleted from the queue if this application confirms collection (collective confirmation possible). Under no circumstances should this status be reset using transaction SMQ1 and the queue activated.
NOSENDS
·        During the qRFC call, the application determines at the same time that the current LUW is not sent immediately. This is used to debug the execution of an LUW via transaction SMQ1.
WAITUPDA
·        This status is set if qRFC is called within a transaction that also contains one or more update functions. As a result of this status, the LUW and thus the queue is blocked until the update has been completed successfully. If this status takes longer than a few minutes, check the status of the update or the update requests using transaction SM13. After a successful retroactive update, the blocked LUW is sent automatically. You can reset this status in the qRFC Monitor SMQ1, and reactivate the queue. Note that this can lead to possible inconsistencies in the application data between the two systems.
If you are using Releases 4.0x, 4.5x, 4.6A or 4.6B, and an update function with the "collective run" type exists in a LUW, an error in the kernel may cause this status. The queue also hangs in this case. This error has already been corrected with a kernel patch (see note 333878).
ARETRY
·        During LUW execution the application has diagnosed a temporary problem and has prompted the qRFC Manager in the sending system via a specific qRFC call to schedule a batch job for a repetition based on the definition in transaction SM59.
ANORETRY
·        During the LUW execution, the application has found a serious error and prompted the qRFC Manager via a specific qRFC call to cancel processing of this LUW. Information from the affected application is required to solve the problem. To solve the problem, information from the affected application is required.
MODIFY
·        Processing of this queue is locked temporarily because the LUW data is being modified.
Table ARFCRSTATE
You can use transaction SE16 to display the status:
EXECUTED
·        The related LUW is completely executed in the target system. The system waits for an internal tRFC/qRFC confirmation from the sending system before this entry is deleted.
HOLD
·        The corresponding application has processed this LUW in parts and wants this LUW to not be repeated in the case of subsequent network or communication errors (see SAP Note 366869 if there are many entries with this status).
WCONFIRM
·        During a LUW execution the application has prompted the tRFC/qRFC Manager to set status HOLD. If the LUW execution has already been completed but this application has not yet signaled the logical LUW end and if the tRFC/qRFC-internal confirmation from the sending system has been received, then this LUW receives status WCONFIRM.
If the respective application informs the tRFC/qRFC Manager about the logical LUW end, then this entry is deleted (see also SAP Note 366869 for more details).
Queue Status in SMQ2 and Table ARFCRSTATE
Use
Depending on the way a Logical Unit of Work (LUW) is processed, an inbound queue or the table ARFCRSTATE (status table of the LUWs in the tRFC/qRFC target system) can have different statuses.
Inbound Queue
The following statuses may be displayed in transaction SMQ2:
·        READY
The queue is ready for processing. This status should only be a temporary status. However, in the following case this status can also be permanent: A queue has been locked manually using transaction SMQ2 or using a program, and then unlocked without being activated at the same time. This queue must be activated explicitly.
·        RUNNING
The first LUW of this queue is currently being processed. If a queue in this status hangs for more than 30 minutes, this may mean that the work process responsible for processing this LUW has been terminated. In this case you can activate this queue again. Note that activating a queue in status RUNNING may cause a LUW to be executed several times if this LUW is still being processed in the target system at that time. We therefore recommend a waiting time of at least 30 minutes before you reactivate the queue.
·        SYSFAIL
A serious error occurred while the first LUW of this queue was being executed. The execution was interrupted. When you double-click on this status, the system displays an error text. For more information on this error, see the corresponding short dump in the target system (transaction ST22). No background job is scheduled for a retry and the queue is no longer processed. To solve the problem, information from the affected application is required. See SAP Note 335162 for the error text "connection closed".
·        CPICERR
A network or communication error occurred while the first LUW was being executed. When you double-click on this status, the system displays an error text. For more information on this error, see the syslog (transaction SM21) or the trace files dev_rd and dev_rfc*. Depending on the registration of this queue (SMQR), a background job is scheduled for a retry. See SAP Note 369524 for the error text u201CLogon failed". Status CPICERR may also exist in the following cases although no communication error occurred: A qRFC application finds out that a LUW cannot be processed any further due to a temporary error in the application and therefore calls the RESTART_OF_BACKGROUNDTASK function module to prompt the qRFC Manager to cancel the execution of this LUW and to repeat this LUW later in accordance with the specification in transaction SM59. In this case, qRFC simulates a communication error with the text "Command to tRFC/qRFC: Execute LUW once again." If this error occurs very often, you must contact the corresponding application.
·        STOP
On this queue or a generic queue (for example BASIS_*) a lock was set explicitly (SMQ2 or programs). Note that the processing of qRFC never locks a queue. After having informed the corresponding application, you can unlock this queue using transaction SMQ2.
·        WAITSTOP
The first LUW of this queue has dependencies to other queues, and at least one of these queues is currently still locked.
·        WAITING
The first LUW of this queue has dependencies to other queues, and at least one of these queues currently still contains other LUWs with higher priorities.
·        ARETRY
When the LUW was processed, the application diagnosed a temporary problem and has prompted the qRFC Manager with a specific qRFC call to schedule a background job for a retry, based on the registration in SMQR.
·        ANORETRY
When the LUW was processed, the application diagnosed a serious error and has prompted the qRFC Manager with a specific qRFC call to stop processing this LUW. To solve the problem, information from the affected application is required.
·        MODIFY
Processing of this queue is locked temporarily because the LUW data is being modified.
Table ARFCRSTATE
You can use transaction SE16 to display the status:
·        EXECUTED
The related LUW is completely executed in the target system. The system waits for an internal tRFC/qRFC confirmation from the sending system before this entry is deleted.
·        HOLD
The corresponding application has processed this LUW in parts and wants this LUW to not be repeated in the case of subsequent network or communication errors (see SAP Note 366869 if there are many entries with this status).
·        WCONFIRM
During a LUW execution the application has prompted the tRFC/qRFC Manager to set status HOLD. If the LUW execution has already been completed but this application has not yet signaled the logical LUW end and if the tRFC/qRFC-internal confirmation from the sending system has been received, then this LUW receives status WCONFIRM.
If the respective application informs the tRFC/qRFC Manager about the logical LUW end, then this entry is deleted (see also SAP Note 366869 for more details).
PS reward me if usefull
reg,
suresh

Credit Release thru VKM3 remove the schedule line delivery block ...

HI Gurus,
I have created the sales order with the delivery block at the schedule line. i have save the order . The order goes to the credit block . So when i release credit block with the help of VKM3 then system also removes the schedule line level block.
This is not std behaviour . Can any one come across such scenario ?
Details: I have removed the routine 101 in the OVB8 so that if order goes to credit block still order will have the confirm qty.
Also in the OVAK order type is mark D for automatic credit check.
Thanks in advance

Hi ,
I have checked the sales order thru the program but we are not using any user exit for the same.
Now i have found that if the qty is confirm on the first date i mean on the date given then system does not remove the block & if the ATP check suggest the diff date so there are two schedule line in this case block get removed ..
May be this is like after credit removes system must be running the ATP check again ..
Please help

SMQ2 queue is blocked and messages are in u201Cwaitingu201D status in RWB

Hello,
A SMQ2 queue is blocked with XXX data and these messages are in u201Cwaitingu201D state in RWB.
What could be the reason?
Im sure its not because of the space because all the messages which flow after that was there in the directory.
Regards,
Mathangi

Hi Mathangi,
double click on the queue and click on the first message which will direct to MONI
--> check what exactly the error is and try to resolve the error accordingly
if you are unable to do that
Right click on the first message and save LUV it will be saved in SMQ3
then unlock the queue and execute again it will process successfully..
later you can process the message which is saved
Regards,
Naveen

Queue gets blocked in Receiver System . Pls advice urgent

Hi All,
When I send data from CRM --- XI --- DM system
Whenever data comes at DM system everytime queue gets blocked and gets status "SYSFAIL".
Pls tell me how to solve this problem.
Regards

1.You can use transaction codes SMQR and SXMB_ADM for queue status resetting.
2.Use transaction codes SMQ1 and SMQ2 for deleting SYSFAIL files, and manually resending messages in the queues.(For activating queues in SMQ1 and SMQ2, you would need to first deregister them in SMQR or SXMB_ADM).
3.As a pre-requisite, the IS configuration parameter MONITOR QRFC_RESTART_ALLOWED should be set to 1.
/people/prashanth.azharuddin/blog/2006/11/24/some-errors-in-an-xi-production-environment
/people/sap.user72/blog/2005/11/29/xi-how-to-re-process-failed-xi-messages-automatically

SMQ2 - Found a queue with name "*" and all other queues stuck in STOP state

Hi all,
We have a problem on the ECC side, on outbound asynchronous proxies. Sometimes a new queue appears on SMQ2 there with name "", and with status "STOP". At this time, all other queues stuck with STOP status... the only way of resetting all those queues to RUNNING state again is to delete the queue named as ""...
Some of you has any idea how this queue "*" appears there and stop all other queues?
thanks
roberti

Hi Ravi,
Is not only about one queue stopped... the problem is this queue named ""... with status STOP, all other queues stops too with it. The only way to make things work again is to delete the queue named as ""... the problem is to discover what or who is creating this stupid "*" queue. I think that this is a procedural error on datacenter, but they are saying is not the case... I'm investigating, but if someone else has any idea about I would appreciate
thanks!
roberti

[Urgent] Queues are blocked in status SYSFAIL

Hi experts,
I have the following problem that arose unexpectedly in an XI 3.0 installation:
Queues are blocked in SYSFAIL status and when I click on one entry, I get message: XI Error CLIENT_RECEIVE_FAILED.INTERNAL: Queue stopped
It seems to me that J2EE stack cannot connect to ABAP stack.
When I test INTEGRATION_DIRECTORY_HMI connection in sm59, I get no reply..
I cannot logon to Visual Administrator. It stops at 99%.
Hardly can I connect to Integration Builder.
Any ideas.
I need your help ASAP.
Evaggelos

Hi Evaggelos,
>I cannot logon to Visual Administrator. It stops at 99%.
Is your XI installation over?
We had a similar problem in one of my earlier projects. We restarted the server and everything started working fine.
If it is possible you can try the same.
Regards,
Sumit

Why queues get blocked in XI

I have observed thet queues in XI get blocked even though there is no error.
When I unlock it , Queues get cleared.
Please let me know why queues get blocked .
Thanks in Advance.

Hi,
Queues might get blocked to various reasons.
The reasons i can think of are:
1) Contention for resources : If there is a contention for resources like memory, the first message of the queue gets blocked, causing subsequent messages to be blocked as well.
2) Huge messages: HUge payloads choke the queues.
3) Receiving system processing the messages slower than the sending system.
Regards,
Ravi Kanth Talagana

Queues are blocked in PI

Queues are blocked in PI,I am unable to release it from SMQ2.Can you please tell me what other methods can I follow to release them.Can I delete them?is it ok
Thanks

Hi there,
what is the error message showing there..
if open the queues you can c message there..
act according to that..
If in production system it is not a good idea to delete the queues.
Regards
Rao

WS_SDK XI 3.1 Query Scheduler Queue

We've a single XI 3.1 server running a single scheduler which processes one scheduled report at a time. Is it possible using the WS-SDK to query the scheduler queue to see how many reports are currently in the queue for process (i.e. those that should have been run, but are queued due at a report running at the moment)?
Cheers,
Jack

it is not possible to access the scheduler queue using WS or any SDK that's exposed. When a schedule is to be run CMS informs Job Server with the scheduling details, the schedule job goes from : pending - in process\running - complete ( success or failed). What you can possibly do is query all schedule instances that are in "pending state". Typically a report would be pending if: is is waiting on one of the events or it is a recurring schedule event and the next schedule time is not yet reached. Also it is possible that a report changes it status from pending - in process\running even before your query finishes running and you retrieve all its results, so ity would be tough to track it.
In short it wont be possible to retrieve the scheduler queue details using a query.

Queues stuck in DB-Queue Monitor .

Hi,
I have B1if with some scenarios in my system, but i have a problem with Queue stuck.
Under DB-Queue Monitor, i have the stuck queues, Q.INB_IQ_INTQ_ASYN_QS.0010000000 > sap.B1SysSLDSync > message(<SLDModify sysid="0010000112" company="SBO_DEPOSITO_NILDO" task="delete" /> ).
I have checked and all IPO-Steps are active.
Any solution????
[]'s

Hi Priyanka,
To clear the no send status entry, go to R3AS, select the object say for BP (Bupa_main) press enter and then execute, then open R3AM1 enter object name as Bupa_main and select Running and done and execute.
Now you can open SMQ2 and click on each entry with nosend status and then click on activate queue in the top toolbar, this shld change the status to running and then click on refresh.
The following is the list of Queue extensions that are used in CRM, all the queues start with these extensions:
Outbound queues
CDB* Start queues for loads CRM -> CDB
CRM_SITE* Load queues for Mobile Clients
CSA* Send queues of CRM Server Applications
EXT* Start queues for loads CRM -> Ext.
R3AI/R* Start queues for loads from ERP Backend system
R3AU* Load queues CRM -> ERP Backend system
Inbound queues
CRI* Initial load queues CRM -> CDB
CRM_SITE* Load queues from Mobile Clients
R3A* Load queues ERP Backend -> CRM
CSA* Send inbound queues of CRM Server Applications
Hope this answers ur query.
Regards,
Amit
Message was edited by:
 Amit Singh

"Driver transmit queue stuck" Error - what does it mean?

My 1231G Cisco on 12.3(7)JA2 is giving me the Critical error message: "Interface Dot11Radio0, failed - Driver transmit queue stuck," I have never seen this before. What does it mean, and can it be resolved? Thanks!

This error means the AP had an radio failure and if had one then it should disconnect the clients at that point. Try upgrading the firmware to the latest. This will resolve this issue.

CSCsx29696 - percentSUPQ-4-CPUHB_RECV_STARVE - receive queue stuck after throttling on 2960

Hello, I have a problem with Cisco Catalyst 2960 with IOS ver 12.2 (35)SE5.
4 years ago we purchased 10 Cisco Catalyst 2960 with IOS ver 12.2 (35)SE5 and now operating them.
After 4 years of normal working one of Cisco Catalyst 2960 became bad. After switching 2 computers to any FastEthernet interfaces in the console I see:
%SUPQ-4-CPUHB_RECV_STARVE: Still seeing receive queue stuck after throttling
%SUPQ-4-CPUHB_SLOW_TRANSMIT: CPU Heartbeat Tx buffer not returned
I tried to upgrade the IOS on the following: IOS Release 12.2(53)SE1, IOS Release 12.2(55)SE, IOS Release 12.2(55)SE9 but where was NO EFFECT.
Please, tell me what shell I do to fix this problem.
Thank you.
Technical engineer, Tischenko Kirill.

Hello Tischenko,
Trust you are doing great.
Have you tried configuring the workaround mentioned in the Bug CSCed03214
Workaround:
1) Configure the interface for full-duplex instead of half-duplex.
2) Find the interface that is receiving 1-byte frames and correct the wiring and/or
problem on the connected device.
Additional Information:
To find the interface that is receiving 1-byte frames, use the command show platform
port-asic receive port-lockup.
If an interface is configured for 10Mbps half-duplex, but shows non-zero and incrementing
ifix counters, reconfigure the interface and connected device for 10 Mbps
full-duplex, or 100Mbps or 1000Mbps (any duplex).
If an interface is configured for 10Mbps full-duplex, 100Mbps or 1000Mbps (any duplex),
but shows non-zero and incrementing ifix counters, the connected interface
or wiring is likely the cause of the 1-byte frames.
Regards,
Mohit
** Please rate if the post is helpfull

SUPQ-4-CPUHB_RECV_STARVE: Still seeing receive queue stuck after throttling.

Hi all,
I have used Cisco catalyst 3750x, port G1/0/1 and G1/0/2 to connect 2 MPLS lines from ISP
There has been an error to the switch after about 1 day of running; as following:
SUPQ-4-CPUHB_RECV_STARVE: Still seeing receive queue stuck after throttling.
It has auto-restarted time by time.
I have already replaced another switch but it has the same error.
Please help me to solve the problem. Thanks a lot!
The attached file is the show version and show logging
show version
Cisco IOS Software, C3750E Software (C3750E-UNIVERSALK9-M), Version 15.2(2)E, RELEASE SOFTWARE (fc3)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2014 by Cisco Systems, Inc.
Compiled Thu 26-Jun-14 11:52 by prod_rel_team
ROM: Bootstrap program is C3750E boot loader
BOOTLDR: C3750E Boot Loader (C3750X-HBOOT-M) Version 12.2(58r)SE1, RELEASE SOFTWARE (fc1)

downgrade IOS 15.0(2)SE7 or upgrade your IOS. work with the TAC on your symptom to understand the root cause of the condition.
same case with this :
https://tools.cisco.com/bugsearch/bug/CSCsx29696

UCCX: Position in queue and real position in scheduler queue

Hi
When using UCCX stats is posible to get position in queue BUT since agents can share skill from different queues, real time scheduler queue can be much longer.
It is posible to get the real position of that call on the scheduler queue?
For example:
Queue A, Skill A, 20 calls
Queue B, Skill B, 20 Calls
Agent 1 have Skills A and Skill B
Next Call on Queue A:
Position in queue acording to UCCX step is 21 but REAL position in scheduler is 41 since UCCX uses FIFO among queues.
Thanks

HI Jonathan
Yes, on this example adding both queues would do it, i put it only to ilustrate the useless of the get position in queue and the need of something more general.
In my project, skill are not evenly distribute between agents and agents logins and logout all the time. Because of that it is not as simple as adding severals queues together. A function should be provided that gives the real time position of the call at anytime in the scheduler and not the simple position in one queue.
Thanks

SMQS scheduler: Queues stuck / block situation

Similar Messages

Maybe you are looking for