Suggestion: the "initialize()" task in AppListener not timeout

Networking & Multiplayer
#1

This wasn’t a deal in 0.9 but, in 0.9.2, my initialized gets timed out.

Of course, I’m running WAY over 1 second, since I’m creating my initial world.

I tried breaking it into sub-bits but, in one area in particular, I’m running over 1000ms just with the file-IO (I read in a config file to define what the world-map looks like.)

Surely the SGS team is aware of the cost-of-initialize()…? Can we get an exception, there?

I know: “write a , using <some documentation that doesn’t exist>”… Uh…, can I get a better hint?

:o

(9.2. looks nice, otherwise :slight_smile: – don’t mean to sound like I’m always bitching; it’s a gift, I guess… 8) )

#2

No, we really do want the feedback.

And we’re looking at the options for exceptional tasks that take longer right now-- including making initialize a special case.

Thanks!

#3

Just a quick note: I really DO appreciate you guys’s openness, here – and the product, even at this “pre-1.0” stage, rocks. It’s nice that I can make my comments in conversational style, and that you understand that I’m not being insulting, just trying to express suggestions/frustrations/ideas without going on for pages and pages.

That part’s very-very nice. I’ll try to remember to not be too abbrasive :wink:

#4

So, is there a temporary workaround for this?

sgs 0.9: I got a lot of
May 12, 2007 12:54:23 PM com.sun.sgs.impl.util.NonDurableTaskQueue$ProcessQueueTask run
WARNING: task queue unexpectedly empty
which made client-communication difficult. It was suggested that I upgrade to 0.91 (or later.)

sgs 0.9.2: can’t initialize my world (task timeouts.)

Can someone suggest a temporary fix to get me back up & testing?

Thanks!

#5

Can you split the work up into two or more tasks that chain each other using the TaskManager?

#6

From my original post (top of page):

Breaking down “open the file, then create a task to read a little of the file, then create a task to read a little more…” sounds like a lot of work. Is there no override I can set?

Alternately, you mentioned that you’re looking into allowing an exception for initialize. Any estimation about when that might be ready? I know you can’t give dates, but can you tell me if it’s a handful of days or weeks or months or years?

Thanks!

#7

Could you possibly put in a hack, temporarily, that did it’s heavy initialize a static block, and initialize() just looks it up? I’m not sure if AppListener.initialize() get’s rescheduled if it times out (since the first call would still timeout).

#8

For a temporary workaround, I’m willing to put in a hack, but I’m not sure what you mean by look-up a static-block.

I’m pretty sure I’m not going to statically declare the world-map – that’s not what you mean, is it?!

Ooo! Am I allowed to fire-off a thread? I suppose I could do that easily enough. Or is it bad-manners for an SGS-Task to do:


new Thread() { public void run() {
   goDoRealInitialization();
}}.start();

?

#9

Sorry, I had a typo in my original post, and I had just woken up, what I was thinking of was something like this


public class Server implements AppListener, Serializable, ManagedObject {
	
	private static final long serialVersionUID = 1L;

	private static final MyWorld world;  // Object that is initialized in static block
	
	static {
.
.  // initialize here in static block
.
 	}

	public void initialize(Properties properties) {

.
.
.
		
	}

	public ClientSessionListener loggedIn(ClientSession clientSession) {
.
.
.
	}	
	
}

Firing a thread off is bad manners, but if you can’t get it to work any other way, maybe that would be ok for a temporary solution. (Just make sure you put a nice TODO to mark it for removal in the future).

Of course, as more of the API becomes public, I’m sure there are much better ways to approach this.

#10

Sorry, at this time no.

Id say we’ll have this resolved in weeks or months. But beyond that at this time I dont know.

There is one other work around. Its ugly but it works: write a special “initialization client” that you connect with after the start of the server to load the data and send it to the server.

This is how wonderland initializes its world currently.
.

#11

Keep in mind that any thread you kick off will be outsiude of the transactional system and unable to read or write data in the object store.

And yes, its really bad manners. Non transactional code should properly go in services and even then use our kernel to get any threads it needs as we’re trying to track resource usage. Since we haven’t told you how to do that yet, though, I realize thats not yet an option.

The static suggestion init block isnt a bad idea as a work around. The only problem I see is that your going to fill system memory with your data where it will remain and this will happen every time you restart the server, not just in the initialize() case. What you do to create a static code block is this:


public class F1oo implements Serializable,ManagedObject {

    static {
          // code here to load the data into storage in memory
    }

    public void initialize(){
         // create managed objects from data in memory
    }
    
}

This is better then throwing your own thread, but not as clean as using an “admin client” approach.