Problem with Opentalk

Hello,

We are working using VisualWorks 7.3.1 and trying to develop a kind of broker logger for logging statistics. The problem is that we cannot find where the remote messages are received.

We wrote down a self halt messaje at Object>> remotePerform: withArguments: and this is the stack we get.

Halt encountered.
WindowManager(Object)>>halt
WindowManager(Object)>>remotePerform:withArguments:
Opentalk.STSTRequest>>doTheWorkFor:
Opentalk.STSTRequest(Opentalk.RemoteRequest)>>evaluateFor:
Opentalk.STSTRequest>>evaluateFor:
optimized [] in Opentalk.RemoteMessage>>dispatchFor:
BlockClosure>>on:do:
Opentalk.STSTRequest(Opentalk.RemoteMessage)>>dispatchFor:
optimized [] in Opentalk.RemoteRequest>>dispatchFor:
BlockClosure>>on:do:
optimized [] in Process class>>forBlock:priority:

We found out that we couldn't find any object receiving the request, but a new process is created instead, so we lose track of the excecution. Any idea which object receives the remote request ?

Ivan Baisi wrote:
Actually this stack shows a subtle issue we had back then and that might be causing some of your troubles. By default Opentalk transfers the contents of your client process environment with your requests to the server. If you're running inside the UI process on the client side, it will take the WindowManager entry with it and install it in the server process as a remote reference back to the client. That can really screw up some tools perusing that process on the server. The fix is to make sure the WindowManager entry doesn't get copied. You need to patch STSTRequest>>getProcessEnvironmentAssociations: as follows:

getProcessEnvironmentAssociations: aConnection
       
        ^(ProcessEnvironment current environmentDictionary associations
                reject: [ :assoc | assoc key = #WindowManager ]),
        (aConnection transportEnvironmentAssociationsFor: self)

I'm not sure when we fixed this, but 7.3.1 sounds old enough to still have that problem.

>
> We found out that we couldn't find any object receiving the request, but
> a new process is created instead, so we lose track of the excecution.

Not sure why. Your halt is executed in the process that will run the incoming remote request, so you shouldn't be loosing track at this point.

Here's a bit of background. The incoming request has to be executed in some process. There aren't that many processes already running in an image. While Opentalk could conceivably interrupt one of the existing UI processes (#interruptWith:), it's hard for me to imagine any case where that would actually be desirable. Having a dedicated process for this purpose is about the only sensible thing to do here. Alternatives are largely just variations of how many of these processes you have and how are they managed. Opentalk will simply spawn a new process for each request by default. It makes sense because Smalltalk processes are cheap and there are no artificial limits to worry about. Alternatively you may want to maintain a pool of processes that can be reused, possibly as a means to limit the amount of concurrently executing requests. However pretty much immediately you have to worry about things like recursive remote calls (what if a single distributed interaction manages to ti
e up all the threads in the pool?). You can come up with zillions of minor variations on this theme. This is all managed by the RequestDispatcher in recent versions of Opentalk (not sure if 7.3.1 is recent enough). You can easily try other available dispatching strategies or come up with your own.

 
> Any idea which object receives the remote request ?

The receiver is the 'target' object in the incoming STSTRequest. The request also holds the 'message' that will be performed on that receiver and few other interesting properties.

As far as logging goes, there are built in mechanisms in Opentalk that should suffice for most purposes:

1) Opentalk brokers and adaptors trigger events for most interesting things that can happen during their operation. You can get a pretty good idea using the following

        broker sendAllEventsTo: EventPrinter new

where broker is your RequestBroker instance. It will print all events into the Transcript. You can use the same mechanism to plug any kind of activity to any of the events. See chapter "Using Broker Events" in doc/OpentalkDevGuide.pdf.

2) In VW 7.4 we added a more "standard" way of doing the same called MessageInterceptors. It's described in the 7.4 ReleaseNotes.

HTH,

Martin