Support ajax monitoring about applicationinsights-js

[SergeyKanzhelev]

Questions:

• How monitoring will behave if send will be sent again before the callback or result returned?
• Is it a valid scenario to do multiple send for one open?
• Will we detect long-poll ajax calls and adjust their processing so they do not make average ajax execution time enormously big?
• Do we instrument abort method?
• is Callbacks only stored in XHR object itself? If not - will it keep it from being garbage collected as it keeps delegates on it?
• Will the ajaxRecord stay alive after trackAjax call? Will Callbacks unsubscribe of onreadystatechange after that?
• Do we plan to stop and send in-flight ajax calls on page onbeforeunload callback?

As a side note I'd advice to set a lock when you call original Open and original Send so that "originl" callback wouldn't call you back and enter recursion in case when customer application has some logic that also does override of XHR and do not expect somebody in the middle to change callbacks.

[MaxShehovtsov]

Thank you for the feedback:

• 2nd should fail (and does so in chrome), however we shouldn't execute send handler 2nd time. I'm adding validations for this.
• long ajax - I think they will be there, spoiling averages, and it's by design
• We do instrument abort however we currently don't send any data about abortion status. So depending on timing when abort was called - if request succeeds it'll be treated as any other ajax call. It makes sense to send the custom property with abortion status though.
• by callbacks i mean 2 different things 1) the xhr instance owns the onreadystatechange callback, it lives on xhr and dies with it. 2) there is an event listenerer for "readystatechange" event - this one lives on ajaxMonitor instance, however it gets unsubscribed once xhr is complete. Unless the number of xhr instances that are not completed (aborted or finished) grows we should be ok. Otherwise we'll not be major contributors to the memory growth.
• ajaxRecord dies with xhr
• onbeforeunload proved unusable for events sending, so all open ajaxes will be lost (similarly to other batched telemetry unless batch timeout and/or batch size is overriden)

[bengreenier]

i noticed there's no milestone associated with this issue - any idea when this feature will be officially supported/fully documented?

[MaxShehovtsov]

Hopefully within next couple weeks

[bengreenier]

bump - any updates here?

[MaxShehovtsov]

@bengreenier It's actually done - https://azure.microsoft.com/en-us/blog/ajax-collection-in-application-insights/
P.s. I thought I closed this issue - my bad it's left open, sorry.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.