maven-verticle-factory re-deploy verticle with the same version

[Konstantinos Liakos]

I am trying to create a master verticle that will be responsible of deploying and re-deploying other verticles.

Maven verticle factory is used.

When I am undeploying a verticle and deploying a newer version (version number changed) of the same verticle, everything works fine.

However when make some changes to the verticle I want to redeploy, but don't change the version, the re-deploy fails. It mentions problems like "my-verticle.json is empty" or malformed json.

The docs mention the following: 

Note that if the current Vert.x classpath contains already an artifact, then this dependency will not be overridden and will be effectively used. Vert.x does not attempt to make some class loading magic, conflicts should be resolved by modifying the Vert.x classpath to not contain this dependency.

I understand that already existing artifacts are re-used. However I have to find a way to redeploy updated verticle, without version update (ie same artifact name). This should be possible, since there is a similar behavior for the SNAPSHOT artifacts.

Any ideas?

[Clement Escoffier]

Hi,

The maven service factory is using an isolation group and its own classloader to resolve an artifact. So releasing this classloader and recreating a new one should work (https://github.com/vert-x3/vertx-maven-service-factory/blob/master/src/main/java/io/vertx/maven/MavenVerticleFactory.java#L159).  However, you also need to remove the artifact from the local maven repository). That’s actually what may be the issue in your case. In case of a non-snapshot artifact, if the artifact exist, it does not attempt to update it.

So in your case, you can try:

* undeploy the verticle, be sure no one reference it anymore

* delete the maven repo artifact you try to update (you may have to also delete the dependencies)

* re-resolve

Clement

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
Visit this group at https://groups.google.com/group/vertx.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/993e2e6a-0d66-480b-80bb-629abd8e0b45%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Konstantinos Liakos]

Hi Clement and thanks for the answer,

* delete the maven repo artifact you try to update (you may have to also delete the dependencies)

Unfortunately this is not an option. I want the logical release and deploy flow to be:

• mvn clean deploy
• Call and endpoint to my manager app that will undeploy the old artifact and deploy the new one

It is not convenient to actually delete files from the local maven repo. Other apps may want to resolve the same artifacts, the time I delete them.

Anyway do you have a hint on how to force a SNAPSHOT-like behaviour for any artifact? It's the same behaviour I want to achieve(update every time), but without actually having the SNAPSHOT name in my artifact.

[Clement Escoffier]

On 14 Nov 2016, at 08:45, Konstantinos Liakos <liakosko...@gmail.com> wrote:

Hi Clement and thanks for the answer,

* delete the maven repo artifact you try to update (you may have to also delete the dependencies)

Unfortunately this is not an option. I want the logical release and deploy flow to be:

• mvn clean deploy
• Call and endpoint to my manager app that will undeploy the old artifact and deploy the new one

It is not convenient to actually delete files from the local maven repo. Other apps may want to resolve the same artifacts, the time I delete them.

Yes, and in this case, if you use hotspot you will SEGFAULT (funny no ?)

Anyway do you have a hint on how to force a SNAPSHOT-like behaviour for any artifact? It's the same behaviour I want to achieve(update every time), but without actually having the SNAPSHOT name in my artifact.

The SNAPSHOT strategy update the file in the local maven repository. It may lead to the same issue as the one you mentioned if someone else is using it while the jar is overridden on the file system.

Clement

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/ee5c8427-2b8e-42ed-85fe-e8e0f0da0b20%40googlegroups.com.

[Konstantinos Liakos]

Yeap, set my artifact to SNAPSHOT version, still the same problem when I try to re-deploy.

java.lang.IllegalArgumentException: my-verticle.json is empty

at io.vertx.service.ServiceVerticleFactory.resolve(ServiceVerticleFactory.java:65)

at io.vertx.maven.MavenVerticleFactory.lambda$resolve$1(MavenVerticleFactory.java:190)

at io.vertx.core.impl.ContextImpl.lambda$executeBlocking$1(ContextImpl.java:259)

at io.vertx.core.impl.OrderedExecutorFactory$OrderedExecutor.lambda$new$0(OrderedExecutorFactory.java:94)

at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)

at java.lang.Thread.run(Thread.java:745)

There must be some workaround though. Bumping the artifact version can't be the only way. I will keep digging into this.

[Konstantinos Liakos]

Found a quite nice solution, but I would like to hear your thoughts.

What if in the isolation group:

deploymentOptions.setIsolationGroup("__vertx_maven_" + coordsString);

we also append the lastModified timestamp? This would create a new isolation group if the artifact is changed, even with the same artifact name!

Moreover we could create a hash from all the dependencies last timestamp, so that even dependencies with changes would produce a new isolation group.

