Regarding the log file. It's absence is absolutely strange. Are you sure you're looking for .yjp/log in appropriate user home? Anyway, you can explicitly specify the log file location with the startup option "logdir":https://www.yourkit.com/docs/java/help/ ... ptions.jsp

Regarding the exception itself. Where do you see that exception, in what log file? Even if it is thrown, it must not go beyond the probe's code in the new agent. In other words, It must not be an uncaught exception now.

You may try running with b34, but we would prefer the log created with the latest build with the proposed fix.

Also, it seems you paste truncated logs. We need full logs. If you cannot share it here in the forum, please feel free to send the files attached to support@yourkit.com

Could you please answer this question:Where do you see that exception, in what log file? Even if it is thrown, it must not go beyond the probe's code in the new agent. In other words, It must not be an uncaught exception now.

2016-05-03 10:30:18.773 PDT [pool-1-thread-2] ERROR h2database - logstore:jdbc[4] exceptionorg.h2.jdbc.JdbcSQLException: The object is already closed [90007-172] at org.h2.message.DbException.getJdbcSQLException(DbException.java:329) ~[h2-1.3.172.jar:1.3.172] at org.h2.message.DbException.get(DbException.java:169) ~[h2-1.3.172.jar:1.3.172] at org.h2.message.DbException.get(DbException.java:146) ~[h2-1.3.172.jar:1.3.172] at org.h2.message.DbException.get(DbException.java:135) ~[h2-1.3.172.jar:1.3.172] at org.h2.jdbcx.JdbcXAConnection$PooledJdbcConnection.checkClosed(JdbcXAConnection.java:488) [h2-1.3.172.jar:1.3.172] at org.h2.jdbc.JdbcConnection.checkClosed(JdbcConnection.java:1388) ~[h2-1.3.172.jar:1.3.172] at org.h2.jdbc.JdbcConnection.getMetaData(JdbcConnection.java:309) ~[h2-1.3.172.jar:1.3.172] at com.yourkit.runtime.Callback.callObjectMethod0(Native Method) [na:na] at com.yourkit.probes.ReflectionUtil.callMethod0(ReflectionUtil.java:72) [na:na] at com.yourkit.probes.ReflectionUtil.callMethod0(ReflectionUtil.java:117) [na:na] at com.yourkit.probes.builtin.Databases.getConnectionURL(Databases.java:729) [na:na] at com.yourkit.probes.builtin.DatabasesLW$1.getResourceName(DatabasesLW.java:50) [na:na] at com.yourkit.probes.ResourceCounter.getResourceNameSafe(ResourceCounter.java:258) [na:na] at com.yourkit.probes.ResourceCounter.close(ResourceCounter.java:242) [na:na] at com.yourkit.probes.builtin.DatabasesLW$Connection_or_Statement_close_Probe.onExit(DatabasesLW.java:275) [na:na] at org.h2.jdbcx.JdbcXAConnection$PooledJdbcConnection.close(JdbcXAConnection.java:478) [h2-1.3.172.jar:1.3.172] at com.synapsense.NoAutocommitQueryRunner.batch(NoAutocommitQueryRunner.java:31) [dm-utils-6.8.0.jar:na] at com.synapsense.plugin.transport.db.H2DataRepository.saveDataPoints(H2DataRepository.java:76) [dm-es-transport-6.8.0.jar:na] at com.synapsense.plugin.transport.jms.DataEventStore.process(DataEventStore.java:52) [dm-es-transport-6.8.0.jar:na] at com.synapsense.eventflow.backup.PrimarySwitch.process(PrimarySwitch.java:44) [dm-utils-6.8.0.jar:na] at com.synapsense.eventflow.backup.BackupFlowSwitcher.process(BackupFlowSwitcher.java:30) [dm-utils-6.8.0.jar:na] at com.synapsense.plugin.transport.jms.JMSTransport.sendData(JMSTransport.java:217) [dm-es-transport-6.8.0.jar:na] at com.synapsense.plugin.manager.CompositeTransport.sendData(CompositeTransport.java:104) [dm-core-6.8.0.jar:na] at com.synapsense.plugin.simulator.sensorplace.SensorsStore.sendValue(SensorsStore.java:120) [dm-simulator-plugin-6.8.0.jar:na] at com.synapsense.plugin.simulator.sensorplace.SensorImitator.run(SensorImitator.java:133) [dm-simulator-plugin-6.8.0.jar:na] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [na:1.7.0_79] at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304) [na:1.7.0_79] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178) [na:1.7.0_79] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [na:1.7.0_79] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [na:1.7.0_79] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [na:1.7.0_79] at java.lang.Thread.run(Thread.java:745) [na:1.7.0_79]

But something is still messed up. The behavior with the profiler enabled is different. H2 will keep trying to close that original connection on any later activity and fail every time. This is just a grep for the first line of the exception:

Instead of catching the exception, can you instead check that the connection is not already closed? This would make YJP more transparent. Who knows what funky stuff the H2 connection pool does when closing a connection? Maybe it also tries closing connections that failed earlier. All exception above refer to the same connection, identified as [90007-172].

Finally, why do I no longer see the yjp log files after the b35 upgrade? Can I look for them in some other place?

Finally, why do I no longer see the yjp log files after the b35 upgrade? Can I look for them in some other place?

I don't know what happened. There were no changes between b34 and b35 in regard of the log file processing. We do not see any log file issues with the newest builds.

Perhaps something has changed on your system. For example, you use cygwin. If it redefines the user home variables used by Java, please take a look at cygwin's user home instead of the normal Windows user home (or vise versa).

Anyway, since you get the logs with "logdir" specified (you do, right?), the problem is not with the agent's inability to create the log but rather with the detected user home directory where it should be located.

If the agent cannot create the log, it writes an error message to stdout or stderr (sorry, don't remember the exact stream). Please check the application logs for such messages.