Dealing with outstanding async requests.

Trap the WINDOW-CLOSE event and CANCEL-REQUESTS there?

Also, since you are bombing out of your client it could be an idea to also trap the STOP event.

Thanks.

Is there any way to end the requests without having to wait?

Before using async requests we were waiting for the GUI to open, now, on a bad connection, it can take 4 or 5 seconds to close the window.

I did the cancel-requests but there is still quite a wait with that.

I suppose I could engineer the requests differently.  ATM I have them all firing at start up.  I could poss change that to load extra info about what the user clicks with an async request whilst displaying the info I already have at the client.

That way there would only ever be one or two requests outstanding.

I suppose a working GUI with a loading indicator is better than a GUI that doesn't work at all.

Hmm...

It's a hell of a lot more complex to work out how to work this when you have stuff going off asynchronously.  If it works though it'll stop a lot of complaints about the GUI hanging when the user is trying to open an enquiry screen.

Thanks for the help!

With a messaging technology, you could just step away from any pending requests without delay.

I'm not sure if this is what the good doctor means below (or above), but if you pass all asynchronous events through a central event handler on your client that services all your windows you could then simply let that catch the no longer required async results.

Ah, ok.

So I would have a persistent procedure running off the top level of my program (i.e. the main menu screen thing) called asynchHandler or something.

Then my window opens and sends off an async request to the server and specifies an event-procedure in asyncHandler that then publishes a message with the output but doesn't care where it goes.

The window that sent the request in the first place subscribes to the message in the asyncHandler so if it's open it deals with the message if not nothing happens.

Or is there a better design for this?

That sounds cool.  I've done similar stuff with OO design in the past.  (I realise this isn't OO stuff but the design principal is similar).

Thanks for the help!

Just been thinking a bit about this and I've thought of something else.

All the AppServer requests that have been written on the client so far are synchronous.

Say, for example, I was to open a window that sets off some BIG async requests (they will take maybe 15 seconds to complete (this is hypothetical)) then I close the window.

By using the message proxy system the requests will still be dealt with once they have completed.

BUT, if the user then opens another window which tries to run something on the AppServer synchronously then will this still crash out due to the outstanding async requests?

The only way round this that I can see working with no conflicts between synchronous and asynchronous requests is to have a separate AppServer set up for async requests.

This would mean having the client connected to 2 AppServers for the duration of the session.

Is this right?  Is this OK to do?  Or is there a better way around this?

Thanks again for the help!

Oliver

I think you just create a seperate connection to the same appserver with a new server handle.

e.g.

create server hAsyncServer.

create server hServer. /*for syncronous*/

hAsyncServer:connect (....).

hServer:connect (....).

As long as you have available agents you can then run both sync and async

ojfoggin schrieb:
The only way round this that I can see working with no conflicts between synchronous and asynchronous requests is to have a separate AppServer set up for async requests.

Two separate client connections (SERVER handles) should do even well - no need for a separate Appserver setup.

 This would mean having the client connected to 2 AppServers for the duration of the session.
Is this right?  Is this OK to do?  Or is there a better way around this?

I see nothing wrong with it. From a license point of view I do also see no issues. Progress does license clients in the form of machines or users accessing the AppServer, not simultanious connections.

Thanks both!

I've set up the server connections as you suggested and it's working smoothly again.

I haven't set up the "proxy" async request handler yet though.  I thought I'd get on with something that someone can actually see

The system is coming on in leaps and bounds now though

In the past month we have gone from a nightmare to a smoothly runnign system!

Thanks for the help!

I was referring to using Sonic instead of AppServer.

Ah.

Not really used Sonic before.

I've seen the name around in our software but that's about it.

I'll have a read up on it tomorrow.

I think that may be something to look at for the future definitely.

Greg Higgins has described some of how he is using Sonic where other people would use AppServer in a thread of mine about using WebClient over here http://communities.progress.com/pcom/message/59405 .  AppServer seems like a natural way to partition an application to a lot of people because they start with an idea of the whole problem and then divide that up into things they would like to have happen on the server and things they would like to have happen on the client and stick AppServer in between.  If they do that well, they might come up with some common services on the server used by many different kinds of processes, but there is nothing inherent in the design process to push you there.  But, if you start thinking of your application as a set of semi-autonomous services all communicating across a bus, not only is it highly likely that you will consolidate similar code into a single service, but you start thinking about an application being loosely coupled.  When I see async requests, that screams for loose coupling to me.

With AppServer, you create a relationship between a client and an agent for the duration of the request.  You have to expect either one of them to get upset if the other one isn't there to handle the action until the request is finished.  With messaging, it can often be send and forget.

Can you run the asysc request from somewhere that a user doesn't close regularly such as the menu or a super?

I'm now running the request from the current procedure and then sending the resultant event-procedure out to a persistent program of the main menu.

It still means hanging around when closing the application if there are things waiting on the server though.

If you haven't done so, spending a day or 2 to learn Sonic and the 4GL Adapter for sonic is worth it as opposed to writing your own messaging system using 4GL (ooops, it's now ABL).