Quantcast

Three Sonar failures due to massively parallel builds ?

classic Classic list List threaded Threaded
7 messages Options
dbb
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Three Sonar failures due to massively parallel builds ?

dbb
We have started using a very parallelized build environment for continuous development into a production system. Many of our modules are now building sub-modul
es concurrently and we are experiencing random failures during the Sonar analysis cycle. We want to make Sonar analysis help gate release of the modules but th
e random errors we are getting has caused us to consider ignoring certain types of Sonar failures.

We are seeing the following 3 failures for example:

Failed to execute goal org.codehaus.mojo:sonar-maven-plugin:2.0:sonar (default-cli) on project tree-parent: Can not execute Sonar: Fail to decorate 'org.sonar.api.resources.Project@11ec822c[id=69258,key=org.familysearch.gadget:FavoritesGadget,qualifier=BRC]': Unable to find org.sonar.api.database.model.Snapshot with id 16460103 -> [Help 1]

Failed to execute goal org.codehaus.mojo:sonar-maven-plugin:2.0:sonar (default-cli) on project tree-parent: Can not execute Sonar: Fail to decorate 'org.sonar.api.resources.Project@1e7c05f1[id=93862,key=org.familysearch.gadget:FtUtils,qualifier=BRC]': Error while commiting the transaction: org.hibernate.StaleStateException: Batch update returned unexpected row count from update [0]; actual row count: 0; expected: 1 -> [Help 1]

org.hibernate.exception.LockAcquisitionException: could not insert: [org.sonar.api.database.model.MeasureModel]: Deadlock found when trying to get lock; try restarting transaction

I know there have been problems with Sonar when multiple analysis are attempted to be logged concurrently and that the following query was meant to clean up af
ter such problems:

mysql -h localhost -u sonar -psonar sonar -e 'update snapshots old_snap, snapshots new_snap set old_snap.islast=0 where old_snap.islast=1 and new_snap.created_at > old_snap.created_at and new_snap.project_id = old_snap.project_id and new_snap.islast=1;'

First question, are all three of these problems related?

Second question -- is something being considered for Sonar to somehow cleanup and retry when a deadlock is encountered?
The time required for a new Sonar analysis to be done and reported would seem to be much more costly time wise than having some recovery measures in place in t
he client (and possibly the server) to handle these problems.

Thanks for any light you can shed on how best to resolve such problems for a continuous delivery environment where there are numerous of build servers handling
 sub-module builds in parallel.

Doug
--

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Three Sonar failures due to massively parallel builds ?

Freddy Mallet
Hi Doug,

We have started using a very parallelized build environment for continuous development into a production system. Many of our modules are now building sub-modul
es concurrently and we are experiencing random failures during the Sonar analysis cycle.

I do confirm that Sonar doesn't support parallel analysis on the same project but also on modules having a hierarchical relationship. Let's take the following example :

Project A
  - Module AA
  - Module AB
        - Module ABA
        - Module ABB

You can't expect Sonar to run correctly if you analyse Module AB and Module ABB simultaneously.

Before answering you other questions could you make sure that you can't face such use cases in your context ?

Thanks
Freddy

 
We want to make Sonar analysis help gate release of the modules but th
e random errors we are getting has caused us to consider ignoring certain types of Sonar failures.

We are seeing the following 3 failures for example:

Failed to execute goal org.codehaus.mojo:sonar-maven-plugin:2.0:sonar (default-cli) on project tree-parent: Can not execute Sonar: Fail to decorate 'org.sonar.api.resources.Project@11ec822c[id=69258,key=org.familysearch.gadget:FavoritesGadget,qualifier=BRC]': Unable to find org.sonar.api.database.model.Snapshot with id 16460103 -> [Help 1]

Failed to execute goal org.codehaus.mojo:sonar-maven-plugin:2.0:sonar (default-cli) on project tree-parent: Can not execute Sonar: Fail to decorate 'org.sonar.api.resources.Project@1e7c05f1[id=93862,key=org.familysearch.gadget:FtUtils,qualifier=BRC]': Error while commiting the transaction: org.hibernate.StaleStateException: Batch update returned unexpected row count from update [0]; actual row count: 0; expected: 1 -> [Help 1]

org.hibernate.exception.LockAcquisitionException: could not insert: [org.sonar.api.database.model.MeasureModel]: Deadlock found when trying to get lock; try restarting transaction

