Hi
So we have an out of process running both on the farm and locally, using pdgcmd.reportResultData()
works fine both local and on the farm
When I am trying to write back an attribute using pdgcmd.writeAttribute() I get a bunch of errors on the farm
related to the server address, which by default seams to be 127.0.0.1
- What do we need to get the proxy server up and running? Our in-house scheduler is built upon the Tractor one
- Is there a way to return the non-local IP using self.scheduler.workItemResultServerAddr(), is that something that needs to be implemented in the scheduler ?
- Why is pdgcmd.reportResultData() working and not pdgcmd.writeAttribute()? I understand the difference, but it would be great if both of them had the std_out option, only pdgcmd.reportResultData() has it at the moment

Cheers

pdgcmd.reportResultData and writeAttribute both default to using the value of $PDG_RESULT_SERVER as the callback server. I'm not sure why one would be succeeding and the other failing unless you are passing the server_addr parameter to one, or if PDG_RESULT_SERVER is actually missing from the environment, in which case reportResultData might be just printing to stdout and not attempting to communicate at all.

workItemResultServerAddr just returns the value that was set by a previous call to setWorkItemResultServerAddr If you are accidentally passing 127.0.0.1, you should take a look at CallbackServer.startCallbackServer in $HH/python2.7libs/pdg/job/callbackserver.py

- What do we need to get the proxy server up and running? Our in-house scheduler is built upon the Tractor one

If you mean the pdgmq message queue process, that's best described by looking at the prtractor.py source. Basically you start that as a task and wait for it to report it's host and port before scheduling the rest of the tasks. See _startPDGMQ in prtractor.py.

Thanks Chris
I will send the stacktrace in a separate post
The result server env exist when running on the farm

Cheers