Followup Question about "pitchforking"

Not applicable

Got a great answer here: https://community.apigee.com/questions/6117/controlling-what-message-processor-a-router-sends.html

i have a followup question:

under /opt/apigee4/conf/apigee/router/

we have a file message-processor-communication.properties

in this file we have an entry that looks like this: local.http.host=<server ip address>

I am wondering if this is causing the behavior we are seeing where traffic never leaves the server hosting the router and message-processor?

1 3 218
3 REPLIES 3

Not applicable

Hi @Benjamin Goldman , I never played with those properties but AFAIK those properties in the Mp message-processor-communication.properties are needed if you want to change the default hostname and port the MP listens on from the routers once you installed instead of reinstalling .

// description from the operations doc

local.http.host = Optional. Hostname to listen on for router connections. This will override the host name configured at registration.

and

local.http.port=8998 . Optional. Port to listen on for router connections. Default is 8998 .

When ever we change the above , we also need to make sure we change the host and port in the routers router-message-processor-communication.properties and restart both routers and Mps .

cc @sgilson

So putting an entry in /opt/apigee4/conf/apigee/router/message-processor-communication.properties/local.http.host=<server ip address> would make the router aware of an "alternate" location for a message processor server. This allows the router to find it. In my build i have 2 servers - each with a router and message processor on them. Each router has its own server IP address in that config setting.

Would this not prevent each router from talking to the other servers message processor ... since the default is being over-ridden and only ONE ip address is listed as an option?

Not applicable

Community clarification.

The functionality discussed above, pitchfork, was available on 4.14.XX and 4.15.XX releases. The functionality was deprecated as part of 4.16.01.