[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

Similar Messages

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

Outbound queues are in ready status

Hi,
In our system outbound queue are getting stuck in READY status. They are not getting executed automtically from READY status we have to manually exceute them in SMQ2.
How i can clear the queue which are in READY status.
Thanks & Regards,
Koushal Solanki

Hi,
Please check if there is any standard background job available to schedule it to run for every 5 or 10 minutes so that it will check the queues with Ready status and then execute them automatically. Also, check the reasons why jobs are coming to Ready status.
Regards,
Sharath

Queue to ERP stopped Status SYSFAIL

Hallo all,
yesterday evening we got the Problem that our Queue to ERP-System stopped. Status is SYSFAIL and and error CALL_FUNCTION_LZ_EXPAND_ERROR occured. Unfortunately theres no text available for this dump. The dump is produced in Program SAPLSMOUTIL in BAPI_CRM_SAVE.
Does anyone have an idea, what's the reason for this failure, or how to resolve it?
Thanks a lot for your help.
Best regards,
Daniel

Hi Frederic and Fredric,
thanks for your further ideas. The dump info didn't contain much info...
We had opened an OSS-message on friday, because it was important to solve this problem fast. SAP meant to delete the entries in the cue, because it seemed that the data got corrupted because of hardware or network errors. The missing data is logged, so we can reload it. Following the queue worked until now.
Thanks for your help!
Best regards,
Daniel

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

Where to search for R3A* queues in status SYSFAIL in my system.

Hi Experts,
Can anyone tell me in which Tcode or table I can search for the below entries. I am trying to find out these entries as one of CRM team member had mentioned the below one.
R3A* queues in status SYSFAIL were detected in your system. As a result, changes in the R/3 system have not been updated in the CRM system.
Regards
Srujan K

Hi Muthu,
Can you please tell me what are these Queues belong to, meaning which is repsonsible for what in SRM?
R3AD_ATTRIBUTE
R3AD_CLASS
R3AD_CUSTOME0000000043
Do we as an SRM consultant have to monitor the SMQR queues also?
please clarify me on the above 2 points.
Thanks in Advance!!!
Regards,
Srujank

Very urgent(Queues blocked in R/3)

I have checked in sm50,smq1 and r3am1.There are no queues that have been blocked in CRM.
But when i checked in R/3 ,I found in SmQ1 that 3000 queues have blocked .So there no flow of data from r/3 to crm.
So please help me how to resolve this problem.
This is very urgent.
regards,
Mdahv.

Hi
Possible error situation: A business object has been changed in a CRM Server Application, but the
change (delta load) is not received in SAP R/3.
In case of errors or missing data updates in the target system, you may perform the following steps:
Check Display BDoc Messages including the middleware trace information
Check the outbound queue
Check the table BDOC_TRACK in SAP R/3 (shows information on the data handling of the SAP R/3
application)
Check the outbound queue of SAP R/3
Check the inbound queue of the CRM System
Furthermore, verify the RFC destination and the logical system assigned to your site (in the Admin
Console) and the CRM Middleware parameter settings in the CRM System and SAP R/3 (for example,
CRMRFCPAR).
Cheers
Message was edited by: Natarajan

Manage Queues - Messages are in Schedule status after upgrade to ERP2004

Hi,
We upgraded SAP to version ERP2004. ABAP proxy XI messages are in schedule status even though we deregister and register & activated all queues.
When I click on the queues it is in running status.
Does anyone has any idea where should I look?
Thanks in advance!
Mrudula

Hi,
my scenario is file to idoc....
I have set paraemter in SXMB_ADM as below.
Category Parameters CurrentValue DefaultValue
RUNTIME HTTP_TIMEOUT 100000 0
I have gone through as you suggested still when i double click on message in SXMB_MONI...i am getting Runtime Error (TIME_OUT).
Please do help me..
Thanks in advance.
Krish

Inbound Queue R3AD_SAL_ERR in Status SYSFAIL

Hi
In CRM 2007 i get this inbound queue R3AD_SAL_ERR in status SYSFAIL.
Could you please let me know why this error occurs and the steps to solve this error.
Regards
Masthan

Hi Masthan,
I hope the below mentioned notes will help you to some extent :
1372859
608332
Thanks and Regards,
Vignesh Ravikumar

Advanced queues are waiting in ready status and do not process

Advanced queues are waiting in ready status and do not process.
There are no Db locks.
DB 11.2.0.2.0

Hi,
With this information it is not possible to get appropriate answer in the forum.
By the way you checked alert log file.
Check the below link also:
http://www.cs.umbc.edu/portal/help/oracle8/server.815/a68005/03_adq2f.htm
Best regards,
Rafi.
http://rafioracledba.blogspot.com/

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

Status SYSFAIL in SMQ1

Hi All,
We are getting an error message with status "SYSFAIL" in SMQ1 while replicating the BP from CRM to ECC and the message goes like "The current application triggered a termination wi th a short dump."
The BDoc status is in YELLOW status.
Please help us to fix the issue.

Hi,
1. Read this note Note 430980 - CRM Server: Analysis in delta data exchange R/3->CRM
They have error status 'SYSFAIL'. This is only the case if there is a technical problem with the receiving system (for example, a database problem on queue tables QRFC, ARFC). The problem must be corrected on the CRM server, and then you can restart the queue. Generally, a short dump is then displayed on the target system, which provides more detailed information on the cause of error.
2. Check entries in tr. smw01.
Denis.

How do I get Firefox to display the information bar when a pop up is blocked I accidentally clicked on "Don't show this message when pop-ups are blocked" when a pop up was blocked. How do I get this message to reappear again when a pop up is blocked?

I just updated Firefox but can't get it to display the message when a pop-up is blocked. Most times I want them blocked but sometimes I need them enabled.

You can see a pop-up block icon in the right corner of the Status Bar if you have chosen to hide the information bar at the top.
You can left-click that pop-up block icon on the Status Bar and remove the check mark from "Don't show info message when pop-ups are blocked"
You can look at these prefs on the '''about:config''' page and reset them via the right-click context menu:
Status bar icon: browser.popups.showPopupBlocker
Info bar at the top: privacy.popups.showBrowserMessage
To open the ''about:config'' page, type '''about:config''' in the location (address) bar and press the Enter key, just like you type the url of a website to open a website.
If you see a warning then you can confirm that you want to access that page.

VNICs (both uplinks and VM's vNIC) are blocked on N5K DVS after upgrading to ESXi 5.1

Hello Gents,
I cought into weird situation after upgrade VMware ESXi 5.0 to 5.1 on UCS C200M2. Before upgrade I have had server with configured static adapter-fex VNICS and floating/dynamic vm-fex interfaces working perfectly in DirectPathIO mode for VMs. Initial deployment was done according Cisco N5K VM-fex operation guide for   NX-OS 5.1(3)N1(1). There were vCenter 5.1, 2xN5K and 2xC200M with ESXi 5.0 integrated so that N5K DVS was brought to vCenter and hosts could be added to DVS. One of C200M2 (still on ESXi5.0) has no problem while operating VM-Fexs and adapter-fexs while part of its uplinks are on VSS and othe part on DVS (in fact there are none VMs on VSS, so all the workloads use DVS).
But upgraded C200M cannot operate with DVS correctly: any vmks, vm networks, VMs connected to DVS lose network connectivity.
Attached picture illustrates diag of connectivity status (uplinks/ets are blocked).
VEM are fresh and running:
~ # vem status -v
Package vssnet-esxmn-next-release
Version 4.2.1.2.2.1a.0-3.1.1
Build 1
Date Sat Sep 28 18:47:14 PDT 2013
VEM modules are loaded
Switch Name      Num Ports   Used Ports Configured Ports MTU     Uplinks
vSwitch0         128         6           128               1500    vmnic0,vmnic1
DVS Name         Num Ports   Used Ports Configured Ports MTU     Uplinks
N5KDVS-1         256         14          256               1500    vmnic3,vmnic2
VEM Agent (vemdpa) is running
~ #
~ # esxcli software vib list | grep cisco
cisco-vem-v162-esx             4.2.1.2.2.1a.0-3.1.1                Cisco     PartnerSupported 2013-11-11
Do anybody have an idea why it is going wrong?

Of course they exist.There is unpatched server with ESXi 5.0 near upgraded server and it works perfectly.
Finally I downgraded server to ESXi5.0 again and VM-FEX functionality restored.

[Urgent] Queues are blocked in status SYSFAIL

Similar Messages

Maybe you are looking for