It looks like the current glassfish sizing tries to allocate more RAM that the server has remaining and consequently memory swap, and connections to MySQL piled up then App crashes, followed by server reboot.
This now seems to happen frequently...we tried to make some changes to the heap size (Xmx/Xms), max-thread-pool-size and innodb_buffer_pool_size with no much luck ..
- It is a physical Linux; 504GB RAM; 7GB swap; 2 sockets; 40 CPUs
- v188.8.131.52; performance-profile=large
Current set-up (domain.xml):
Cuerrent set-up (db.cnf):
Here is what i would like to understand... Do these values look reasonable? if not, could you please suggest what needs to be adjusted?
Do we need to use -Xmn or can the young gen be managed via NewRatio & SurvivorRatio? As the NewRatio=2, my understanding is current -Xmn is half the heap size (1:2) i.e ~100g.
Awaiting some quick response...
... View more
we repeatedly see the following error in or server.log. Can someone please help to understand what is "action: VIEW_DBMON_UI entity: APPLICATION 1" in this error, and also if we could restrict this operation for a specific user or a group ?
I also couldn't see much information in audit.log for the specific user. Are there any docs that explains different actions?
[#|2018-08-06T17:49:50.976-0500|SEVERE|glassfish 4.1|com.singularity.ee.controller.beans.ExceptionHandlingInterceptor|_ThreadID=266;_ThreadName=http-listener-1(21);_TimeMillis=1533595790976;_LevelValue=1000;|Encountered a permission exception; permission=[VIEW_DBMON_UI]; affected entity=[Type:APPLICATION, id:1] com.singularity.ee.controller.api.exceptions.PermissionException: The current user 'xxxxxxx' does not have permission to do this. (action: VIEW_DBMON_UI entity: APPLICATION 1) at com.singularity.ee.controller.beans.manage.permissions.PermissionsManager.isNotPermitted(PermissionsManager.java:352) at com.singularity.ee.controller.beans.manage.permissions.PermissionsManager.checkPermission(PermissionsManager.java:311) at com.appdynamics.platform.persistence.TransactionInterceptor$1.call(TransactionInterceptor.java:30) at com.singularity.ee.controller.beans.model.EJBManagerBean.runWithinSupportsTransaction(EJBManagerBean.java:58) at sun.reflect.GeneratedMethodAccessor306.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1081) at org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1153) at com.sun.ejb.containers.BaseContainer.invokeBeanMethod(BaseContainer.java:4786) at com.sun.ejb.EjbInvocation.invokeBeanMethod(EjbInvocation.java:656) at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:824) at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:608) at com.singularity.ee.controller.beans.EntityManagerInterceptor.manageEntityManagerLifecycle(EntityManagerInterceptor.java:57) at sun.reflect.GeneratedMethodAccessor298.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:883) at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:823)
Would appreciate any swift response on this...
... View more
We are trying to enabe Object Instance Tracking (OIT) for a Java node and we get this following message,
There is no object instance data. This could be caused by the following reasons:
 This feature is only supported for Oracle JVMs. It does not work for JRockit or IBM JVMs.
 tools.jar is not in the JVM classpath. You must add it to the classpath and restart the JVM.
 - Yes, it is a an Oracle JVM
 - here, does "JVM class path" refers to java.home?
Please note the application is being run by "JDK"
The doc says "This feature requires tools.jar to be in JRE_HOME/lib/ext.
If you are running with the JDK then tools.jar will probably be setup correctly, but if you are running with the JRE you must add tools.jar to JRE_HOME/lib/ext and restart the JVM for this feature to start working"
When it says "...If you are running with the JDK then tools.jar will probably be setup correctly..", where exactly should it have been set up ?
Now, the current path for tools.jar is "\\ms\dist\msjava\PROJ\oraclejdk\1.8.0_121\lib\tool.jar"
What needs to be done to get this work? do we need to copy "\ms\dist\msjava\PROJ\oraclejdk\1.8.0_121\lib\tool.jar" to "/ms/dist/msjava/PROJ/oraclejdk/1.8.0_162/.exec/@sys/jre/lib/ext" ?
Application team doesn't want to create /lib/ext under "/ms/dist/msjava/PROJ/oraclejdk/1.8.0_162/.exec/@sys/jre" as it is a shared location.
Can someone please advise how we can get this working?
... View more
I have a healthrule suppression schedule enabled and it doesn't seem to be working as expected.
The requirement is to suppress or disable helathrule between 1 AM and 6 AM only on Sundays, and this the cron entry that i set up (see attached).
start time cron expression: * * 6 ? * 7
end time cron expression : * * 1 ? * 7
If this is incorrect, please advise what needs to be modified. Thank you!
... View more