Cancel a single asynchronous AppServer request?

No, sorry,  there is no way to just cancel one request.  If you close the .p with the event procedure, it just won't get called when the async procedure ends, whether it ends normally or due to a cancel all.

Then closing the .p with the event procedure, and restarting it for the next async call would get closest to what I want, without getting errors.

Thanks Laura.

ps: I could add a feature request for this if you think it is technically feasible to implement this...

Three things:

1. I assume you checked to see that there is not a CancelRequest method on the async handle itself (as opposed to the server handle). I'm not at work to check.  But I'm pretty sure there isn't one, thus my original answer.

2. Just to be clear, if you close the .p with the handler, the handler won't get called.  But the .p will still have run on the server.  

3. I know we contemplated doing this but it is problematic to implement.  So I doubt we would do it now.  But you can always try

1. Indeed, there's no such method.

2. Yes, that's what I've understood. I'm about to test this out now.

3. I'll log an 'Idea'...

Thanks!

Hi Laura,

After testing it seems your suggestion isn't working. I get the following error when deleting the .p that has the event procedure:

Invalid event-procedure context encountered when trying to invoke event procedure '<ProcedureName>'. (8982)

I'm hesitant to add a WAIT-FOR PROCEDURE-COMPLETE since that will cause succeeding calls to be stacked on top of that wait-for...

Do you have any other ideas or suggestions?

My colleague has solved this for another case by keeping track of the number of outstanding asynchronous requests, and instead of deleting the procedure we mark it as "ShouldDelete". When the number of outstanding requests reaches 0 and we ShouldDelete, then we delete the procedure. I'll try that out now...

Whenever we fire an asynchronous request we first create a dedicated (state-free) AppServer connection for the request. The client can have a pool of (we decided on a maximum of 10) asynchronous AppServer handles.

There were technical challenges to implementing this having to do with managing the queue of requests and responses for asynch procedures.  One of the considerations is that when you run multiple asynch requests, they go into a queue that the AVM attempts to manage 'behind the scenes'.  This involves sending queued requests and queuing their response and issuing the next request.  This happens even when the AVM is not waiting for events so it is not always easy to know if a particular request has been already executed when you try to cancel it.

Gee.  I did not think we issued an error if we couldn't find the handler context.  I thought we just ignored it and gave up.  

But it sounds like you have a solution anyway.  You don't necessarily need to delete the procedure.  If you keep track of what you wanted to cancel, for example in the PRIVATE-DATA of the asynch handle, you can let the handler run and just don't do whatever it was you were going to do in there,,like display the results.