Locking a Queue.

I am doing a program in which there are 2 threads - first thread will add integer values to a queue and the second thread polls the value from the queue. I need to lock the queue so that both add and poll wont happen simultaneously. How can I achieve this? How can I lock the queue? As I am newbie to concurrency, somebody help me with code snippet. Thanks in advance.

sowndar wrote:
As I am newbie to concurrency, somebody help me with code snippet. Thanks in advance.You cannot code snippet a complicated concept such as this. There is only one way to go: learn this stuff, learn it well and design your code to be concurrent from the beginning - you won't get it done by plugging in two lines of code, I can tell you that.

Similar Messages

Is commit lock on Queue or QueueSpace?

Hello,
when a transaction is committed in a Tuxedo Queue (/Q), does that lock the
queue only or does it look the whole queue-space?
I have a /Q with multiple TMQFORWARD and service handlers. There is a
backlog in the /Q, but occasionally I have observed that no messages are
being processed for a few seconds.
I measure in the service handler the time between the tpreturn() and the
next invocation. The TMQFORWARD idle time is 1 second.
So, with lots of messages in the queue I would not expect to see more than
one second between requests. But I see 2 - 3 seconds occasionally.
My conclusion is that one TMQFORWARD takes some time to commit (the
transaction also include Oracle via XA). It is quite reasonable to assume
that during the commit, no other TMQFORWARD can manipulate the queue.
My next thought was to have multiple queues (in the same queue space). But
if the commit locks the queue space, then this will not help.
Thanks...
Roger

Roger,
/Q uses several types of locks, including a lock on the entire queue space,
locks on individual queues, a lock on the transaction table, and locks on
several other tables. The lock on the entire queue space is used only when
creating, opening, or destroying a queue, and is not used when committing a
transaction. However, committing a transaction does require a lock on the
transaction table for short periods of time, and the transaction table is
shared between all queues in a queue space. Therefore, there may be some
degradation in commit performance caused by combining multiple queues in one
queue space, but it should not be much. Combining multiple queues in one
queuespace rather than multiple queuespaces also has advantages, including
the ability to allocated shared memory and disk resources as best benefits
all of the queues rather than deciding on a fixed allocation at the time the
queuespaces are created. Depending on the particular application and how it
is configured, this resource sharing benefit might or might not outweigh the
overhead of a transaction table lock shared between mulitple queues.
Queuespaces are often large, and involve many I/O operations (except for
in-memory queues.) The allocation of queues and queuespaces among different
disks can improve performance if an application is I/O bound. Different
queuespaces will necessarily reside on different filesystem paths, which may
be located on the same or different physical disks. A single queuespace can
reside on a single filesystem pathname, but can also reside on multiple
filesystem pathnames by using the qmadmin "qaddext" command if this is
judged to be desirable.
"Roger Fischer" <[email protected]> wrote in message
news:[email protected]...
Hello,
when a transaction is committed in a Tuxedo Queue (/Q), does that lock the
queue only or does it look the whole queue-space?
I have a /Q with multiple TMQFORWARD and service handlers. There is a
backlog in the /Q, but occasionally I have observed that no messages are
being processed for a few seconds.
I measure in the service handler the time between the tpreturn() and the
next invocation. The TMQFORWARD idle time is 1 second.
So, with lots of messages in the queue I would not expect to see more than
one second between requests. But I see 2 - 3 seconds occasionally.
My conclusion is that one TMQFORWARD takes some time to commit (the
transaction also include Oracle via XA). It is quite reasonable to assume
that during the commit, no other TMQFORWARD can manipulate the queue.
My next thought was to have multiple queues (in the same queue space). But
if the commit locks the queue space, then this will not help.
Thanks...
Roger

Why orders gets locked in Queue's

Dear all,
Could you please help me to know why orders gets locked on Queue's as well SMCL trasaction.
what is the route cause for that? and is there any why we can unlcok automatically with a program?
please suggest me.
Thanks for your help.
Regards,
Shaik

Hi Shaik,
Orders you are seeing in SMCL transaction is Cross System Locks. When Scenario A is activated, then Cross System Locks must be activated. This locks will be released automatically from the system when the transaction is completed successfully in ECC & CRM.
You are not supposed to remove the locks for the orders from SMCL transaction directly. First analyze the issue with the order. If any issue in order replication from CRM to ECC or vice versa Cross system lock will not release automatically.
For example, from SMCL take one order and analyze the order in ECC & CRM, definately you should see the difference in ECC and CRM order.
Some times Cross System Locks will not be released, if updates are not coming to CRM from ECC, better check filters in SALESDOCUMENT middleware object for the sales document types.
Regards,
Bhanu

Sysfail locks smq2 queue

Hi,
We are live with our PI7.1 system as of 11/6 and are seeing serious issues when a data error causes a sysfail for a SMQ2 queue. At this point the queue is locked for further processing. We have monitors setup which page us for this situation. However, we really need to prevent the queue from locking so other messages are sent even when one item is in sysfail status.
Notes 813209 and 1118297 do not seem to offer any help is this situation.
Is there a way to prevent the queue from locking due to sysfail status messages?
Any help is greatly appreciated.
Regards,
Rick Taylor

Rick,
Check out this blog..
http://www.sdn.sap.com/irj/scn/weblogs;jsessionid=(J2EE3417500)ID1371322850DB11715461650132929943End?blog=/pub/wlg/2728
"For automatic qRfc failure recovery, schedule the report RSQIWKEX to run periodically. This report enables automatically resets the queues. "
I remember there is a way to put error messages in different queue so that current queue wont b lock anymore...I'll check and let you know.
Hope this will help.
Thanks,
Nilesh

CRM Transaction not in ECC,not locked in queue, has Status of Locked in Dis

Background:
I have an unusual case where a transaction was created in CRM along with a follow-on transaction, but only the follow-on transaction made it to ECC. The initial transaction was created correctly and should have replicated. We did have a server malfunction on the same day that affected a lot of orders in ECC, even deleting some out. It looks like this transaction may have been one of those.
Issue:
I now have a transaction in CRM that says it is locked in Distribution, but it is not in SMQ1 or SMQ2 in either CRM or ECC and it isn't showing up as an error in SMW01.
Is there a way for me to unlock this from distribution aside from SMQ1, SMQ2, or SMW01?
I thought of making a change to the system status using a table like CRM_JEST but haven't yet found a way to do that. There are some fnction modules out there but I am not sure of the correct one. I had used one in the past to update the User Status but ended up mass changing a bunch of transactions instead of the one transaction in question. I don't want to make that mistake with the System Status.

Go to SE38 and run program CRM_DATAEXCHANGE_TOOLBOX and execute Resend CRM Documents option and check if it works.
If you want to delete system status, go to table crm_jest, run it for desired guid, select the proper status and then in debugging mode switch from display (SHOW) to delete (DELE). But I would go with this option yet.
Regards.

Lock Queue for a particular Partner No.

Hi All,
We want to lock the RFC queue for a particaular partner No. is this possible in SAP?
Background : We are having a maintainace activity on one of our middle ware, hence there would be changes done to a particular and critical interface. The middle ware team has requested that they should not receive any IDOCs during this time but as the activity is for a substantially high time, we cannot stop the batch which generates the critical Idocs during time as the critical IDOCs can be generated only for N and N-1 day only (Activity may last for 3-5 days depending on the outcome). We would want to lock the queue for a particular Partner No. so that once these IDOCs are generated they can be waiting in queue untill the queue is released and the target system has all the IDOCs required by the time the system is handed over to the bussiness.
P.S : We are transfering IDOC through TRFC call to the target system.
Can you please suggest?
Regards,
Anand.