I know there have been problems with Sonar when multiple analysis are attempted to be logged concurrently and that the following query was meant to clean up af
ter such problems:

mysql -h localhost -u sonar -psonar sonar -e 'update snapshots old_snap, snapshots new_snap set old_snap.islast=0 where old_snap.islast=1 and new_snap.created_at > old_snap.created_at and new_snap.project_id = old_snap.project_id and new_snap.islast=1;'

First question, are all three of these problems related?

Second question -- is something being considered for Sonar to somehow cleanup and retry when a deadlock is encountered?
The time required for a new Sonar analysis to be done and reported would seem to be much more costly time wise than having some recovery measures in place in t
he client (and possibly the server) to handle these problems.

Thanks for any light you can shed on how best to resolve such problems for a continuous delivery environment where there are numerous of build servers handling
 sub-module builds in parallel.

Doug
--

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



dbb
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Three Sonar failures due to massively parallel builds ?

dbb
Freddy,

I have checked with the engineer responsible for the builds. He said:
"We are not trying to analyze AB and ABB in parallel during a single run.  Currently we are running sonar on a multi-module project at the same time as running it on the same multi-module project.  Each run is serial though, so no two modules are run at the same time as each other within one of those runs."

I hope this helps in figuring out what is going on and the best way to resolve the problem without us getting the errors noted and having to do a total re-run of the build job.

Thanks,
Doug

On Tue, Jul 24, 2012 at 10:26:41PM +0200, Freddy Mallet wrote:

> Hi Doug,
>
> We have started using a very parallelized build environment for continuous
> > development into a production system. Many of our modules are now building
> > sub-modul
> > es concurrently and we are experiencing random failures during the Sonar
> > analysis cycle.
>
>
> I do confirm that Sonar doesn't support parallel analysis on the same
> project but also on modules having a hierarchical relationship. Let's take
> the following example :
>
> Project A
>   - Module AA
>   - Module AB
>         - Module ABA
>         - Module ABB
>
> You can't expect Sonar to run correctly if you analyse Module AB and Module
> ABB simultaneously.
>
> Before answering you other questions could you make sure that you can't
> face such use cases in your context ?
>
> Thanks
> Freddy
>
>
>
> > We want to make Sonar analysis help gate release of the modules but th
> > e random errors we are getting has caused us to consider ignoring certain
> > types of Sonar failures.
> >
> > We are seeing the following 3 failures for example:
> >
> > Failed to execute goal org.codehaus.mojo:sonar-maven-plugin:2.0:sonar
> > (default-cli) on project tree-parent: Can not execute Sonar: Fail to
> > decorate 'org.sonar.api.resources.Project@11ec822c[id=69258,key=org.familysearch.gadget:FavoritesGadget,qualifier=BRC]':
> > Unable to find org.sonar.api.database.model.Snapshot with id 16460103 ->
> > [Help 1]
> >
> > Failed to execute goal org.codehaus.mojo:sonar-maven-plugin:2.0:sonar
> > (default-cli) on project tree-parent: Can not execute Sonar: Fail to
> > decorate 'org.sonar.api.resources.Project@1e7c05f1[id=93862,key=org.familysearch.gadget:FtUtils,qualifier=BRC]':
> > Error while commiting the transaction: org.hibernate.StaleStateException:
> > Batch update returned unexpected row count from update [0]; actual row
> > count: 0; expected: 1 -> [Help 1]
> >
> > org.hibernate.exception.LockAcquisitionException: could not insert:
> > [org.sonar.api.database.model.MeasureModel]: Deadlock found when trying to
> > get lock; try restarting transaction
> >
> > I know there have been problems with Sonar when multiple analysis are
> > attempted to be logged concurrently and that the following query was meant
> > to clean up af
> > ter such problems:
> >
> > mysql -h localhost -u sonar -psonar sonar -e 'update snapshots old_snap,
> > snapshots new_snap set old_snap.islast=0 where old_snap.islast=1 and
> > new_snap.created_at > old_snap.created_at and new_snap.project_id =
> > old_snap.project_id and new_snap.islast=1;'
> >
> > First question, are all three of these problems related?
> >
> > Second question -- is something being considered for Sonar to somehow
> > cleanup and retry when a deadlock is encountered?
> > The time required for a new Sonar analysis to be done and reported would
> > seem to be much more costly time wise than having some recovery measures in
> > place in t
> > he client (and possibly the server) to handle these problems.
> >
> > Thanks for any light you can shed on how best to resolve such problems for
> > a continuous delivery environment where there are numerous of build servers
> > handling
> >  sub-module builds in parallel.
> >
> > Doug
> > --
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this list, please visit:
> >
> >     http://xircles.codehaus.org/manage_email
> >
> >
> >

