0

From Javascript, I am calling a REST method which is computationally intensive. Would it be possible to stop that REST call, if you are no longer interested in what it returns.

I understand, it is possible to abort a request in JS. But it won't stop the thread which gets triggered due to the REST call. This is how I am aborting the ajax call in JS. Abort Ajax requests using jQuery

The REST interface is written in Java. And internally this thread may create multiple threads also.

I would like to stop a Java thread. But from the caller. From JS, where I have triggered it. How to properly stop the Thread in Java?

Community
  • 1
  • 1
Java Kumara
  • 97
  • 2
  • 12
  • Assuming you are using HTTP for this, have you tried looking for a connection closed packet from your JS client? – Tyzoid Oct 15 '15 at 14:26
  • 1
    confusing question...... :( – Jayesh Oct 15 '15 at 14:29
  • @Jayesh Assume, a REST call takes 1 hour to return the value. And if I am no longer interested in the result after 15 min, I would like to abort that thread which is triggered by me. – Java Kumara Oct 15 '15 at 14:31
  • Possible duplicate of [How to properly stop the Thread in Java](http://stackoverflow.com/questions/10961714/how-to-properly-stop-the-thread-in-java) – Nir Alfasi Oct 15 '15 at 14:32
  • @Tyzoid No, I have not. I will check. Trying to read more about what you said. – Java Kumara Oct 15 '15 at 14:32
  • @alfasin Yes, I want to stop the Java thread. But the one which is triggered from my REST call. And I want to stop it from outside. (from the caller) – Java Kumara Oct 15 '15 at 14:33
  • Have a look : http://stackoverflow.com/questions/446594/abort-ajax-requests-using-jquery – Jayesh Oct 15 '15 at 14:34
  • If you have synchronous REST calls that take one hour to process you're doing it wrong. You should change the implementation to be async in order to save resources and make your application more resilient to transient network issue. – Nir Alfasi Oct 15 '15 at 14:34
  • @Jayesh I am aborting it in JS. But it is not stopping the thread which is triggered by the REST call. – Java Kumara Oct 15 '15 at 14:35
  • There is no easy way to do what you are wanting. Typically REST requests should be kept very short, thus avoiding this problem entirely. For cases which are just really large, I would look to chunk them down into smaller parts. Failing that you can have the server return a job id and have it work in the back ground and offer other end points to control the job.. but that is a fair amount of work which I would only consider as a solution of last resort. – Chris K Oct 15 '15 at 14:39
  • If you want to stop the operation which is already triggered at server side, then I think, you have to take one global variable say "processTill", which decides until when the server should work. If you are not getting response by specific time, send fresh request to stop the process, which makes the variable state "processTill" to false which stops server side processing. I wrote in very abstract way, in real situation you have to take care of ACID properties if database operation is involved. – Jayesh Oct 15 '15 at 14:40
  • In other way, If server knows that if it take more than x amount of time, then client will send stop request, then why not stop at server side only and send client notification that server will be taking more time. – Jayesh Oct 15 '15 at 14:42
  • @ChrisK Thanks. The second solution looks exactly what I was looking initially. But yes, I will check at the possibility of breaking them down into smaller parts. – Java Kumara Oct 15 '15 at 14:46
  • @Jayesh Thanks. The time to complete varies significantly on the computation as it depends on many factors. Sending the fresh request and handling looks similar to how Chrisk explained. – Java Kumara Oct 15 '15 at 14:53
  • Possibly helpful: http://stackoverflow.com/questions/7730199/best-practice-for-implementing-long-running-searches-with-rest/7730452#7730452 – Rob Hruska Oct 16 '15 at 13:28

2 Answers2

1

You could send a unique identifier along with your request, and then make another request that instructs the server to abort the operation started for that ID.

Cos64
  • 1,617
  • 2
  • 19
  • 30
1

As Chris mentioned in the comments above, REST calls should be quick, definitely not an hour long. If the server needs to do a lot of work which takes considerably amount of time, you should modify your design to async. Either provide a callback that the server will use once it's done (also called push approach), or pull every few minutes, by sending a new request to the server to see if it's done.

In order to implement it you'll need the server to return a unique-id for each request in order to be able to identify in the callback/check-call what's the status of that specific request.

The unique-id should be implemented on the server-side in order to avoid two clients send the same ID - overriding each other.

In the link that I posted above you can see an example of how to implement a "stop thread" mechanism which can be implemented on the server-side and called by the client whenever is needed.

Community
  • 1
  • 1
Nir Alfasi
  • 53,191
  • 11
  • 86
  • 129