I am intending to use JS web worker thread to make an AJAX (xmlhttprequest) call to server in background while user continues to fill the form on main UI thread. My question is what if there is an another server call made from main UI thread (e.g. user submitting form, refreshing UI layouts etc.) while AJAX (raised from worker thread) is still in progress? My assumption is although there are two JS concurrent threads in parallel, still there is just one JAVA thread for given requestor managing all server calls made from browser. Hence in this scenario request made to server from main UI thread will be put on hold until AJAX processing is complete.
To follow up on what Tashika said, why are you creating custom AJAX calls? If you use the out of the box tools you get all that for free. Is there something that Pega's UI can't do that leads you to want to use JS Web Worker?
Business Requirement - User should be able to drag/drop multiple files and while files upload processing (reading file content in browser, posting the stream on to server) is carried out in background, he should be able to perform any task on the work item. Each file can be of size up to 40 mb. User may drop about 10 files in a go.
Solution Design -
OOTB control pzMultiDragDropControlStandard freezes UI until upload is complete. Hence I am intending to customize OOTB control, instantiate separate worker thread for each file dropped, let worker thread to read file content, post on to server and post message back to main UI thread when upload is complete. This will keep main UI thread responsive when entire processing is carried out by web worker thread in background. Also we are using third party FileNet system to store the files, ultimately we may have to push file content through REST service to FileNet system. We are exploring two options to trigger REST service :
(1) Call an activity from worker thread (AJAX call) and pass file content as input param to activity. Call Rest service from activity by passing required request param. So its like Browser --> PRPC app server --> FileNet. Potential downside is time taken in posting file content from browser to PRPC app server could be more depending on file size.
(2) Directly trigger Rest service from worker thread (AJAX call). This will eliminate the need of using PRPC app server as an intermediate platform hence faster in processing.
I would like to know if there is any better way of implementing the solution.
It sounds like you've got quite a sophisticated design and are playing in areas outside of my personal expertise. My one thought is that if there is a problem in any of all that asynchronous processing, and you don't keep the work object from moving forward, the browser may not be able to notify the user of the problem because the necessary piece of the DOM is gone. I'd definitely test as many error cases as you can think of, since I expect you'll run into a few issues that you'll need to address.