Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

0.16.3 and higher block indefinitely when invoking docker:start #586

Closed
josephlbarnett opened this issue Oct 12, 2016 · 6 comments
Closed

Comments

@josephlbarnett
Copy link

We've been using an older version (org.jolokia) of the plugin for a while, and in upgrading to the latest version, noticed that our docker:start invocations would block forever with the stacktrace attached below. 0.16.2 works, but 0.16.3-0.16.7 exhibit this behavior. I suspect it's related to commit 2946205 and also possibly related to the fact that we <link> to docker images that are already started earlier in the build process by other mechanisms (It seems like the plugin may be waiting to start those <link>ed images, but it never will start them?).

"main" #1 prio=5 os_prio=0 tid=0x00007fb77800a000 nid=0x5d1a waiting on condition [0x00007fb77f7b3000]
   java.lang.Thread.State: WAITING (parking)
    at sun.misc.Unsafe.park(Native Method)
    - parking to wait for  <0x000000077067bc50> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
    at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
    at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
    at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
    at java.util.concurrent.ExecutorCompletionService.take(ExecutorCompletionService.java:193)
    at io.fabric8.maven.docker.StartMojo.executeInternal(StartMojo.java:188)
    - locked <0x000000076ddd1598> (a io.fabric8.maven.docker.StartMojo)
    at io.fabric8.maven.docker.AbstractDockerMojo.execute(AbstractDockerMojo.java:193)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
    at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
    at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
    at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
    at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
    at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
    at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
    at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
@hwellmann
Copy link
Contributor

I'm seeing the same problem with the same thread dump using 0.16.7 in a fairly complex setup, so unfortunately I cannot provide a self-contained example.

rhuss added a commit that referenced this issue Oct 14, 2016
External container ids should not be wait for.
@rhuss
Copy link
Collaborator

rhuss commented Oct 14, 2016

@jbarnettwomply @hwellmann yeah, your are right. Links which refer plain container-names / ids are added naively to the list of dependencies. I filter these out now.

I just released a 0.16-SNAPSHOT. If you could give it a try that would be awesome and if it fixes the problem I can do 0.16.8 short after.

@hwellmann
Copy link
Contributor

I'm not sure where you publish the snapshots, so I built the integration branch locally - I hope that's the correct one. With that version the problem appears to be fixed.

Thanks for the quick feedback! Release 0.16.8 would be much appreciated...

@rhuss
Copy link
Collaborator

rhuss commented Oct 14, 2016

@hwellmann ah, perfect. will do a 0.16.8 this evening.

The snapshot is in the Maven snapshot repo, you would need to add

<repository>
    <id>apache.snapshots</id>
    <name>Apache Development Snapshot Repository</name>
    <url>https://repository.apache.org/content/repositories/snapshots/</url>
    <releases>
        <enabled>false</enabled>
    </releases>
    <snapshots>
        <enabled>true</enabled>
    </snapshots>
</repository>

to your pom.xml

@josephlbarnett
Copy link
Author

confirmed it works for me as well. thanks for the quick turnaround!

rhuss added a commit that referenced this issue Oct 14, 2016
External container ids should not be wait for.
@rhuss
Copy link
Collaborator

rhuss commented Oct 14, 2016

0.16.8 has just been released, waiting to bubble up to Maven central (should be there in less than an hour).

Thanks again for reporting and analysing the issue !

@rhuss rhuss closed this as completed Oct 14, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants