1. Marcin Kuzminski
  2. RhodeCode
  3. Issues

Issues

Issue #736 resolved

Can not see the last changes in the repository

Anonymous created an issue

I can not see recent changes made ​​by the command "push". Execution of another operation, such as "push", "fetch" or "clone" will appear on the list of changes the previous operation.

What could be causing this behavior? Is there a parameter responsible for this situation?

Comments (20)

  1. someonehastakenallthegoodones

    Hello, I can confirm this independently, also with version 1.5.2

    I am using git repositories with git version 1.7.11; everything else is working perfectly -- forking, email tasks, remote push and pull etc.

    When pushing a new repository, the Quick Start remains, even though the trending files and commit activity statistics show up. We can pull or clone the repository so the data is there -- just not showing up.

    Running top doesn't show high CPU usage.

    No celery/rhodecode warnings or errors logged that I can associate with this, just:

    2013-01-24 15:10:09.476 INFO [rhodecode.lib.middleware.simplegit] push action on GIT repo ......

    Running on CentOS 6 with mysql backend

  2. someonehastakenallthegoodones

    Some further information...

    As original poster hinted, committing and pushing a new change makes the previous changes show up, but then the new change is not showing.

    Setting the 'landing page' to master instead of tip updates to the latest tip -- but this is a temporary solution. Next push is missing from the landing page again. Setting the landing page back to tip does the same thing. Therefore, updating the choice of landing page, like a push, triggers some kind of update of the page. I have yet to find a permanent workaround.

    [Just another piece of info: we tried disabling statistics but this did not affect the problem]

  3. Mike Noordermeer

    Same issue here, seems to be caching related. Refreshing the page sometimes shows more of the latest commits, but generally I'm missing the last 1-4 commits. Using mercurial as backend with 1.5.2.

  4. Marcin Kuzminski repo owner

    The way it works now with vcs_full_cache is it caches last data in memory, when there's a push event the cache get's invalidated and re-loaded. If push comes outside of RhodeCode system via SSH or local, the cache will not get invalidated. Special case for git repos is when there are missing git hooks installed in the repo which causes the cache invalidation event.

    Mike Noordermeer Be carefull when using apache mod_wsgi with this, since if you set multiprocessing things can get bad. There's special warning about that in the RhodeCode docs.

    someonehastakenallthegoodones - i think with GIT it might be missing hooks, check if there's a pre-receive post-receive hooks installed in git-repos that aren't getting cache invalidation.

  5. someonehastakenallthegoodones

    Hello Marcin Kuzminski,

    The hooks look to be in place, pre-receive and post-receive have the following in them:

    try:
        import rhodecode
        RC_HOOK_VER = '1.5.2'
        os.environ['RC_HOOK_VER'] = RC_HOOK_VER
    

    We're using Apache but I excluded mod_wsgi as being the cause of our problem.

    So there is still some other problem... I've switched to vcs_full_cache = false for now as a workaround, which is a big help.

    Thanks!

  6. Mihai Nica

    I'm having the same issue, but with mercurial as VCS. Runing Rhodecode 1.5.2 with MySQL backend on Nginx reverse proxy for paster managed via upstart job.

    If I go in the admin section and use "rescan repositories" then the data it's updated. Also if wait a considerable amount of tine (a few hours), tha changes will show up. O I guess that it's a cache issue, maybe somehow related to #733.

    LE: Also every push it's made thru rhodecode (runs on it's own server, so no local or ssh repo operations)

  7. Marcin Kuzminski repo owner

    no 1.5.4 doesn't have any fixes for that. Are you able to reproduce the issue for hg or git repos ? If it's git repos, check if rhodecode hooks are installed properly in git folder

  8. reddot

    I'm using hg repos for personal purposes and interact with server repo only via push-/pull- over http shared by rhodecode. I've checked error.log against push/pull log messages. Seems no any notable warnings or errors there except on push actions:

    Exception AttributeError: AttributeError("'_DummyThread' object has no attribute '_Thread__block'",) in <module 'threading' f rom '/usr/lib/python2.7/threading.pyc'> ignored

    The most notable behavior of issue is that changes shown inconsistent across various pages. I.e. home screen could show me latest revision, but changelog and admin repos do not.

    Sometimes after viewing page with outdated rev info it reverts to outdated on pages where it was already shown properly. I haven't done enough testing to define whether latest statement is always true.

    I've rather stable way to reproduce the issue, so I can provide any additional info if needed or put some kind of debug patches to rhodecode server instance.

  9. Marcin Kuzminski repo owner

    Ok, so i think you're using multiprocessing setup somewhere in RhodeCode, this is very often an issue i'm seeing.

    If you use gunicorn don't use more than 1 worker, if using mod_wsgi in apache remember to turn off multiprocessing.

    The issues you posted are exactly what happens when you do it. RhodeCode cannot be runned in multiprocess mode. You need to run multiple instances of RhodeCode instead.

  10. reddot

    Ok, here is a cut from rhodecode wsgi directives at apache conf:

        WSGIDaemonProcess rhc threads=4 python-path=/srv/env-rhc/lib/python2.7/site-packages
        WSGIScriptAlias / /srv/www-rhc/hg.wsgi
        WSGIPassAuthorization On
        WSGIApplicationGroup rhc
    

    As of wsgi documentation there is no multiprocessing in this configuration. However I've switched threads to 1 and for a while can't get issue to be reproduced. I will work with these settings for a 2-3 days to confirm that issue resolved.

  11. reddot

    Hmm.. a little bit more playing around. And now I'm not sure threads=1 solves the problem. Moreover I've just lose my reproducible way to issue :)

  12. reddot

    Finally it seems problem had place due to interference of several wsgi-based sites hosted as virtual hosts on apache. I've solved the problem by adding following line in addition to previously posted:

        WSGIProcessGroup rhc
    

    where 'rhc' should be the same name declared in WSGIDaemonProcess directive and be unique for every wsgi site.

  13. Log in to comment