[
https://issues.apache.org/jira/browse/MNG-7536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17653737#comment-17653737
]
David Elliott commented on MNG-7536:
------------------------------------
Looking at it some more I'm actually _not_ running these in parallel so my code
isn't as broken as I thought.
I only have one thread running the executions sequentially, it's just that it
isn't the original thread running the mojo because the thread running the mojo
is doing something else before ultimately waiting for the secondary thread to
complete.
I think I can reverse things so the other stuff is done on a secondary thread
and the original thread running the mojo runs all the follow-up steps
sequentially, including the mojo executions. This is clearly a more compatible
approach.
Therefore, my opinion doesn't change. The original change was reasonable. You
can close this.
I'll fix my code. It's disappointing for a potential deadlock to be added to a
point release and without clear notice of the circumstances that will lead to
it, but what can we do? Welcome to software engineering. Sometimes well-meant
changes have unforeseen side effects.
> Mojo execution locking in Maven 3.8.5 deadlocks my plugin
> ---------------------------------------------------------
>
> Key: MNG-7536
> URL: https://issues.apache.org/jira/browse/MNG-7536
> Project: Maven
> Issue Type: Bug
> Affects Versions: 3.8.5, 3.8.6
> Reporter: David Elliott
> Assignee: Guillaume Nodet
> Priority: Major
> Fix For: waiting-for-feedback, wontfix-candidate
>
> Attachments: thread-example.tar.gz
>
>
> I have an existing mojo which stopped working in Maven 3.8.5 but had been
> working for years. It looks like MNG-7156 is the cause.
> This mojo looks through its dependencies for other reactor projects, then
> looks at those projects for any plugin executions with a special phase name.
> For all found executions, it executes them in a thread pool as part of some
> other processing it is doing.
> My plugin is proprietary and I am unable to share it, but I am able to share
> a much smaller example illustrating the problem.
> Being example code, it just spawns a thread to run the mojo executions and
> attempts to join the thread. In the real code all executions for a given
> project will run sequentially on one thread, but each project's work will be
> scheduled concurrently on a thread pool.
> I didn't feel it was necessary to use a thread pool and schedule more than
> one project's executions for this example. The deadlock will occur simply by
> running any mojo at all on a secondary thread while the calling thread is
> running a mojo waiting for that secondary thread to complete.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