Hi Anand,
As per SAP documentation
Creating an Outbound Partner Profile (SAP Library - IDoc Interface/Electronic Data Interchange)
http://help.sap.com/saphelp_nw04/helpdata/en/dc/6b7f5643d711d1893e0000e8323c4f/content.htm
When you assign a port number for IDOC partner profile, this port number is mapped to a RFC destination.
Either you can hash out port <-> RFC destination mapping or hash out the RFC destination host mentioned in SM59.
Hope this helps.
Regards,
Deepak Kori

Locked Queues

Hello SDN,
Sometimes message processing is not executed successfully and the error lock the queues.
When we check the message status (message monitoring / SXMB_MONI) it is "scheduled for outbound processing" or "System error".
We fixed the errors when they occur but the problem is that the error locks the queue therefore the messages waiting for execution in the same queue have to wait until a manual cancel of the message with problems to be executed.
I wonder if is there any way to configure that when an error occurs during the execution in a queue, the error always can be transfered to the message (as a message with a system error) and do not lock the queue, so the following messages can be executed.
Do someone have had the same problem?
Best regards,
Gustavo P.

Hi Gustavo,
Tine Related Parameter can be checked with ::
There are two ways of changing this timeout:
a) check out note: 824554 and try to change it in the instance profile
b) TCODE SXMB_ADM -> Configure Integration server -> change specific identifiers
Set Runtime parameter: HTTP_TIMEOUT
Rember to restart XI after the change
For Dealing with All knid of Time Out Errors ::
See
/people/michal.krawczyk2/blog/2006/06/08/xi-timeouts-timeouts-timeouts
Now Coming back to Queues getting Blocked I dont hink Queue Prioritization is a ggod Idea, We have to manually Deal with Queues and the Data in Ind, remember if are force to delete any data from the Queues Delete the Complete LUW rather then individual message.
Have a Look at this Blog as well::
/people/stefan.grube/blog/2006/04/27/how-to-deal-with-stuck-eoio-messages-in-the-xi-30-adapter-framework
Please Keep the Table of important SAP Notes for common XI work::
SAP Note     Description
856597     FAQ: XI 3.0 SOAP Adapter
856346     FAQ: J2EE JMS Adapter: Frequently Asked Questions
821267     FAQ: XI 3.0 File Adapter
831162     FAQ: XI 3.0 JDBC Adapter
730870     FAQ XI 3.0 RFC Adapter
813993     FAQ: Message status in the adapter framework
856599     FAQ : XI 3.0 Mail Adapter
816022     FAQ: XI 3.0 J2EE Adapter Engine / Messaging System
801868     Java(TM) Web Start in XI 3.0: FAQ/Troubleshooting
774854     FAQ XI 3.0 BC Adapter
830039     FAQ: Deployment of the XI adapter framework
813993     FAQ: Message status in the adapter framework
793669     FAQ: SUS in SRM 4.0 with XI 3.0
615740     FAQ: CCMS GRMG Availability Monitoring
872388     Troubleshooting Archiving and Deletion in XI 3.0
872508     XI 3.0 AF: BufferOverflowException when sending large msgs
764417     Information for troubleshooting of the SAP J2EE Engine 6.40
721548     Changing the passwords of the XI service users
886888     XI 3.0 Adapter Framework: XML parsing error for xmlns
885405     Troubleshooting End-to-End Monitoring in XI 3.0
821268     XI 3.0 Adapter Framework: Overview of available FAQ notes
858366     SAP XI 3.0 SP12: iWay Adapter Release Note
801951     XI30: Analyzing mapping problems
711947     ITK 1.5 FAQ
768148     Using a separate SLD for XI
764393     Configuration of the SAP System Landscape Directory
813029     Automatic processing of failed XI messages
913858     XI3.0 Alerting: Troubleshooting (new)
I hope it will help you :::-))
Regards
Piyush
Please reward Points if you find this helpfull::-))

Locking Queue

