12

I have to create a Java EE application which converts large documents into different formats. Each conversion takes between 10 seconds and 2 minutes. The SOAP requests will be made from a client application which I also have to create.

What's the best way to handle these long running requests? Clearly the process takes to much time to run without any feedback to the user.

I can think of the following ways to provide some kind of feedback, but I'm not sure if there isn't a better way, perhaps something standardized.

  1. The client performs the request from a thread and the server sends the document in the response, which can take a few minutes. Until then the client shows a "Please wait" message, progress spinner, etc. (This seems to be simple to implement.)
  2. The client sends a "Start conversion" command. The server returns some kind of job ID which the client can use to frequently poll for a status update or the final document. (This seems to be user friendly, because I can display a progress, but also requires the server to be stateful.)
  3. The client sends a "Start conversion" command. The server somehow notifies the client when it is done. (Here I don't even know how to do this)

Are there other approaches? Which one is the best in terms of performance, stability, fault tolerance, user-friendliness, etc.?

Thank you for your answers.

Daniel Rikowski
  • 71,375
  • 57
  • 251
  • 329
  • How did you end up implementing this? I'm faced with this same question and was considering #2, then I saw your question and thought I'd ask. – SqlRyan Aug 24 '10 at 15:56
  • I'm still on it. Because it's a hobby project it takes a little time. But I'm still convinced #2 is the best solution. – Daniel Rikowski Aug 25 '10 at 08:57

3 Answers3

6

Since this almost all done server-side, there isn't much a client can do besides poll the server somehow for updates on the status.

#1 is OK, but users get impatient really fast. "A few minutes" is a bit too long for most people. You'd need HTTP Streaming to implement #3, but I think that's overkill.

I would just go with #2.

NullUserException
  • 83,810
  • 28
  • 209
  • 234
1

For 3 the server should return a unique ID back to the client and using that ID the client has to ask the server the result at a later time

Lisa
  • 103
  • 4
  • 1
    Server doesnt have to be sateful.Client will persist the id to a persistant store and the Server also would persist the id to a persistant data store and then at a later time the client would use the id persisted from the store to request the information from the server – Lisa Aug 02 '10 at 07:56
  • we have used what i have outlined above and it works perfectly well. The only issue is we have two versions of our clients and some clients have not migrated to the later version where they used a id to request the information back from the server at a later time – Lisa Aug 02 '10 at 07:57
  • Can anyone let me know what are the technologies can be used in option-2 above please? Ex java async event? Or jms? Thank you. – Hasanka Sapumal Sep 12 '21 at 13:55
0

option 4 for those desiring to use web sockets

you request will be response with a jobId, you get progress state over the web soket

ΦXocę 웃 Пepeúpa ツ
  • 47,427
  • 17
  • 69
  • 97