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
