Paul,
I am thinking about the mapred branch and the case of a mapred
multiprocess run over one or more machines. In this case,
multiple tasktracker processes are created.
I'm not sure what you mean.
As far I understand the code there is only one tasktracker per machine.
why are the
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
Hi,
why are the taskReportPort and mapOutputPort randomly generated?
I can not see any reasons for that and wondering why we not just have
that configurable as well.
I can understand that in some situations it is necessary to
reinitialize the task tracker but it can use in any case the same
Stefan Groschupf wrote:
Beside that a behavior like the datanode that iterates until it find a
free port would be a better than just random.
That would be fine.
Would a patch have a chance to be applied? I can create one, but I
wouldn't love to waste time in case people do not want to
Stefan Groschupf wrote:
Beside that a behavior like the datanode that iterates until it find
a free port would be a better than just random.
There is a possibility that a test run could start many processes
on one machine and a sequential available port search could be
contentious.
If you
Hi Paul,
my call stack say that actually no other classes using the tasktracker.
Beside that tasktracker could be implement NutchConfigurable than all
problems would be solved since this is IOC pattern.
Or do I oversee something?
Stefan
Am 27.09.2005 um 01:24 schrieb Paul Baclace:
Stefan
Stefan Groschupf wrote:
Hi Paul,
my call stack say that actually no other classes using the tasktracker.
Beside that tasktracker could be implement NutchConfigurable than all
problems would be solved since this is IOC pattern.
Or do I oversee something?
I am thinking about the mapred branch