--

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


dbb
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Three Sonar failures due to massively parallel builds ?

dbb
Just wondering if anone had more thoughts on the problems asked about in this thread as I have not seen a reply?

Thanks,
Doug

On Wed, Jul 25, 2012 at 10:01:42AM -0600, Doug Beattie wrote:

> Freddy,
>
> I have checked with the engineer responsible for the builds. He said:
> "We are not trying to analyze AB and ABB in parallel during a single run.  Currently we are running sonar on a multi-module project at the same time as running it on the same multi-module project.  Each run is serial though, so no two modules are run at the same time as each other within one of those runs."
>
> I hope this helps in figuring out what is going on and the best way to resolve the problem without us getting the errors noted and having to do a total re-run of the build job.
>
> Thanks,
> Doug
>
> On Tue, Jul 24, 2012 at 10:26:41PM +0200, Freddy Mallet wrote:
> > Hi Doug,
> >
> > We have started using a very parallelized build environment for continuous
> > > development into a production system. Many of our modules are now building
> > > sub-modul
> > > es concurrently and we are experiencing random failures during the Sonar
> > > analysis cycle.
> >
> >
> > I do confirm that Sonar doesn't support parallel analysis on the same
> > project but also on modules having a hierarchical relationship. Let's take
> > the following example :
> >
> > Project A
> >   - Module AA
> >   - Module AB
> >         - Module ABA
> >         - Module ABB
> >
> > You can't expect Sonar to run correctly if you analyse Module AB and Module
> > ABB simultaneously.
> >
> > Before answering you other questions could you make sure that you can't
> > face such use cases in your context ?
> >
> > Thanks
> > Freddy
> >
> >
> >
> > > We want to make Sonar analysis help gate release of the modules but th
> > > e random errors we are getting has caused us to consider ignoring certain
> > > types of Sonar failures.
> > >
> > > We are seeing the following 3 failures for example:
> > >
> > > Failed to execute goal org.codehaus.mojo:sonar-maven-plugin:2.0:sonar
> > > (default-cli) on project tree-parent: Can not execute Sonar: Fail to
> > > decorate 'org.sonar.api.resources.Project@11ec822c[id=69258,key=org.familysearch.gadget:FavoritesGadget,qualifier=BRC]':
> > > Unable to find org.sonar.api.database.model.Snapshot with id 16460103 ->
> > > [Help 1]
> > >
> > > Failed to execute goal org.codehaus.mojo:sonar-maven-plugin:2.0:sonar
> > > (default-cli) on project tree-parent: Can not execute Sonar: Fail to
> > > decorate 'org.sonar.api.resources.Project@1e7c05f1[id=93862,key=org.familysearch.gadget:FtUtils,qualifier=BRC]':
> > > Error while commiting the transaction: org.hibernate.StaleStateException:
> > > Batch update returned unexpected row count from update [0]; actual row
> > > count: 0; expected: 1 -> [Help 1]
> > >
> > > org.hibernate.exception.LockAcquisitionException: could not insert:
> > > [org.sonar.api.database.model.MeasureModel]: Deadlock found when trying to
> > > get lock; try restarting transaction
> > >
> > > I know there have been problems with Sonar when multiple analysis are
> > > attempted to be logged concurrently and that the following query was meant
> > > to clean up af
> > > ter such problems:
> > >
> > > mysql -h localhost -u sonar -psonar sonar -e 'update snapshots old_snap,
> > > snapshots new_snap set old_snap.islast=0 where old_snap.islast=1 and
> > > new_snap.created_at > old_snap.created_at and new_snap.project_id =
> > > old_snap.project_id and new_snap.islast=1;'
> > >
> > > First question, are all three of these problems related?
> > >
> > > Second question -- is something being considered for Sonar to somehow
> > > cleanup and retry when a deadlock is encountered?
> > > The time required for a new Sonar analysis to be done and reported would
> > > seem to be much more costly time wise than having some recovery measures in
> > > place in t
> > > he client (and possibly the server) to handle these problems.
> > >
> > > Thanks for any light you can shed on how best to resolve such problems for
> > > a continuous delivery environment where there are numerous of build servers
> > > handling
> > >  sub-module builds in parallel.
> > >
> > > Doug
> > > --
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe from this list, please visit:
> > >
> > >     http://xircles.codehaus.org/manage_email
> > >
> > >
> > >
>
> --
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>

