Task77 Editing
A 'long' call into a client should not temporarily pause the server. Eg. a call to some Command object held in a client should occur asynchronously, returning straight-away rather than waiting for the remote function to return. This might be implemented by having a thread run command::execute, with some method of timing-out before killing the thread (if it has not completed already). A thread-pool might be used to minimise thread creation/destruction. At a later stage this could be implemented using AMI, when we have an orb that supports it. This is suggested as a way to implement non-blocking pinging for connection-tracking, since that also involves calling client code asynchronously.
As an alternative to AMI (ie. before that is implemented in an orb that we use), I found that you can use the DII to make 'deferred synchronous' calls. See: http://www.iona.com/hyplan/vinoski/col15.pdf What I envisage is that we have a 'remote execute' thread, which steps through entries in a queue of Commands to be executed. For each Command it uses the async method (AMI/DII-deferred-request/...) to try and run it; if it fails within some timeout period it signals an error condition. It then proceeds onto the next entry in the queue. Entries are added into the queue when a command would previously be execute, eg. when clicking a button. If we get an error condition (failed to contact client before some timeout), we might kill the client, or 'remove one of its lives' (eg. kill a client after n failed attempts), or... Does this sound reasonable?
I think the proper way to handle this is by using the messaging QoS specs, i.e. inside the ORB. This means we don't need to care ourselfs, once the POAs and objects are instantiated. I'll remove this task from milestone2, as this solution will take more time. In any case, there is no need for haste.
While I definitely think that the messaging spec is the ideal way of solving this, I don't see a reason for not doing a separate solution just for fresco, as an available alternative. This comes from a) we don't have an orb that has the messaging spec supported (yet), so an early implementation might be useful to examine what functionality we need b) we might want to run with orbs that won't support the messaging spec, eg. old or embedded/proprietary orbs (we're not limiting fresco to using orbs that are free, are we?) As long as the clients don't need changing, which applies to AMI as well as the 'alternative' methods suggested here (and assuming we can perform the encapsulation easily enough) I see no harm in having some wrapper system. This may also be useful for other reasons: I've not read the Messaging Spec at all, but what if we need behaviour beyond it, or want to treat certain calls differently? The encapsulation could be useful for those situations as well. That is, while we don't wrap the core corba api at all, I currently think that the non-corba specs should be wrapped, to allow alternative implementations - if just from a coding standpoint, if we isolate the code dependent upon each (non-core) corba spec, we can deal with problem implementations (eg. with certain orbs) or extensions to corba specs separately. Perhaps this is over-the-top, but we can't always rely on just porting omniorb and then porting fresco ;) However granted this is not necessarily something that is a 'major target' for the next milestone; OTOH, I might have a play with a DII fix...at some point ;)
hmm, I meant 'non-core specs', not 'non-corba specs' :)
I'm not going to tell anybody not to work on something, or not to experiment. However, providing a mechanism to protect the server from blocking client requests is non-trivial to say the least. You can't encapsulate it, as this surfaces to the API. Either your method call will return after completion or it will push a request for execution on a task queue, at which point you have to poll the result explicitely. I'd rather spend my time with something more worthy and rely on the ORB doing this job for me, if I can. omniORB is going to have it at some point in the not-so-far future, and TAO already has it (no surprize, Douglas Schmidt, its author, is one of the authors of these new specs...). Find me any other ORB we can cooperate with, then we can talk about how to make it support AMI and the rest of the messaging QoS spec. Again, feel free to try out different schemes to invoke callbacks asynchronously, but you may have a hard time convincing me that the Fresco interfaces should be adjusted to make this change explicit.
stefan, I think I understand your general concerns, but the issue I ran into (bug201) were Command calls. I believe these are relatively easy to fix, without changes to the API and without ORB support. In that case, there is no result to be queried by the server from the client, so the client doesn't have to offer additional ways to query the result and the further server execution also doesn't depend on the complete Command execution. The only difference is that right now, we implicitly mandate clients to implement Commands in a way that they return quickly, because people will run into bug201 otherwise. I believe that a quick return would be a bad rule (when made explicit in the documentation), because it makes the implementation of clients a lot more difficult. And we'd have to deal with bad clients anyways. So, either way, we should allow clients to let Command->execute() to take as long as it wants, which means that it makes no difference to the (wanted) API, if we implement a workaround now or not. The only difference is, if we expose that unwanted behaviour (bug201) or not. Meaning that it actually helps API-stability to implement a workaround now, because clients don't have to work around our bugs. </ramble> > I'd rather spend my time with something more > worthy I vaguely remember having a patch which worked around the issue for me, but you rejected it. I don't remember the details anymore, though (what I did or why you rejected it). I think I could dig it up, if wanted. > Find me any other ORB we can cooperate with IIRC, Sun's ORB in Sun Java 1.4 works with Fresco.
Ben, I have never seen any code 'fixing' the blocking nature of standard CORBA method invocations. If you have some, it would indeed be interesting to discuss it here. The semantics of synchronous (distributed) method invocations is a bit more involved: you have to wait till the method is done, or else you won't be able to catch exceptions that may be thrown midway. Look at exceptions as some form of return value. That's precisely the problem with the (old) CORBA spec for 'oneway' calls: it's unreliable. The new specs allow a lot of fine-tuning, so you control the level of reliability your application needs. It's good to know that other ORBs work with fresco, but the context here is about ORBs we can run the display server with, i.e. an ORB with a C++ mapping.
not logged in
register
Home