07-09-2020, 09:28 AM
One of our senior developers is working on an Intraweb app which we are trialing with around 2000 end users per day. On occasions, the handled exception shown below is raised. This would be fine however it leads to approximately 20% of users experiencing a continual timeout waiting on the return of any callback submissions.
It is important to note it is not all users, or just ones connected after the event that is affected and it always follows on from one of these exceptions.
It would appear it is from the aSync Callback taking time to complete on a slow connection so the button does not disable quickly enough and though the process lock is in place for the callback if they click it enough before it disables the button then it raises the Exception.
We have worked around this by adding in an onClick javascript setting 'disabled = true' by directly referencing the button within the DOM, thus client-side. This is just a little labor-intensive and I would have expected it to be experienced by others. The callback is a aSync event and not just a form submission as we have to ensure that certain data is processed before submitting.
As such my questions would simply be:
1) Why does the Exception then affect a percentage of other users and make the platform unstable?
2) Is it possible within Intraweb to automatically force a client-side disable of buttons without having to manually create the javascript to disable or is the technology always designed to be server-side via the aSync callbacks?
3) As we are still getting the error (I assume by the user refreshing via the command line) is there any way to ensure it does not affect others.
Thank you in advance for sharing your thoughts.
-------------------
Exception message : Session is already locked.
Session ID is invalid.
Exception class : ESessionAlreadyLocked
Session ID : xl6wwk6EmwwelmrhI0sdUSvmaNa
Exception details : UrlPath=/$/callback
Exception address : 00000000008ECD79
Exception Time : 2020-07-08 15:19:17.966
------------------------------------------------------------------------------------------------------------------------
//REDACTED
Compiler Version : 300
//REDACTED
IntraWeb Version : 15.2.3
Multi-session : True
//REDACTED
Session count : 489
//REDACTED
Request PathInfo : /0~0fvmTbdG-jD5jbI2S4~oC2G4a/$/callback
Request Method : POST
Request User Agent : Mozilla/5.0 (iPhone; CPU iPhone OS 13_5_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.1.1 Mobile/15E148 Safari/604.1
Cookies Count : 1
It is important to note it is not all users, or just ones connected after the event that is affected and it always follows on from one of these exceptions.
It would appear it is from the aSync Callback taking time to complete on a slow connection so the button does not disable quickly enough and though the process lock is in place for the callback if they click it enough before it disables the button then it raises the Exception.
We have worked around this by adding in an onClick javascript setting 'disabled = true' by directly referencing the button within the DOM, thus client-side. This is just a little labor-intensive and I would have expected it to be experienced by others. The callback is a aSync event and not just a form submission as we have to ensure that certain data is processed before submitting.
As such my questions would simply be:
1) Why does the Exception then affect a percentage of other users and make the platform unstable?
2) Is it possible within Intraweb to automatically force a client-side disable of buttons without having to manually create the javascript to disable or is the technology always designed to be server-side via the aSync callbacks?
3) As we are still getting the error (I assume by the user refreshing via the command line) is there any way to ensure it does not affect others.
Thank you in advance for sharing your thoughts.
-------------------
Exception message : Session is already locked.
Session ID is invalid.
Exception class : ESessionAlreadyLocked
Session ID : xl6wwk6EmwwelmrhI0sdUSvmaNa
Exception details : UrlPath=/$/callback
Exception address : 00000000008ECD79
Exception Time : 2020-07-08 15:19:17.966
------------------------------------------------------------------------------------------------------------------------
//REDACTED
Compiler Version : 300
//REDACTED
IntraWeb Version : 15.2.3
Multi-session : True
//REDACTED
Session count : 489
//REDACTED
Request PathInfo : /0~0fvmTbdG-jD5jbI2S4~oC2G4a/$/callback
Request Method : POST
Request User Agent : Mozilla/5.0 (iPhone; CPU iPhone OS 13_5_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.1.1 Mobile/15E148 Safari/604.1
Cookies Count : 1