We are unable to instrument the jprofiler on the Webshpere App server JVM.
We are getting errors like below
java.lang.UnsatisfiedLinkError: com/jprofiler/agent/Agent.registerAnnotationMethods([[Ljava/lang/String;[I[II)V
at com.jprofiler.agent.Agent.registerInterceptions(ejt:579)
at com.jprofiler.agent.Agent.registerAllAnnotationMethods(ejt:513)
at com.jprofiler.agent.Agent.<clinit>(ejt:149)
at java.lang.J9VMInternals.initializeImpl(Native Method)
at java.lang.J9VMInternals.initialize(J9VMInternals.java:194)
when i start the JVM, the JVM was able to communicate to the jprofiler client. and i was able to see some samples before the JVM starts. and after a few sec the JVM crashes and it is in stopped status.
Environment details
App server - WAS 6.1
java version "1.5.0_55"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_55-b10)
Java HotSpot(TM) Server VM (build 1.5.0_55-b10, mixed mode)
i see this in the log
JProfiler> Protocol version 37
JProfiler> Using JVMTI
JProfiler> Thread status info workaround enabled.
JProfiler> 32-bit library
JProfiler> Listening on port: 8849.
JProfiler> Native library initialized
JProfiler> VM initialized
JProfiler> Waiting for a connection from the JProfiler GUI ...
java.lang.UnsatisfiedLinkError: com/jprofiler/agent/Agent.registerAnnotationMeth
ods([[Ljava/lang/String;[I[II)V
at com.jprofiler.agent.Agent.registerInterceptions(ejt:579)
at com.jprofiler.agent.Agent.registerAllAnnotationMethods(ejt:513)
at com.jprofiler.agent.Agent.<clinit>(ejt:149)
at java.lang.J9VMInternals.initializeImpl(Native Method)
at java.lang.J9VMInternals.initialize(J9VMInternals.java:194)
JProfiler> Using dynamic instrumentation
JProfiler> Time measurement: elapsed time
JProfiler> CPU profiling enabled
and the JVM is in stopped status. If i remove the argument from "Generic JVM arguments" i'm able to start the JVM without jprofiler.
This happens when you have an agent.jar from a different
JProfiler version in your bootclasspath or classpath. Please check your system for
any different JProfiler version to avoid this.
Related
When using Oracle Instant Client 21.7 and using the below json being sent to the Debezium connector, the follow error is generated.
Error message:
Caused by: java.sql.SQLException: No suitable driver found for jdbc:oracle:oci:#//<database-host>:<port>/DB
at java.sql.DriverManager.getConnection(DriverManager.java:689)
at java.sql.DriverManager.getConnection(DriverManager.java:208)
at io.debezium.jdbc.JdbcConnection.lambda$patternBasedFactory$0(JdbcConnection.java:191)
at io.debezium.jdbc.JdbcConnection$ConnectionFactoryDecorator.connect(JdbcConnection.java:128)
at io.debezium.jdbc.JdbcConnection.connection(JdbcConnection.java:882)
at io.debezium.jdbc.JdbcConnection.connection(JdbcConnection.java:877)
at io.debezium.jdbc.JdbcConnection.queryAndMap(JdbcConnection.java:630)
at io.debezium.jdbc.JdbcConnection.queryAndMap(JdbcConnection.java:504)
at io.debezium.connector.oracle.OracleConnection.resolveOracleDatabaseVersion(OracleConnection.java:141)
... 71 more
openjdk version "1.8.0_332"
OpenJDK Runtime Environment (build 1.8.0_332-b09)
OpenJDK 64-Bit Server VM (build 25.332-b09, mixed mode)
Running a later version of Java, the driver worked, but the connector still throws that error.
I've moved the drivers into the correct location, as mentioned here but still no dice.
I have a Gradle project with unit tests. If I do
./gradlew tests
the tests run as expected. One of them is very slow, so I was attempting to profile it with JProfiler. Based on https://www.ej-technologies.com/resources/jprofiler/help/doc/commandLine/gradleTasks.html, I added this to my build.gradle.
buildscript {
repositories {
maven {
url "https://plugins.gradle.org/m2/"
}
}
dependencies {
classpath "gradle.plugin.com.jprofiler:gradle_publish:13.0-PRE1"
}
}
apply plugin: "com.jprofiler"
<pre-existing build file>
jprofiler {
installDir = file('/Applications/JProfiler.app/Contents/Resources/app')
}
task testProfile(type: com.jprofiler.gradle.TestProfile) {
// mainClass = 'com.mycorp.MyMainClass'
//classpath sourceSets.main.testClasspath
// offline = true
// sessionId = 80
// configFile = file('path/to/jprofiler_config.xml')
}
Now if I do ./gradlew tasks, it lists the testProfile task. When I try to run the task, it waits for the profiler to connect.
$ ./gradlew testProfile
> Task :testProfile
JProfiler> Protocol version 55
JProfiler> Using JVMTI
JProfiler> Java 9+ detected.
JProfiler> JVMTI version 1.1 detected.
JProfiler> 64-bit library
JProfiler> Listening on port: 8849.
JProfiler> Instrumenting native methods.
JProfiler> Can retransform classes.
JProfiler> Can retransform any class.
JProfiler> Native library initialized
JProfiler> VM initialized
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by com.jprofiler.agent.LockManager to field java.util.concurrent.locks.AbstractOwnableSynchronizer.exclusiveOwnerThread
WARNING: Please consider reporting this to the maintainers of com.jprofiler.agent.LockManager
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
JProfiler> Retransforming 249 base class files.
JProfiler> Base classes instrumented.
JProfiler> Waiting for a connection from the JProfiler GUI ...
<===========--> 85% EXECUTING [53s]
> :testProfile > 0 tests completed
In JProfiler, I open Start Center and in the Quick Attach tab, I see to gradle related processes.
I select the one with testProfile, and get an error about numeric values.
In the gradle window, there are messages that look like JProfiler starting up.
<===========--> 85% EXECUTING [2m 32s]
> :testProfile > 0 tests completed
JProfiler> Protocol version 55
JProfiler> Using JVMTI
JProfiler> Java 9+ detected.
JProfiler> JVMTI version 1.1 detected.
JProfiler> 64-bit library
JProfiler> Listening on port: 51641.
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by com.jprofiler.agent.LockManager to field java.util.concurrent.locks.AbstractOwnableSynchronizer.exclusiveOwnerThread
WARNING: Please consider reporting this to the maintainers of com.jprofiler.agent.LockManager
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
JProfiler> Instrumenting native methods.
JProfiler> Can retransform classes.
JProfiler> Can retransform any class.
JProfiler> Retransforming 9 base class files.
JProfiler> Attach mode initializedzed
<===========--> 85% EXECUTING [3m 41s]
> :testProfile > 0 tests completed
When I reopen Start Center, the process is now highlighted in green.
I select it, and now JProfiler appears to connect. I can see all the types of information I expect to see about the process.
However, it appears to just be Gradle control processes.
In the gradle window, I do not see any indication that the tests are running. All I see is, every 2 minutes, a message about a timeout and (I think) a restart.
JProfiler> Using sampling (5 ms)
Unable to connect to the child process 'Gradle Test Executor 12'.
It is likely that the child process have crashed - please find the stack trace in the build log.
This exception might occur when the build machine is extremely loaded.
The connection attempt hit a timeout after 120.0 seconds (last known process state: STARTED, running: true).
org.gradle.process.internal.ExecException: Unable to connect to the child process 'Gradle Test Executor 12'.
It is likely that the child process have crashed - please find the stack trace in the build log.
This exception might occur when the build machine is extremely loaded.
The connection attempt hit a timeout after 120.0 seconds (last known process state: STARTED, running: true).
at org.gradle.process.internal.worker.DefaultWorkerProcess.doStart(DefaultWorkerProcess.java:192)
at org.gradle.process.internal.worker.DefaultWorkerProcess.start(DefaultWorkerProcess.java:168)
at org.gradle.process.internal.worker.DefaultWorkerProcessBuilder$MemoryRequestingWorkerProcess.start(DefaultWorkerProcessBuilder.java:252)
at org.gradle.api.internal.tasks.testing.worker.ForkingTestClassProcessor.forkProcess(ForkingTestClassProcessor.java:118)
at org.gradle.api.internal.tasks.testing.worker.ForkingTestClassProcessor.processTestClass(ForkingTestClassProcessor.java:91)
at org.gradle.api.internal.tasks.testing.processors.RestartEveryNTestClassProcessor.processTestClass(RestartEveryNTestClassProcessor.java:52)
at jdk.internal.reflect.GeneratedMethodAccessor43.invoke(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:36)
at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at org.gradle.internal.dispatch.FailureHandlingDispatch.dispatch(FailureHandlingDispatch.java:30)
at org.gradle.internal.dispatch.AsyncDispatch.dispatchMessages(AsyncDispatch.java:87)
at org.gradle.internal.dispatch.AsyncDispatch.access$000(AsyncDispatch.java:36)
at org.gradle.internal.dispatch.AsyncDispatch$1.run(AsyncDispatch.java:71)
at org.gradle.internal.concurrent.InterruptibleRunnable.run(InterruptibleRunnable.java:42)
at org.gradle.internal.operations.CurrentBuildOperationPreservingRunnable.run(CurrentBuildOperationPreservingRunnable.java:42)
at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64)
at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:48)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:56)
at java.base/java.lang.Thread.run(Thread.java:834)
JProfiler> Protocol version 55
JProfiler> Using JVMTI
JProfiler> Java 9+ detected.
JProfiler> JVMTI version 1.1 detected.
JProfiler> 64-bit library
JProfiler> Listening on port: 8849.
JProfiler> Instrumenting native methods.
JProfiler> Can retransform classes.
JProfiler> Can retransform any class.
JProfiler> Native library initialized
JProfiler> VM initialized
I have also tried connecting to the other gradle process, but it has similar results.
What do I need to do to get the tests to actually run?
Config:
JProfiler 9.2.1
$ ./gradlew --version
Gradle 6.4.1
Build time: 2020-05-15 19:43:40 UTC
Revision: 1a04183c502614b5c80e33d603074e0b4a2777c5
Kotlin: 1.3.71
Groovy: 2.5.10
Ant: Apache Ant(TM) version 1.10.7 compiled on September 1 2019
JVM: 11.0.8 (AdoptOpenJDK 11.0.8+10)
OS: Mac OS X 10.16 x86_64
We have a legacy application which is build using spring3 and java 7 and it was running on Jboss 6. Recently we have upgraded the jboss server from version 6 to version 7.1.3 with spring version from 3.0 to 4.3.1 and java from Oracle 1.7.0_60-b19 to Open java-1.8.0-openjdk.x86_64 1:1.8.0.191.b12-0.el6_10.
After the upgrade we are started getting error java.lang.OutOfMemoryError: GC overhead limit exceeded.
There is no code change in application and the linux box is same as it was there for Jboss 6.
We have analysed the heap dump shared by the production linux team. we used the JvisualVM and Eclipse Memory analyzer and it is pointing to below two possible leakage susspect.
1. io.undertow.server.session.InMemorySessionManager$SessionImpl
2. org.jboss.vfs.spi.JavaZipFileSystem
Linux team has copied the same configuration from jBoss 6 to jBoss 7. The configuration is -
export JAVA_OPTS="$JAVA_OPTS -Xms4096m -Xmx4096m -XX:MaxPermSize=1024m -Xverify:none -Dorg.jboss.resolver.warning=true -Djboss.modules.system.pkgs=com.sun.crypto.provider -Dsun.rmi.dgc.client.gcInterval=1800000 -Dsun.rmi.dgc.server.gcInterval=1800000 -server -XX:+DoEscapeAnalysis -XX:+UseCompressedOops -XX:+UseParallelGC -XX:+UseParallelOldGC -Dcom.ibm.mq.cfg.useIBMCipherMappings=false -Djava.net.preferIPv4Stack=true -Djava.net.preferIPv4Stack=true -Dsun.security.ssl.allowUnsafeRenegotiation=true -Dorg.apache.jasper.compiler.Parser.STRICT_WHITESPACE=false -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/opt/logs/EAP/"
Increasing the heap space (young generation, eden storage) is the only option?
I have an issue with FileNet configuration manager connecting to WAS when configuring CPE. Details are below
OS : Windows 10 Enterprise (This is where CPE 5.5 is installed)
WAS : 8.5.5.13
WAS Java : 1.8_64_bundled
FN Config Details
I'm able to login to WAS console and the SOAP port is also correct.
Things that I tried,
adding -Dhttps.protocols="TLSv1,TLSv1.1,TLSv1.2" in configmgr.ini of FileNet configuration manager
Verified SSL configuration on WAS
But noting seems to work. I see below error message on the FileNet configuration manager logs
!ENTRY com.ibm.ecm.configmgr.engine 4 0 2018-06-27 15:45:09.289
!MESSAGE An invalid profile path was specified. C:\IBM\FileNet\ContentEngine\tools\configure\profiles\dotnetclient does not contain any configuration information.
!SESSION 2018-06-27 16:05:40.995 -----------------------------------------------
eclipse.buildId=unknown
java.fullversion=JRE 1.7.0 IBM J9 2.6 Windows 8 x86-32 20170718_357001 (JIT disabled, AOT disabled)
J9VM - R26_Java726_SR10_20170718_1208_B357001
GC - R26_Java726_SR10_20170718_1208_B357001
J9CL - 20170718_357001
BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US
Framework arguments: gui
Command-line arguments: -os win32 -ws win32 -arch x86 gui
!ENTRY com.ibm.ecm.configmgr.app.ce 4 0 2018-06-27 16:13:56.518
!MESSAGE Connection error: The connection to the application server cannot be established. Ensure the application server is running and that the SOAP connector port and host name are correct.
!STACK 0
com.ibm.ecm.configmgr.engine.ConfigurationManagerException: Connection error: The connection to the application server cannot be established. Ensure the application server is running and that the SOAP connector port and host name are correct.
at com.ibm.ecm.configmgr.engine.jmx.JMXInvoker.invokeConnectMethodAndMethods(JMXInvoker.java:243)
at com.ibm.ecm.configmgr.engine.jmx.JMXInvoker.invokeConnectMethodAndMethod(JMXInvoker.java:142)
at com.ibm.ecm.configmgr.engine.jmx.WebSphereJMXInvoker.connect(WebSphereJMXInvoker.java:86)
at com.ibm.ecm.configmgr.app.ce.applicationserver.WebsphereApplicationServer$TestActivity.testWork(WebsphereApplicationServer.java:371)
at com.ibm.ecm.configmgr.engine.profile.EnvironmentTestActivity.test(EnvironmentTestActivity.java:64)
at com.ibm.ecm.configmgr.ui.wizards.NewProfileWizardPageGetProfileEnvironmentProps$7.widgetSelected(NewProfileWizardPageGetProfileEnvironmentProps.java:604)
at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:240)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1053)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4165)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3754)
at org.eclipse.jface.window.Window.runEventLoop(Window.java:825)
at org.eclipse.jface.window.Window.open(Window.java:801)
at com.ibm.ecm.configmgr.app.ce.handlers.ProfileNewHandler.execute(ProfileNewHandler.java:67)
at org.eclipse.ui.internal.handlers.HandlerProxy.execute(HandlerProxy.java:293)
at org.eclipse.core.commands.Command.executeWithChecks(Command.java:476)
at org.eclipse.core.commands.ParameterizedCommand.executeWithChecks(ParameterizedCommand.java:508)
at org.eclipse.ui.internal.handlers.HandlerService.executeCommand(HandlerService.java:169)
at org.eclipse.ui.internal.handlers.SlaveHandlerService.executeCommand(SlaveHandlerService.java:241)
at org.eclipse.ui.menus.CommandContributionItem.handleWidgetSelection(CommandContributionItem.java:829)
at org.eclipse.ui.menus.CommandContributionItem.access$19(CommandContributionItem.java:815)
at org.eclipse.ui.menus.CommandContributionItem$5.handleEvent(CommandContributionItem.java:805)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1053)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4165)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3754)
at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2701)
at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2665)
at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2499)
at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:679)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:668)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
at com.ibm.ecm.configmgr.app.ce.rcp.Application.start(Application.java:86)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:344)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:56)
at java.lang.reflect.Method.invoke(Method.java:620)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:622)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:577)
at org.eclipse.equinox.launcher.Main.run(Main.java:1410)
Caused by: java.lang.Exception: The connection to the application server cannot be established. Ensure the application server is running and that the SOAP connector port and host name are correct.
at com.ibm.ecm.configmgr.utils.websphere.WebSphereJMXUtil.connect(WebSphereJMXUtil.java:227)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:56)
at java.lang.reflect.Method.invoke(Method.java:620)
at com.ibm.ecm.configmgr.engine.jmx.JMXInvoker.invokeConnectMethodAndMethods(JMXInvoker.java:191)
... 45 more
*************************telenet response**************************
When did telenet and after a few seconds, I see the below error
HTTP/1.1 408 Request Timeout Content-Type: text/html Content-Length: 117 Connection: close <HTML><TITLE>408 - Request Timeout</TITLE><BODY><h1>408 Connection timed out while reading request</h1></BODY></HTML> Connection to host lost. C:\Windows\system32>
*****************************workaround*****************************
Ok once the profile is created and ran first steps, I disabled global security and restarted websphere. Configuration manager is able to connect to WAS now (looks like issue with security. I verified Quality of protection (QoP) settings
with ssl.client.properties and it was selected as TLSv2. Then I changed it to TSLv1.2 and modified ssl.client.properties also. Still it did not work) I will updated this topic later.
Check default path Webshere.
C:\Program Files\IBM\WebSphere\AppServer
C:\Program Files\IBM\WebSphere\AppServer\profiles\your_profile
VS
C:\Program Files (x86)\IBM\WebSphere\AppServer
C:\Program Files (x86)\IBM\WebSphere\AppServer\profiles\your_profile
The Configuration Manager right now seems to support only older protocols. If you specify TLSv1 in WebSphere console, as opposed to TLSv1.2 for example, Test Connection will work. That will create you another problem though. Newer browsers don't support older protocols and you will not be able to open your WebSphere console in say, Firefox. On Windows, you can use your old but still included IE configured to use these older protocols - Tools -> Internet Options -> Advanced -> Security -> Use * . You'll get your console back that way.
We are using spring ehcache in our application, recently we upgraded the java version of the tomcat in which the app runs to 1.8.66.
Strangely there are no errors in the logs - but caching doesn't work on the linux machine.
On my local (windows) same version of java 1.8.66, it works like a charm... what could be the issue?
We are using aspecJ load time weaving with TomcatInstrumentableClassLoader - version 3.2.3.
Details of dependencies:
ehcache 2.7.4
aspectJ weaver 1.6.2
spring 3.1.1
INFO 2015-12-28 14:09:19,667 (org.springframework.cache.ehcache.EhCacheManagerFactoryBean.afterPropertiesSet(EhCacheManagerFactoryBean.java:100)) - Initializing EHCache CacheManager
INFO 2015-12-28 14:09:19,828 (net.sf.ehcache.pool.sizeof.filter.AnnotationSizeOfFilter.<clinit>(AnnotationSizeOfFilter.java:53)) - Using regular expression provided through VM argument net.sf.ehcache.pool.sizeof.ignore.pattern for IgnoreSizeOf annotation : ^.*cache\..*IgnoreSizeOf$
INFO 2015-12-28 14:09:19,873 (net.sf.ehcache.pool.sizeof.JvmInformation.<clinit>(JvmInformation.java:446)) - Detected JVM data model settings of: 64-Bit HotSpot JVM with Compressed OOPs
INFO 2015-12-28 14:09:20,190 (net.sf.ehcache.pool.sizeof.AgentLoader.getAgentFile(AgentLoader.java:198)) - Extracted agent jar to temporary file /opt/projects/tomcat/instance_7/temp/ehcache-sizeof-agent7845091970407661363.jar
INFO 2015-12-28 14:09:20,190 (net.sf.ehcache.pool.sizeof.AgentLoader.loadAgent(AgentLoader.java:138)) - Trying to load agent # /opt/projects/tomcat/instance_7/temp/ehcache-sizeof-agent7845091970407661363.jar
INFO 2015-12-28 14:09:20,199 (net.sf.ehcache.pool.impl.DefaultSizeOfEngine.<init>(DefaultSizeOfEngine.java:111)) - using Agent sizeof engine
INFO 2015-12-28 14:09:20,456 (net.sf.ehcache.pool.impl.DefaultSizeOfEngine.<init>(DefaultSizeOfEngine.java:111)) - using Agent sizeof engine
INFO 2015-12-28 14:09:20,746 (net.sf.ehcache.pool.impl.DefaultSizeOfEngine.<init>(DefaultSizeOfEngine.java:111)) - using Agent sizeof engine
INFO 2015-12-28 14:09:20,768 (net.sf.ehcache.pool.impl.DefaultSizeOfEngine.<init>(DefaultSizeOfEngine.java:111)) - using Agent sizeof engine
INFO 2015-12-28 14:09:20,789 (net.sf.ehcache.pool.impl.DefaultSizeOfEngine.<init>(DefaultSizeOfEngine.java:111)) - using Agent sizeof engine
I can see same logs in both Windows and Linux after application starts up
Could this be a issue with Linux JVM?
I think that it's a problem with spring 3.x.x and Java 8.
Take a look here Spring 3.2.x with Java 8