Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SharedObjectPool clearUnusedObjects is making my app to freeze more than 6 seconds! #6

Open
CrazyFlasher opened this issue Jul 23, 2015 · 6 comments

Comments

@CrazyFlasher
Copy link

..it calls GC and killing everything for 6.5 seconds!
Please fix this or at least make SharedObjectPool class public to avoid auto clean up.

Here is a scout log:
https://dl.dropboxusercontent.com/u/13321619/space-balls.flm

45th second

@PrimaryFeather
Copy link
Contributor

Sorry to hear about those problems — and thanks for the report!

Wow, that's really an amazingly long time ... may I ask what you've been doing that there are so many objects to be collected?

(Flox stores shared objects for each request it makes to the server, as well as for all entities, to be able to cache them if the server is not reachable.)

After all, if there was no SharedObjectPool, those objects would be released just as well (but probably multiple times, so it would take even longer); and if we don't clean up, memory consumption might just go up and up and you'd run out of memory at some point.

@PrimaryFeather
Copy link
Contributor

What I also don't understand is that after 6.5 seconds of garbage collection, the memory usage does not change at all! That's extremely strange ...

@CrazyFlasher
Copy link
Author

I do nothing special.
Just logging in player, getting completed levels and friends completed level.
Is it possible to disable storing shared objects for each request Flox makes to the server?
I have my own caching system.

@PrimaryFeather
Copy link
Contributor

No, you cannot disable that, and it wouldn't be advisable, because you'd lose all offline functionality, which would make your development efforts much harder. Anyway, I was a little imprecise before: not all requests are stored as shared objects, only those that are queued (e.g. "entity.saveQueued()").

May I ask why you are so sure that it's the SharedObjectPool that causes the garbage collection? And how often have you noticed this huge delay — is it easily reproducible?

You're the first to have reported this, so there must be something special in your case. Such a huge pause wouldn't be easy to overlook, I'm sure this would have been reported if more people had experienced that problem in the past.

@CrazyFlasher
Copy link
Author

"May I ask why you are so sure that it's the SharedObjectPool that causes the garbage collection?"
I saw that in other scout log. I made SharedObjectPool as public and disabled auto clean. That helped with this issue.
"And how often have you noticed this huge delay — is it easily reproducible?"
Always on 45th second, when clean up called.

I'll investigate more tomorrow. And write more details about this issue.
By the way, where I can read more about offline functionality of Flox? May be there is no need for me to use my own offline functionality?

@PrimaryFeather
Copy link
Contributor

I'll investigate more tomorrow. And write more details about this issue.

Thanks! What would be especially interesting is a trace out name and size of all SharedObjects at the moment they are deleted.

By the way, where I can read more about offline functionality of Flox? May be there is no need for me to use my own offline functionality?

There's no specific manual page about that, but I'll give you an overview:

  • Any entity methods that contain the keyword "queued" (e.g. saveQueued) will be stored and executed when the device becomes online, in the correct order.
  • If you make more such calls on the same entity (e.g. call saveQueued multiple times) Flox will detect that redundancy and will just store/execute the last of those calls.
  • Whenever you load an entity, it will be stored in a cache. When you then load an entity while the device is offline, you'll have access to this cached version in the onError callback (via the cachedEntity:Entity parameter).
  • The entity Player.current is special and will always stay in memory. Every time your game starts, Player.current will contain the exact state it had when you left the game, without contacting the server. (You can call refresh on that entity to make sure it's in sync with the server.)
  • Calls to postScore will be queued as well.
  • Calls to loadScores also have a cachedScores:Array argument in the onError callback.
  • Any analytics data (session duration, logs, etc.) are also sent through the queue, i.e. when you play several games while being offline, all the data will be sent once the player goes back online.

I hope that helps! :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants