David Powell wrote:
Darren Reed wrote:
In chasing down 6271923, it appears that the culprit
is a new and seemingly arbitrary limit on the number
of contracts that a process can create. The default
would seem to be 10000.
The limit on the number of contracts has been there as long as
contracts have :)
...
e inclinued to change the way the
system ships but it would provide a proper path for someone
to set the system for the expected load/task.
Comments?
I don't see a reason why you couldn't raise the limit on the number
of contracts inetd creates in the shipping product. The point of the
control is to prevent users from denying service (contracts are cheap
to create but have a fixed namespace), not to create an employment
program for system tuners.
Ok, I'm with you on that.
The only thing I'd look out for is to make sure that if you put inetd
in a new project, that the services it starts are correctly placed
into their projects and aren't simply inheriting inetd's.
Hmm... are you implying that when inetd starts a new
service that it will not apply the method_context
properties, if set?
My temptation with inetd would be to have it take a
snapshot of which project it is in when it starts,
put it in the inetd project that has no limit on
max-contracts (or otherwise just remove that particular
resource control ?), and then place all of its children
in the project remembered from startup, unless there
is a specific project property in their context_method.
Sounds more like an RFE than bug-fix...
Darren
_______________________________________________
networking-discuss mailing list
[email protected]
