1

Can someone come up with a good example how JSOM code (Meaning JavaScript, and not REST) can cause a server-side memory leak?

My initial opinion was that it's highly unlikely that you can write such code, but if someone challenged you to do it, would you be able to? What would you do to cause the worst memory leak? Request all webs, lists, columns over and over again? Write to property bags, etc?

We have some JSOM-based solutions and a very large SharePoint on-prem farm. Some people suspect that these JSOM solutions might cause a memory leak, but I don't know how to prove/disprove it yet.

What do you think?

1 Answer 1

1

(Trying to answer from both an On-Prem and Online context here...)

No, you cannot create a server side memory leak in JavaScript unless you're interacting with a custom server side component.

What you're describing though isn't so much a memory leak as a performance degradation, which you certainly can do. Some examples off the top of my head:

  • Executing asynchronous requests in an infinite loop could tax the system and simulate a DOS attack. Taxonomy calls are particularly resource intensive so if I were to try this I'd probably start there. An incompetent or sloppy developer could certainly do something like this inadvertently and could cause a big problem if enough people execute this code (and there is no code review process to stop this from getting to production).
  • Uploading LOTS of document content in JavaScript could definitely cause issues on the server and could result in a SharePoint Online tenant getting throttled. I've seen this happen before. In an on-prem environment it could definitely cause memory spikes with enough volume.
  • In an extreme case, suspicious client side traffic could result in an Online tenant getting blocked.

Some light reading around the topics of throttling and blocking in SharePoint Online: https://docs.microsoft.com/en-us/sharepoint/dev/general-development/how-to-avoid-getting-throttled-or-blocked-in-sharepoint-online

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.