Make long-running steps in progress indicators (particularly API calls) run on monitored background threads

[Alan Birchenough]

This was derived from the following reported issue:

I have tried cancelling and re-creating the project numerous times, but it always gets stuck at the same point.

I attach the relevant log. It is now 10:39a, and you can see that 9 minutes have therefore elapsed since the last log entry.

Thanks - I am really stumped here!

As described in a comment below, ideally long-running steps of long-running operations wouldn't run in a sync/blocking mode but would instead run in a monitored background thread so that intermediate status (e.g., "Still working...") and mid-operation cancellation requests could occur.

[Alan Birchenough]

I wonder if I should close this now - after 13 minutes it "unstuck". However, that seemed like a long time during which nothing appeared to be happening.

Sorry for the churn.

[Alan Birchenough]

You can close this unless you have any advice regarding ways of expediting delays like this, or at least, finding out where the sticking point is. Otherwise, my experience of the SF API is that whether it is responsive on a particular day in a particular org seems a little random. Again, sorry for the churn. I will endeavor to ensure that my next report will be worth working on.

[Scott Wells]

Sorry for the long-delayed response, Alan (from me, I mean, though I guess from the server as well!). My kids were out of school today so my wife and I played hooky with them and went to Six Flags! I only had my phone with me so it wasn't an ideal quick support situation.

That's definitely a LONG time for it to be running, but the fact that it finished certainly indicates that it's a long-running request against the server. IC is configured internally for a 5 minute timeout on each request against the server, so given how long it took, it sounds like multiple requests were long-running. Unfortunately there's not much that I can do to change those server response times when it goes that direction. What I could do is give the user an indicator that server interactions are running long just so that it doesn't look like things are wedged. Since you just experienced this, I'd love to hear your thoughts on how the UX might be improved. If you're amenable, let's keep this issue open to collect that type of feedback and then I'll decide whether this issue morphs into a UX-related enhancement or just gets closed.

[Alan Birchenough]

Hi Scott -

This wasn't very urgent and your support responsiveness is already off-the-charts awesome, so there is no problem on that score. I hope you and the family had an enjoyable visit to Six Flags.

i will give the feedback question some thought. However, you are already using the IJ user interface in a nice and standard way complete with background running option, so I am not sure what more you can do within the confines of operating as a well-behaved IJ plugin. The question would be what options exist for displaying something like "still here - still attempting to contact the server". We are already using the status bar and the progress dialog. Perhaps you can log an event in the event log, although not being an IJ internals expert I am not sure if that complies with their UX guidelines. At any rate, anything logged in the Event Log gets one's attention straightaway. Whatever you do decide to do, this is something that occurs infrequently, so it shouldn't be elaborate, and shouldn't take too much of your effort away from more interesting backlog items. ;-)

Just my $0.02...

[Scott Wells]

Good feedback, Alan. Yeah, to a large extent I'm generally operating within the constraints of the host environment. For long-running operations like OST generation I use IntelliJ's native support for progress indicators and then update the text and fraction on the progress indicator as I move through the steps. Each step is synchronous, though, so when I make an API call and it doesn't respond for a while, any new activity has to wait until that API call completes or times out. For example, clicking the Cancel button will begin a cancel operation, but that operation can't complete until the current step itself completes and the overall process "sees" that a cancel was requested. Similar with posting an updated "Still working..." state for the user or posting an entry to the event log. At that point, the worker thread is blocking waiting for a response.

For a long while I've considered changing this so that a long-running, blocking step such as an API call would instead run on a monitored background thread. That would allow me to post intermediate status as well as to allow immediate cancelation if something goes south even if the operation is potentially still running in the background.

I think I'll co-opt this ticket to track progress on something like that...expect to see a summary line change shortly!

[Scott Wells]

Pretty sure this is the case now, but if there are specific long-running operations that aren't already on backgroundable progress indicators (and that could be), feel free to log them in a separate new issue and list them explicitly.

[Scott Wells]

Removing component: IntelliJ IDEA (automated comment)