--

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Three Sonar failures due to massively parallel builds ?

Olivier Gaudin-2
Hi Doug,

I think this is it: Sonar does not support parallel for a single project (or module): http://jira.codehaus.org/browse/SONAR-3306

Regards

Olivier


On Tue, Aug 7, 2012 at 3:22 PM, Doug Beattie <[hidden email]> wrote:
Just wondering if anone had more thoughts on the problems asked about in this thread as I have not seen a reply?

Thanks,
Doug

On Wed, Jul 25, 2012 at 10:01:42AM -0600, Doug Beattie wrote:
> Freddy,
>
> I have checked with the engineer responsible for the builds. He said:
> "We are not trying to analyze AB and ABB in parallel during a single run.  Currently we are running sonar on a multi-module project at the same time as running it on the same multi-module project.  Each run is serial though, so no two modules are run at the same time as each other within one of those runs."
>
> I hope this helps in figuring out what is going on and the best way to resolve the problem without us getting the errors noted and having to do a total re-run of the build job.
>
> Thanks,
> Doug
>
> On Tue, Jul 24, 2012 at 10:26:41PM +0200, Freddy Mallet wrote:
> > Hi Doug,
> >
> > We have started using a very parallelized build environment for continuous
> > > development into a production system. Many of our modules are now building
> > > sub-modul
> > > es concurrently and we are experiencing random failures during the Sonar
> > > analysis cycle.
> >
> >
> > I do confirm that Sonar doesn't support parallel analysis on the same
> > project but also on modules having a hierarchical relationship. Let's take
> > the following example :
> >
> > Project A
> >   - Module AA
> >   - Module AB
> >         - Module ABA
> >         - Module ABB
> >
> > You can't expect Sonar to run correctly if you analyse Module AB and Module
> > ABB simultaneously.
> >
> > Before answering you other questions could you make sure that you can't
> > face such use cases in your context ?
> >
> > Thanks
> > Freddy
> >
> >
> >
> > > We want to make Sonar analysis help gate release of the modules but th
> > > e random errors we are getting has caused us to consider ignoring certain
> > > types of Sonar failures.
> > >
> > > We are seeing the following 3 failures for example:
> > >
> > > Failed to execute goal org.codehaus.mojo:sonar-maven-plugin:2.0:sonar
> > > (default-cli) on project tree-parent: Can not execute Sonar: Fail to
> > > decorate 'org.sonar.api.resources.Project@11ec822c[id=69258,key=org.familysearch.gadget:FavoritesGadget,qualifier=BRC]':
> > > Unable to find org.sonar.api.database.model.Snapshot with id 16460103 ->
> > > [Help 1]
> > >
> > > Failed to execute goal org.codehaus.mojo:sonar-maven-plugin:2.0:sonar
> > > (default-cli) on project tree-parent: Can not execute Sonar: Fail to
> > > decorate 'org.sonar.api.resources.Project@1e7c05f1[id=93862,key=org.familysearch.gadget:FtUtils,qualifier=BRC]':
> > > Error while commiting the transaction: org.hibernate.StaleStateException:
> > > Batch update returned unexpected row count from update [0]; actual row
> > > count: 0; expected: 1 -> [Help 1]
> > >
> > > org.hibernate.exception.LockAcquisitionException: could not insert:
> > > [org.sonar.api.database.model.MeasureModel]: Deadlock found when trying to
> > > get lock; try restarting transaction
> > >
> > > I know there have been problems with Sonar when multiple analysis are
> > > attempted to be logged concurrently and that the following query was meant
> > > to clean up af
> > > ter such problems:
> > >
> > > mysql -h localhost -u sonar -psonar sonar -e 'update snapshots old_snap,
> > > snapshots new_snap set old_snap.islast=0 where old_snap.islast=1 and
> > > new_snap.created_at > old_snap.created_at and new_snap.project_id =
> > > old_snap.project_id and new_snap.islast=1;'
> > >
> > > First question, are all three of these problems related?
> > >
> > > Second question -- is something being considered for Sonar to somehow
> > > cleanup and retry when a deadlock is encountered?
> > > The time required for a new Sonar analysis to be done and reported would
> > > seem to be much more costly time wise than having some recovery measures in
> > > place in t
> > > he client (and possibly the server) to handle these problems.
> > >
> > > Thanks for any light you can shed on how best to resolve such problems for
> > > a continuous delivery environment where there are numerous of build servers
> > > handling
> > >  sub-module builds in parallel.
> > >
> > > Doug
> > > --
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe from this list, please visit:
> > >
> > >     http://xircles.codehaus.org/manage_email
> > >
> > >
> > >
>
> --
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>

