This week's book giveaway is in the Python forum.
We're giving away four copies of Python Continuous Integration and Delivery and have Moritz Lenz on-line!
See this thread for details.
Win a copy of Python Continuous Integration and Delivery this week in the Python forum!
  • 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
  • Paul Clapham
  • Jeanne Boyarsky
Sheriffs:
  • Devaka Cooray
  • Junilu Lacar
  • Tim Cooke
Saloon Keepers:
  • Tim Moores
  • Ron McLeod
  • Tim Holloway
  • Claude Moore
  • Stephan van Hulst
Bartenders:
  • Winston Gutkowski
  • Carey Brown
  • Frits Walraven

Closing of JSP threads  RSS feed

 
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • 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.
 
Marshal
Posts: 67241
170
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • 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
Marshal
Posts: 67241
170
IntelliJ IDE Java jQuery Mac Mac OS X
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
P.S. Welcome to the Ranch!
 
Saloon Keeper
Posts: 20509
115
Android Eclipse IDE Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • 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
Marshal
Posts: 67241
170
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • 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
  • 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
Marshal
Posts: 67241
170
IntelliJ IDE Java jQuery Mac Mac OS X
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
See this article for an article on properly structuring Java web applications.
 
Rancher
Posts: 371
13
  • Mark post as helpful
  • send pies
  • 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!
     
    He's my best friend. Not yours. Mine. You can have this tiny ad:
    Become a Java guru with IntelliJ IDEA
    https://www.jetbrains.com/idea/
    • Post Reply Bookmark Topic Watch Topic
    • New Topic
    Boost this thread!