hi Greg,
I don't have that setting in my universe. Should I just add it? The
output of hg summary is (hg incoming doesn't show any available updates):
parent: 12276:dc067a95261d tip
Added tag release_2014.02.10 for changeset 5e605ed6069f
branch: stable
commit: 22 modified, 1 deleted, 127
Hi Jeremy,
After checking, the two js scripts are absent from the release:
backbone-relational.js ( static/scripts/packed/libs/backbone/ )
galaxy.utils.js ( static/scripts/packed/utils/ )
bw
C
On 25 Mar 2014, at 16:16, Shu-Yi Su wrote:
Hi Jeremy,
Thank you very much for the reply.
Hi Geert,
The setting should be in your universe_wsgi.ini.sample, and you woud have to
manually edit your universe_wsgi.ini to add it. I would say that 125 installed
packages is probably what is causing the slow starts. This feature is not
currently useful, so it can be set to not function
Hi Greg,
The setting was not in my universe_sample file. I added it, set log_info
to DEBUG and restarted galaxy.
The startup time remained the same, and there were many entries in the
log file indicating that the lag is indeed the creation of the
dependency system:
This sounds like a cache issue. Both of these scripts have been removed from
the distribution, so they should be absent from the distribution. Can you try
clearing your cache and see if that fixes the issue?
Thanks,
J.
--
Jeremy Goecks
Assistant Professor of Computational Biology
George
The changeset that made this a configurable setting was committed to the stable
branch in d270d3c, which was committed on 2014-02-19
https://bitbucket.org/galaxy/galaxy-central/commits/d270d3cf7627a42b6fac2aa69701deadb89c8ffc
If you are tracking the stable branch in the galaxy central repo
I think usegalaxy.org (which main.g2.bx.psu.edu still aliases) was
experiencing many issues and was mostly down over the time period you
described due to disk and network issues in the data center at TACC.
Those specific links no longer seem to produce 500 status code errors
and usegalaxy.org has
I have many jobs stuck in the 'new' state on our local Galaxy instance. The
jobs can't be stopped using the Admin-Manage jobs tool. First, does anyone
know why a job would get stuck in the 'new' state for weeks? I have cleaned
things up by manually setting their states to 'error' in the
The next step then is to revert all the changes that you pulled from -central
and report back the errors you’re seeing. Manually pulling selected change sets
can be problematic if you don’t get all the dependencies.
Best,
J.
--
Jeremy Goecks
Assistant Professor of Computational Biology
George