Any way to extend the timeout on individual HTTP requests?

We've built an admin page/widget which uses ajax calls to a helper 'attachment' within the widget itself which does the work.. we call it like this in the front-end JS;

Fullscreen

1
2
3
4
5
6
7
8
9
10
## Simplified code for ease of reading
jQuery.telligent.evolution.post({
    url: '$core_v2_encoding.JavascriptEncode($core_v2_widget.GetExecutedFileUrl('changeGroupPerms.vm'))',
    data: { sourceGroupId: data.sourceGroupId, groupId: data.groupId }
})
.then(function(response) {
    console.info(response.message);
    if (!response.success) window.failedCount++;
    resolve();
});
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

## Simplified code for ease of reading
jQuery.telligent.evolution.post({
	url: '$core_v2_encoding.JavascriptEncode($core_v2_widget.GetExecutedFileUrl('changeGroupPerms.vm'))',
	data: { sourceGroupId: data.sourceGroupId, groupId: data.groupId }
})
.then(function(response) {
	console.info(response.message);
	if (!response.success) window.failedCount++;
	resolve();
});

The chageGroupPerms.vm attachment in the widget takes a while to complete, especially if the group we're changing has a lot of sub-groups.. sometimes it'll take over 2 minutes, at which point the chageGroupPerms.vm returns a 500 error.

It's literally a few seconds off completing (I added logging to find out how far through it is)

Is there any way to increase this timeout for this request since I know it'll take a bit longer than usual?

FYI, we're hosting this in Azure as an app service (so we're not running IIS as such).

Thanks!

Top Replies

0 Karl Barber over 3 years ago

Would an alternative be to create an automation and fire back any responses as an email to the site admin

or you could look to increase the timeout site wide (via httpRuntime in web.config) but this seems like something which should not be running as a widget
+1 Former Member over 3 years ago

Try Scheduling Background or Long Running Processes
0 Matt over 3 years ago in reply to Karl Barber

Karl Barber said:
but this seems like something which should not be running as a widget

I know what you mean, but it's an admin panel for our team to apply bulk changes to whatever groups they select.

It has a nice progress bar and works really well in the main.. apart from these parent groups, which take longer for Verint to process under the covers.
0 Karl Barber over 3 years ago in reply to Former Member

Matt you could combine this with community.telligent.com/.../scheduledfile-ui-component

which can be used to show progress
0 Matt over 3 years ago in reply to Karl Barber

Sounds good.. I'll see what I can put together. Thanks for your replies Mathew & Karl.. I really appreciate it!
0 Matt over 3 years ago in reply to Karl Barber
BTW, I think I have another alternative.. I added a helper script API with the following C# code;

Fullscreen
1
2
3
4
5
6
7
[Documentation("Set the timeout on a particular request (overriding the default, which is 110 sec)")]
public void SetRequestTimeout(int Timeout)
{
var context = System.Web.HttpContext.Current;
if (context == null) return;
context.Server.ScriptTimeout = Timeout;
}
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
[Documentation("Set the timeout on a particular request (overriding the default, which is 110 sec)")] public void SetRequestTimeout(int Timeout) { var context = System.Web.HttpContext.Current; if (context == null) return; context.Server.ScriptTimeout = Timeout; }

We can then add this to the top of any widget worker code that is going to take a little bit longer than usual;

$e14_utils.SetRequestTimeout(180)

In my limited testing it looks like it's done the trick; I see to see how it behaves when it hits our Azure environments later today.

When I get time I'll look into the other suggestions you had