Queue consumer blocking producer!?!?

This shouldn't be possible as far as I am aware, but somehow it seems that my consumer's receive call is preventing the producer from connecting to the queue and thus writing the message. Does anyone have any idea why this might be occurring?
Running in a WAS 5.02 / MQSeries environment, I have a servlet that sends a message to a request queue and then waits to recieve the correlating message message on the response queue (using correlation id). Meanwhile, the request message is picked up by the MDB, processed, and a response message is generated by my session bean. However, the session bean is unable to establish a connection to the response queue and send the response if the web app is already waiting to recieve it (it will successfully post if no recieve call is made). Eventually the reciever will time out waiting for the response, and an exception is thrown by the producer indicating that the connection pool could not allocate a managed connection.
As I understand, the reciever should only block its own thread of execution, and should not prevent a producer from writing to the queue. Is there some sort of configuration issue that might be causing this? Any possible insight into this problem would be greatly appreciated.
thanks,
zeffren

brilliant!
I couldn't for the life of me figure out what was going on because to my knowledge nothing in the code or our environement had changed. However, as it turned out, a team member had added some new MDB's which coincidentally had upped the number of connections to one less than the max available in the pool, therefore after my consumer established a recieve connection, there were none left for the producer!
Thanks for outside perspective, sometimes thats all it takes ;)

