Stefan Groschupf wrote:
As far I understand the code there is only one tasktracker per machine.
That is true, but only for the most apparent use case. I'm working on testing which needs emulate a multi machine deployment.
As you can see in the tasktracker code, the ports are cleanly closed in case the tasktracker status is worng, since there is a finally sections that closes the outputserver and the reportserver in any case.
This is good practice and I expect that, but dynamic/random port assigning adds even more robustness. What you later wrote indicates that we are coming at this from different use cases/scenarios. I see these use cases/scenarios: 1. Development testing: one machine emulating many. 2. Deployment on a server farm: long running, many machines commonly administrated, no firewall. 3. Deployment as distributed, individual systems (P2P): SETI style band of workstations separated by firewalls. These are listed in order of priority, but it should be possible to support all three. The expectation is that the P2P scenario will not be capable of quick (<6sec.) results so it would require considerable end-user patience. Nevertheless, it would be nice to allow P2P type deployments for experimental purposes (vertical search). Perhaps the best option is to have a config that can specify either a specific port or a port range. We should preserve the dynamic/random port assignment ability and have the option of static assignment. Paul
