• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Bear Bibeault
  • Junilu Lacar
  • Martin Vashko
Sheriffs:
  • Jeanne Boyarsky
  • Tim Cooke
  • Knute Snortum
Saloon Keepers:
  • Ron McLeod
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Scott Selikoff
  • salvin francis
  • Piet Souris

Break the connection between browser and service

 
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I want to break the connection between browser and REST service immediately as soon as the client send the request and let the processing continue in background async way.
Any suggestion please.
 
Saloon Keeper
Posts: 21309
140
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
HTTP doesn't need "broken connections". The HTTP standard is nothing but broken connections. A client makes an HTTP URL request, the server processes it, returns a response and the client/server connection is closed. End of sentence. If you want to make another request, the client must open another connection. Again. And again. And again.

A well-behaved web application will spend a minimum amount of time processing that request and returning the response. The web is not the place for long-running request/response cycles. The browser will, in fact, eventually time out and break the request on its own if a response doesn't come back soon enough.

If you need ReST (or any other HTTP request) to set off a long-running process, then you should use the HTTP request to queue up an out-of-band processor and either poll for completion (as successive periodic HTTP requests) or provide some sort of callback mechanism to notify anyone who wants to know when the long-running request is done. Email, for example.

The out-of-band processor might be some sort of batch system, but you can also spawn an engine thread(s) in your webapp ServletContextListener startup listener.

On no account should a servlet or JSP attempt to spawn threads themselves, either directly or via methods invoked by the servlet or JSP. This violates the J2EE specification and can potentially randomly crash the entire webapp server.

On the other hand, the ServletContextListener can safely spawn threads. So a servlet or JSP can use a shared synchronized resource to push processing requests to those threads.
 
Sheriff
Posts: 24744
59
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Tim Holloway wrote:but you can also spawn an engine thread(s) in your webapp ServletContextListener startup listener.



I'm no longer writing web apps, but I have been curious about this for quite a while. Is it okay to just use an ordinary ExecutorService, or when you say "engine thread" does that mean something more limited?
 
Tim Holloway
Saloon Keeper
Posts: 21309
140
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I haven't been writing major webapps lately either. In fact, I haven't done much with Futures or the ExecutorService. I just meant any generic process or processes that can be handed a task and allowed to go its merry way. Back when I dealt with such things regularly I had to use brute force, since more civilized approaches hadn't been invented yet, but an ExecutorService would certainly work. As would some of the Spring Framework services that weren't available to me back then either.
 
pari Nagda
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
HTTP doesn't need "broken connections". The HTTP standard is nothing but broken connections. A client makes an HTTP URL request, the server processes it, returns a response and the client/server connection is closed. End of sentence. If you want to make another request, the client must open another connection. Again. And again. And again.

A well-behaved web application will spend a minimum amount of time processing that request and returning the response. The web is not the place for long-running request/response cycles. The browser will, in fact, eventually time out and break the request on its own if a response doesn't come back soon enough.

If you need ReST (or any other HTTP request) to set off a long-running process, then you should use the HTTP request to queue up an out-of-band processor and either poll for completion (as successive periodic HTTP requests) or provide some sort of callback mechanism to notify anyone who wants to know when the long-running request is done. Email, for example.


The out-of-band processor might be some sort of batch system, but you can also spawn an engine thread(s) in your webapp ServletContextListener startup listener.

On no account should a servlet or JSP attempt to spawn threads themselves, either directly or via methods invoked by the servlet or JSP. This violates the J2EE specification and can potentially randomly crash the entire webapp server.

On the other hand, the ServletContextListener can safely spawn threads. So a servlet or JSP can use a shared synchronized resource to push processing requests to those threads.



Can JMS be a good solution here ?
 
Marshal
Posts: 67313
170
Mac Mac OS X IntelliJ IDE jQuery Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What problem are you actually trying to solve?
 
Saloon Keeper
Posts: 10867
234
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Paul Clapham wrote:I'm no longer writing web apps, but I have been curious about this for quite a while. Is it okay to just use an ordinary ExecutorService, or when you say "engine thread" does that mean something more limited?


You may not create your own ExecutorService, because it will be populated with threads from the JVM directly, while you want the threads to be managed by your application container.

In Java EE, you can inject a ManagedExecutorService into an EJB.

In Spring, you can autowire a TaskExecutor, which is Spring's version of Executor.
 
Tim Holloway
Saloon Keeper
Posts: 21309
140
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Stephan van Hulst wrote:
You may not create your own ExecutorService, because it will be populated with threads from the JVM directly, while you want the threads to be managed by your application container.



The difference between the JVM and the application container (by which I assume you mean the webapp application itself - e.g., Tomcat) is relatively minor. More specifically, you'd be best served by having the engine controlled by the ServletContext because that way it goes up and down with the webapp rather than leading a rogue existence of its own.

I should qualify that whether you do roll-your-own or a sophisticated manager like ManagedExecutorService that it is absolutely essential that the engine manager's worker threads not be parented by servlets or JSPs. That is, if a servlet request should invoke a ManagedExecutor (or whatever), and the ManagedExecutor spawns a thread or threads but it's doing so under the servlet thread, you're still violating J2EE constraints.
 
Stephan van Hulst
Saloon Keeper
Posts: 10867
234
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sorry for the confusion. I thought TaskExecutor and ManagedExecutorService WERE scoped to the web application, and not the entire container. Am I mistaken?
 
Pay attention! Tiny ad!
Java file APIs (DOC, XLS, PDF, and many more)
https://products.aspose.com/total/java
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!