• 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

Question about open connections

 
Ranch Hand
Posts: 213
Eclipse IDE Tomcat Server Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In a previous post it was stated:

With Servlets you don't usually 'Push' the status of long running tasks to the client. Instead the client has to 'Pull' the data. This is because HTTP is a Request/Response cycle - Clients Request info, Server Responds with it. These cycles are intended to be short, and making them long can cause trouble by clogging the server with open connections.



How is pushing data that much different then watching a video?

 
Author
Posts: 12617
IntelliJ IDE Ruby
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Beause the client is requesting the data (plus < HTML 5, videos are played by a player app, not HTML).

Push means the server can send data to the client at arbitrary times.
 
Saloon Keeper
Posts: 27763
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Actually, HTTP-based servers can't "push" at all. At best all you can do is "tug".

This isn't just a J2EE thing. The HTTP protocol strictly defines how this works:

1. The client opens a connection to the server (usually port 80, 443, although others also work such as 8080, 8443 depending on the server).

2. The client opens a reply port to listen on.

3. The client sends an HTTP request to the server. That request includes the reply port number as part of its overhead.

4. The server, which has been listening for requests, accepts the request, dispatches it to back-end logic which generates response data.

5. The server sends the response data to the listening reply port on the client.

6. The client closes its connections to the server and renders the response (usually as a web page).

There are no long-term open connections. The connections remain only as long as it takes to service a request and receive a reply. The next request starts it all over again. No reply can be sent ("pushed") except in response to a request.
 
reply
    Bookmark Topic Watch Topic
  • New Topic