--

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



dbb
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Three Sonar failures due to massively parallel builds ?

dbb
Thanks Olivier for the pointer to the issue.

I have voted on it and added the text from this email thread to give more data as to possible errors that one may experience until this issue is resolved.
As we become more sophisticated in a continuous development environment I believe more groups will find this improvement to be of high importance.

Doug

On Wed, Aug 08, 2012 at 10:57:31PM +0200, Olivier Gaudin wrote:

> Hi Doug,
>
> I think this is it: Sonar does not support parallel for a single project
> (or module): http://jira.codehaus.org/browse/SONAR-3306
>
> Regards
>
> Olivier
>
>
> On Tue, Aug 7, 2012 at 3:22 PM, Doug Beattie <[hidden email]> wrote:
>
> > Just wondering if anone had more thoughts on the problems asked about in
> > this thread as I have not seen a reply?
> >
> > Thanks,
> > Doug
> >
> > On Wed, Jul 25, 2012 at 10:01:42AM -0600, Doug Beattie wrote:
> > > Freddy,
> > >
> > > I have checked with the engineer responsible for the builds. He said:
> > > "We are not trying to analyze AB and ABB in parallel during a single
> > run.  Currently we are running sonar on a multi-module project at the same
> > time as running it on the same multi-module project.  Each run is serial
> > though, so no two modules are run at the same time as each other within one
> > of those runs."
> > >
> > > I hope this helps in figuring out what is going on and the best way to
> > resolve the problem without us getting the errors noted and having to do a
> > total re-run of the build job.
> > >
> > > Thanks,
> > > Doug
> > >
> > > On Tue, Jul 24, 2012 at 10:26:41PM +0200, Freddy Mallet wrote:
> > > > Hi Doug,
> > > >
> > > > We have started using a very parallelized build environment for
> > continuous
> > > > > development into a production system. Many of our modules are now
> > building
> > > > > sub-modul
> > > > > es concurrently and we are experiencing random failures during the
> > Sonar
> > > > > analysis cycle.
> > > >
> > > >
> > > > I do confirm that Sonar doesn't support parallel analysis on the same
> > > > project but also on modules having a hierarchical relationship. Let's
> > take
> > > > the following example :
> > > >
> > > > Project A
> > > >   - Module AA
> > > >   - Module AB
> > > >         - Module ABA
> > > >         - Module ABB
> > > >
> > > > You can't expect Sonar to run correctly if you analyse Module AB and
> > Module
> > > > ABB simultaneously.
> > > >
> > > > Before answering you other questions could you make sure that you can't
> > > > face such use cases in your context ?
> > > >
> > > > Thanks
> > > > Freddy
> > > >
> > > >
> > > >
> > > > > We want to make Sonar analysis help gate release of the modules but
> > th
> > > > > e random errors we are getting has caused us to consider ignoring
> > certain
> > > > > types of Sonar failures.
> > > > >
> > > > > We are seeing the following 3 failures for example:
> > > > >
> > > > > Failed to execute goal org.codehaus.mojo:sonar-maven-plugin:2.0:sonar
> > > > > (default-cli) on project tree-parent: Can not execute Sonar: Fail to
> > > > > decorate 'org.sonar.api.resources.Project@11ec822c
> > [id=69258,key=org.familysearch.gadget:FavoritesGadget,qualifier=BRC]':
> > > > > Unable to find org.sonar.api.database.model.Snapshot with id
> > 16460103 ->
> > > > > [Help 1]
> > > > >
> > > > > Failed to execute goal org.codehaus.mojo:sonar-maven-plugin:2.0:sonar
> > > > > (default-cli) on project tree-parent: Can not execute Sonar: Fail to
> > > > > decorate 'org.sonar.api.resources.Project@1e7c05f1
> > [id=93862,key=org.familysearch.gadget:FtUtils,qualifier=BRC]':
> > > > > Error while commiting the transaction:
> > org.hibernate.StaleStateException:
> > > > > Batch update returned unexpected row count from update [0]; actual
> > row
> > > > > count: 0; expected: 1 -> [Help 1]
> > > > >
> > > > > org.hibernate.exception.LockAcquisitionException: could not insert:
> > > > > [org.sonar.api.database.model.MeasureModel]: Deadlock found when
> > trying to
> > > > > get lock; try restarting transaction
> > > > >
> > > > > I know there have been problems with Sonar when multiple analysis are
> > > > > attempted to be logged concurrently and that the following query was
> > meant
> > > > > to clean up af
> > > > > ter such problems:
> > > > >
> > > > > mysql -h localhost -u sonar -psonar sonar -e 'update snapshots
> > old_snap,
> > > > > snapshots new_snap set old_snap.islast=0 where old_snap.islast=1 and
> > > > > new_snap.created_at > old_snap.created_at and new_snap.project_id =
> > > > > old_snap.project_id and new_snap.islast=1;'
> > > > >
> > > > > First question, are all three of these problems related?
> > > > >
> > > > > Second question -- is something being considered for Sonar to somehow
> > > > > cleanup and retry when a deadlock is encountered?
> > > > > The time required for a new Sonar analysis to be done and reported
> > would
> > > > > seem to be much more costly time wise than having some recovery
> > measures in
> > > > > place in t
> > > > > he client (and possibly the server) to handle these problems.
> > > > >
> > > > > Thanks for any light you can shed on how best to resolve such
> > problems for
> > > > > a continuous delivery environment where there are numerous of build
> > servers
> > > > > handling
> > > > >  sub-module builds in parallel.
> > > > >
> > > > > Doug
> > > > > --
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe from this list, please visit:
> > > > >
> > > > >     http://xircles.codehaus.org/manage_email
> > > > >
> > > > >
> > > > >
> > >
> > > --
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe from this list, please visit:
> > >
> > >     http://xircles.codehaus.org/manage_email
> > >
> > >
> >
> > --
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this list, please visit:
> >
> >     http://xircles.codehaus.org/manage_email
> >
> >
> >

