Forum ‹ BigDB ‹ Unable to create BigDB objects - thread aborted

[wildbunny]

Hi guys,

Don't know if any admins have seen the post in c# forum:

http://playerio.com/forum/csharp/thread-was-being-aborted-t1528

But I'm unable to create bigDB objects anymore, the thread keeps getting aborted and i've no idea whats going on...

Any help is greatly appreciated

Cheers, Paul.

[Oliver]

Hey Paul,

I assume you're getting this issue in the development server?

Would you be willing to zip your project up (server+client) and send it to me along with steps to reproduce? Then we'll look at it from our end.

Best,
Oliver

[wildbunny]

Hi oliver,

Yes, i can do that - do you just need .exes or buildable source code as well - if so do you need server and client?

Cheers, Paul.

[Oliver]

sources for client and server. won't share and will delete after use for debugging.

[wildbunny]

sources for client and server. won't share and will delete after use for debugging.

Did you get my mail that I sent last friday with the code?

[Oliver]

Yes, i have received it. It's on my todo for today or tomorrow.

- Oliver

[markloika]

Oliver - I think I'm experiencing a similar problem. My development server is aborted sometimes. When it does abort, it aborts under one of the following conditions:

DatabaseObject.Save(); - Sometimes that works, sometimes it aborts with no visible reason why
Player.Send(); - Same as above - sometimes works, sometimes aborts

If it helps, this is the data I'm trying to save (or send). This is what it traces out to when it has successfully been received by the client:

Code: Select all

type:      world
length:      27
content:   Id   Type      Value
         ---------------------
         0   int         1
         1   ByteArray   Length:6000
         2   ByteArray   Length:6000
         3   int         2
         4   ByteArray   Length:32778
         5   ByteArray   Length:32778
         6   int         3
         7   ByteArray   Length:190
         8   ByteArray   Length:190
         9   int         4
         10   ByteArray   Length:178
         11   ByteArray   Length:178
         12   int         5
         13   ByteArray   Length:198
         14   ByteArray   Length:198
         15   int         6
         16   ByteArray   Length:160
         17   ByteArray   Length:160
         18   int         7
         19   ByteArray   Length:178
         20   ByteArray   Length:178
         21   int         8
         22   ByteArray   Length:170
         23   ByteArray   Length:170
         24   int         9
         25   ByteArray   Length:148
         26   ByteArray   Length:148

When it comes to saving it in BigDB, I'm structuring it just like Chris does for the EE world data. You can see a screenshot of a successfully saved object here:
http://share.erebosgames.com/index.php? ... height=689

In that screenshot, the byte arrays for the x and y coordinates are extremely short, much shorter than what I'll actually be saving. That was just for testing - the point being it doesn't seem to be caused because there's a lot of data being saved to the DatabaseObject, there's hardly any. What I'll actually be saving is the same as what the client receives (in the above code snippet).

[Oliver]

Inside .Save and .Send we check to see if your runtime has gone for too long before we do the actual Save or Send.. In fact, we do this in all places you call into our code; it's a fairly new thing.

So, could you check if perhaps you have some code before calls to .Send or .Save that run for too long?

[wildbunny]

Inside .Save and .Send we check to see if your runtime has gone for too long before we do the actual Save or Send.. In fact, we do this in all places you call into our code; it's a fairly new thing.

So, could you check if perhaps you have some code before calls to .Send or .Save that run for too long?

How do you handle slowdown due to OS page-file access, or any other rubbishness associated with windows?

Perhaps this watchdog checking would be best left as a switch or only on the live server?

Cheers, Paul.

[markloika]

Oliver,

Thanks for the insight on why this happens. What the issues seems to be is the world generation for the game I'm currently working on. I'm faced with an issue - the server has a strict limit on how much time it will allow a thread to execute, right? Yet the load on the server varies, so what it can accomplish in that time window will vary widely. I've tested my world generation function many times without issue on worlds up to 400x400 blocks (160,000 blocks), yet it seems to abort with the same frequency as it does when I test with world sizes on 100x200 (20,000 blocks). The problem is in the fact that I have no way of knowing how busy the server is - so I have no way of knowing if the server will be able to generate 160,000 blocks with no issue, or if it will fail (due to time) in generating only 20,000 blocks.

In looking at a similar situation, If I visit a website, and the website's web server is under heavy load, I may have to wait a few more seconds than normal for the web page to load - but the web page will still load unless the server is under extreme load. The same problem of varying server load applies to the player.io servers, except that if the server is busy, instead of taking more time to process things, the server breaks the game.

I don't know what the best solution for this problem is. I understand the need to not allow code to execute for long periods of time, but it also is not ideal to limit the code execution time in this manner.

Does player.io offer a way to lift this thread execution time limit? Do you guys raise the limit for higher paying plans? Do you offer dedicated servers at additional cost? It seems a dedicated server may be the best situation, because then the limit could be listed entirely. What do you think? How can I get around this issue?

[wildbunny]

Any news on when this will be resolved?

I can't use bigDB at all due to this

[markloika]

WildBunny - I talked to Chris, and he said that this was an issue in the dev server only and that it would be resolved soon (or perhaps that was only my issue - I'm not sure if we have the exact same issue). In any case, I put my code up on the live servers, and I've only had one abort since then. It's a bit concerning that there was that one abort, but I guess it's better than nearly 100% of the time like what I get using the dev server.

[Oliver]

Hi Guys,

I'm gathering this issue into a single thread, see here: multiplayer/cpu-runtime-thread-aborts-t1620

[wbsaputra]

yes i can't create new bigdb object anymore and got this error
An unexpected error occured inside the Player.IO webservice. Please try again

[Tenko]

Oliver,

I've tested my world generation function many times without issue on worlds up to 400x400 blocks (160,000 blocks), yet it seems to abort with the same frequency as it does when I test with world sizes on 100x200 (20,000 blocks). The problem is in the fact that I have no way of knowing how busy the server is - so I have no way of knowing if the server will be able to generate 160,000 blocks with no issue, or if it will fail (due to time) in generating only 20,000 blocks.

I believe it is possible to create an event timer in the C# server?
http://playerio.com/documentation/reference/multiplayer/playerio.gamelibrary.timer

If this is so, you can split up your world generation algorithm to only process X elements per timer execution. Once the timer stops executing it shouldn't keep counting the milliseconds of operation, it should reset?