How to execute a very heavy process exposed as REST from wildfly?

Question

How to execute a very heavy process exposed as REST from wildfly?

Navigation

#1 by (0 votes)

1

I have a process that processes an input file, uses 100% of the processor (uses the 16 cores), and 8 GB of RAM. I currently run it directly from the console. But I need to call this process from a REST service. The service must be asynchronous, and there will be another service to check the exit of the first service called. The input files must be pasted, because only one can be processed at a time. I use RestEasy in Wildfly.

My query is:

What architecture do you suggest to call this process?

I have these possible solutions.

Call from my EJB to the JAR with Runtime. And have a queue of files in a database.
Transform my JAR into a Demon, which is constantly monitoring a directory. And the files are stored there. And let the devil take the files one by one according to the arrival date.
Copy the classes in my EAR project, and call them as a simple EJB, and wildfly administer the resources. This would also imply having a queue of files in a database.

Do you have any other suggestions?

java rest jboss wildfly

asked by Marcelo Franco 05.06.2017 в 03:05

source

1 answer

$ ionicHistory.clear History () does not work android 6.0 and higher Failed to perform POST request in java with AndroidStudio

score 0 · Answer 1

The first answer I can think of is: Do not do it in the WebService.

Such a heavy process that needs so much RAM and so much CPU usage is an anti-pattern in a WebService; it is going to block it. I do not appreciate any advantage to include this within a WS.

What I would recommend is for the WS to receive the requests and store them in a table. The WS can also consult in that same table to check the status of those batches.

And then, ideally on another machine, you can have your application running by looking at the database every so often, starting the processes that you put in that table (one by one as you say), and updating the table with the results I get. It will force you to put some management such as rebooting the dead processes at the start of the application, checking by date / time how long the process has been running and if it would be convenient to restart it, etc., but it's worth it.

A WS is a high concurrency environment by definition. If you put such a large multi-threaded process, it is most likely to be detrimental to the WS service, which is something you can not normally afford. If you still want to put it , do what I have told you in a separate war that deals with the requests related to this process, puts the jar that allows to do the process in that war, and then adds that war to the ear that you will already be generating.

If you put it in the WS I recommend limiting a bit the resources used by that process so that it does not block or slow down excessively the rest of the application.