How to find number of free appserver agents?

[adisney]

We have an application which works with a stateless appserver, minimum of 2 servers, maximum of 5. We may have 100 users making calls to the appserver.

(Please excuse me if my terminology is not 100% correct - hope you can figure out what I'm asking here)

Using information gleaned from a session at the last Exchange, we have just added the capability (for our users) of making an asynchronous request for large reports. This allows the report to be generated on the server side (may take from 1 min to an hour) while the user continues to work with data entry tasks on their screen. User is not allowed to make a second report request until the first one is completed and appears on their screen/printer.

We're concerned that too many users will request these large reports at once, tying up 5/5 appserver agents and preventing anyone from doing anything else. Is there any way to query the broker and see how many appserver agents are either busy or available? That way, if 4/5 were busy, we could prevent users from submitting a request which would tie up the last appserver agent.

Any ideas would be *greatly* appreciated.

Anne Disney
Great Valley Technologies

 

[sdjensen]

I know this is a wild suggestion but you asked for it ;-)

You know you can see the number of avail app servers from the server by using the asbman.

$DLC/bin/asbman -i <name> -query

My wild suggestion is that you do an os-command and with the asbman and parse the output.


Another solution could be starting to two app servers. One for normal use and one for big reports.


If there is another solution I will look forward for it as we could use it as well in our system.

 

[KnutHandsome]

I think you are looking at it the wrong way.

• I would stick in a db flag/counter to control access to 'special' functions. This approach is just a system-wide extension of "User is not allowed to make a second report request until the first one is completed".
  
• Investigate why certain reports are taking an hour, and if there are ways of speeding them up.
  
• As for reporting generally, just create a server process queue and add the report requests to that to be emailed/whatever when they are completed.

 

[KnutHandsome]

If you insist on monitoring agent access, then you should be able to write connect/disconnect procedures to update a db flag/count.

However this may be unreliable (compared to sdjensen's suggestion) due to unhandled exits, I'm not sure.

 

[TomBascom]

IMHO this is the real solution:

* As for reporting generally, just create a server process queue and add the report requests to that to be emailed/whatever when they are completed.

Use an app server call to put report requests in the queue. Run the server queue as a batch process on the server (connect self-service for best performance). You could also create status checks and all sorts of exciting functionality like that using app-server calls. You could use an async call to do it but there really isn't any advantage to doing so.

Async app servers sound interesting and the reporting use-case sounds good but, so far anyway, I don't think the actual implementation is particularly useful for anything beyond a demo.

 

[sdjensen]

We have been running the batch solution for the last 10 years and it works without problems.

A nerd solution could be to write the broker yourself. All it does is parsing your connection to the avail app servers. So if you create a program that listens for connections and when it gets one, it parses the infomation to another program which basically " run program xx with parm yy". Output is then parsed back to calling program.

The problem with this solution is the speed and loadbalance.

 

[FrancoisL]

You could create 2 different broker with one broker dedicated to the App and one broker with 1 or 2 agent dedicated to reporting.

You can be sure that one will not prevent the other.

 

[adisney]

Thank you all for the advice/ideas.

Tom writes "Use an app server call to put report requests in the queue. Run the server queue as a batch process on the server (connect self-service for best performance). You could also create status checks and all sorts of exciting functionality like that using app-server calls. You could use an async call to do it but there really isn't any advantage to doing so."

The reason we are making the async request to the appserver is so that the printer output can be sent to the user's printer, which is often available only to the client side through an RTS session. Or so that the output (when ready) can be popped up on the user's screen. I couldn't see how to do that, especially the first, without an async request.

As far as the long reports - most are reasonable, but there are certain unpredictable queries which are occasionally run over millions of DB records and just take a long time.

Anne

 

[KnutHandsome]

The reason we are making the async request to the appserver is so that the printer output can be sent to the user's printer, which is often available only to the client side through an RTS session. Or so that the output (when ready) can be popped up on the user's screen. I couldn't see how to do that, especially the first, without an async request.

The server process just emails the report to the user when complete, but you are correct it will not just automatically print out unless you intercept it in some way - but normally a user will want to preview a report before printing - it may be hundreds of pages long.

As far as the long reports - most are reasonable, but there are certain unpredictable queries which are occasionally run over millions of DB records and just take a long time.

There may be scope for improvement by implementing better indexing/denormalisation/seperate reporting schema/etc. but that's a seperate discussion for other people, and you may well have it covered.

 

[TomBascom]

I don't get it. Why would that have anything to do with anything? This sounds like an application with no separation between business logic and data access? Which would be a problem in terms of even using app servers at all.

Are you doing "output to printer" or some such thing?

If you are then, IMHO, that's a mistake. You should always output to an intermediate file and then, if appropriate, preview it, send to a printer e-mail it or shred it.

 

[GregTomkins]

We have (over the years) invested a huge amount of time and energy developing the queue type approach Tom suggests. It's an entire subsystem of ours. It includes a Sonic message (with polling backup) back to the client that either prints the report right away or lets them look at it on-screen, in both cases by converting the report to PDF using GS, shipping the PDF across the network using MEMPTR's, and finally rendering it with Acrobat. This system has a million bits and pieces to it and frankly every time I see a report print I marvel that it actually worked, but it does; it's a core part of our app.

Async AppServers having little practical value for us. I thought they sounded awesome when I first heard about them and made vague plans to replace all of the above with them, but upon further thought decided the queue system is actually much preferable, never mind the fact that we had already built it.