Spinning off new progress sessions from the 4GL

Version? Platform?

And isn't this what an AppServer does? Or is for, really? Spawn off persistent AVM sessions?

-- peter

The version is Progress OpenEdge 10.2B.

The target platforms are both Windows and Unix Solaris.

Need more information.

What are the relationships of these new sessions with each other and with the session that creates them? What are their life cycles? How are these sessions managed and/or monitored? Do they have user interfaces of some sort? What resources will they use? How many will exist simultaneously? Are they all owned by the same user? Are they members of the same group? What operating system? etc.

The Progress Appserver server obviously must have some logic to spin off brokers.

However the problem I am trying to solve cannot be solved by the appserver.

I am spinning off continuously running server processes that are polling a task queue and process every task that is pushed into the task queue.

A variable amount of these "task servers" will be spun off to handle to the volume of tasks in the task queue.

The use case is this.

• I have a queue table in the database
• I have a number of server processes that poll the queue table
  • As soon as a new task record is created in the queue table with a process flag of false then the server process processes the task and sets the processed flag to true
• As many "task server" server processes are instantiated as needed to attend to each task in a timely fashion
• There is a control panel that takes care of instantiating the desired number of "task servers" 
  • We do not want to have to processing a shortcut the desired number of times

The target platforms are windows as well as solaris unix.

Ideally we would be able to spawn task servers from a windows client on a unix server.

For this we are considering to use a JAVA hazelcast distributed queue wrapped in a COM object in windows and a shared procedure library (.so) library on Unix.

The problem I need to solve is how to do an os-command on Unix as well as windows that does not block.

In other words the os-command returns the program cursor control to the progress session while the task servers go about there business of fully instantiating and running.

If we do go the hazelcast route I could make the com object, so library and the java jar file available as an oopen source project if there is interest for that. 

So you are only concerned about how to spawn a background process (worker) to run some ABL code? Try

PIDFILE=/tmp/worker.pid
mpro -b -p /path/to/some/workercode.p >> $LOGFILE 2>&1 &
echo $! > $PIDFILE

if you want to pass in arguments, you should be able to do something like this:

ARG=foo mpro -b -p /path/to/some/workercode.p >> $LOGFILE 2>&1 &

and then in the workercode.p,

OS-GETENV("ARG").

(Unix solution obviously)

You could also use inetd to start your background processes automatically when a request arrives on the assigned port. You would have to add an entry to /etc/inetd.conf. Your batch process would then be started with the file descriptors 0, 1, and 2 set to the socket. You could change them from that as needed.