--

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Three Sonar failures due to massively parallel builds ?

Olivier Gaudin-2
Doug,

I guess in the mean time, you can use your continuous integrating engine to stop parallel build of the same project to happen.

Olivier


On Thu, Aug 9, 2012 at 12:01 AM, Doug Beattie <[hidden email]> wrote:
Thanks Olivier for the pointer to the issue.

I have voted on it and added the text from this email thread to give more data as to possible errors that one may experience until this issue is resolved.
As we become more sophisticated in a continuous development environment I believe more groups will find this improvement to be of high importance.

Doug

On Wed, Aug 08, 2012 at 10:57:31PM +0200, Olivier Gaudin wrote:
> Hi Doug,
>
> I think this is it: Sonar does not support parallel for a single project
> (or module): http://jira.codehaus.org/browse/SONAR-3306
>
> Regards
>
> Olivier
>
>
> On Tue, Aug 7, 2012 at 3:22 PM, Doug Beattie <[hidden email]> wrote:
>
> > Just wondering if anone had more thoughts on the problems asked about in
> > this thread as I have not seen a reply?
> >
> > Thanks,
> > Doug
> >
> > On Wed, Jul 25, 2012 at 10:01:42AM -0600, Doug Beattie wrote:
> > > Freddy,
> > >
> > > I have checked with the engineer responsible for the builds. He said:
> > > "We are not trying to analyze AB and ABB in parallel during a single
> > run.  Currently we are running sonar on a multi-module project at the same
> > time as running it on the same multi-module project.  Each run is serial
> > though, so no two modules are run at the same time as each other within one
> > of those runs."
> > >
> > > I hope this helps in figuring out what is going on and the best way to
> > resolve the problem without us getting the errors noted and having to do a
> > total re-run of the build job.
> > >
> > > Thanks,
> > > Doug
> > >
> > > On Tue, Jul 24, 2012 at 10:26:41PM +0200, Freddy Mallet wrote:
> > > > Hi Doug,
> > > >
> > > > We have started using a very parallelized build environment for
> > continuous
> > > > > development into a production system. Many of our modules are now
> > building
> > > > > sub-modul
> > > > > es concurrently and we are experiencing random failures during the
> > Sonar
> > > > > analysis cycle.
> > > >
> > > >
> > > > I do confirm that Sonar doesn't support parallel analysis on the same
> > > > project but also on modules having a hierarchical relationship. Let's
> > take
> > > > the following example :
> > > >
> > > > Project A
> > > >   - Module AA
> > > >   - Module AB
> > > >         - Module ABA
> > > >         - Module ABB
> > > >
> > > > You can't expect Sonar to run correctly if you analyse Module AB and
> > Module
> > > > ABB simultaneously.
> > > >
> > > > Before answering you other questions could you make sure that you can't
> > > > face such use cases in your context ?
> > > >
> > > > Thanks
> > > > Freddy
> > > >
> > > >
> > > >
> > > > > We want to make Sonar analysis help gate release of the modules but
> > th
> > > > > e random errors we are getting has caused us to consider ignoring
> > certain
> > > > > types of Sonar failures.
> > > > >
> > > > > We are seeing the following 3 failures for example:
> > > > >
> > > > > Failed to execute goal org.codehaus.mojo:sonar-maven-plugin:2.0:sonar
> > > > > (default-cli) on project tree-parent: Can not execute Sonar: Fail to
> > > > > decorate 'org.sonar.api.resources.Project@11ec822c
> > [id=69258,key=org.familysearch.gadget:FavoritesGadget,qualifier=BRC]':
> > > > > Unable to find org.sonar.api.database.model.Snapshot with id
> > 16460103 ->
> > > > > [Help 1]
> > > > >
> > > > > Failed to execute goal org.codehaus.mojo:sonar-maven-plugin:2.0:sonar
> > > > > (default-cli) on project tree-parent: Can not execute Sonar: Fail to
> > > > > decorate 'org.sonar.api.resources.Project@1e7c05f1
> > [id=93862,key=org.familysearch.gadget:FtUtils,qualifier=BRC]':
> > > > > Error while commiting the transaction:
> > org.hibernate.StaleStateException:
> > > > > Batch update returned unexpected row count from update [0]; actual
> > row
> > > > > count: 0; expected: 1 -> [Help 1]
> > > > >
> > > > > org.hibernate.exception.LockAcquisitionException: could not insert:
> > > > > [org.sonar.api.database.model.MeasureModel]: Deadlock found when
> > trying to
> > > > > get lock; try restarting transaction
> > > > >
> > > > > I know there have been problems with Sonar when multiple analysis are
> > > > > attempted to be logged concurrently and that the following query was
> > meant
> > > > > to clean up af
> > > > > ter such problems:
> > > > >
> > > > > mysql -h localhost -u sonar -psonar sonar -e 'update snapshots
> > old_snap,
> > > > > snapshots new_snap set old_snap.islast=0 where old_snap.islast=1 and
> > > > > new_snap.created_at > old_snap.created_at and new_snap.project_id =
> > > > > old_snap.project_id and new_snap.islast=1;'
> > > > >
> > > > > First question, are all three of these problems related?
> > > > >
> > > > > Second question -- is something being considered for Sonar to somehow
> > > > > cleanup and retry when a deadlock is encountered?
> > > > > The time required for a new Sonar analysis to be done and reported
> > would
> > > > > seem to be much more costly time wise than having some recovery
> > measures in
> > > > > place in t
> > > > > he client (and possibly the server) to handle these problems.
> > > > >
> > > > > Thanks for any light you can shed on how best to resolve such
> > problems for
> > > > > a continuous delivery environment where there are numerous of build
> > servers
> > > > > handling
> > > > >  sub-module builds in parallel.
> > > > >
> > > > > Doug
> > > > > --
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe from this list, please visit:
> > > > >
> > > > >     http://xircles.codehaus.org/manage_email
> > > > >
> > > > >
> > > > >
> > >
> > > --
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe from this list, please visit:
> > >
> > >     http://xircles.codehaus.org/manage_email
> > >
> > >
> >
> > --
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this list, please visit:
> >
> >     http://xircles.codehaus.org/manage_email
> >
> >
> >

--

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



Loading...