IllegalStateException: Already undeployed

[dsgrieve]

Running the sample gives an IllegalStateException: Already undeployed. This is not an problem, so maybe the exception shouldn't be logged as severe.

First, run ./mvnw clean install from the project root. Then, from the sample directory, run ../mvnw compile dependency:copy-dependencies. Lastly, run java --module-path target/classes:target/lib --module com.microsoft.gctoolkit.sample/com.microsoft.gctoolkit.sample.Main ../gclogs/preunified/cms/defnew/details/defnew.log. These steps are in the README file for the root and sample.

java --module-path target/classes:target/lib --module com.microsoft.gctoolkit.sample/com.microsoft.gctoolkit.sample.Main ../gclogs/preunified/cms/defnew/details/defnew.log
Jun 13, 2023 12:25:30 PM io.netty.util.internal.PlatformDependent <clinit>
INFO: Your platform does not provide complete low-level API for accessing direct buffers reliably. Unless explicitly requested, heap buffer will always be preferred to avoid potential system instability.
Jun 13, 2023 12:25:30 PM io.netty.resolver.dns.DnsServerAddressStreamProviders <clinit>
WARNING: Can not find io.netty.resolver.dns.macos.MacOSDnsServerAddressStreamProvider in the classpath, fallback to system defaults. This may result in incorrect DNS resolutions on MacOS. Check whether you have a dependency on 'io.netty:netty-resolver-dns-native-macos'
Jun 13, 2023 12:25:31 PM io.vertx.core.impl.DeploymentManager
SEVERE: Undeploy failed
java.lang.IllegalStateException: Already undeployed
	at io.vertx.core@4.4.3/io.vertx.core.impl.DeploymentManager$DeploymentImpl.doUndeploy(DeploymentManager.java:322)
	at io.vertx.core@4.4.3/io.vertx.core.impl.DeploymentManager.undeployVerticle(DeploymentManager.java:82)
	at io.vertx.core@4.4.3/io.vertx.core.impl.DeploymentManager.undeployAll(DeploymentManager.java:109)
	at io.vertx.core@4.4.3/io.vertx.core.impl.VertxImpl.lambda$close$15(VertxImpl.java:629)
	at io.vertx.core@4.4.3/io.vertx.core.impl.future.FutureImpl$3.onSuccess(FutureImpl.java:141)
	at io.vertx.core@4.4.3/io.vertx.core.impl.future.FutureBase.emitSuccess(FutureBase.java:60)
	at io.vertx.core@4.4.3/io.vertx.core.impl.future.FutureImpl.addListener(FutureImpl.java:196)
	at io.vertx.core@4.4.3/io.vertx.core.impl.future.PromiseImpl.addListener(PromiseImpl.java:23)
	at io.vertx.core@4.4.3/io.vertx.core.impl.future.FutureImpl.onComplete(FutureImpl.java:164)
	at io.vertx.core@4.4.3/io.vertx.core.impl.future.PromiseImpl.onComplete(PromiseImpl.java:23)
	at io.vertx.core@4.4.3/io.vertx.core.impl.VertxImpl.close(VertxImpl.java:628)
	at com.microsoft.gctoolkit.vertx@3.0.5-SNAPSHOT/com.microsoft.gctoolkit.vertx.VertxChannel.close(VertxChannel.java:36)
	at com.microsoft.gctoolkit.vertx@3.0.5-SNAPSHOT/com.microsoft.gctoolkit.vertx.VertxDataSourceChannel.close(VertxDataSourceChannel.java:39)
	at com.microsoft.gctoolkit.api@3.0.5-SNAPSHOT/com.microsoft.gctoolkit.jvm.AbstractJavaVirtualMachine.analyze(AbstractJavaVirtualMachine.java:199)
	at com.microsoft.gctoolkit.api@3.0.5-SNAPSHOT/com.microsoft.gctoolkit.GCToolKit.analyze(GCToolKit.java:308)
	at com.microsoft.gctoolkit.sample@3.0.5-SNAPSHOT/com.microsoft.gctoolkit.sample.Main.analyze(Main.java:53)
	at com.microsoft.gctoolkit.sample@3.0.5-SNAPSHOT/com.microsoft.gctoolkit.sample.Main.main(Main.java:31)

The XYDataSet for DefNew contains 19114 items.
The XYDataSet for Remark contains 26 items.
The XYDataSet for InitialMark contains 26 items.
DefNew : 19114
Remark : 26
InitialMark : 26

[kcpeppe]

I thought this was resolved... I'll look again.

[dsgrieve]

This isn't the hang issue. It's just that we call close twice. This isn't a problem other than the log at SEVERE which makes one think there is. Fix should probably just be a try-catch in the close method of VertxChannel

[loyispa]

I think the problem maybe caused by this part , It caused repeat undeploy if several Parser consumes END_OF_DATA_SENTINEL.

Are these codes duplicate with dataSourceBus.close() ?

[loyispa]

I think the problem maybe caused by this part , It caused repeat undeploy if several Parser consumes END_OF_DATA_SENTINEL.

Are these codes duplicate with dataSourceBus.close() ?

@kcpeppe When I commented this block of code I found the Exception was solved. Could you check that ?

[kcpeppe]

We need to close to happen at least once. Unfortunately the current API makes a second call. I'll try to recover the fix that was in play