Hi I have a Mendix app running in the public cloud. Periodically (I haven't been able to discern a pattern yet), the app will become unresponsive. This happened earlier today. The app platform showed the service as green, however no one could login. When I tried to stop and restart the app, the app platform was unable to stop the app in an orderly fashion - twice I received a message that the app could not be shut down in the normal way, and asking if I wanted to force the service to stop. I did so and was finally able to restart the service. Looking in the log, I see the following messages from the time frame when this happened: 2014-05-27 18:44:35.282 INFO - Core: Removing session for user 'marcus' 2014-05-28 05:55:56.530 INFO - Connector: New login request from [Source-IP: 127.0.0.1, X-Forwarded-For: 10.183.248.6, User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.114 Safari/537.36] 2014-05-28 05:55:56.717 INFO - WebUI: Login OK: user 'marcus' (Number of concurrent sessions: 1). 2014-05-28 06:37:29.567 INFO - Core: Removing session for user 'marcus' 2014-05-28 06:39:39.287 ERROR - ActorSystem: access denied ("java.lang.RuntimePermission" "accessDeclaredMembers") 2014-05-28 06:39:39.287 ERROR - ActorSystem: java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "accessDeclaredMembers") at java.security.AccessControlContext.checkPermission(Unknown Source) at java.security.AccessController.checkPermission(Unknown Source) at java.lang.SecurityManager.checkPermission(Unknown Source) at java.lang.Class.checkMemberAccess(Unknown Source) at java.lang.Class.getDeclaredConstructors(Unknown Source) at akka.util.Reflect$.findConstructor(Reflect.scala:84) at akka.actor.Props.constructor(Props.scala:194) at akka.actor.Props.<init>(Props.scala:213) at akka.actor.Props$.apply(Props.scala:130) at com.mendix.core.session.DispatchSupervisor$$anonfun$receive$1.applyOrElse(SourceFile:71) at akka.actor.ActorCell.receiveMessage(ActorCell.scala:498) at akka.actor.ActorCell.invoke(ActorCell.scala:456) at akka.dispatch.Mailbox.processMailbox(Mailbox.scala:237) at akka.dispatch.Mailbox.run(Mailbox.scala:219) at akka.dispatch.ForkJoinExecutorConfigurator$AkkaForkJoinTask.exec(AbstractDispatcher.scala:386) at scala.concurrent.forkjoin.ForkJoinTask.doExec(ForkJoinTask.java:260) at scala.concurrent.forkjoin.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1339) at scala.concurrent.forkjoin.ForkJoinPool.runWorker(ForkJoinPool.java:1979) at scala.concurrent.forkjoin.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:107) Any ideas regarding how to go about troubleshooting this problem? Thanks, Mike
The Mendix 5.4.1 release requires additional security permission to run in the cloud. Unfortunately these additional security permission weren't added to the cloud policy file at the same time as 5.4.1 was released.
All cloud servers should now have this permission in their policy file and you shouldn't run into this issue again.
Please note that if you ever get an AccessControlException, or ClassNotFoundError, or anything similar to this, your application will become unstable and will not be able to run as expected.
The app administrator should inspect the cause of the error and restart the application after solving the problem.
As Ronald states, the platform waits for all actions to succesfully finish before shutting down. Since all actions/microflows are in an inconsistent state it will always result in a time-out asking you to force the application to shutdown. This is the expected behavior.
Jasper van der Hoek
It may not be related but I am reacting because of the symptoms you describe. At the moment we have two customer environments that have the same symptons (one more often then the other).
Out of curiousity could you check your monitor / running now the next time to see if you have long running microflows?
What we see is that a microflow does not stop. It seems to hang on a commit action. The commit just never finishes (it is always the same microflow causing this, but different ones in each environment). Because of this other microflows will also not end with the result that the environment becomes inresponsive and eating up resources. Killing the request does not help. I do not know what this feature does, but we never have seen any result of killing the action. After a refresh the microflow is there again.
We already filed a support ticket for this problem but have the same problem as you. Sample project is of no use because it will happen only in a production environment and never in the test environments of these projects (both projects are on Mx 4.7.2.)
And again the problem might not be related at all but I give a response because of the exact same symptoms.