Similar Messages

  • Jms Adapter Consume and produce

    Hai guys,
    i don't know anything in soa. i have got a usecase which is to
    1) Read a .csv file
    2) Send it to a bpel (in bpel do nothing to payload). Again i have to send the payload to jms adapter( which i dnt knw how )
    3) From the same jms adapter passing the payload to mediator
    4) Pass the input to another jms( jms2 ). from jms2 pass the payload to another bpel
    5) from bpel to db adapter
    am using
    Oracle jDevloper 11.1.13
    Weblogic server is a 10.3.6
    my problem is how to create the same jms in two ways like consuming and producing
    Thanks in advance
    Edited by: Beckyard on Sep 26, 2012 9:49 PM

    Hi,
    Why do you need 2 JMS queues? Can't you consider following pattern?
    Read .csv --> BPEL --> JMS Q
    JMS Q --> Mediator --> BPEL (only if some payload processing required) --> Db Adapter
    Assuming the above pattern, you'll have to develop 2 processes (in your pattern 3 processes).
    - One that will enqueue the data in JMS in which the JMS Adapter will be placed in the External references and will be invoked with Produce operation.
    - Another process in which Mediator will consume the message using Consume operation from JMS and pass it to BPEL for inserting into database. In this case, JMS Adapter will be placed in Exposed Service swim-lane.
    Let us know how you proceed.
    Regards,
    Neeraj Sehgal

  • Data passing from consumer to producer

    Hello forum,
    I am using Producer-Consumer design pattern for data acquisition. While my producer loop acquires data, consumer loop does,analyze, display and save the data. One thing I would like to do is to pass a data from the consumer loop to producer loop. This is for a taring function, where my consumer loop would analyze the acquired data for n-point average and pass the value to produced loop where, this value is subtracted from the acquired data. How would I pass a data from Consumer to Producer?
    Many thanks to all,
    Zacharia

    MoReese wrote:
    johnsold wrote:
    Some of my dual loop systems pass data one way and commands or status messages the other way.  When I need to do this I use a pair of queues, one for each direction.
    Lynn
    Hmmm.  I thought of this but I couldn't get it to work.  It sounded like a good idea.  It just locked up the program.  The fp panel became unresponsive.  I had to use the Abort Execution button to stop it.  Could you provide a sample of this?  Just curious.  Thanks.
    Using the two queue method would require the producer to check the status of the queue and move on when it is empty. This ultimately turns it into a form of a polling system.
    If the producer is using an event structure you can pass data back via a user event.
    Also, the OP mentioned that they handle the UI and analyze the data in the consumer loop. I would recommend for the greatest felxibility and reuse that the UI actually be in its own loop separate from the analysis. The UI loop would use an event structure and the UI updates can be passed to it using user events.
    Mark Yedinak
    "Does anyone know where the love of God goes when the waves turn the minutes to hours?"
    Wreck of the Edmund Fitzgerald - Gordon Lightfoot

  • 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

  • WSRP - Pass Custom Data between Consumer and Producer

    Hello All,
    I am having a couple of queries with respect to Custom Data Transfer. Consider I have a Map of values which I need to transfer between both Consumer and Producer.
    For eg: the map that Consumer sends would contain "firstName", "lastName", etc... On the other hand Producer needs to do some business function based on the data and add more values to the map like "rewardPoint" etc....
    On Consumer Side:
    I have choice to use Backing File or IGetMarkupInterceptor to implement the preInvoke to pass the data using SimpleStateHolder.
    Question: I am not able to send a simple Serializable POJO Object... I can only send primitive / default java objects like Strings, Maps of String etc. Is my understanding correct?
    On Producer side:
    I am able to receive the Custom Data from request. No problems. Now how to send more data from Producer to consumer. I need to add the "rewardPoints" into the map and send back.
    My understanding is that if the Producer puts any values into StateHolder objects, Consumer will receive it in IGetMarkupResponseContext object in the Interceptor's postInvoke method.
    Question: How do I get a handle to the IGetMarkupResponseContext object @ Producer end???
    Question: Do I need to write some interceptors on Producer end? If so which file I need to use?
    Any help / pointers would be greatly appreciated.
    Thanks,
    Paz

    Hi All,
    I tried to set the data in the producer using the following command
    SimpleStateHolder stateSimpleOuterReq = (SimpleStateHolder)request.getAttribute(MarkupRequestState.KEY);;
              if (stateSimpleOuterReq == null) {
                   SimpleStateHolder state = new SimpleStateHolder();
                   state.addParameter("name", "data1");
                   request.setAttribute(MarkupResponseState.KEY, state);
    I am not able to retrieve the same in consumer.
    The above is a WSRP struts request.
    I also tried setting the data by unwrapping the request in producer and still value is null in consumer :-(
              HttpServletRequest requestq = (HttpServletRequest)((HttpServletRequestWrapper) request).getRequest();
              SimpleStateHolder stateSimpleReq1 = (SimpleStateHolder)requestq.getAttribute(MarkupRequestState.KEY);
                   if (stateSimpleReq1 == null) {
                        SimpleStateHolder state = new SimpleStateHolder();
    state.addParameter("name", "data1");
                        requestq.setAttribute(MarkupRequestState.KEY, state);
    Please help me in resolving the issue. Correct me if i am doing anything wrong.
    Thanks
    T. Deena
    Edited by: user11261911 on 12/06/2009 19:49

  • 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

  • JMS queue consumer challenge

    Hi there,
              I have met a pretty challenging problem in JMS queue consumer and
              would like to know if any JMS lovers in the group know about it.
              We have queue receiver listening on queue which contains a number of
              mugs.
              Once a msg is received (onMessage returns), the msg is handed over to
              a worker thread from a thread pool.
              Essentially there are two parts of the problem:
              1. We want kind of flow control - only x number of msg can be
              processed at a given time. This can be resolved by using semaphore.
              However, there might be better solution out there. Anyhow, this is
              less an issue than the second part -
              2. As we know client_acknowledge happens at the session level:
              Acknowledging a consumed message automatically acknowledges the
              receipt of all messages that have been consumed by its session. For
              example, if a message consumer consumes ten messages and then
              acknowledges the fifth message delivered, all ten messages are
              acknowledged. 
              -- this is the problem -- we want to acknowledge each msg
              individually so that only the processed msg is acknowledged although
              there are x number of msg being retrieved. By doing that we won't lost
              any msg in case the JMS client crashes.
              It is a challenge, isn't it? Might well not be one for you, if you
              know the trick. If you do, could you share with us? Thanks a lot.
              Mike
              

    Just to be clear, I favor (2), where each worker thread has its own session and
              consumer.
              This naturally throttles, as there are only as many outstanding messages as
              worker-threads.
              BTW, be aware that it is against spec, and dangerous, to call acknowledge()
              outside of
              onMessage() - as this multi-threads the Session and Session's are not thread
              safe.
              Tom
              Tom Barnes wrote:
              > Actually you both are correct. The ack behavior is configurable on the
              > connection factory via the "AcknowledgePolicy", where the default is
              > what the spec requires (ack-all). Prior to 6.1
              > the behavior was what one would expect (ack-before).
              >
              > As for how to solve the problem at hand. I can think of three approaches:
              >
              > (1) use the current async consumer but set the ack-policy
              > to ack-before, and defer acknowledging a msg until all msgs before
              > it have finished their processing
              >
              > (2) use multiple synchronous consumers, one consumer per defered msg
              >
              > (3) use a single synchronous consumer, but dequeue transactionally,
              > one transaction per msg. suspend the transaction, then have
              > the worker thread resume the transaction once it finishes processing
              > the message and call commit. (Take care that the default
              > tran timeout is 30 seconds.)
              >
              > Shean-Guang Chang wrote:
              >
              > > Just to correct one assumption. Ack the fifth message will not ack message
              > > received after that (e.g. message 6, 7, 8, etc...). At least not WLS JMS.
              > > If this is not true for you please give details of your client code and
              > > version of WLS JMS you have. Thanks!
              > >
              > > "Mike" <[email protected]> wrote in message
              > > news:[email protected]...
              > > > Hi there,
              > > >
              > > > I have met a pretty challenging problem in JMS queue consumer and
              > > > would like to know if any JMS lovers in the group know about it.
              > > >
              > > > We have queue receiver listening on queue which contains a number of
              > > > mugs.
              > > > Once a msg is received (onMessage returns), the msg is handed over to
              > > > a worker thread from a thread pool.
              > > >
              > > > Essentially there are two parts of the problem:
              > > >
              > > > 1. We want kind of flow control - only x number of msg can be
              > > > processed at a given time. This can be resolved by using semaphore.
              > > > However, there might be better solution out there. Anyhow, this is
              > > > less an issue than the second part -
              > > >
              > > > 2. As we know client_acknowledge happens at the session level:
              > > > Acknowledging a consumed message automatically acknowledges the
              > > > receipt of all messages that have been consumed by its session. For
              > > > example, if a message consumer consumes ten messages and then
              > > > acknowledges the fifth message delivered, all ten messages are
              > > > acknowledged.
              > > > -- this is the problem -- we want to acknowledge each msg
              > > > individually so that only the processed msg is acknowledged although
              > > > there are x number of msg being retrieved. By doing that we won't lost
              > > > any msg in case the JMS client crashes.
              > > >
              > > > It is a challenge, isn't it? Might well not be one for you, if you
              > > > know the trick. If you do, could you share with us? Thanks a lot.
              > > >
              > > > Mike
              

  • [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

  • How to build a stable, reliable application with consumer and producer

    Hi all,
    As a frontend solution, Flex is really powerful and fascinate. On the other hand, it inevitiably needs to exchange data. And I am trying to find a good way to build a stable and reliable application.
    Here's the workaround. On server side, blazeDS or LCDS is involved and on frontend component Consumer and Producer are used to interact. A group of users cooperates on the whole processing. Everybody will send an update once he finished current job.
    Of course each frontend need to subscribe first. But if one frontend is disconnect temporarily and other frontends send message to backend during that time, how can the disconnect one get message it missed? How can I fix the inconsistent status?
    Thanks and regards,

    Hello meshgraphics,
    Your reply is useful, but feasible I have to say. Creating DB tables, updating entries and synchronizing contents involve a lot of work. As we can use blazeDS and LCDS, that'll be good option. From online help, it doesn't explain what will happen if consumer disconnects temporarily which is very important to me. If some messages are missed, the whole process can't move on smoothly.
    Simply speaking, I hope below issues can be solved with blazeDS or LCDS:
    1) how to ensure messages are delivered to subscribed consumers if they are temporarily disconnected?
    2) how to recover work if consumers are thoroughly disconnect?
    Thanks and regards,
    Felix

  • Cleanup on Producer/C​onsumer template puts consumer above producer?

    See the attached pic.  I have the stock "pro/con" template, and the i do the auto block diagram cleanup and then it spatially positions the consumer loop on top of the producer loop.  Is my block diagram cleaner upper behaving correctly?  Is there a way to force them to stay in the stock orientation with the pro loop above the con loop?  
    Thanks. 
    Attachments:
    bdc_ofPCtemplate.png ‏66 KB

    It's avoiding the wire crossing over the error wire with the queue reference.  Personally, I prefer having the Producer on top; data flows down.
    So to answer your question, there is nothing wrong with your Diagram Cleanup.
    There are only two ways to tell somebody thanks: Kudos and Marked Solutions
    Unofficial Forum Rules and Guidelines

  • Queue consumer stops with 100% cpu usage

    I'm trying to use Berkeley DB queue with transactions. When I tested what happens when transactions with DB_APPEND are aborted I found that while it works and DB_CONSUME correctly skips over rolled back records, unfortunately extents that have those records are never deleted, which causes database to always grow. Next I tried DB_CONSUME with database opened using DB_INORDER flag and it seems there's a serious regression in Berkeley DB that causes it to loop indefinitely with 100% cpu usage when it encounters a rolled back record. I tested various versions and found that this bug doesn't happen with 5.1.29, but it is reproducible with 5.2.42, so this regression might have been introduced in 5.2. I have also tested 5.3 and 6.0, and both have this behavior. There may be something wrong with the way queue records are rolled back, one indication of that would be that in 5.1.29 doesn't have neither of the two problems I found with DB_QUEUE: extents are deleted after being consumed, and there are no issues when consuming with DB_INORDER either.
    You can find Python code to reproduce this issue here:
    https://gist.github.com/snaury/027a3c546f5b0a62a440
    Sorry for using Python and not e.g. C++, but it's a lot shorter that way.

    We have looked at the issues and they are valid.   We will roll the fixes out for this in our next release of BDB.   The test case was very useful and really helped to speed the process up.    If you have any questions, please contact me directly at [email protected]  Thanks again for bringing this to our attention.
    thanks
    mike

  • BPM queue get block

    Hi,
    I have a web services that use bpm scenario. Every time when a error example date type format happen on the bpm the queue with get block on smq2 and others request by the web services will get hold. Any way that can i disable this? Every time i have to delete the error queue in order to let the webservices work again.
    Thanks for help.

    Hi Fcgan,
    Use these reports to handle the queue in automated manner.
    · RSARFCSE: Restart an LUW (background job)
    · RSARFCEX: Restart tRFC LUWs (background job)
    · RSQOWKEX: Restart QOUT qRFC LUWs
    · RSQIWKEX: Restart QIN qRFC LUWs
    · RSARFCSE: Delete an LUW (background job)
    · RSARFCER: Delete various LUWs  
    Thanks!

Maybe you are looking for