You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Kristian Rosenvold <kr...@gmail.com> on 2010/04/26 00:08:33 UTC
Concurrency in m3 - a status report
Now that the first Jira issue has arrived on parallel maven, I think
it's time I do a little summary of how things are ATM. For those of you
that don't routinely hang around at #maven-dev on irc:
I have found and fixed a series of insidious concurrency problems in
several plexus components (thanks a million Benjamin for all help with
discussing & patching those!)
The issues were:
http://jira.codehaus.org/browse/MNG-4632
http://jira.codehaus.org/browse/PLXUTILS-130
http://jira.codehaus.org/browse/PLXCOMP-149
The last two of these issues affect linear-maven-2.2.1 too and can be
the cause of deadlocks (in numerous plugins) and data
corruption/deadlock/other interesting behaviour in the jar/war/ear/?ar
plugins.
plexus-utils (2.0.5), plexus-io (1.0) and plexus-archiver (1.0) are the
required dependencies to stay clear. I will file issues on the affected
plugins/modules RSN.
Both parallel mode and weave mode now work stunningly well, and all my
test builds are green (or otherwise accounted for). I have one last
minor update on weave that's running the tests now, and I'm targetting
http://jira.codehaus.org/browse/MNG-4633 for beta-2.
All of Arnaud's projects that I was able to build with regular m3 on
java 6 also build with parallel m3 now.
The CI running the tests can be seen here; and it's quite interesting.
I'll leave it to the reader to spot the 6-core i7 980X vs the C2D 2.5
Ghz in those graphs ;)
Weave mode: http://rosenvold.dyndns.org:8085/browse/PARALLEL-CH1W
PArallel: http://rosenvold.dyndns.org:8085/browse/PARALLEL-CH1
m3 weave: http://rosenvold.dyndns.org:8085/browse/PARALLEL-M31W
m3 parallel: http://rosenvold.dyndns.org:8085/browse/PARALLEL-M31
This CI has now run 40.000 parallel builds (most of which are
non-public) and all errors are accounted for. Those of you surfing
around a little more will see a couple of disabled builds, which also
has known causes.
Plugins
=========
I have only managed to find "real" concurrency problems in the EAR
plugin and modello as of yet. Modello is fixed in trunk, ear is
not started AFIK.
All the other stuff I've seen in the core plugins relate to the
plexus-issues.
Our jira issue is from a user who's complaining about plugins not
working, and I think he's somewhat right in that we have to make some
kind of system to indicate compatibility with the -T option.
Although several strategies may be recommended, my personal favourite
is to make a @threadsafe javadoc annotation and make M3 core
COMPLAIN LOUDLY about plugins that are unmarked, then proceed as
requested (i.e. complain but still run threaded).
The problem with these things is that thread safety is not necessarily a
constant, and in the next 9 months there will be issues. So for some
plugins @threadsafe might equally much express an intent as much as it
reflects reality. So that makes me a bit sceptical to @threadsafe too.
Aggressively displaying the link to the wiki page containing the
most up-todate threading info may be an equally good solution; maybe
even adding a WARNING: Experimental or something to the build output.
http://cwiki.apache.org/confluence/display/MAVEN/Parallel+builds+in
+Maven+3 (if it's up), should contain all the information needed on
which plugins are known to have issues. But as we all know, it's an open
ecosystem.
Documentation
============
I will keep the wiki page updated, provided cwiki.a.o actually stays
up ;)
I will add a section on mojo threading models/threading concerns to the
mojo api specification.
I think we have to take some extra measures to keep users out of the
issue trackers on this one, or at least make sure they go to the right
place.
What do you think ?
Kristian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Concurrency in m3 - a status report
Posted by Stephen Connolly <st...@gmail.com>.
I agree that a @NotThreadSafe annotation is the best way to go.
On 26 April 2010 09:13, nicolas de loof <ni...@gmail.com> wrote:
> >
> > Plugins
> > =========
> > I have only managed to find "real" concurrency problems in the EAR
> > plugin and modello as of yet. Modello is fixed in trunk, ear is
> > not started AFIK.
> >
> > All the other stuff I've seen in the core plugins relate to the
> > plexus-issues.
> >
> > Our jira issue is from a user who's complaining about plugins not
> > working, and I think he's somewhat right in that we have to make some
> > kind of system to indicate compatibility with the -T option.
> >
> > Although several strategies may be recommended, my personal favourite
> > is to make a @threadsafe javadoc annotation and make M3 core
> > COMPLAIN LOUDLY about plugins that are unmarked, then proceed as
> > requested (i.e. complain but still run threaded).
> >
> > The problem with these things is that thread safety is not necessarily a
> > constant, and in the next 9 months there will be issues. So for some
> > plugins @threadsafe might equally much express an intent as much as it
> > reflects reality. So that makes me a bit sceptical to @threadsafe too.
> >
> >
> +1, I can't see any way to ENSURE a plugin is threadsafe as it depends on
> project and (maybe overriden) plugin dependencies. We can just tag a
> plugin
> to be expected to work fine in multithreaded context
>
> I'd suggest to get a @NotThreadSafe annotation for plugins that are KNOWN
> to
> not be thread safe, mostly due ti the embedded tools. I got
> ConcurrentModification issues with aspectJ plugin, so I don't think any
> AJC-based plugin could work fine with // build.
>
> I don't know the way the weave mode is expected to work, but it could maybe
> support such @NotThreadSafe plugins by locking concurrent execution of the
> same plugin, but still runing other ones/othe phases in // modules.
>
>
>
> > Aggressively displaying the link to the wiki page containing the
> > most up-todate threading info may be an equally good solution; maybe
> > even adding a WARNING: Experimental or something to the build output.
> >
>
> +1
> As we can't make the world thread safe, let the user know what's possible
> and how to tweak the build.
>
>
> >
> >
> > http://cwiki.apache.org/confluence/display/MAVEN/Parallel+builds+in
> > +Maven+3 (if it's up), should contain all the information needed on
> > which plugins are known to have issues. But as we all know, it's an open
> > ecosystem.
> >
> > Documentation
> > ============
> > I will keep the wiki page updated, provided cwiki.a.o actually stays
> > up ;)
> > I will add a section on mojo threading models/threading concerns to the
> > mojo api specification.
> >
> >
> > I think we have to take some extra measures to keep users out of the
> > issue trackers on this one, or at least make sure they go to the right
> > place.
> >
> > What do you think ?
> >
> > Kristian
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
Re: Concurrency in m3 - a status report
Posted by Stephen Connolly <st...@gmail.com>.
On 26 April 2010 13:40, Jason van Zyl <ja...@sonatype.com> wrote:
> On Apr 26, 2010, at 7:05 AM, Benjamin Bentmann wrote:
>
> > Stephen Connolly wrote:
> >
> >> ... but each release of m3
> >> would have it's own compatibility info and we would have another state:
> >> unknown
> >>
> >> e.g.
> >>
> >> <thread-safety>
> >> <plugin groupId="..." artifactId="...">
> >> <wieve-mode action="ban" versions="...">message</wieve-mode>
> >> <wieve-mode action="warn" versions="...">message</wieve-mode>
> >> <wieve-mode action="checked" versions="..."/>
> >> <parallel-mode action="ban" versions="...">message</paralle-mode>
> >> <parallel-mode action="warn" versions="...">message</paralle-mode>
> >> <parallel-mode action="checked"
> versions="...">message</paralle-mode>
> >> </plugin>
> >> </thread-safety>
> >>
> >> Any plugins not in the list would be "unknown" and the user gets a big
> fat
> >> warning
> >
> > Did you also consider the maintainability aspect of such a list? No user
> wants to see "big fat warnings" that are irrelevant for their builds so I
> envision users will either bug the plugin author or us directly to add
> plugin X to this list and ask us to roll a new release of this list such
> that they get rid of that warning.
> >
> > Plugins should be self-describing, that's why mojo annotations and the
> plugin descriptor exists. I definitively don't want to see us maintaining
> the metadata for 3rd party plugins.
> >
> > For this reason, I prefer the original suggestion to introduce a new mojo
> annotation. Apparently, whatever mojo annotation we come up with, it's not
> present in any existing plugin release. Now, for plugins missing the
> threading anno, what is the safer assumption with respect to proper build
> results: That mojo X is thread-safe (when this was never before a concern)
> or that it isn't?
> >
> > IMHO, there's only way to limit this "oh, I deliberately enabled nitro
> injection and now my engine blew up, how am I supposed to know that this is
> dangerous?": Unless a mojo is explicitly marked with @threadsafe, issue a
> warning like
> >
>
> Right. It's pretty simple. If the author has worked on and tested then they
> can mark the mojo as such. Otherwise the mojo gets no benefit from the
> parallel mode.
>
> A @nothreadsafe annotation makes no sense. We're going to go around and
> mark everyone else's mojos? That's not going to work and neither is
> maintaining third party information. If we start the process of adding the
> annotation we can easily get the basic mojos in the default lifecycle
> annotated accordingly. If we deem this a requirement for the 3.0 release
> then we'll work on plugins for a little while before releasing 3.0.
>
>
This is not an @nothreadsafe annotation I was suggesting, but a @noparallel
annotation
i.e. for the plugin author to mark a mojo as specifically banning parallel
execution
-Stephen
> > "Goal X does not appear to support concurrent execution and might fail
> the build, use parallel building at your own risk."
> >
> >
> > Benjamin
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> ----------------------------------------------------------
>
>
Re: Concurrency in m3 - a status report
Posted by Jason van Zyl <ja...@sonatype.com>.
On Apr 26, 2010, at 9:09 AM, Kristian Rosenvold wrote:
> Den 26.04.2010 14:40, skrev Jason van Zyl:
>> On Apr 26, 2010, at 7:05 AM, Benjamin Bentmann wrote:
>>
>>> IMHO, there's only way to limit this "oh, I deliberately enabled nitro injection and now my engine blew up, how am I supposed to know that this is dangerous?": Unless a mojo is explicitly marked with @threadsafe, issue a warning like
>>>
> LOL. I think you're right. Enable nitro injection, you get warnings for any plugin not marked @threadsafe. If the build fails too you get an additional warning at the end that
> you're running on your own, please go see our marvellous wiki site.
>
>
>> Right. It's pretty simple. If the author has worked on and tested then they can mark the mojo as such. Otherwise the mojo gets no benefit from the parallel mode.
>>
>> A @nothreadsafe annotation makes no sense. We're going to go around and mark everyone else's mojos? That's not going to work and neither is maintaining third party information. If we start the process of adding the annotation we can easily get the basic mojos in the default lifecycle annotated accordingly. If we deem this a requirement for the 3.0 release then we'll work on plugins for a little while before releasing 3.0.
>>
>
> @notthreadsafe/@noparallel makes only marginal sense, since you'd achieve the intended effect by sunchronizing execute.
> But on the other hand I suppose a thread-reluctant mojo would end up with a "@threadsafe" annotation and
> a synchronized execute method. But it shows that threading has been considered, which is fine with me.
>
> I think an important issue to settle is if the annotations should have any impact on run-time behaviour (other than complaining...)
> I somewhat dislike the idea of only running mojos marked with @threadsafe concurrently; it also decreases overall performance and increases risks of
> deadlocks in weave mode significantly. And you're only getting parallel-mode because you asked for it, right ?
>
> So my 2cents are: Add @threadsafe annotation, complain loudly about executions missing annotations but proceed as requested. Increases community motivation to make plugins thread-safe.
> This solution would allow future extensions if required.
>
We have until 3.0 is out and we can push out the release date if we need to do some mojo housecleaning first. Nothing dire.
>
> Kristian
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------
Re: Concurrency in m3 - a status report
Posted by Kristian Rosenvold <kr...@gmail.com>.
Den 26.04.2010 14:40, skrev Jason van Zyl:
> On Apr 26, 2010, at 7:05 AM, Benjamin Bentmann wrote:
>
>> IMHO, there's only way to limit this "oh, I deliberately enabled nitro injection and now my engine blew up, how am I supposed to know that this is dangerous?": Unless a mojo is explicitly marked with @threadsafe, issue a warning like
>>
LOL. I think you're right. Enable nitro injection, you get warnings for
any plugin not marked @threadsafe. If the build fails too you get an
additional warning at the end that
you're running on your own, please go see our marvellous wiki site.
> Right. It's pretty simple. If the author has worked on and tested then they can mark the mojo as such. Otherwise the mojo gets no benefit from the parallel mode.
>
> A @nothreadsafe annotation makes no sense. We're going to go around and mark everyone else's mojos? That's not going to work and neither is maintaining third party information. If we start the process of adding the annotation we can easily get the basic mojos in the default lifecycle annotated accordingly. If we deem this a requirement for the 3.0 release then we'll work on plugins for a little while before releasing 3.0.
>
@notthreadsafe/@noparallel makes only marginal sense, since you'd
achieve the intended effect by sunchronizing execute.
But on the other hand I suppose a thread-reluctant mojo would end up
with a "@threadsafe" annotation and
a synchronized execute method. But it shows that threading has been
considered, which is fine with me.
I think an important issue to settle is if the annotations should have
any impact on run-time behaviour (other than complaining...)
I somewhat dislike the idea of only running mojos marked with
@threadsafe concurrently; it also decreases overall performance and
increases risks of
deadlocks in weave mode significantly. And you're only getting
parallel-mode because you asked for it, right ?
So my 2cents are: Add @threadsafe annotation, complain loudly about
executions missing annotations but proceed as requested. Increases
community motivation to make plugins thread-safe.
This solution would allow future extensions if required.
Kristian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Concurrency in m3 - a status report
Posted by Jason van Zyl <ja...@sonatype.com>.
On Apr 26, 2010, at 7:05 AM, Benjamin Bentmann wrote:
> Stephen Connolly wrote:
>
>> ... but each release of m3
>> would have it's own compatibility info and we would have another state:
>> unknown
>>
>> e.g.
>>
>> <thread-safety>
>> <plugin groupId="..." artifactId="...">
>> <wieve-mode action="ban" versions="...">message</wieve-mode>
>> <wieve-mode action="warn" versions="...">message</wieve-mode>
>> <wieve-mode action="checked" versions="..."/>
>> <parallel-mode action="ban" versions="...">message</paralle-mode>
>> <parallel-mode action="warn" versions="...">message</paralle-mode>
>> <parallel-mode action="checked" versions="...">message</paralle-mode>
>> </plugin>
>> </thread-safety>
>>
>> Any plugins not in the list would be "unknown" and the user gets a big fat
>> warning
>
> Did you also consider the maintainability aspect of such a list? No user wants to see "big fat warnings" that are irrelevant for their builds so I envision users will either bug the plugin author or us directly to add plugin X to this list and ask us to roll a new release of this list such that they get rid of that warning.
>
> Plugins should be self-describing, that's why mojo annotations and the plugin descriptor exists. I definitively don't want to see us maintaining the metadata for 3rd party plugins.
>
> For this reason, I prefer the original suggestion to introduce a new mojo annotation. Apparently, whatever mojo annotation we come up with, it's not present in any existing plugin release. Now, for plugins missing the threading anno, what is the safer assumption with respect to proper build results: That mojo X is thread-safe (when this was never before a concern) or that it isn't?
>
> IMHO, there's only way to limit this "oh, I deliberately enabled nitro injection and now my engine blew up, how am I supposed to know that this is dangerous?": Unless a mojo is explicitly marked with @threadsafe, issue a warning like
>
Right. It's pretty simple. If the author has worked on and tested then they can mark the mojo as such. Otherwise the mojo gets no benefit from the parallel mode.
A @nothreadsafe annotation makes no sense. We're going to go around and mark everyone else's mojos? That's not going to work and neither is maintaining third party information. If we start the process of adding the annotation we can easily get the basic mojos in the default lifecycle annotated accordingly. If we deem this a requirement for the 3.0 release then we'll work on plugins for a little while before releasing 3.0.
> "Goal X does not appear to support concurrent execution and might fail the build, use parallel building at your own risk."
>
>
> Benjamin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------
Re: Concurrency in m3 - a status report
Posted by nicolas de loof <ni...@gmail.com>.
What about adding such concurrency metadata aside plugin artifact in local
repository, either by extending metadata.xml or using a new
concurrency-metadata.xml file ?
In such case users/repo maintainers could easily "tag" plugin as (not)
beeing thread-safe
2010/4/26 Stephen Connolly <st...@gmail.com>
> On 26 April 2010 12:05, Benjamin Bentmann <be...@udo.edu>
> wrote:
>
> > Stephen Connolly wrote:
> >
> > ... but each release of m3
> >> would have it's own compatibility info and we would have another state:
> >> unknown
> >>
> >> e.g.
> >>
> >> <thread-safety>
> >> <plugin groupId="..." artifactId="...">
> >> <wieve-mode action="ban" versions="...">message</wieve-mode>
> >> <wieve-mode action="warn" versions="...">message</wieve-mode>
> >> <wieve-mode action="checked" versions="..."/>
> >> <parallel-mode action="ban" versions="...">message</paralle-mode>
> >> <parallel-mode action="warn" versions="...">message</paralle-mode>
> >> <parallel-mode action="checked"
> versions="...">message</paralle-mode>
> >> </plugin>
> >> </thread-safety>
> >>
> >> Any plugins not in the list would be "unknown" and the user gets a big
> fat
> >> warning
> >>
> >
> > Did you also consider the maintainability aspect of such a list? No user
> > wants to see "big fat warnings" that are irrelevant for their builds so I
> > envision users will either bug the plugin author or us directly to add
> > plugin X to this list and ask us to roll a new release of this list such
> > that they get rid of that warning.
> >
> > Plugins should be self-describing, that's why mojo annotations and the
> > plugin descriptor exists. I definitively don't want to see us maintaining
> > the metadata for 3rd party plugins.
> >
> > For this reason, I prefer the original suggestion to introduce a new mojo
> > annotation. Apparently, whatever mojo annotation we come up with, it's
> not
> > present in any existing plugin release. Now, for plugins missing the
> > threading anno, what is the safer assumption with respect to proper build
> > results: That mojo X is thread-safe (when this was never before a
> concern)
> > or that it isn't?
> >
> > IMHO, there's only way to limit this "oh, I deliberately enabled nitro
> > injection and now my engine blew up, how am I supposed to know that this
> is
> > dangerous?": Unless a mojo is explicitly marked with @threadsafe, issue a
> > warning like
> >
> > "Goal X does not appear to support concurrent execution and might fail
> the
> > build, use parallel building at your own risk."
> >
> >
> Fair enough, but I would also like to be able to annotate a mojo such that
> I
> explicitly don't want it invoked in parallel and not warn the user (perhaps
> explain to the user why certain mojos cannot be executed in parallel)
>
> -Stephen
>
>
> >
> > Benjamin
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
Re: Concurrency in m3 - a status report
Posted by Stephen Connolly <st...@gmail.com>.
On 26 April 2010 12:05, Benjamin Bentmann <be...@udo.edu> wrote:
> Stephen Connolly wrote:
>
> ... but each release of m3
>> would have it's own compatibility info and we would have another state:
>> unknown
>>
>> e.g.
>>
>> <thread-safety>
>> <plugin groupId="..." artifactId="...">
>> <wieve-mode action="ban" versions="...">message</wieve-mode>
>> <wieve-mode action="warn" versions="...">message</wieve-mode>
>> <wieve-mode action="checked" versions="..."/>
>> <parallel-mode action="ban" versions="...">message</paralle-mode>
>> <parallel-mode action="warn" versions="...">message</paralle-mode>
>> <parallel-mode action="checked" versions="...">message</paralle-mode>
>> </plugin>
>> </thread-safety>
>>
>> Any plugins not in the list would be "unknown" and the user gets a big fat
>> warning
>>
>
> Did you also consider the maintainability aspect of such a list? No user
> wants to see "big fat warnings" that are irrelevant for their builds so I
> envision users will either bug the plugin author or us directly to add
> plugin X to this list and ask us to roll a new release of this list such
> that they get rid of that warning.
>
> Plugins should be self-describing, that's why mojo annotations and the
> plugin descriptor exists. I definitively don't want to see us maintaining
> the metadata for 3rd party plugins.
>
> For this reason, I prefer the original suggestion to introduce a new mojo
> annotation. Apparently, whatever mojo annotation we come up with, it's not
> present in any existing plugin release. Now, for plugins missing the
> threading anno, what is the safer assumption with respect to proper build
> results: That mojo X is thread-safe (when this was never before a concern)
> or that it isn't?
>
> IMHO, there's only way to limit this "oh, I deliberately enabled nitro
> injection and now my engine blew up, how am I supposed to know that this is
> dangerous?": Unless a mojo is explicitly marked with @threadsafe, issue a
> warning like
>
> "Goal X does not appear to support concurrent execution and might fail the
> build, use parallel building at your own risk."
>
>
Fair enough, but I would also like to be able to annotate a mojo such that I
explicitly don't want it invoked in parallel and not warn the user (perhaps
explain to the user why certain mojos cannot be executed in parallel)
-Stephen
>
> Benjamin
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Concurrency in m3 - a status report
Posted by Benjamin Bentmann <be...@udo.edu>.
Stephen Connolly wrote:
> ... but each release of m3
> would have it's own compatibility info and we would have another state:
> unknown
>
> e.g.
>
> <thread-safety>
> <plugin groupId="..." artifactId="...">
> <wieve-mode action="ban" versions="...">message</wieve-mode>
> <wieve-mode action="warn" versions="...">message</wieve-mode>
> <wieve-mode action="checked" versions="..."/>
> <parallel-mode action="ban" versions="...">message</paralle-mode>
> <parallel-mode action="warn" versions="...">message</paralle-mode>
> <parallel-mode action="checked" versions="...">message</paralle-mode>
> </plugin>
> </thread-safety>
>
> Any plugins not in the list would be "unknown" and the user gets a big fat
> warning
Did you also consider the maintainability aspect of such a list? No user
wants to see "big fat warnings" that are irrelevant for their builds so
I envision users will either bug the plugin author or us directly to add
plugin X to this list and ask us to roll a new release of this list such
that they get rid of that warning.
Plugins should be self-describing, that's why mojo annotations and the
plugin descriptor exists. I definitively don't want to see us
maintaining the metadata for 3rd party plugins.
For this reason, I prefer the original suggestion to introduce a new
mojo annotation. Apparently, whatever mojo annotation we come up with,
it's not present in any existing plugin release. Now, for plugins
missing the threading anno, what is the safer assumption with respect to
proper build results: That mojo X is thread-safe (when this was never
before a concern) or that it isn't?
IMHO, there's only way to limit this "oh, I deliberately enabled nitro
injection and now my engine blew up, how am I supposed to know that this
is dangerous?": Unless a mojo is explicitly marked with @threadsafe,
issue a warning like
"Goal X does not appear to support concurrent execution and might fail
the build, use parallel building at your own risk."
Benjamin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Concurrency in m3 - a status report
Posted by Stephen Connolly <st...@gmail.com>.
Which implies that it should be a versioned file....
Sounds like a jar with a resource containing the parallel compatibility
info....
We'd have to maintain it versioned.... and perhaps provide some system
property to ovrerride the version via settings.xml... but each release of m3
would have it's own compatibility info and we would have another state:
unknown
e.g.
<thread-safety>
<plugin groupId="..." artifactId="...">
<wieve-mode action="ban" versions="...">message</wieve-mode>
<wieve-mode action="warn" versions="...">message</wieve-mode>
<wieve-mode action="checked" versions="..."/>
<parallel-mode action="ban" versions="...">message</paralle-mode>
<parallel-mode action="warn" versions="...">message</paralle-mode>
<parallel-mode action="checked" versions="...">message</paralle-mode>
</plugin>
</thread-safety>
Any plugins not in the list would be "unknown" and the user gets a big fat
warning
-Stephen
On 26 April 2010 10:15, nicolas de loof <ni...@gmail.com> wrote:
> >
> >
> > The issue is http://jira.codehaus.org/browse/MNG-4642, and as an
> > alternative solution we could
> > simply make a list somewhere that blacklists/whitelists/greylists
> plugins,
> > as long as there's a reasonable
> > way to update such a list. Maybe something enforcer-like;
> >
> > org.codehaus.plexus:plexus-io:[,1.0), BAN:"Serious compromises of thread
> > integrity"
> > org.apache.maven:plugins:maven-era-plugin:*:WARN:"Can only run once per
> > reactor"
> > org.codehaus.modell:modello-maven-plugin:(,1.3]:BAN:"Does not work
> -period"
> >
> > If there was some place we could put such a list and update it we could
> > probably provide the best
> > possible information. How could we do this ?
> >
> >
> We could maintain such compatibility matrix using a wiki page, but - to be
> usable from the build by various enforcer/check plugins - it should be
> deployed on central / downloaded to local repository in some
> computer-compliant format.
>
Re: Concurrency in m3 - a status report
Posted by nicolas de loof <ni...@gmail.com>.
>
>
> The issue is http://jira.codehaus.org/browse/MNG-4642, and as an
> alternative solution we could
> simply make a list somewhere that blacklists/whitelists/greylists plugins,
> as long as there's a reasonable
> way to update such a list. Maybe something enforcer-like;
>
> org.codehaus.plexus:plexus-io:[,1.0), BAN:"Serious compromises of thread
> integrity"
> org.apache.maven:plugins:maven-era-plugin:*:WARN:"Can only run once per
> reactor"
> org.codehaus.modell:modello-maven-plugin:(,1.3]:BAN:"Does not work -period"
>
> If there was some place we could put such a list and update it we could
> probably provide the best
> possible information. How could we do this ?
>
>
We could maintain such compatibility matrix using a wiki page, but - to be
usable from the build by various enforcer/check plugins - it should be
deployed on central / downloaded to local repository in some
computer-compliant format.
Re: Concurrency in m3 - a status report
Posted by Kristian Rosenvold <kr...@gmail.com>.
Den 26.04.2010 10:13, skrev nicolas de loof:
>> The problem with these things is that thread safety is not necessarily a
>> constant, and in the next 9 months there will be issues. So for some
>> plugins @threadsafe might equally much express an intent as much as it
>> reflects reality. So that makes me a bit sceptical to @threadsafe too.
>>
>>
>>
> +1, I can't see any way to ENSURE a plugin is threadsafe as it depends on
> project and (maybe overriden) plugin dependencies. We can just tag a plugin
> to be expected to work fine in multithreaded context
>
The issue is http://jira.codehaus.org/browse/MNG-4642, and as an
alternative solution we could
simply make a list somewhere that blacklists/whitelists/greylists
plugins, as long as there's a reasonable
way to update such a list. Maybe something enforcer-like;
org.codehaus.plexus:plexus-io:[,1.0), BAN:"Serious compromises of thread
integrity"
org.apache.maven:plugins:maven-era-plugin:*:WARN:"Can only run once per
reactor"
org.codehaus.modell:modello-maven-plugin:(,1.3]:BAN:"Does not work -period"
If there was some place we could put such a list and update it we could
probably provide the best
possible information. How could we do this ?
>not be thread safe, mostly due ti the embedded tools. I got
>ConcurrentModification issues with aspectJ plugin, so I don't think any
>AJC-based plugin could work fine with // build.
I don't mean to be disrespectful of aspectj, but from what I've seen of
the code wrt thread
safety I think the appropriate solution is to syncrhonize the execute
method of all aspectj-related
mojos. This is basically the same as @NotThreadSafe
> I don't know the way the weave mode is expected to work, but it could maybe
> support such @NotThreadSafe plugins by locking concurrent execution of the
> same plugin, but still runing other ones/othe phases in // modules.
>
>
>
Oh we can do all sorts of weird and wonderful magics ;) The trick is not
to deadlock the build - I /think/ it
should be ok but it's not the first thing I would like to do.
I will update m3 to add more warnings and possibly also update the link
to the wiki page when builds fail in
parallel build mode. Ok to put a wiki link in release binaries ?
Kristian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Concurrency in m3 - a status report
Posted by nicolas de loof <ni...@gmail.com>.
>
> Plugins
> =========
> I have only managed to find "real" concurrency problems in the EAR
> plugin and modello as of yet. Modello is fixed in trunk, ear is
> not started AFIK.
>
> All the other stuff I've seen in the core plugins relate to the
> plexus-issues.
>
> Our jira issue is from a user who's complaining about plugins not
> working, and I think he's somewhat right in that we have to make some
> kind of system to indicate compatibility with the -T option.
>
> Although several strategies may be recommended, my personal favourite
> is to make a @threadsafe javadoc annotation and make M3 core
> COMPLAIN LOUDLY about plugins that are unmarked, then proceed as
> requested (i.e. complain but still run threaded).
>
> The problem with these things is that thread safety is not necessarily a
> constant, and in the next 9 months there will be issues. So for some
> plugins @threadsafe might equally much express an intent as much as it
> reflects reality. So that makes me a bit sceptical to @threadsafe too.
>
>
+1, I can't see any way to ENSURE a plugin is threadsafe as it depends on
project and (maybe overriden) plugin dependencies. We can just tag a plugin
to be expected to work fine in multithreaded context
I'd suggest to get a @NotThreadSafe annotation for plugins that are KNOWN to
not be thread safe, mostly due ti the embedded tools. I got
ConcurrentModification issues with aspectJ plugin, so I don't think any
AJC-based plugin could work fine with // build.
I don't know the way the weave mode is expected to work, but it could maybe
support such @NotThreadSafe plugins by locking concurrent execution of the
same plugin, but still runing other ones/othe phases in // modules.
> Aggressively displaying the link to the wiki page containing the
> most up-todate threading info may be an equally good solution; maybe
> even adding a WARNING: Experimental or something to the build output.
>
+1
As we can't make the world thread safe, let the user know what's possible
and how to tweak the build.
>
>
> http://cwiki.apache.org/confluence/display/MAVEN/Parallel+builds+in
> +Maven+3 (if it's up), should contain all the information needed on
> which plugins are known to have issues. But as we all know, it's an open
> ecosystem.
>
> Documentation
> ============
> I will keep the wiki page updated, provided cwiki.a.o actually stays
> up ;)
> I will add a section on mojo threading models/threading concerns to the
> mojo api specification.
>
>
> I think we have to take some extra measures to keep users out of the
> issue trackers on this one, or at least make sure they go to the right
> place.
>
> What do you think ?
>
> Kristian
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Concurrency in m3 - a status report - performance
Posted by Kristian Rosenvold <kr...@gmail.com>.
Den 26.04.2010 04:02, skrev Igor Fedorenko:
> I am sorry if this has been answered already, but do you have any info
> that shows performance comparison single vs milti threaded build? If you
> happen to have any profiler snapshots that show where time is spent
> during single and multi threaded builds, I am interested to see these
> too.
>
> PS: we got first // build question on tycho-users list last week ;-)
Interesting question; and the answer is not /always/ as clear cut as one
would think.
Regarding overall performance I added another linear build for comparison.
This is not a particuarly good showcase project, but such is life:
Linear: http://rosenvold.dyndns.org:8085/browse/PARALLEL-CH (~36-37
seconds)
Parallel: http://rosenvold.dyndns.org:8085/browse/PARALLEL-CH1 (~34-35
seconds)
http://rosenvold.dyndns.org:8085/browse/PARALLEL-CH1W (~29-30 seconds)
Remember it's a build cluster with one C2D and one i7-980X, so the
tall columns are the C2D. There's a third node being added any day now
(i7 920).
Please remember that this build cluster is heavily loaded, also with
non-public jobs - so per build variantions can be significant.
Unfortunately bamboo's average build time calculation does not produce
reliable results in a cluster with very different nodes, so this is just
my estimate:
The topology of your build is the most important factor governing parallel
performance. Weave mode is less sensitive to this. Both parallel modes
are sensitive to indidivudal mojo executions being slow, and it effects
the overall build.
If your build process ends up creating a 500mb EAR file, it'll tend to
marginalize
effects of a few modules running in parallel here & there. Weave mode
does a real good
job with projects that have tasks evenly distributed across modules (as
opposed to
all the real work happening in just a few specific mojo executions in
one or two modules).
Surefire in test-phase is not phase-locked to the upstream test phases
in weave mode
(Haven't done this for it-phase yet). Parallel is not always faster than
linear, weave
is always fastest.
Focus up to now has been on achieving stability and functionality, and
for the next month
or so making all mojos work reliably will be my top priority. Regarding
performance
I have not really investigated too much yet, but I will ;)
I have a short list of things I want to investigate:
- According to "strace", File.exists() is being called twice for all
access to any
file in the local repository (affects all modes)
- I am almost sure there's one or more synchronization points somewhere
within surefire
that is reducing surefire performance needlessly.
Only the first issue is within core, and my gut feeling is that not much
more performance
will be tweaked out of the core unless one manages to re-think at a
higher level an even
smarter way of executing mojos and respecting dependencies. Someone
please prove
me wrong, but I think the remaining performance will have to be found in
the
plugins/libraries - and it will be found.
I have run serveral profiler tests, but I'm mostly studying threading
effects currently.
Most of the stuff I've seen is "as expected", and only a small
percentage of execution
happens within core (and a fair size of that is related to xml parsing,
surprise...)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Concurrency in m3 - a status report
Posted by Igor Fedorenko <ig...@ifedorenko.com>.
I am sorry if this has been answered already, but do you have any info
that shows performance comparison single vs milti threaded build? If you
happen to have any profiler snapshots that show where time is spent
during single and multi threaded builds, I am interested to see these too.
PS: we got first // build question on tycho-users list last week ;-)
--
Regards,
Igor
Kristian Rosenvold wrote:
> Now that the first Jira issue has arrived on parallel maven, I think
> it's time I do a little summary of how things are ATM. For those of you
> that don't routinely hang around at #maven-dev on irc:
>
> I have found and fixed a series of insidious concurrency problems in
> several plexus components (thanks a million Benjamin for all help with
> discussing & patching those!)
>
> The issues were:
> http://jira.codehaus.org/browse/MNG-4632
> http://jira.codehaus.org/browse/PLXUTILS-130
> http://jira.codehaus.org/browse/PLXCOMP-149
>
> The last two of these issues affect linear-maven-2.2.1 too and can be
> the cause of deadlocks (in numerous plugins) and data
> corruption/deadlock/other interesting behaviour in the jar/war/ear/?ar
> plugins.
>
> plexus-utils (2.0.5), plexus-io (1.0) and plexus-archiver (1.0) are the
> required dependencies to stay clear. I will file issues on the affected
> plugins/modules RSN.
>
> Both parallel mode and weave mode now work stunningly well, and all my
> test builds are green (or otherwise accounted for). I have one last
> minor update on weave that's running the tests now, and I'm targetting
> http://jira.codehaus.org/browse/MNG-4633 for beta-2.
>
> All of Arnaud's projects that I was able to build with regular m3 on
> java 6 also build with parallel m3 now.
>
> The CI running the tests can be seen here; and it's quite interesting.
> I'll leave it to the reader to spot the 6-core i7 980X vs the C2D 2.5
> Ghz in those graphs ;)
>
>
> Weave mode: http://rosenvold.dyndns.org:8085/browse/PARALLEL-CH1W
> PArallel: http://rosenvold.dyndns.org:8085/browse/PARALLEL-CH1
>
> m3 weave: http://rosenvold.dyndns.org:8085/browse/PARALLEL-M31W
> m3 parallel: http://rosenvold.dyndns.org:8085/browse/PARALLEL-M31
>
>
> This CI has now run 40.000 parallel builds (most of which are
> non-public) and all errors are accounted for. Those of you surfing
> around a little more will see a couple of disabled builds, which also
> has known causes.
>
>
> Plugins
> =========
> I have only managed to find "real" concurrency problems in the EAR
> plugin and modello as of yet. Modello is fixed in trunk, ear is
> not started AFIK.
>
> All the other stuff I've seen in the core plugins relate to the
> plexus-issues.
>
> Our jira issue is from a user who's complaining about plugins not
> working, and I think he's somewhat right in that we have to make some
> kind of system to indicate compatibility with the -T option.
>
> Although several strategies may be recommended, my personal favourite
> is to make a @threadsafe javadoc annotation and make M3 core
> COMPLAIN LOUDLY about plugins that are unmarked, then proceed as
> requested (i.e. complain but still run threaded).
>
> The problem with these things is that thread safety is not necessarily a
> constant, and in the next 9 months there will be issues. So for some
> plugins @threadsafe might equally much express an intent as much as it
> reflects reality. So that makes me a bit sceptical to @threadsafe too.
>
> Aggressively displaying the link to the wiki page containing the
> most up-todate threading info may be an equally good solution; maybe
> even adding a WARNING: Experimental or something to the build output.
>
>
> http://cwiki.apache.org/confluence/display/MAVEN/Parallel+builds+in
> +Maven+3 (if it's up), should contain all the information needed on
> which plugins are known to have issues. But as we all know, it's an open
> ecosystem.
>
> Documentation
> ============
> I will keep the wiki page updated, provided cwiki.a.o actually stays
> up ;)
> I will add a section on mojo threading models/threading concerns to the
> mojo api specification.
>
>
> I think we have to take some extra measures to keep users out of the
> issue trackers on this one, or at least make sure they go to the right
> place.
>
> What do you think ?
>
> Kristian
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org