• 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 Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Closing of JSP threads

 
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have code that fetches data by  AJAX call  from a JSP that uses lot of  SOAP WebServices  . My doubt is if 100 request came to my server if people suddenly closes the main JSP. Will the jsp thread that fetches the data from SOAP web services willl be also killed.
 
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Are you having demonstrable problems with a servlet container not managing its threads correctly or efficiently? If not, then I wouldn't worry about it.
 
Bear Bibeault
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
P.S. Welcome to the Ranch!
 
Saloon Keeper
Posts: 27752
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
First, there is no ongoing conversation between client and JSP to be closed.

In HTTP, the client connects to the server and sends the HTTP request as a unit. Only when the entire request has been received by the server does the server act on it.

The server parses the request URL and determines which webapp to send the request to and which servet/JSP to send the request to. JSPs get compiled into servlets, so the same actions apply to both JSPs and servlets.

The servlet (JSP) is not an independently-running program nor does it directly communicate with the network. Instead the webapp server pulls a Thread from a pool and dispatches that thread to the servlet(JSP).

In absolutely no case should the servlet/JSP terminate that thread

Nor should the servlet/JSP attempt to spawn threads of its own. If you do either of these things, you will destabilize the webapp server and it may eventually crash, taking down all its applications at unpredictable times.

When the client sends the request to the server, it opens a reply port for the server to send the response back to. The client will hold that port for a certain (cllent-defined) interval. If no response is received by the time that the interval expires, it will time out, close, and the browser will display an error message. If the server attempts to send a response back from the JSP request, but the client is not listening, the response will be discarded.

So it doesn't matter how many clients there are as far as processing threads go. Each thread is associated with one and only one client. If there aren't enough free threads in the server thread pool, further requests will be queued until a thread becomes available. If the thread queue also gets full, the server will reject any further incoming requests until the backlog is relieved.

If your JSP is calling a SOAP service, first Bear will growl at you for putting application logic on a JSP instead of in a servlet, but secondly, the JSP/servlet worker thread will hang until the response has either been received or timed out. So if you know that the SOAP service will routinely take a lot of time, you need to set up an alternative means of processing it. Because while the thread won't die, it also won't be available for any other client requests, and the server will start backing up like I just described.
 
Bear Bibeault
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Tim Holloway wrote:If your JSP is calling a SOAP service, first Bear will growl at you for putting application logic on a JSP instead of in a servlet


I wait until at least someone's 2nd post to growl. :cool:
 
Bibil Chacko
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Tim Holloway wrote:First, there is no ongoing conversation between client and JSP to be closed.

In HTTP, the client connects to the server and sends the HTTP request as a unit. Only when the entire request has been received by the server does the server act on it.

The server parses the request URL and determines which webapp to send the request to and which servet/JSP to send the request to. JSPs get compiled into servlets, so the same actions apply to both JSPs and servlets.

The servlet (JSP) is not an independently-running program nor does it directly communicate with the network. Instead the webapp server pulls a Thread from a pool and dispatches that thread to the servlet(JSP).

In absolutely no case should the servlet/JSP terminate that thread

Nor should the servlet/JSP attempt to spawn threads of its own. If you do either of these things, you will destabilize the webapp server and it may eventually crash, taking down all its applications at unpredictable times.

When the client sends the request to the server, it opens a reply port for the server to send the response back to. The client will hold that port for a certain (cllent-defined) interval. If no response is received by the time that the interval expires, it will time out, close, and the browser will display an error message. If the server attempts to send a response back from the JSP request, but the client is not listening, the response will be discarded.

So it doesn't matter how many clients there are as far as processing threads go. Each thread is associated with one and only one client. If there aren't enough free threads in the server thread pool, further requests will be queued until a thread becomes available. If the thread queue also gets full, the server will reject any further incoming requests until the backlog is relieved.

If your JSP is calling a SOAP service, first Bear will growl at you for putting application logic on a JSP instead of in a servlet, but secondly, the JSP/servlet worker thread will hang until the response has either been received or timed out. So if you know that the SOAP service will routinely take a lot of time, you need to set up an alternative means of processing it. Because while the thread won't die, it also won't be available for any other client requests, and the server will start backing up like I just described.



So it needs a massive restructuring of the code 😱😭😱😭. Thanks for the info Tim
 
Bear Bibeault
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
See this article for an article on properly structuring Java web applications.
 
Rancher
Posts: 383
13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Bear Bibeault wrote:See this article for an article on properly structuring Java web applications.



With apologies for hijacking this thread, after having read your article I have to commend you on a well-written piece of work.

There are 3 criteria by which I consider an author to be good at writing:

  • A very good command of language, English or otherwise (i.e. forming sentences into a well-organized and grammatically correct structure)
  • Thought-provoking content that keeps the reader interested (i.e. can't stop reading it)
  • Explains concepts in layman's terms...something us "average joes" can understand (and hence appreciate)

  • Nice work Bear!
     
    Don't get me started about those stupid light bulbs.
    reply
      Bookmark Topic Watch Topic
    • New Topic