Few features that'd be nice

Mike Hearn

Hiya,

I'm playing around with Ice for a simple game I'm writing. It runs a "world simulation" in a Java process, and the world state is serialized using the Freeze Evictor. Works great! I have a few questions/suggestions:

1) Java only has single inheritance and doesn't support mixins natively. It really should.

As is, you have to write delegation methods manually, ie if you have a class that already inherits from Ice.Object and would like to implement an interface using a 'stock implementation', you can't do that. You either have to duplicate the code each time, or write methods like void foo() { mixin.foo(); } which is annoying.

You can solve this in regular Java with an automatically generated proxy object that knows how to route the calls around to the right implementing class. To the user, the proxy looks like a regular class that implements a bunch of interfaces. To the person implementing the object, they can delegate any interface to another object at their convenience.

Ice is already generating such proxy objects, it'd be nice to reuse them. Concretely, my proposal is something like:

class AnnotatedItem {
// allow administrator to make himself notes about things
string getNote();
["freeze:write"] string setNote(string value);

string note;
}

class Widget mixin AnnotatedItem {
// now Widget doesn't have to implement getNote()/setNote()
// because slice2java will implicitly add a data member like
// AnnotatedItem __a;
// and then forward getNote() and setNote() onto it.
// In the case of name conflicts an slice compile error occurs.
// From the users perspective, our Widget can now be given notes
// and it seems to be just a regular set of operations.

int blah();

}


2) It's not really clear to me if methods marked ["freeze:write"] are synchronized by the dispatch thread or not.

Will the evictor thread possibly try and save my object while an RPC is operating inside it or not? If so why do I have to synchronize on it manually, can't the runtime do that?


3) I'd like to be able to drain a server using an RPC.

I think the hold() and waitForHolding() methods will nearly do what I want, but it's not clear what happens if I run these within an RPC. Will this cause deadlock as waitForHolding() waits for all currently running RPCs to finish, including the one that invoked it? Also, will direct dispatch calls block whilst the object adapter is in a holding state?

I've got two use cases in mind here - the first is I'd like to have my server go unhealthy if something bad happens to it, in which case, it'll temporarily not handle "user" RPCs. But I'd still like it to handle "admin" RPCs like to find out internal state, etc.

The other use case is that I'd like to be able to avoid some concurrency issues by draining away RPC traffic so the server can go through and do some updates/housekeeping on all its (freeze managed) objects without having to deal with concurrent RPCs. My current thinking is to use a single dispatch thread, then have the "housekeeping thread" just fire off an RPC to the dispatch thread.

It's kind of a roundabout way to do things though. I'd rather give the waitForShutdown() method a timeout, so I can run it in a loop from my main thread and wake up every few seconds to call hold()/waitForHolding()/update()/activate() on the root of my object tree. Because I want Freeze to manage my objects though, I must do update() via proxies, thus, I want to avoid external RPC traffic but still allow internal direct calls!


4) I'd like to maximize "coding by convention" to minimize boilerplate.

Right now I am using some simple reflection and utility functions to eliminate most boilerplate code needed to use Ice/Freeze, but I still need to call addObjectFactory for each class I want to use.

All my implementations are named with the I suffix convention - it'd be nice if Ice could find all classes named that way and register them with a single generic factory by itself. It's not really straightforward because Java doesn't let you list the classes inside a package in an easy way, but it can certainly be done (eg, Hibernate does this).

I might well do this myself and send in a patch at some point, seeing as I have some of it written already. I don't actually have enough classes for it to really be a pain, I am just anal-retentive about boilerplate code

Thanks!