Android Application freezes up completely when using saveEventually()

[tutorbear]

Issue Description

saveEventually() is suppose to save objects using relations recursively just like saveInBackground does. The logic of my code is very simple and straight forward. I have a logged in user. I create a new ParseObject (Profile) and associate it with the user. Then when I call saveEventually The entire app freezes up.
Yes Local Db is enabled

Steps to reproduce

1. Signup and login.

2. Put this code on the onClick listener of a button in android.

   Parse user = ParseUser.getCurrentUser();
//A profile object
profile = new ParseObject("StudentProfile");
profile.put("user", user);
profile.put("name", "John");
profile.setACL(new ParseACL(user));
//Put profile object into user
user.put("profile",profile);
user.saveEventually();

Expected Results

user saved along with new profile object while pointing towards it.

Actual Outcome

App Freezes

Environment Setup

• parse-server version: 3.9.0
• Hosted on Back4app

Logs/Trace

Non , App freezes up and stops responding

[Jawnnypoo]

Can you pinpoint the exact line that causes the freeze, and can you see if saveInBackground causes the same freeze?

[ramiro-ciocca]

@Jawnnypoo, I don't know if @tutorbear problem is related with the issues I have opened about LDS and saves.
I see that @tutorbear is trying to save an object with a pointer to an usaved object, maybe that is his problem.
But, there is a real issue with LDS and saves. If your LDS grows enough, and you try to save some complex object, with some pointers to other objects, then the app hangs.
I explained in #1006 and in #993 that what causes the hangs is a recursive method inside ParseObject that inefficiently traverse all the LDS with each save.
I dont know if you could fix the entire LDS, but what I know is that we can have a true/false parameter in every save method to tell ParseObject that we don't wan't cascade save, just root object.
I have done a crap fix commenting out the recursive line that starts the LDS traverse, it would be very easty to add a true/false parameter that ignores that recursive line.
I could do it if you explain to me how to upload this change, I know nothing about merge requests.
I made magic downloading the sdk, making modifications and generating my own aars that works as I need them to work (without cascade save).
Let me know if I could help with this.

Thanks!

[tutorbear]

@Jawnnypoo
Hello.
SaveInBackgound() works fine, its saveEventually() thats causing the issue. I have tried it with both LDS enabled and disabled , on both occasion the app freezes up. And I have found exactly whats wrong.

Parse user = ParseUser.getCurrentUser();
//A profile object
profile = new ParseObject("StudentProfile");

// THIS LINE is the curprit----------------------->
profile.put("user", user);
//-------------------------------------->

profile.put("name", "John");
profile.setACL(new ParseACL(user));
//Put profile object into user
user.put("profile",profile);
user.saveEventually();

No error is givin in the log cat, only this is shown
Background concurrent copying GC freed 346064(19MB) AllocSpace objects, 0(0B) LOS objects, 49% free, 20MB/41MB, paused 338us total 191.114ms
Background concurrent copying GC freed 372128(21MB) AllocSpace objects, 0(0B) LOS objects, 49% free, 21MB/43MB,
Background concurrent copying GC freed 372128(21MB) AllocSpace objects, 0(0B) LOS objects, 49% free, 21MB/43MB, paused 454us total 201.072ms
And this keeps on going on and on in the Logs.

@ramiro-ciocca Like ramiro said complex pointer saving is causing the issue i guess ?

[tutorbear]

So no one is going to do anything about this issue ? Has the android skd community given up on fixing bugs ?

[ramiro-ciocca]

Hello, like I said in previous comment, in your particular case, I think that trying to save a parse object with a pointer to an unsaved parse object can lead to problems.
Said that, we know that local data store has a lot of issues, and in certains conditions it collapses apps.
The main problem are the saves in all their variants, that by default try to save in cascade the root object and all its pointers, traversing all the local data store recursivelly, looking for dirty children, and hanging the app.
Like I said in previous posts, I have succesfully implemented a "cascade save false" variant of the sdk, that prevents the hangs. With this fix, you have to take care about saving the root object and every children you need to save as well. No cascade save, but no hangs.
I think this should have been the default behavior since the beggining of the sdk, and we should have a parameter "cascadeSave" true or false, just like the js sdk has.
The LDS should be revamped but I think that is a lot to ask.

[tutorbear]

Yes I too have found a work around , but its sad that we have do do work arounds while the community is still there.
Too much to ask ? Yes maybe it is I guess ? No one wants to take up a task this big. Since we have found work arounds , they chose to ignore it I guess. I just feel sorry about the fact that this will always remain buggy. Apart from this one problem I have found many others related to the LDS. Have a look at this post.
parse-community/Parse-SDK-iOS-OSX#535
This issue was first posted in the year 2005 and still pending answers lol. Anyone and everyone has just gone through work arounds and thats it. Very sad in my opinion

[mtrezza]

Too much to ask ? Yes maybe it is I guess ? No one wants to take up a task this big. Since we have found work arounds , they chose to ignore it I guess.

First of all, thank you for taking the time and bringing attention to the issue. Bug reporting and analysis are important first steps to fix an issue, and we are glad to have you in the community. As you already mentioned, this is a community effort. Do you want to take the next step and dig deeper into this to open a PR?

[Shvet]

Hello, I have same problem as above saveEventually() keep code in loop and garbage collector is running with it which is giving me application isn't responding error.

[mtrezza]

It would be great if someone could open a PR with a failing test to replicate this.

[Shvet]

What do i have to add for PR? I can create simple android code for this but on sever side i can not share info as it would not be mine. @mtrezza

[azlekov]

@Shvet which version of the SDK are you using, can you update the issue description?