Develop Reference

Long running we request, UI gets timed out by the time response is ready

I have one angular app and one spring boot app, there is one request goes from UI to spring boot with some 100-200 objects even more, for each of these objects another back end system is called within a loop.
something like..
list.parallelStream().forEach(e->{
//code using rest template for backend.
// add the responses to an array list.
// i can send all these objects to backend at one shot because they have some limitations and dont support it currently.
});
This takes a lot of time to complete and by the time all the request is completed the UI gets timed out.
I tried using executer framework, forkjoin or parallel but this is not enough. because browser wait for 30-60 sec.
I want to switch to anyc process where i submit request to spring boot, from UI I should be able to check the status of the request after time interval. i tried concepts like DeferredResult, #Async, completeable future and StreamingResponseBody. is there any way to handle these long running request???
Some of these concepts works but when the input size increase they also fail to work properly. how do i manage to get the status of my request and use some progress bar etc to show even user.
or any better approch?

For me it sounds like you want to stream data.
Perhaps spring's reactive stack is something you want to look at:
Building a Reactive RESTful Web Service
Video Tutorial using Kotlin
With this your angular app should be able to display or react very finished processing of an individual item as they happen.
Hope that helps.

Dynamically force transition in Spring Web Flow

Spring web flow is a state machine of sorts for a user interacting with html pages. Traditionally, while a user is in a view state the system will wait until the user interacts with the page which will trigger some transition.
Is it possible to force a transition or update a page without interaction from the user in spring web flow? For example, I may have a REST controller, or an AMQP listener, or even maybe just some background process running. When data comes in from one of these independent processes, I'd like to update the user into a new transition.
For example the user is sitting at a decision point for a period of time and another service will call via REST into the web flow service to logout this user. The web page should suddenly navigate to a logged out screen.
The only way I've been able to achieve this is save the information and do a check for logout messages once input has been received but this is less than ideal.

You seem to be talking about a message sent asynchronously from the server to the client, like with Websockets.
Without a technology like that, I think your only options - unrelated to Web Flow itself - are:
JavaScript on the page timing out or polling
Wait for the user to submit their next request

Jersey update user on front-end while a big request is running

Currently I'm working on a single page application with java/jersey running as my back-end. But at the moment I have some requests that take a while (over 10 seconds). I was wondering if its possible to send updates back to the client with jersey?
I wanna use like a status bar but I have no clue how far the request is without updates from the back-end.
I couldn't find anything about this topic searching on google/stackoverflow. Maybe I'm using the wrong search terms.

If you don't want to use websockets there are a few approaches you can take.
Provide API to client that takes clientId and optionally processId and gives status of the process running on server.
Then client can have Javascript to asynchronously call this API and update progress bar.
In addition you can have server side Jersey resource start long running process asynchronously and immediately return response with estimated time and processId.

Generating PDFs in multi-threaded environment

The goal is to make a pdf-generating service. The service is avaiable via simple servlet.
Assumptions made are such, that the service is supposed to be running on multiple load-balanced servers (e.g. Tomcat instances), with each server running its manually created threads, which generate PDFs. Each request has to be written to a database, and its pdf status has to be updated throughout the whole process, like:
QUEUED at first
IN PROGRESS when the pdf generation starts
PROCESSED after a pdf is created
Another assumption is that each Tomcat instance which got the request is responsible for generating the document. The whole solution must be persistent across restarts, so each server instance needs to store its task queue somehow (in a file for example?).
One might think that the whole process might be synchronized with the database, but IMHO polling a database for new PDF requests can be time-consuming.
Any ideas, hints?
Assumptions are flexible, so if anyone, who happens to come with some good out-of-assumptions solution, is kindly asked to share his/her ideas.

For queuing, use a message bus like RabbitMQ or ActiveMQ with persistent queues.
Provide a request servlet which puts a request on a message queue and sets a QUEUED status for the request in the database.
Use listeners (in the Tomcat servlet container or not) to listen for messages on the queue.
When the listeners detect a new message, they pull it off and start PDF generation, and set the IN PROGRESS status on the message.
When the listeners are done processing, they set PROCESSED status on the job, ACK the message to totally remove it from the queue, and move on to the next one.
If a listener dies before it is done processing the message, the message will be un-ACK'd and available for other listeners to process. Another listener will pick it up, set the status to IN PROGRESS again, and complete it.

Send data to front end when back end updates [duplicate]

This question already has answers here:
Real time updates from database using JSF/Java EE
(3 answers)
Closed 2 years ago.
The backend of my web application receives updates from several clients. When such an update happens it should be communicated to all other clients.
How can I initiate an update from the server to all web browser clients when my backend is updated?
I'm using JBoss, JSF and the Spring framework.

See similar Stack overflow quetion : WebSockets vs. Server-Sent events/EventSource
I'm assuming, as DarthVader did, that your frontend is a (generally) stateless HTML page of some sort. Something in a browser. If you want all clients to be pushed changes automatically, you have three options:
Comet: (deprecated)
Comet is essentially making AJAX requests that have no request timeout limit. You make the request, and it sits there and streams data through it as is neccessary. This can be done with hidden iFrames or standard XMLHTTPRequests (which jQuery can wrap for you). You can read more about this method here.
Long Polling:
Essentially, you use the javascript setInterval method to continuously poll your server for changes. Simply set an interval that does a standard AJAX GET request to the server, and upon every success, update your page accordingly.
Browser APIs
HTML5 WebSockets
Using any type of Event-Based backend (Twisted, EventMachine, node.js, etc) makes WebSockets the ideal solution. Simply have all clients register with the backend, and upon a submit from any given client, push the changes to all other clients. You can read more (and see a nice example) of WebSockets on this page. Browser support => canIuse
Server-sent event (SSE)
With server-sent events, it's possible for a server to send new data to a web page at any time, by pushing messages to the web page. These incoming messages can be treated as Events + data inside the web page.
Browser suppport => canIuse

When you say front end, you are talking about stateless http client.
You cant push anything from your web servers to http or stateless clients.
The "trick" to do this if using asynchronous calls from front end to your back end, periodically.
Think about gmail, how do you think it displays that you have an email when you recieve a new email. You browser contantly, sending Asynch calls to gmail servers, if and when there is a new message, it displays it.
So Clients are stateless. use Ajax.
is this clear?

There are a couple of ways to go around this.. The way it should be in the future is following standards like Websockets
For now you are stuck with Comet which is essentially sending a request to the server and keeping it open (not signaling a response end) and just streaming data through it (Parking the request they call it). Or periodic polling, where you just do an AJAX request to the server every predefined interval to ask if the server has something new to say. Needless to say the first work around requires streaming support on both the server and browser but is more efficient in most scenarios.