Model is NOT an Entity Bean registered with this server after restart (Heroku/Play Framework)

[Pedro Rio]

Hi guys, I wanted to know if any has seen a problem like this before.

I'm using Play Framework (2.6.11) with Play-Ebean from payintech (https://github.com/payintech/play-ebean) version 18.01 (Ebean 11.7.1).

I'm deploying on Heroku and last night after Heroku's daily restart, I started getting the error of "Model is NOT an Entity Bean registered with this Server"

The application was working just fine before the restart. I tried restarting it again a few times, but was not able to fix the issue. I decided to try and rebuild the application (git push heroku master) and after that, everything was ok. Seems that between restarts something went wrong.

Has anyone experienced something like this?

javax.persistence.PersistenceException: <ModelName> is NOT an Entity Bean registered with this server?
    at io.ebeaninternal.server.core.DefaultServer.createQuery(DefaultServer.java:1046)
    at io.ebeaninternal.server.core.DefaultServer.find(DefaultServer.java:1002)
    at io.ebean.Finder.query(Finder.java:196)

[Pedro Rio]

Just an updated. It happened again after today's daily restart. My staging environment does not have the same problem, trying to see if there are diferences that would cause this

[Thibault Meyer]

Very strange issue, have you try to recompil project with "sbt clean; sbt stage" ?

we are deploying into Docker container, not Heroku, never see this kind of issue (Play 2.6.x). If you find the root of this issue, i'm glad to know about it.

[Pedro Rio]

Hi Thibault, thanks for replying :) (also thanks a lot for the work on play-ebean!)

While deploying on Heroku I don't have a way to do "sbt clean, sbt stage" directly. I can however set an environment variable to *I think* achieve that (https://devcenter.heroku.com/articles/scala-support#clean-builds). That's a good idead, I'll have to try that.

My first try will be to restart manually to see if there's a difference between Heroku's automatic daily restart and a manual restart. After the problem occurred, manual restarts didn't have any effect, only a rebuild would do this.

I'm waiting for an opportunity with little/no active users, because if this triggers the problem the application will be unavailable.

I'll keep this post updated. I'm reached out to Heroku support for tips but so far nothing useful came out of it.

[Pedro Rio]

Ok, an update.

I've mentioned to Heroku support that the only thing I have different from production and staging is the new-relic agent and they replied back that the agent does bytecode manipulation at runtime (didn't recall that)

I've tried disabling the agent and restarting and the problem didn't occur (when I did re-enable the agent the problem did not occur as I was expecting).

I guess I need to run a few more experiments, but it seems promising.

--

---
You received this message because you are subscribed to a topic in the Google Groups "Ebean ORM" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ebean/sAAdMTU1520/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ebean+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Pedro Rio

[Pedro Rio]

Ok, another update:

I haven't figured out the issue regarding the production environment, but it started happening in staging as well (and staging didn't have new-relic installed). I pinned it down to a commit that introduced the usage of Ebean via Guice, and apparently it was creating the Ebean default server and registering it, but without having the indication of which packages the models were :(

So after I set the path to the packages for this scenario, things started working in staging again. I've disabled new-relic in production until I have more time to investigate the issue.

Anyway, that's basically it.