Server <name> Has Outstanding Asynchronous Requests. C

Posted by Karikalan Ram on 28-Nov-2016 16:06

Hello Everyone,

I assume that before asynchronous calls get completes, if app server queued with synchronous call request then we get this error#9004. Progress KB - What is the Progress AppServer asynchronous request mechanism?

Could someone pls shed some light what would be the possible solution(s) on this?

Thanks

OpenEdge Development - Forum
Posted by Brian K. Maher on 29-Nov-2016 11:20

Hi Karikalan,
 
You can just check the AppserverHandle:ASYNC-REQUEST-COUNT  and when it returns zero there are no more outstanding/active async requests and you should then be able to run your sync request.
 
/* loop until all async requests are complete                */
 
DO WHILE AppserverHandle:ASYNC-REQUEST-COUNT <> 0:
     PROCESS EVENTS.
END.
 
/* once DO WHILE block ends there are no more async requests */
/* so now we can run the sync request.                       */
 
RUN <ExternalProc>.p ON AppserverHandle.
 
Brian
 

Posted by Brian K. Maher on 29-Nov-2016 11:36

Hi Karikalan,
 
Can you please mark my answer in communities as having resolved your question?
 
Thanks, Brian

Posted by Thomas Mercer-Hursh on 29-Nov-2016 13:49

By "handled sequentially" do you mean will be assigned to process in the order they are submitted, then I believe the answer is yes BUT, there is no guarantee that the return will be sequential.  That is the whole nature of async.

Posted by Brian K. Maher on 29-Nov-2016 13:50

Hi Karikalan,
 
Session-Managed = one connection to the appserver broker, async requests are queued up in the client and executed one at a time, one after the other.
 
Session-Free = the connection creates a pool of connections on the client, async requests are queued up and parsed out to available connections within the pool.
 
Does that make sense?
 
Brian

All Replies

Posted by Brian K. Maher on 29-Nov-2016 05:44

Hi Karikalan,
 
If you need to make async and sync calls to an appserver at the same time you will need to define two handle variables (one for async calls and the other for the sync calls) then connect to the appserver twice and split your calls between the two.
 
Brian

Posted by Karikalan Ram on 29-Nov-2016 10:46

Thanks Brian,

For example, I've an valid appserver handle and not sure whether its already handling any asynchronous calls before I submit any synchronous call I would like to check if any asynchronous calls are in process/uncompleted/queue. I can see some other external progress procedure runs asynchronous RPC with respective EVENT-PROCEDURE. I am developing the new program with the statement to submit synchronous RPC using same app server session handle. In this scenario, I've 3 options. 1. Use new appserver handle to submit synchronous RPC 2. Instead of running synchronous mode, submit the call in asynchronous mode. 3. Before submitting synchronous call check if any asynchronous call already in process.

For option 3, I understand OpenEdge provides a mechanism to check the status of asynchronous requests for a session-managed connection or session-free operating mode. Just to make sure if no asynchronous calls are in queue/process, can we check this criteria by

IF VALID-HANDLE(AppserverHandle) AND AppserverHandle:COMPLETE THEN /* To make sure no uncompleted aynchronous calls exists. */

 RUN <ExternalProc>.p ON AppserverHandle.

DO WHILE NOT AppserverHandle:COMPLETE:

 PROCESS EVENTS.

 IF AppserverHandle:COMPLETE THEN

   RUN <ExternalProc>.p ON AppserverHandle.

END.

Thanks.

Posted by Brian K. Maher on 29-Nov-2016 11:20

Hi Karikalan,
 
You can just check the AppserverHandle:ASYNC-REQUEST-COUNT  and when it returns zero there are no more outstanding/active async requests and you should then be able to run your sync request.
 
/* loop until all async requests are complete                */
 
DO WHILE AppserverHandle:ASYNC-REQUEST-COUNT <> 0:
     PROCESS EVENTS.
END.
 
/* once DO WHILE block ends there are no more async requests */
/* so now we can run the sync request.                       */
 
RUN <ExternalProc>.p ON AppserverHandle.
 
Brian
 

Posted by Karikalan Ram on 29-Nov-2016 11:32

Great, thanks Brian.

Posted by Brian K. Maher on 29-Nov-2016 11:36

Hi Karikalan,
 
Can you please mark my answer in communities as having resolved your question?
 
Thanks, Brian

Posted by Karikalan Ram on 29-Nov-2016 11:46

Sorry Brian, done.

Posted by Karikalan Ram on 29-Nov-2016 11:50

Brian, Just curious to confirm, if we submit the call in asynchronous mode again it wont cause #9004 error isn't it? I beleive if operating mode is session managed then new asynchronous call will be in queue, if session free then it would be paralley executed. Pls let me know if my understanding is wrong on this. - Thanks.

Posted by Brian K. Maher on 29-Nov-2016 13:24

Hi Karikalan,
 
If you have outstanding async requests and you try to submit a sync request using the same server handle you will receive the error.  It doesn’t matter if you finished all the async requests then started more.  The rule is this .. if there are any async requests active you cannot use the server handle for a sync request.
 
Brian

Posted by Karikalan Ram on 29-Nov-2016 13:38

Hi Brian, I understand if any outstanding async requests and try to submit a sync request using the same server causes error. However, despite of outstanding "async" request if I submit another "async" request in session free mode then it wont raise any error and it would be handled parrally. In session managed mode these "async" requests are handled sequential order. Is that correct? - Thanks.

Posted by Thomas Mercer-Hursh on 29-Nov-2016 13:49

By "handled sequentially" do you mean will be assigned to process in the order they are submitted, then I believe the answer is yes BUT, there is no guarantee that the return will be sequential.  That is the whole nature of async.

Posted by Brian K. Maher on 29-Nov-2016 13:50

Hi Karikalan,
 
Session-Managed = one connection to the appserver broker, async requests are queued up in the client and executed one at a time, one after the other.
 
Session-Free = the connection creates a pool of connections on the client, async requests are queued up and parsed out to available connections within the pool.
 
Does that make sense?
 
Brian

Posted by Karikalan Ram on 29-Nov-2016 13:57

Fine, thanks Brian and Tom.

This thread is closed