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

Memory Leak #92

Closed
rickyv3 opened this issue Nov 16, 2016 · 13 comments
Closed

Memory Leak #92

rickyv3 opened this issue Nov 16, 2016 · 13 comments
Assignees

Comments

@rickyv3
Copy link

rickyv3 commented Nov 16, 2016

Hello,

It appears a recent version of the widget results in a large memory leak. As I am sure you can imagine, that has caused all sorts of performance related issues for us. We utilize temporary objects in conjunction with this widget, but it seems that the temporary objects are not actually temporary.

I've attached a couple screenshots to show you what we are seeing within our app. We have also brought this up to Mx and they confirmed our suspicion, that the chartjs widget is causing a memory leak. Our contact at Mx was sure this is only fixable within the widget itself.

Can you take a look?

objectcache

objectcount

@JelteMX JelteMX self-assigned this Nov 17, 2016
@JelteMX
Copy link
Contributor

JelteMX commented Nov 21, 2016

Could you test this version? This should fix the problem, although I still have to look into the DataPoints, not sure if those are released as well

@JelteMX
Copy link
Contributor

JelteMX commented Nov 21, 2016

Update: Same link now links to version that will also release datapoints if they are there. It uses https://apidocs.mendix.com/6/client/mx.data.html and is done in uninitialize.

It checks if mx.data.release is available, as this will be deprecated in Mendix 7

@rickyv3
Copy link
Author

rickyv3 commented Nov 22, 2016

Hi Jelte,

We've given the fix a try, and it seems we have only part of the solution. The cache is cleared when the user signs out of the app, which is good, but it is not cleared when they leave the page. We believe the datapoints, datasets and chart objects should be cleared when the user leaves the page where they generated said charts.

@JelteMX
Copy link
Contributor

JelteMX commented Nov 22, 2016

What do you mean with 'cleared'? As in, this should be cleared in the backend? If that's the case, this should be fixed by my fix, using mx.data.release. On the front-end these values do not remain, as they are part of the widget (and thus destroyed).

If it is indeed back-end, we have to check it with R&D, because this is the only viable solution that I can think of.

@JelteMX
Copy link
Contributor

JelteMX commented Nov 23, 2016

Got some other feedback that this doesn't solve the issue yet (keeping objects in the cache), which seems strange. Next thing I am going to try is doing a mx.data.release when ChartJS has plotted or on a refresh

@rickyv3
Copy link
Author

rickyv3 commented Feb 16, 2017

Has this been addressed? It doesn't look like it has been resolved on our end.

@rickyv3
Copy link
Author

rickyv3 commented May 3, 2017

Hi Jelte - anything new to report here? We are running into big issues.

@JelteMX
Copy link
Contributor

JelteMX commented May 10, 2017

Well I still haven't found out what the problem is. We are releasing all objects in the widget, I double checked. This might be an issue R&D has to investigate, because I'm running out of options here

@JelteMX
Copy link
Contributor

JelteMX commented May 10, 2017

I did some intensive investigation and I conclude that this is not an issue with the widget itself. Yes, objects weren't released in previous versions of the widget, which is bad practice, so it seems. That's why we introduce mx.data.release in the uninitialize method. (per release 3.5.3)

Did this solve the problem in the test-project (GC-Test on Sprintr)? No. This was created in Mendix 5.21.5. I checked the issue in our own test-project and objects were kept in the cache.

But, then I decided to open our test-project in Mx 6.4.1. The non-persistent objects are not kept in cache when mx.data.release is called. Therefore , the problem is not in the widget itself, but in the MX runtime.

To solve the problem, the options are limited:

  • Update to Mendix 6

That's all I can say about this issue. I know this will not solve the problem in Mendix 5, but that's not something I can do. What I will do is this: introduce an onDestroy microflow in the widget. This one will be called when the widget is destroyed and will use the dataset object as input parameter. This way you could delete the object yourself (which should not be necessary, but in this case I think it's the only viable solution to this problem).

JelteMX pushed a commit that referenced this issue May 10, 2017
@JelteMX
Copy link
Contributor

JelteMX commented May 10, 2017

Suggestion added to 3.6.0

@JelteMX JelteMX closed this as completed May 10, 2017
@rickyv3
Copy link
Author

rickyv3 commented May 10, 2017

We are using Mx 6.10.3, and the issue persists.

@JelteMX
Copy link
Contributor

JelteMX commented May 10, 2017

Every object that gets into the widget, is released upon uninitialize. The backend knows we don't need the objects anymore. In my test-project the issue was resolved, which would mean that this issue has nothing to do with the widget, but with the model in your project.

@JelteMX
Copy link
Contributor

JelteMX commented May 10, 2017

Out of curiosity, two things you could try (might not make sense, but could help):

  • Use the newly added onDestroy microflow under behavior, remove the non-persistent chart entity. This should mean that the other objects can be destroyed, as they have no reference anymore
  • Set delete behavior on the non-persistent reference. Like I said, doesn't make sense, since they are non-persistent, but I'd like to know if that might help.

As far as I know I have everything covered in the widget to release the objects. This would mean that there is something else wrong with the logic in your project. Contact Support, I think we'll need access to the project to see where the problem occurs. It can't be this widget, because the issue was resolved in our own test-project.

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