«

I am writing a server which can have maximum number of simultaneous
connection equal to the maximum number of open file descriptors. How
can it be enforced in java as well as best design strategy?

Thanks

On 6 Sep 2006 21:11:01 -0700, puzzlecracker wrote:
> I am writing a server which can have maximum number of simultaneous
> connection equal to the maximum number of open file descriptors. How
> can it be enforced in java as well as best design strategy?

The operating system will enforce the limit for you. Your application
will fail to open additional files, sockets etc after reaching the
descriptor limit.

/gordon

--
[ don't email me support questions or followups ]
g o r d o n + n e w s @ b a l d e r 1 3 . s e

Hi,

This just seems like a bad idea to me.

In practice if this single server actually holds your max number of
simultaneous connections then you wont be able to do anything else on
that OS. No other applications will be able to open any other
resources.

I'd rather impose a configurable maximum number of simultaneous
connections.

My 2c

Chris


puzzlecracker wrote:
> I am writing a server which can have maximum number of simultaneous
> connection equal to the maximum number of open file descriptors. How
> can it be enforced in java as well as best design strategy?
>
> Thanks

On 7 Sep 2006 00:37:45 -0700, Chris Brat wrote:
> In practice if this single server actually holds your max number of
> simultaneous connections then you wont be able to do anything else
> on that OS. No other applications will be able to open any other
> resources.

On most platforms I know, you'll be stopped by a per-process limit
long before you reach any system wide limit.

/gordon

--
[ don't email me support questions or followups ]
g o r d o n + n e w s @ b a l d e r 1 3 . s e

Gordon Beaton wrote:

> On most platforms I know, you'll be stopped by a per-process limit
> long before you reach any system wide limit.

Not to mention that in most configurations of most systems, that limit is set
higher than a sensible architecture would attempt to use.

-- chris

Chris Uppal wrote:
> Gordon Beaton wrote:
>
> > On most platforms I know, you'll be stopped by a per-process limit
> > long before you reach any system wide limit.
>
> Not to mention that in most configurations of most systems, that limit is set
> higher than a sensible architecture would attempt to use.
>
> -- chris

Hi,

Both good points.

Unfortunately I worked on an existing application that did run out of
file-handles and caused the environent to sieze.

To manage the problem the support team wrote a script to periodically
check the number of open filehandles and when a pre-defined limit was
reached the application would reboot, to prevent the environment
siezing.

I don't think the problem was ever actually resolved.

Regards,
Chris

Chris Brat wrote:
> Chris Uppal wrote:
> > Gordon Beaton wrote:
> >
> > > On most platforms I know, you'll be stopped by a per-process limit
> > > long before you reach any system wide limit.
> >
> > Not to mention that in most configurations of most systems, that limit is set
> > higher than a sensible architecture would attempt to use.
> >
> > -- chris
>
> Hi,
>
> Both good points.
>
> Unfortunately I worked on an existing application that did run out of
> file-handles and caused the environent to sieze.
>
> To manage the problem the support team wrote a script to periodically
> check the number of open filehandles and when a pre-defined limit was
> reached the application would reboot, to prevent the environment
> siezing.
>
> I don't think the problem was ever actually resolved.
>
> Regards,
> Chris
OK, is it possible in Java to find when max fd when is being (or about
to be ) reached? how? what is a good design for it?

thanks

On 7 Sep 2006 05:30:28 -0700, puzzlecracker wrote:
> OK, is it possible in Java to find when max fd when is being (or
> about to be ) reached? how? what is a good design for it?

There is no general way to know how many file descriptors you've got
open, except by keeping track of every Socket, ServerSocket, and
FileInputStream you open (and I've probably missed some), and knowing
when library methods open these things for you (as Runtime.exec()
does).

On Linux you can cheat a little by counting the files in
/proc/self/fd, and you can check the limit with "ulimit -n".

But this seems to like a lot of trouble, I don't see the point of
knowing that they will "soon" run out, because you'll get an exception
when you attempt to exceed the limit anyway (so why stop sooner).

What real problem are you trying to solve?

/gordon

--
[ don't email me support questions or followups ]
g o r d o n + n e w s @ b a l d e r 1 3 . s e

Chris Brat wrote:

> Unfortunately I worked on an existing application that did run out of
> file-handles and caused the environent to sieze.
>
> To manage the problem the support team wrote a script to periodically
> check the number of open filehandles and when a pre-defined limit was
> reached the application would reboot, to prevent the environment
> siezing.

Good sound support engineering

In fact, if you have a leak in code you can't get at, such as the OS or a
third-party library, then there may be nothing you can do except restart at
intervals. I think it's a good idea for long-running processes to restart
themselves automatically from time to time -- just as a precaution.

-- chris