Hi All
I have created a queue in SAP PI for serializing of IDocs. Now for testing I need to lock this queue, I went to SMQR and unregistered the queue which is resulting in flowing of IDocs using different queues.
Can anyone tell me how can I lock that particular queue.
Regards
Sourabh

Hi Sourabh,
Check this blog: /people/community.user/blog/2006/11/04/how-to-serialize-idoc-xml-messages-fed-into-xi
Check SAP Note: 752194
Normally, when a dedicated queue is assigned then it should be block the message when we de-register the queue.
If you are not able to view the messages in queue, then unlock the queue from smq1/smq2.
Thanks,

How to UNLOCK queues when data is migrated from legacy system to SAP syste

Hi All,
I need some help regarding queues (SMQ2). XI is been used to migrate data from legacy system to SAP system. Sometimes the queue is getting locked. Once the queue is unlocked then the message is processed correctly. So, the incoming queues must be "unlocked" routinely so that they can process through the system. There is a standard report RSQIWKEX available that can be scheduled in SAP system to automatically unlock the queues. Before using the standard report RSDIWKEX, we made sure that we have added parameter MONITOR QRFC_RESTART_ALLOWED set to "1" in Integration Engine specific configuration (TCODE SXMB_ADM).We are unable to analyze the reason for locking of queues and how to avoid it. If the locking of the queues can not be avoided, is there any way to unlock the queues? We tried executing this report but were not successful in unlocking the queues. Please guide us in solving this issue. It would be really helpful if you can give us a direction in solving this problem.
Thanks in Advance,
Shwetha.

Hi,
Just check if the Queues are registered in Transaction SMQR.
If its not, then register the Queue by pressing 'Register' Button
Sharif.

Not clearing the job queue

Hello everyone,
We've been experiencing some oddities in our database and we hope to find some help around here. The scenario is as follows:
Our job queue shows 13 pages of jobs, updated in the last 5 days, in which we find lots of jobs - actually most of them from 3 days ago - with the progress showing "transcoding clip" and the status as "RUN".
When we try to cancel any of those jobs we get an error message that says: "Error cancelling - this job is currently not running".
We have tried flushing the event queue from Terminal using the following commands:
fcsvr_client flushresponsequeue
fcsvr_run psql px pxdb -c "vacuum analyze verbose;"
but none of them solved our problem. We cannot clear the event tables in the db (pxevent and pxeventresponse). We have even tried a more desperate solution by accessing the db via Navicat and manually deleting each and every row (!!!), visually clearing the tables.
BUT on the next day they did reappear and on the day after double in quantity (i.e. empty table --next day--> 4K rows --next day--> +4K rows and so on...).
So now we have 18,826 entries in our table which seems to grow indefinitely (and for no apparent reason).
We fear that our problem may get worse and cause us bigger problems. Any help would be very appreciated.
Details of the system: FCS V1.5.2 / Mac OS X (10.5.8)
Thank you in advance,

Hey guys, thanks for the replies.
the issues with the "pxevent" and "pxeventresponse" tables seems to have been solved BUT the issue with the Job queue remains the same.
Old (1 day old or more) jobs are showing status as RUN although when you try to delete it you get an error message which says "error cancelling - this job is currently not running" despite the fact it is shown as running. When you "get info" on any of those, you can see in the logs that it has failed and retried, then failed again (on the retry). This condition should make the status change from RUN to FAIL but it is not what's happening.
All this ends up putting some recently added jobs on a WAIT status which ends up kind of locking my queue (therefore preventing jobs from running, timming them out and, consequently, failing them). If I go to the "pxjobs" table and delete all entries it solves the symptom (as it was well said by one of you) but the problem doesn't cease to happen.
I can force the waiting jobs to run now but they end up failing too.
Any thoughts on that? I have some print screens but don't know if I can post them here (newbie on this forum, sorry ).
Thanks for your attention

Stuck Messages in Queue in SMQ2