Is there a caveat in the above solution?

[Clement Escoffier]

Hi,

It would work, but it may have unloading issues (leaks). But it depends on how is used the loaded library and how this library uses the rest of the application. So, I believe it would work for development environment quite nicely, if all interactions are loosely-coupled (use JsonObject), but may still suffer from leaks if it exchanged objects from classes packaged in the loaded library. You have a leak when you will get errors like: "me.escoffier.vertx.Data cannot be cast to me.escoffier.vertx.Data”, because the 2 classes are loaded by 2 different classloaders. 

Clement

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
Visit this group at https://groups.google.com/group/vertx.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/bc02fc16-5c00-40e6-be67-1654bd68d8bb%40googlegroups.com.

[Konstantinos Liakos]

But how is this different from what actually happens when an artifact with newer version is loaded?

Both solutions (new artifact version vs last update timestamp) will have the same effect: create a new isolation group, and the classloader will inherit any jars possible from the parent classloader.

Isn't there the same memory leak danger in both cases?

[Clement Escoffier]

On 15 Nov 2016, at 10:07, Konstantinos Liakos <liakosko...@gmail.com> wrote:

But how is this different from what actually happens when an artifact with newer version is loaded?

Both solutions (new artifact version vs last update timestamp) will have the same effect: create a new isolation group, and the classloader will inherit any jars possible from the parent classloader.

Isn't there the same memory leak danger in both cases?

Yes it does. 

However, for snapshot (development version), we considered it “ok” in the sense that it’s just for dev (you should not go to prod with snapshot  dependencies, as your build is not reproducible). 

Clement

On Tuesday, 15 November 2016 10:51:48 UTC+2, clement escoffier wrote:

Hi,

It would work, but it may have unloading issues (leaks). But it depends on how is used the loaded library and how this library uses the rest of the application. So, I believe it would work for development environment quite nicely, if all interactions are loosely-coupled (use JsonObject), but may still suffer from leaks if it exchanged objects from classes packaged in the loaded library. You have a leak when you will get errors like: "me.escoffier.vertx.Data cannot be cast to me.escoffier.vertx.Data”, because the 2 classes are loaded by 2 different classloaders. 

Clement

On 14 Nov 2016, at 10:26, Konstantinos Liakos <liakosko...@gmail.com> wrote:

Found a quite nice solution, but I would like to hear your thoughts.

What if in the isolation group:

deploymentOptions.setIsolationGroup("__vertx_maven_" + coordsString);

we also append the lastModified timestamp? This would create a new isolation group if the artifact is changed, even with the same artifact name!

Moreover we could create a hash from all the dependencies last timestamp, so that even dependencies with changes would produce a new isolation group.

Is there a caveat in the above solution?

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
Visit this group at https://groups.google.com/group/vertx.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/bc02fc16-5c00-40e6-be67-1654bd68d8bb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
Visit this group at https://groups.google.com/group/vertx.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/4dff2d2e-1bc7-4caf-bc23-c19c74c03c9e%40googlegroups.com.

[Konstantinos Liakos]

Wasn't referring to SNAPSHOTS necessarily.

Assume I have a running my-verticle:1.0, I undeploy it and deploy my-verticle:1.1. All these operations are performed from a manager verticle without stopping anything.

Don't you have the same danger of memory leak? Since the background process is again the same (new isolation group and classloader).

I am trying to understand how is it possible to utilize maven-service-factory to hot deploy a new verticle in production without vertx restart.

[Clement Escoffier]

On 15 Nov 2016, at 10:30, Konstantinos Liakos <liakosko...@gmail.com> wrote:

Wasn't referring to SNAPSHOTS necessarily.

Assume I have a running my-verticle:1.0, I undeploy it and deploy my-verticle:1.1. All these operations are performed from a manager verticle without stopping anything.

Don't you have the same danger of memory leak? Since the background process is again the same (new isolation group and classloader).

You do have the same danger. You need to be sure that no-one is referencing a class from the loaded library.

I am trying to understand how is it possible to utilize maven-service-factory to hot deploy a new verticle in production without vertx restart.

Interesting use case. In the past, I used OSGi for this. 

Clement

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/0da5c96f-e653-4e55-88d6-a6450c84452c%40googlegroups.com.

[Konstantinos Liakos]

 

I am trying to understand how is it possible to utilize maven-service-factory to hot deploy a new verticle in production without vertx restart.
Interesting use case. In the past, I used OSGi for this.

And I currently use servlet containers. Drop the war, new version is loaded.

However I want to switch to vertx, but can't find so far a decent solution for hot deploy of new jar.