I am wriring a program that spins off new progress sessions directly from the 4GL.
Anybody has suggestions as to what is the best way to go about that?
And isn't this what an AppServer does? Or is for, really? Spawn off persistent AVM sessions?
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.
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.pidmpro -b -p /path/to/some/workercode.p >> $LOGFILE 2>&1 &echo $! > $PIDFILE
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,
(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.