Hi,
I have messages that are stuck in a specific queue seen in SMQ2. when I checked the status of the queue, it is RUNNING and the first message in the queue has a statusText 'Transaction Executing'.
We have deregister - register, activate, unlock, lock the queues already but nothing happened.
there are NO ERROR seen inside the queue.
Already referred to these links:
RECORDED FOR OUTBOUND PROCESS in SXMB_MONI
Recorded for outbound processing
Restarting "Recorded for outbound processing"
Problem Recorded for Outbound Processing...
XI : How to Re-Process failed XI Messages Automatically
thank you.

Hi,
did you check other Tcodes...like SLDCHECK,SXI_CACHE and ST22 whether everthing is working fine.
else as suggested by Rudra, please to ABAP Stack restart.
Regards,
Mastan vali

JMS Queue

Can anyone help me on this error:
Serverjava.lang.ClassCastException: com.evermind.server.jms.EvermindConnectionFactory
I got the above exception while trying to connect to JMS server (in OC4J 9.0.4) with the following code:
ctx = new InitialContext();
qconFactory = (QueueConnectionFactory) ctx.lookup("jms/ConnectionFactory");
I am using standard jms Queue interfaces and classes.
This is the jms.xml setup in OC4J 9.0.4:
<queue name="Locker"
location="Locker">
<description>Queue for DB Lock</description>
</queue>
<queue-connection-factory
name="jms/QueueConnectionFactory"
location="jms/QueueConnectionFactory" />

Sorry. It is my mistake.
I used the wrong name of JMS connection factory:
qconFactory = (QueueConnectionFactory) ctx.lookup("jms/ConnectionFactory");
It should be like this:
qconFactory = (QueueConnectionFactory) ctx.lookup("jms/QueueConnectionFactory");
Because my jms.xml setting is using :
<queue-connection-factory name="QueueConnectionFactory"
location="jms/QueueConnectionFactory"/>

EOIO cluster lock in JMS sender channel

Hi All,
Our production environment is using cluster.
I have 2 sender JMS channel where EOIO feature has been used.
Today while monitoring we found one of the cluster node is showing below error
EOIO cluster lock:com.sap.aii.adapter.jms.eoio has already been acquired for EOIO channel by another cluster node. Therefore channel has been made inactive. Underlying lock manager reported message(if any) as: Cannot lock [20u2026u2026u2026u2026ip address, com.sap.aii.adapter.jms.eoio,c8u2026(channel ID),E]; it is in use by another owner. The lock collision occurred with user.
We have asked basis to remove the lock and they said that can be removed in NWA system lock.
But before removing the lock I wanted to understand the following
1)Why this lock happened, since it is EOIO? ( this issue is not there in other EO communication channels)
2)Is there any side effect if we delete the lock?
Appreciate your fast response .

Hi Michal,
The warning of EOIO cluster lock is still there.
we have 2 clusters, c1 and c2.
in NWA i can see the lock name *($com.sap.aii.adapter.jms.eoio)* is locked by c1 (2 locks (i.e.2 lock argumnets)) and c2 (1 lock).
i can understand that , to ensure the EOIO message proccessing the AF locks the queue , but it should theoritically unlock once the message processing completes.But this is not happening in my case.
Should i try removing one lock? or this is bug.

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

Running smq2 queues in debug mode

Hi,
Can anyone tell me how to successfully run an inbound queue in debug mode.
Following are the steps undertaken.
I locked the queue in SMQ1. The Queue is set to STOP state.
I then triggered an sBdoc flow into CRM.
I am expecting the sBdoc to be in an intermediate state, but to my surprise it is coming as Fully Processed.
At this point, setting Debug mode in smq2 and Unlocking the queue does not help me analyse the bdoc/process flow as the bdoc is allready processed.
Any inputs in this regard would be helpful.
Thanks & Regards
Ron.

Hi Ron,
Please check below blog, hope it helps u.
Regards,
Deven
/people/lokesh.aggarwal/blog/2008/02/27/debugging-crm-middleware--sales-document

Locking a Queue.

Similar Messages

Maybe you are looking for