Trying to export execl table task with queue optimization

foreword

This week, I will try to do an issue of using the queue to optimize the export of execl tables. Due to the server memory, multiple export tasks may cause memory overflow at the same time. Use the queue to export in sequence to reduce the pressure on the server.

The task also points out that the export operation can be canceled halfway while the queue is waiting, and the corresponding entity should be deleted from the queue at this time.

queue

Queue is a first-in, first-out data structure, which is different from the first-in-last-out of the stack. In java, the queue only appears as an interface, and a linked list is generally used to implement its interface.
In order to prevent the server from going down during the export process, and to allow users to download the historical export records, add the historyExportExcel entity to save the query parameters of each query, that is, the file name and other attributes.
original export logic

Since there are two situations after modification, one is that there is no task of exporting the excel sheet when requesting to export the excel sheet, so export it directly. One case is that there is an exporting task when requesting to export an excel sheet, then the user needs to be prompted that there are many exporting tasks currently, which have been added to the exporting task queue, please check in the historical export list later
Then what needs to be considered is the second case, how the background tells the foreground to join the export queue, for example, the background tells the foreground the length of a current export queue, such as 1,2,3. So how does it differ from the export progress 1-100 when exporting directly

first revision

It becomes two requests. The first request first requests the current export queue length. If the current export queue is 0, it will be exported directly. If the current export queue is not 0, no request will be issued, and the user will be prompted directly.

second revision

The teacher told me that different types of values can be judged according to the content-type field of the response header. If the token is written through the output stream, there will be no content-type. You can also define the response header as content-type, if it is the value of return , then the content-type field defaults to application/json.
Then, according to the content-type, the two requests just now are simplified back to one request. If the current export queue is empty, it will be exported directly, and the filename will be returned through the output stream. If the current queue is not empty, the content-type will be specified as application. /json.
Encountered a problem that there is a progress even if the content-type type field is returned. When returning filename, the foreground will get the progress 1-100, and the foreground will call the loading popup window according to the progress value. When returning the queue length, there will also be progress, and the progress is 1. The Loading popup is also called at this time.

Through the teacher's guidance, interrupt the point in the foreground to see the return data type
the first time

data = {type: 3, loaded: 1, total: 1}

the second time

data = HttpResponse {headers: HttpHeaders, status: 200, statusText: "OK", url: "http://localhost:8015/api/resident/exportExcel?page=0&size=10&loading-ignore=true", ok: true, …}

If it is filename, the total value is 100, and if it is the queue length, total is a value less than 100.

Then add the entity state field to prevent concurrency problems