You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@bloodhound.apache.org by Eric Jouffrey <er...@asygn.com> on 2014/01/27 16:44:58 UTC
Reload product configuration
Hello everyone,
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.
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
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 ?
For now, I'm going to kill the bloodhound process after added changset
in my post-hook script. But that's ugly.
Thanks by advance if you have any clue.
----------------------------------------------
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
Re: Reload product configuration
Posted by Ryan Ollos <ry...@wandisco.com>.
On Tue, Jan 28, 2014 at 12:21 AM, Eric Jouffrey <er...@asygn.com>wrote:
> 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.
>
The issue you've reported can be tracked in ticket #748,
https://issues.apache.org/bloodhound/ticket/748
Thank you for your careful and detailed description.
Re: Reload product configuration
Posted by Olemis Lang <ol...@gmail.com>.
On Tue, Jan 28, 2014 at 3:34 PM, Ryan Ollos <ry...@wandisco.com> wrote:
> On Tue, Jan 28, 2014 at 12:21 AM, Eric Jouffrey <er...@asygn.com>wrote:
>
>> 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.
>>
>
> What you describe sounds like the issue documented in
> https://issues.apache.org/bloodhound/ticket/539.
> I can reproduce the issue you describe with granting permissions. I'm
> testing the patches in #539, but so far I can't see that the issue is
> solved by the patches.
>
IMO this is closer to #685 . There should not be DB violation error (if
still at all happening for PostgreSQL) because the OP is using SQLite ,
which silently ignores duplicated column names in queries . AFAICT the
patches submitted for #539 are not related to this issue . #539 is mainly
about config whereas #685 is about DB table where permissions are actually
stored .
--
Regards,
Olemis - @olemislc
Re: Reload product configuration
Posted by Ryan Ollos <ry...@wandisco.com>.
On Tue, Jan 28, 2014 at 12:21 AM, Eric Jouffrey <er...@asygn.com>wrote:
> 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.
>
What you describe sounds like the issue documented in
https://issues.apache.org/bloodhound/ticket/539.
I can reproduce the issue you describe with granting permissions. I'm
testing the patches in #539, but so far I can't see that the issue is
solved by the patches.
Re: Reload product configuration
Posted by Olemis Lang <ol...@gmail.com>.
On 1/28/14, Eric Jouffrey <er...@asygn.com> wrote:
> 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.
>
ok , please share with us any issues you might find .
> My repository was defined using web configuration and it's linked to a
> product.
>
so it's defined in the DB .
[...]
>
> 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.
similar to what's been reported in #685 but without the duplicate key
DB violation ?
https://issues.apache.org/bloodhound/ticket/685
> Granting right for global level is perfect.
>
helps to know that .
> I'm going to try investigate more on all this and keep you to date.
>
thanks !
--
Regards,
Olemis - @olemislc
Re: Reload product configuration
Posted by Eric Jouffrey <er...@asygn.com>.
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 <ma...@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
>
Re: Reload product configuration
Posted by Olemis Lang <ol...@gmail.com>.
On Mon, Jan 27, 2014 at 10:44 AM, Eric Jouffrey <er...@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