Issue in Message processors executing the run time policies.

Not applicable

Hi, I have 5 node cluster architecture for Apigee with MPs and routers available on two machines say A1 and A2. My problem is when I do any change in policy (e. g. adding a new variable in assign message) and if that request goes to A1, all the variables are initialized properly. But when same request is served by A2 I am not getting the new variables I have added due to which my API is failing. Never encountered such issue before. Any pointer on this would be really very helpful.

Solved Solved
0 2 82
1 ACCEPTED SOLUTION

Is it possible you have multiple revisions of the API proxy in deployment?

Here's what I would try:

  1. check the status of the API proxy deployment, using the Edge admin API. A deployment error may be revealed, in which case you may need to attend to the MP that is not able to deploy the proxy.
  2. Force undeploy the API proxy, using the administrative API.
  3. Save the API proxy as a new proxy, and deploy the proxy with the new name, to see if the problem persists.

As for the first check, the API call is like this:

curl -i -n ${mgmtserver}/v1/o/ORG/apis/APIPROXY/deployments

You must replace the ORG and APIPROXY with the appropriate values. If the response indicates that the proxy is not deployed correctly on all MPs, then you may need to examine the system.log for the MP in question to further diagnose. Or restart the MP, if you don't care to diagnose the problem.

For #2, the call is like this:

curl -X DELETE  -i -n ${mgmtserver}/v1/o/ORG/e/ENV/apis/APIPROXY/revisions/REV/deployments?force=true

You must replace the ORG, ENV, APIPROXY and REV in the URL with the appropriate values.

View solution in original post

2 REPLIES 2

Is it possible you have multiple revisions of the API proxy in deployment?

Here's what I would try:

  1. check the status of the API proxy deployment, using the Edge admin API. A deployment error may be revealed, in which case you may need to attend to the MP that is not able to deploy the proxy.
  2. Force undeploy the API proxy, using the administrative API.
  3. Save the API proxy as a new proxy, and deploy the proxy with the new name, to see if the problem persists.

As for the first check, the API call is like this:

curl -i -n ${mgmtserver}/v1/o/ORG/apis/APIPROXY/deployments

You must replace the ORG and APIPROXY with the appropriate values. If the response indicates that the proxy is not deployed correctly on all MPs, then you may need to examine the system.log for the MP in question to further diagnose. Or restart the MP, if you don't care to diagnose the problem.

For #2, the call is like this:

curl -X DELETE  -i -n ${mgmtserver}/v1/o/ORG/e/ENV/apis/APIPROXY/revisions/REV/deployments?force=true

You must replace the ORG, ENV, APIPROXY and REV in the URL with the appropriate values.

Thanks @Dino. There was some deployment issue in one of the Message Processors. The issue was resolved after restarting the MP.