Sign In Register

How can we help you today?

Start a new topic
Answered

Option for downtime

Hi, I was wondering whether we could take down the server if we want to do some maintenance? For example, if I want to modify the database internal structure, it would be hard if there is no way to take down the server for a while


Best Answer

Hi Samuel,

Using snapshots you can have your current configuration live on the server while working on changes in a separate one. When it's ready to be published you can switch to the newer snapshot and avoid having any downtime in your game.


Thanks,

Liam



Answer

Hi Samuel,

Using snapshots you can have your current configuration live on the server while working on changes in a separate one. When it's ready to be published you can switch to the newer snapshot and avoid having any downtime in your game.


Thanks,

Liam


This is a good way to do it. However what about some automated daily maintenance? I use the "Every Day" script to do some archiving of data that won't be used anymore and some other things that I do not want to handle manually. Data consistency could be affected if players continue to interact with the server at that point.

Is there a way to block GS interaction and notify players automatically? 

I am now thinking about having a single entry in a "management" mongodb collection for this. Setting a bool to true/false at every end of the "Every Day" script and adding a function to check it in each of my events, blocking player input and showing them a message. Is this a good solution? Would the continuous looking at this collection be efficient?

On a related matter: how to know at what time the "Every Day Script is run? And is it possible to affect that value?


Thanks.

Gabriel


Gabriel,


Your single "management" entry solution is what we use in our games, but we called the collection "Configuration". When the game starts or resumes we call a cloud event to get the current configuration and alert the player if there's a maintenance or a mandatory app update. But to support Apple long review process, we had to include a version number to the configuration.

The "configuration" document structure:

{

version:"1.0"

maintenance:false or false

requiredAppVersion:"1.0",

....

}


So during an Apple review process:

  • the old game read version "1.0" of the configuration which has its maintenance flag set to true. A maintenance alert is shown to the players.
  • The game in review read version "1.1" which has its maintenance flag set to false and the requiredAppVersion set to "1.1". So no alert will popup to the Apple reviewers.
  • Once the new version is available, we update "configuration" version "1.0", with the following values: maintenance:false, requiredAppversion: "1.1". So players won't see the maintenance alert but the "update app" alert. 

We were doing this because the development effort was really to great to support the old and the app simultaneously. On the downside, the maintenance period could last many days depending on the review process.


Maybe some else has a better design that he wants to share with the community.


Christian

As for the other questions:

how to know at what time the "Every Day Script is run?

You can add Spark.getLog().debug("Daily task time: " + new Date()); then check the log collection in NoSQL console.

or wait for GS support to answer :-)


And is it possible to affect that value?

I'm quite that you can't. But it's still doable. let's say you want to run a task around midnight in the New York time zone, add a system task that runs at every hour and the first thing the task does is to check the current time and if it's near GMT-5 process the real job. You will have to store in collection the date of the last run to avoid processing the job twice. 

This was instructive. 

I'll go forward with this dedicated collection solution then. And probably also with this version control system.

I would however still like to hear about the solutions others GS users have devised, or if this solution is standard.

Thanks Christian.

We're using GameSparks' Properties for storing configuration information such as minimum client version. Advantage over a dedicated Mongo collection is that Properties are (supposed to be) included in the configuration you download via the REST API (and probably in the snapshot as well, although I haven't checked). Currently doesn't actually end up in the downloaded configuration but I'm told they're working on it. 


For the Apple review process: if your game requires logging in / identifying yourself you could create a separate GameSparks environment containing the new version, and use a few hard-baked reviewer accounts that will have your game connect to this sandbox environment instead of the live one. Then update the live environment once the app is through review.


Thanks Christian for the versioning tip - smart to use a separate configuration per app version, and using a Mongo collection for this makes sense.

Login to post a comment