• 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:
  • Tim Cooke
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Liutauras Vilda
Sheriffs:
  • Jeanne Boyarsky
  • Rob Spoor
  • Bear Bibeault
Saloon Keepers:
  • Jesse Silverman
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Piet Souris
  • Al Hobbs
  • salvin francis

how to keep longer http connection

 
Ranch Hand
Posts: 31
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


I have HTTP client:

   

And one put method on the server (implemented in Spark):



The problem: when I set up for example TimeUnit.MINUTES.sleep(10) everything is fine I see return value "text". But when I set up TimeUnit.MINUTES.sleep(20) or longer I do not see return value also I do not see any errors, my client is just waiting and waiting. Do you have any idea what happen ?

 
Saloon Keeper
Posts: 24558
168
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
Http is not like time-sharing where you connect and stay connected until you log out.

Instead, HTTP consists of a series of request/response cycles, where the client connects to the server, uploads the HTTP Request, the server generates an HTTP Response (preferably as fast as possible), then the connection closes. The next request/response requires a whole new connect/send/receive/disconnect cycle, ad inifinitum. Evey cycle has both a request and a response. HTTP does not support unsolicited messages from server to client and every request gets back at a minimum a response code indicating how the server dealt with the request.

So submitting a request and expecting to wait for long periods of time while connected is not a reasonable thing to do with HTTP. Either the client or the server will timeout and disconnect in order to free up resources.

This lack of persistent connections is actually one of the virtues of HTTP, since there are only a limited number of TCP/IP ports on a machine and only one process can hold a port at a time, so by disconnecting when not in active use, more clients can be supported than if each client held a connection long-term.
 
Sheriff
Posts: 22510
122
Eclipse IDE Spring VI Editor Chrome Java Windows
  • Likes 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
HTTP does support long-lasting HTTP connections using the keep-alive mechanism, but it's still a request-response model. As Tim said, the server doesn't initiate anything.

There are two mechanisms that do provide some form of pushes from the server:
  • Server-sent events
  • WebSockets

  • Those both require a completely different type of client though.
     
    Tim Holloway
    Saloon Keeper
    Posts: 24558
    168
    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

    Rob Spoor wrote:HTTP does support long-lasting HTTP connections using the keep-alive mechanism, but it's still a request-response model. As Tim said, the server doesn't initiate anything.



    No, you can't do something clever to exploit keep-alive. Think of it like a cache, where entries can get dumped without warning. It's not visible to the HTTP application code.

    Rob Spoor wrote:
    There are two mechanisms that do provide some form of pushes from the server:

  • Server-sent events
  • WebSockets

  • Those both require a completely different type of client though.


    Also a different type of server. Older JEE webapp servers did not support WebSockets. You need JEE 7 or greater.
     
    reply
      Bookmark Topic Watch Topic
    • New Topic