This question was closed Nov 23, 2015 at 10:56 PM by birute@google.com for the following reason:
Problem is not reproducible or outdated
Jar files are not loaded when the new MP is added
Jar files are not added to the below location when a new MP is added,
/opt/apigee4/var/log/apigee/message-processor/work/o/<org>/java
Errors are seen when an API call tries to access the jars present in these locations.
Make a comparison of the new MP vs. old MP work directory. They should look the same from the old MP and the new MP. So jar files that are not in use, should not be expanded out in the directory, but jar files in use will be expanded exactly the same directory structure as on a new MP vs. old MP.
A few things to be checked:
1. Any permissions errors in the path: /opt/apigee4/var/log/apigee/message-processor/work/o/<org>/java
2. system.log for the message processor. /<install-root>/apigee4/var/log/apigee/message-processor/logs/system.log
3. Also check the management-server logs at
/<install-root>/apigee4/var/log/apigee/management-server/logs/system.log
Ideally when a new MP get added to the pod and the org/env, that already exist and have api proxies already deployed, a restart of the MP should do two things needed for your API traffic to run:
- it will pull down the API proxies and deploy them to the new MP - resource files from Cassandra are uploaded to the MP in its directory structure
Thus, API proxies that exist on your old MPs should work just fine on your new MPs . The directory structure where the jar file gets created on the MP itself in the "work" directory, may not be there for the jar file if there are no deployed API proxies that have calls to the classes in that jar. That may be a reason why the jar resource is not there.
