Hi,

We're attempting to move our tractor implementation for houdini over to PDG, but we can't seem to get even simple renders cooking on tractor.

We're using Houdini 17.5.360 in Windows 10, tractor engine on centos and a tractor blade service running on the same workstation as houdini.

When we switch to a local scheduler and cook the top net, the rop renders, and an image is generated.

But with tractor, the ‘cook’ task sit without progress on tractor if we launch within the scheduler itself. And when we cook from the topnet, two tasks go onto tractor: the mq server, and the ropnet. But the mq server doesn't ever finish and in houdini, the status shows as ‘scheduled’.

Could it be a port issue?
The log of the MP server mentions other ports than the ones we've specified:

Hip file is attached and thoughts are welcome.

Are you configuring your firewall to allow your chosen ports? If there's no firewall involved, then leave the port toggles disabled and it will choose free ports for you.

Port 1023 is a reserved port that usually needs admin permission to bind - try a higher port number

chrisgreb
Are you configuring your firewall to allow your chosen ports? If there's no firewall involved, then leave the port toggles disabled and it will choose free ports for you.

Port 1023 is a reserved port that usually needs admin permission to bind - try a higher port number

Good to know about port 1023. But yes, all firewall exceptions are in place on both the tractor engine centos server and the windows machines, just in case.

My question is: what does port 56669 accomplish in this case, and why is a random port chosen when we're already specifying ports? Is there some intended functionality that assumes all blade ports are meant to be open, and our workstation as a blade scenario is affected by that?

jeremykhardin
My question is: what does port 56669 accomplish in this case, and why is a random port chosen when we're already specifying ports? Is there some intended functionality that assumes all blade ports are meant to be open, and our workstation as a blade scenario is affected by that?

That's just the ephemeral port used by the client. It isn't related to the server ports or firewalls, we probably should only print the hostname in the connection log message.

Tried again with 60230 and 60250 as relay ports. Still no progress in tractor with pdg.


Any thoughts or info is appreciated.

Just to rule out firewalls, we temporarily disabled them on our closed network. The issue persists. Thoughts are welcome.

Could you check that your blade is configured to provide a ‘Houdini’ service key? Also the ‘Service Keys’ parm mqservicekey on the tractorscheduler1 node should be filled in to something that is available.

What version of Tractor server are you using?

chrisgreb
Could you check that your blade is configured to provide a ‘Houdini’ service key? Also the ‘Service Keys’ parm mqservicekey on the tractorscheduler1 node should be filled in to something that is available.

What version of Tractor server are you using?

Thanks for your help Chris.

We seem to have service keys set up in both blades-config and in the tractorscheduler1 node.



We're using Tractor 2.3 here. We don't have renderman, so we're successfully using standalone tractor for nuke jobs and oiio commands without issue.

Strange. Could you please enter a support bug and attach logs - it might be worth looking at the tractor engine log as well.