Parallel maven build: 33% improvement
by Paul Robinson
All,
I tried telling maven to use all my cores (8 if you count hyper-threaded cores) and I've seen a 33% reduction in build times. Here's my results:
./build.sh clean install -DskipTests 3:43
./build.sh clean install -DskipTests -T 4 2:57
./build.sh clean install -DskipTests -T 8 2:30
I'm using an SSD, so YMMV.
However, there are 4 plugins that are not marked as @ThreadSafe, so i'm not sure how safe this is.
[WARNING] org.apache.maven.plugins:maven-help-plugin:2.2 (Can't find an issue for this yet)
[WARNING] org.codehaus.mojo:buildnumber-maven-plugin:1.2 (Claims to be fixed in 1.2: http://jira.codehaus.org/browse/MBUILDNUM-13)
[WARNING] org.codehaus.mojo:xml-maven-plugin:1.0 (Unresolved: http://jira.codehaus.org/browse/MOJO-1709)
[WARNING] org.kuali.maven.plugins:properties-maven-plugin:1.5.3 (Unresolved: http://jira.codehaus.org/browse/MOJO-1677)
For more info on parallel maven builds:
https://cwiki.apache.org/MAVEN/parallel-builds-in-maven-3.html
Has anyone else experimented with this feature?
Paul.
--
Paul Robinson
Web Service Transactions Lead
paul.robinson(a)redhat.com
JBoss, a Division of Red Hat
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham (USA), Brendan Lane (Ireland), Matt Parson
(USA), Charlie Peters (USA)
13 years
Re: [jboss-as7-dev] Deployment restarts
by Thomas Diesler
On Mar 22, 2013, at 10:47 AM, Stuart Douglas <sdouglas(a)redhat.com> wrote:
>
>
> Thomas Diesler wrote:
>> I think we need to have a conversation on how this is generally supposed to work.
>>
>> Option #1
>>
>> Undeployment of a deployment that others dependent on (automatically) takes the transitive graph of dependent deployments down. If so, we need to look at when restart is attempted. Should this be done automatically when the named dependency reappears? This is more or less what we have today.
>
> We only have half of this today. It takes down the dependent deployments, however it is not possible to restart them.
Yes, restart is attempted but the DUPs are not designed for it.
>
>>
>> Options #2
>>
>> Undeployment of a deployment that others dependent on does not effect existing wiring. Dependent deployments continue to work and reference a stale deployment with associated module/classloader. Only if there are no users/wires to the undeployed - it can be removed completely. User interaction is needed to cause a rewiring.
>>
>
> I think this is very problematic, as dependencies are not just class loading dependencies but can also be dependencies on EJB's, EntityManagers etc.
Yes, OSGi uninstall is more like an intension to undeploy. We would need to look at whether this approach can be adopted for all deployment types or whether we need a differentiator that deployments can use if intension to undeploy is the the desired behaviour.
>
>> ------
>>
>> The OSGi model is option #2 and can IMHO not be mapped cleanly to what we have in AS today. Even if we fix the DUP issue it will not work because bundle A that depends on bundle B should not be effected when B gets undeployed (i.e. BundleActivator.stop() must not be called for A). Some time back I suggested the notion of "lazy service dependency"
>>
>> * A depends on B
>> * A stays up even when B goes down
>> * B must have come up at least once for A to come up
>
> That would actually not be that hard to implement. I think you could implement it using a service that depends on deployment B with mode PASSIVE, and when that service comes up it simply actives the deferred deployment A. This would be an OSGi only thing though.
This is an option we can explore. You mean that module phase services for OSGi deployments would not have module service dependencies coming from other deployments? I believe that access to "removal pending" bundles is limited to resource and class loading. Services associated with the uninstalled bundle are gone. AFAIU, undeploy of an in use bundle could roll back the phases down to FIRST_MODULE_USE (i.e. the Module stays available)
>
>>
>> I suggest we wait for the outcome of the FY2014 planning in Newcastle. If it should be decided that AS is supposed to provided proper OSGi support, we can revisit this issue together with
>>
>> * deployment start/stop
>> * deployment update
>> * wiring refresh
>
> Ok, but I would really like to get this into EAP 6.1 if at all possible, as it does make inter deployment dependencies and class loader dependencies work a lot better.
>
> I guess the read question is other than the failing test, does this actually cause real problems for OSGi, especially given that the current behavior means that half the time restarts won't work anyway.
It does cause real problems for OSGi, because the fundamental semantics of install/start/stop/uninstall is not mapped properly to deployment management operations. Bundle update is not implemented, neither is FrameworkWiring.refreshPackages().
IMHO, the best approach would be to look at this from the perspective of deployment management ops. When the required functionality is available at that level, the OSGi layer could simply use that.
Initially, we would need proper support for start/stop operations. Undeploy, when given with a differentiator, should first stop the deployment and then depending on some criteria (i.e. in use wirings) continue the undeploy or not. If start/stop was supported properly it would be a matter of fixing individual DUPs and perhaps selectively disabling cleanup (i.e. a DUP could that needs the cleanup state to support start/stop could prevent the cleanup)
>
> Stuart
>
>>
>> cheers
>> --thomas
>>
>>
>> On Mar 22, 2013, at 8:08 AM, Stuart Douglas<sdouglas(a)redhat.com> wrote:
>>
>>> I have done up a patch that should allow deployment restarts to work, basically it just detects if the deployment has already started, and forces a complete restart, rather than attempting to re-run the DUP's.
>>>
>>> https://github.com/jbossas/jboss-as/pull/4268
>>>
>>> Unfortunately this breaks DeferredResolveTestCase, because a new instance of DeferredFailActivator is created. I'm not really sure how best to solve this, as I am not sure what the allowed semantics are here with regard to OSGi.
>>>
>>> Do you have any ideas about how to deal with this?
>>>
>>> Stuart
>>
>> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
>> Thomas Diesler
>> JBoss OSGi Lead
>> JBoss, a division of Red Hat
>> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
>>
>>
>>
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
13 years
Re: [jboss-as7-dev] why is jboss-logging a bundle anyway
by Philippe Marschall
> why is jboss-logging a bundle anyway?
Because people want to use libraries that use jboss-logging in OSGi
environments other than JBoss OSGi.
> I thought due to its tight integration with the JDK logging system it
needs to be on the boot class path.
See answer from James Perkins.
> How is the jboss-logging bundle lifecycle
install/start/stop/update/uninstall supposed to work?
1. code has a dependency on jboss-logging, either through Import-Package
or Require-Bundle
2. the OSGi resolver makes sure this code isn't run before the
dependency on jboss-logging is met
3. at the latest when the code that required jboss-logging does
Logger.getLogger the jboss-logging bundle gets activated,
LoggerProviders gets initialized and a look up of the LoggerProvider
implementation class happens.
4. A new version of jboss-logging can be installed at any time, it will
just do the look up of the LoggerProvider implementation class again.
Standard OSGi rules will apply which bundles the the new version of
jboss-logging. Since jboss-logging is not an actual logging
implementation loading multiple versions of it is fine. This isn't the
case for implementations like Logback. If you have two versions of
Logback installed that want to log into the same file this may cause a
problem. Therefore only actual log implementations should be marked as
singleton bundles, not jboss-logging itself.
5. As with any OSGi bundle jboss-logging should not be stopped until all
bundles that depend on it transitively are stopped. Otherwise you have
code that references objects and classes in a stopped bundle. Once they
all have been stopped jboss-logging can be restared, uninstalled or updated.
> Would it not be better to ship it as a library if it can't work
properly as bundle, or can it?
It works fine. I have code here that runs it in Equinox and it runs fine.
Cheers
Philippe
13 years
App deployed but not accessible
by CanI HasU
Hello
I have pasted a war file into deployment dir, but when i type
localhost:8080/app nothing happens. when i add index.jsp to the url it
displays a 404 message...
Yes I only have the war file... isn't that enough?
I'm confused
13 years
Re: [jboss-as7-dev] Deployment restarts
by Thomas Diesler
I think we need to have a conversation on how this is generally supposed to work.
Option #1
Undeployment of a deployment that others dependent on (automatically) takes the transitive graph of dependent deployments down. If so, we need to look at when restart is attempted. Should this be done automatically when the named dependency reappears? This is more or less what we have today.
Options #2
Undeployment of a deployment that others dependent on does not effect existing wiring. Dependent deployments continue to work and reference a stale deployment with associated module/classloader. Only if there are no users/wires to the undeployed - it can be removed completely. User interaction is needed to cause a rewiring.
------
The OSGi model is option #2 and can IMHO not be mapped cleanly to what we have in AS today. Even if we fix the DUP issue it will not work because bundle A that depends on bundle B should not be effected when B gets undeployed (i.e. BundleActivator.stop() must not be called for A). Some time back I suggested the notion of "lazy service dependency"
* A depends on B
* A stays up even when B goes down
* B must have come up at least once for A to come up
I suggest we wait for the outcome of the FY2014 planning in Newcastle. If it should be decided that AS is supposed to provided proper OSGi support, we can revisit this issue together with
* deployment start/stop
* deployment update
* wiring refresh
cheers
--thomas
On Mar 22, 2013, at 8:08 AM, Stuart Douglas <sdouglas(a)redhat.com> wrote:
> I have done up a patch that should allow deployment restarts to work, basically it just detects if the deployment has already started, and forces a complete restart, rather than attempting to re-run the DUP's.
>
> https://github.com/jbossas/jboss-as/pull/4268
>
> Unfortunately this breaks DeferredResolveTestCase, because a new instance of DeferredFailActivator is created. I'm not really sure how best to solve this, as I am not sure what the allowed semantics are here with regard to OSGi.
>
> Do you have any ideas about how to deal with this?
>
> Stuart
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
13 years
Pull request processing hiccups fixed
by Tomaž Cerar
Hi,
past few days there ware some problems automatically building pull requests.
That resulted in many duplicated jobs running on Jenkins and never getting
back proper result.
Problem was caused by Jenkins upgrade on lightning over weekend.
after which this bug https://issues.jenkins-ci.org/browse/JENKINS-15583 bit
us.
This should all be all resolved now.
If you notice any problem or strange behavior let me know.
--
Tomaz
13 years
migrate
by CanI HasU
If I wana migrate to a newer jboss version with a newer java version,
should i just install jdk to another folder than /usr/java and only change
the jboss java_home variable?
13 years
Should I create a new Subsytem for this?
by Paul Robinson
All,
To use our implementation of the REST-AT spec, a developer has jump through a lot of hoops. We'd like to remove these hoops making it easier for users to get started with distributed transactions over REST.
The subsystem would carry out the following steps, that are currently the burden of the application developer:
1. Deploy a war application containing the transaction coordinator.
2. Register some interceptors for deployments that use REST-AT
3. Register a single REST endpoint (for all applications) to receive protocol messages from remote coordinators.
4. Start the recovery manager
So, I'm pretty sure we should do these steps in a subsytem.
The next question is, do we create a new subsytem, or add this to one of the existing transaction subsytems (transactions or xts)?
The transactions subsytem contains the bulk of the transactions functionality. The XTS subsytem contains just enough to distribute transactions over Web services, delegating the core transaction management capabilities to the transaction subsytem. I think we need another subsytem called 'RTS' that provides the REST specific functionality of REST-AT and delegates to the transaction subsytem for the core transaction management capabilities.
The other benefit of having XTS and RTS in separate subsytems is that they can be separately enabled/disabled. This is especially important when you consider that each depend on a transport (Web services and REST) which may not be enabled.
My concern with creating another subsytem is that it is yet another thing to maintain. Maybe you are trying to keep the number of subsytems low?
Paul.
--
Paul Robinson
Web Service Transactions Lead
paul.robinson(a)redhat.com
JBoss, a Division of Red Hat
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham (USA), Brendan Lane (Ireland), Matt Parson
(USA), Charlie Peters (USA)
13 years
