starting a gem from another gem...

If I wanted to do something like that a gem and have it start 1 or more other gems to do some work, what is the best way to do that?

Hi Sean,

The basic rule is that a Gem must be associated with a GCI client library and there are a variety of ways of referencing a GCI library. The typical approach is to use Topaz or access a GCI library from Smalltalk (such as Pharo). Your question, however, asks about starting a Gem from within another Gem, that is, from GemStone Smalltalk.

One approach is to use System class>>#'performOnServer:' to execute a Topaz process with a script. This is somewhat straightforward and the script can be created and tested from a command line before being incorporated into the Smalltalk code.

A more sophisticated approach is to use the GemStone Smalltalk class GciInterface. A limitation of this approach is that it is difficult to pass back complex objects (and use of the traversal buffer is disabled). You could, however, pass back a simple flag and execute code that stores more complex objects in the database (through a commit). Another limitation is that you need to have a NetLDI running (not needed for linked Topaz). Finally, there is a certain amount of confusion about error reporting. But with those limitations, it does give you an option.

James

| parameters gciLibrary x y |
parameters := GemStoneParameters new
        gemService: '!tcp@localhost#netldi:gs64ldi#task!gemnetobject';
        gemStoneName: 'seaside';
        username: 'DataCurator';
        password: 'swordfish' copy;
        yourself.
gciLibrary := GciInterface new.
[
        x := gciLibrary
                login: parameters
                execute: '2 + 3'.
        y := gciLibrary remoteExecute: '#abc at: 2'.
] ensure: [
        gciLibrary logout.
].
^Array with: gciLibrary lastError with: x with: y.


On Sep 24, 2010, at 1:37 PM, Sean Allen wrote:

> If I wanted to do something like that a gem and have it start 1 or more other gems to do some work, what is the best way to do that?
> I looked through the programming guide and tried searching for information but didn't find anything. I assume the answer would be in
> there somewhere. Pointers on where to look would be appreciated.
>
>

Hi Sean,

This discussion arrives at a perfect timing for us! Same needs here to
start a background task.  Our background task is probably going to
take a lot of time (large data upload). It takes already 30 minutes in
an early prototype.

James simple topaz-based approach would certainly work here. The data
upload trigger will move from the web site to a cron job anyway.

Trying to digest Dale's code.


Thierry

Thierry Thelliez wrote:
I always pop a couple of Tums before trying to digest my code:)

Dale

Do you get Tums in Africa? Oops, gave my position away :)

We've followed the topaz background process approach. It works,
mostly. The issues we're having are:
1. We've got to be careful because if we dynamically launch topaz
processes when a we user hits a button, we run into resource problems
on the machine as there are too many (resource hungry) sessions, and
they end up starving the hyper servers.
2. Error handling is a challenge because it is difficult to know
what's going on in the background. Sure, it's good to commit
"progress" or something back into GS so that you know what's going on.
And build a resilient "catch all" handler that a) logs useful
information and b) perhaps commits (hopefully successfully) something
GS to tell you what went wrong.

We've implemented a "Worker" kind of model that picks up work when it
arrives in a Queue on another project (proprietary, unfortunately not
ours to give away). Anyone interested in something like that too?

Cheers
Otto

On Wed, Sep 29, 2010 at 2:05 AM, Dale Henrichs <[hidden email]> wrote:

Otto Behrens wrote:
The "Worker"-style model is kinda what the sevice vm work is aimed
at..The implementation that Nick worked on evolved into a futures
framework for GemStone where the future is actually on another vm ....
the current model is based on a single vm, but could be extended to
multiple vms feeding off of the queue...

The maintenance vm is a sort of worker vm as well...tasks can be
dynamically added to be performed in the vm ...

I'd be interested in hearing the types of tasks that need to be done ...
if you'd fork of a green thread in a client smalltalk to perform the
task, you need to run it in a separate vm (of some sort) in GLASS...

Dale