aspose file tools*
The moose likes Servlets and the fly likes request.getLocalPort and the number of client requests Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Servlets
Bookmark "request.getLocalPort and the number of client requests" Watch "request.getLocalPort and the number of client requests" New topic
Author

request.getLocalPort and the number of client requests

Anand Athinarayanan
Greenhorn

Joined: May 20, 2011
Posts: 27
Hi,

I was reading the HFServlets and JSP book when I noticed this -

There is a subtle difference between getServerPort and getLocalPort, while the former says to which port the request was originally sent the latter says on which port the request end up. The difference being although requests are sent to a single port the server turns around and finds a different local port for each thread so that the app can handle multiple request at the same time


It is the last line I'm confused about, if each thread ends up in a separate port then theoretically the app shouldn't be able to handle more than 65,535 requests at a time since it is the maximum number of ports available on a computer. of course some of them are reserved ports which makes the concurrent requests to be less than 65,535. I'm assuming that each request will be executed in a separate thread and going by the book each thread will have a specific port. So does it mean that an app deployed on a single instance of a server cannot handle more than 65,535 requests at a time? I don't think so . Am I missing something here?

Any thoughts appreciated.

Thanks !
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18564
    
    8

Anand Athinarayanan wrote:I'm assuming that each request will be executed in a separate thread and going by the book each thread will have a specific port. So does it mean that an app deployed on a single instance of a server cannot handle more than 65,535 requests at a time? I don't think so . Am I missing something here?


What do you find wrong with the statement that an app deployed on a single server cannot handle more than 65535 requests at a time?
Kumaravadivel Subramani
Ranch Hand

Joined: Jul 05, 2008
Posts: 166

Since there is only 65535 logical ports available to process, you cannot go for more than that of.


No pain, No gain.
OCJP 1.6
Anand Athinarayanan
Greenhorn

Joined: May 20, 2011
Posts: 27
Hi Paul,
That was just my assumption, I'm glad I got it right atleast for one time I just felt 65 thousand and odd is too small a number in the world of Internet. But as Kumaravadivel pointed out, you cannot go more than that. Thank you guys.
Daniel Val
Ranch Hand

Joined: Jan 09, 2012
Posts: 44
Anand Athinarayanan wrote:Hi,

...

It is the last line I'm confused about, if each thread ends up in a separate port then theoretically the app shouldn't be able to handle more than 65,535 requests at a time since it is the maximum number of ports available on a computer. of course some of them are reserved ports which makes the concurrent requests to be less than 65,535. I'm assuming that each request will be executed in a separate thread and going by the book each thread will have a specific port. So does it mean that an app deployed on a single instance of a server cannot handle more than 65,535 requests at a time? I don't think so . Am I missing something here?

Any thoughts appreciated.

Thanks !


Yes; do you believe you will ever have 65k transactions coming same time to the server?

Example: a guy from very big country works for some telecom from there. Data Services are in big demand like everywhere and they have dunno how many millions of subscribers. Many millions.

They get 400 charges per second. It is a lot! They process them with a cluster.

In other parts of the world probably the number is one magnitude order smaller.

65k transactions the same time, man, that is a lot... You don't run in this issue every day

D.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: request.getLocalPort and the number of client requests