bloodhound-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Jouffrey <eric.jouff...@asygn.com>
Subject Re: Reload product configuration
Date Tue, 28 Jan 2014 08:21:58 GMT
I used the solution in #695, but maybe not the version that you send 10 
days ago. I'm going check differences see if there is some improvement.

My repository was defined using web configuration and it's linked to a 
product.

I'm going to try the repository_sync_per_request option. By reload 
configuration I was thinking that's basically what's happen when you 
change the log level for example (what resync all changeset)
And in our configuration we're using a SQLite database. I've also add 
some no-cache pragma to templates headers for be sure it wasn't any 
browser cache issues. And for the "kill -s HUP $PID", it don't seem to 
do the trick.

I've already done few more tests. And maybe there is something similar 
on granting right for a product. When I grant new right for a user or a 
group at product level, each refresh of permission page display randomly 
that new right or not. Granting right for global level is perfect.

I'm going to try investigate more on all this and keep you to date.

Eric

On 01/27/2014 05:50 PM, Olemis Lang wrote:
>
>
>
> On Mon, Jan 27, 2014 at 10:44 AM, Eric Jouffrey 
> <eric.jouffrey@asygn.com <mailto:eric.jouffrey@asygn.com>> wrote:
>
>     Hello everyone,
>
>
> Hi !
> :)
>
>     We are evaluating to use bloodhound as bugtracker for a very small
>     team of developers. So far everything seems good for us and it's
>     already a quite usable system, meeting what we were looked for.
>     But on our little test sever, we face something a bit strange.
>     [ Configuration is bloodhound 0.8-dev over Apache, SQLite, one
>     active project and one SVN repository. SVN repository is mirrored
>     using svnsync. ]
>
>     After a new changeset is added, bloodhound seems to randomly be
>     aware it.
>     For example sometimes page of changeset indicate invalid number,
>     sometimes it's good and changeset is displayed
>     I know that changeset have been correctly added because comments
>     are added to tickets that the changeset comment refer to, tickets
>     states change if comment contain good syntax, etc.
>
>
> Are you using tracopt.ticket.commit_updater or the component we are 
> building / testing in #695 [1]_ ? The former solution is not aware of 
> Bloodhound multiproduct architecture , so it might be buggy (... 
> actually untested) .
>
>     And after :
>     - a restart of apache server
>      or
>     - a kill of bloodhound process
>     or
>     - a modification of configuration (enable/disable log for exemple)
>     everything is back to normal
>
>
> Where did you defined your repository (config vs DB) ? Did you link it 
> to a given product ?
>
>
>     So I have three questions that maybe you can help :
>     - Is this a bug or something I do wrong into this process,
>     specially around svnsync ?
>     - Is it more a trac or bloodhound related problem ?
>     - Is there a command for reload configuration that I can execute
>     in the hook ?
>
>
> What do you mean for "reload configuration" ?
> There's a config option , see [trac] repository_sync_per_request ...
>
>     For now, I'm going to kill the bloodhound process after added
>     changset in my post-hook script. But that's ugly.
>
>
> It's ugly , yes . We'd like to help you to sort this out . In the mean 
> time an HUP from time to time could help ... but that's by far a 
> solution to your problem .
>
>
>     Thanks by advance if you have any clue.
>
>
> It'd be beneficial for us if you could spend some time helping us to 
> elucidate this situation because we have been noticing some issues 
> related to some kind of DB caching happening (... mainly on PostgreSQL) .
>
> .. [1] https://issues.apache.org/bloodhound/ticket/695
>
>
>
>
>
>     ----------------------------------------------
>     LOG Extract when changeset cannot be found :
>     2014-01-23 12:35:26,738 Trac[main] DEBUG: Dispatching
>     <ProductRequestWithSession "GET '/changeset/668/MyRepo'">
>     2014-01-23 12:35:26,740 Trac[session] DEBUG: Retrieving session
>     for ID u'user'
>     2014-01-23 12:35:26,741 Trac[main] DEBUG: Negotiated locale: None
>     -> fr
>     2014-01-23 12:35:26,747 Trac[api] WARNING: Unable to find
>     repository '(default)' for synchronization
>     2014-01-23 12:35:26,750 Trac[chrome] DEBUG: Prepare chrome data
>     for request
>     2014-01-23 12:35:26,774 Trac[web_ui] DEBUG: {'active': False,
>     'name': 'wiki', 'label': <Element "a">}
>     2014-01-23 12:35:26,774 Trac[web_ui] DEBUG: {'active': True,
>     'name': 'browser', 'label': <Element "a">}
>     2014-01-23 12:35:26,774 Trac[web_ui] DEBUG: {'active': False,
>     'name': 'tickets', 'label': <Element "a">}
>     2014-01-23 12:35:26,774 Trac[main] WARNING: [172.16.128.112]
>     HTTPNotFound: 404 Numéro de révision non valide (Aucune révision
>     668 dans ce dépôt)
>     2014-01-23 12:35:26,880 Trac[main] DEBUG: Dispatching
>     <ProductRequestWithSession "GET
>     '/chrome/dashboard/css/bootstrap-responsive.css'">
>     ----------------------------------------------
>     My post-revprop-change hook :
>     REPOS="$1"
>     REV="$2"
>     USER="$3"
>     PROPNAME="$4"
>     ACTION="$5"
>
>     #/bin/echo "`date` post-revprop $REPOS $REV $USER $PROPNAME
>     $ACTION" >> /root/svnsync.log # Log all actions
>
>     if [ "$PROPNAME" = "svn:sync-last-merged-rev" ]; then
>         YOUNGEST_REV=`svnlook youngest /opt/svn/myRepo`
>
>         # Start virtualeven for bloodhound
>         source /opt/bloodhound/installer/bloodhound/bin/activate
>         # Fire update to Bloodhound
>         trac-admin
>     /opt/bloodhound/installer/bloodhound/environments/main/ changeset
>     added "myRepo" $YOUNGEST_REV
>
>         # Restart bloodhound daemon by killing it..
>         PID=`pgrep -U bloodhound`
>         #echo "Kill the bloodhound daemon, PID $PID"
>         if [[ ! -z $PID ]]
>         then
>             kill $PID
>         fi
>
>     fi
>
>
> kill -s HUP $PID ?
> afaict the fact that the changeset was added (i.e. 
> CommitTicketUpdater) might not directly mean that changesets cache has 
> been synchronized, cmiiw .
>
> -- 
> Regards,
>
> Olemis - @olemislc
>


Mime
View raw message