Could not initialize class com.apigee.steps.accessentity.AccessEntityRegistry

[ofields]

This API works fine sometimes and throws errors othertimes. The full JSON that gets returned is below. Error on our side or something else? What we're doing is taking a developer client_id and doing a lookup.

{"fault": {"faultstring": "Could not initialize class com.apigee.steps.accessentity.AccessEntityRegistry","detail": {"errorcode": "Internal Server Error"}}}

[adas]

@ofields Are you an cloud EDGE customer or on-premise, or are you a EDGE free customer ? It seems to me that one of the message processors that you are hitting has something going on, while the others are fine and that's why the inconsistent behaviour. Can you tell me your organization name, if you are a cloud customer. I will take a look at the setup.

I found a similar issue last week, where one of the servers didn't have the correct release deployed to it and hence was throwing class not found exception. This looks very similar too.

[ofields]

It worked fine in the free environment (what we're using as a sandbox). When moved over to the Edge environment (hosted) is when it would work intermittently. Here's a URL we were using: https://jnj-dev.apigee.net/app_info?clientkey=zvXQk6GnOgcdIkBoB1KUkg5l3RBDWeWj

[jhans]

@ofields It seems that the problem is with cassandra. I can see the calls coming in trace.

I have tried to redeploy the apiproxy but it didn't help. I will check if the client key is present in all cassandras.

[adas]

@jagjyot The problem was with one of the message-processors. Please read my comment below. The problem should be resolved now.

[jhans]

@arghya das got that. Cool.

[adas · Accepted solution]

@ofields Like I suspected, there was a problem with one of the message-processor servers. The message-processor got the recent release that we pushed last night, but the process was not restarted for some weird reason. So the message-processor server was acting up. I have bounced that server now and tested with your calls to make sure everything looks good.

I am investigating this at our end with the devops folks so that such issues don't happen in the future. We would take care of this in our future deployments by correcting the necessary steps in our deployment automation and rollout process.