Hi All,
Some of the developers will know me already but it's my first time being properly on this list as I'm now working concertedly on Galaxy. I'm responsible for Bio-Linux which currently ships with an out-of-date and slightly flakey galaxy, but I'm working to fix that.
I've hit a problem. This may or may not be the same as the issue seen by Luobin Yang.
When uploading a file, no job appears in the right-hand panel. If I click refresh I might see a job but it stays in the blue "Dataset is uploading" state forever.
I'm working on packaging Galaxy for Debian/Ubuntu/Bio-Linux, specifically Ubuntu 12.04 LTS (python 2.7.3). To rearrange Galaxy into something that resembles a Debian package takes a lot of tinkering and I've patched a few bits of the code, so when uploads started freezing like this I assumed it was something I'd done and started reverting patches.
But it turns out I can trigger this problem on a pristine download of the latest server release (20130926 from Bitbucket). All I do is:
grab and unpack latest version python ./scripts/fetch_eggs.py -c universe_wsgi.ini.sample python ./scripts/fetch_eggs.py -c universe_wsgi.ini.sample -e psycopg2 (note - I'm not actually using Posgres in this case and I'm assuming this is irrelevant but reporting for completenes) mkdir eggs-cache ; export PYTHON_EGG_CACHE=`pwd`/eggs-cache ./run.sh (wait for SQLite DB to build) Ctrl-C, ./run.sh, test, Ctrl-C, ./run.sh, test, etc...
After a few restarts the problem occurs. Failing that, it seems I can make failure more likely by tarring up the whole directory and untarring it again. I suspect all this is doing is affecting the disk cache timing and thus triggering some underlying race condition.
Once the server is started, behaviour is apparently consistent - ie. all uploads either fail or all work. Other tasks seem to work, so long as they don't depend on the stalled uploads, but I've only tried a couple of these (just a basic "select first lines").
I'm now convinced there is some sort of race condition on start-up that is responsible. On my DEB package it fails like this all the time, but an issue is clearly there in the unmolested code, just rarer.
I don't mind getting into the code to try and debug this but I don't know where to start, even with the source code docs and my rapidly increasing Python-fu. Trying to fathom the interactions between the threads and the browser and the SQLAlchemy layer I either need a good outline document or a developer to hold my hand for a bit. Can someone help me out with this one?
Thanks in advance,
TIM
On Fri, Oct 4, 2013 at 8:11 AM, Tim Booth tbooth@ceh.ac.uk wrote:
When uploading a file, no job appears in the right-hand panel. If I click refresh I might see a job but it stays in the blue "Dataset is uploading" state forever.
Hi Tim,
It is great news to hear Galaxy deb packages could be a possibility in the near future. Regarding this issue, I can confirm I see it a lot on Chrome but never on Firefox. It has been so bad for me that I almost completely moved to using only Firefox when working on Galaxy. I thought it could be a cookies issue, but clearing out galaxy cookies from Chrome doesn't help in my case.
I'll be happy to do further testing as this is something I would love to see fixed.
Best, Carlos
I have seen this behavior too and I too have switched to Firefox, but I have only ever seen this with chrome on localhost, never with chrome on a remote server behind a proxy.
-John
On Fri, Oct 4, 2013 at 8:55 AM, Carlos Borroto carlos.borroto@gmail.com wrote:
On Fri, Oct 4, 2013 at 8:11 AM, Tim Booth tbooth@ceh.ac.uk wrote:
When uploading a file, no job appears in the right-hand panel. If I click refresh I might see a job but it stays in the blue "Dataset is uploading" state forever.
Hi Tim,
It is great news to hear Galaxy deb packages could be a possibility in the near future. Regarding this issue, I can confirm I see it a lot on Chrome but never on Firefox. It has been so bad for me that I almost completely moved to using only Firefox when working on Galaxy. I thought it could be a cookies issue, but clearing out galaxy cookies from Chrome doesn't help in my case.
I'll be happy to do further testing as this is something I would love to see fixed.
Best, Carlos ___________________________________________________________ Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/
To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
On Oct 4, 2013, at 10:00 AM, John Chilton wrote:
I have seen this behavior too and I too have switched to Firefox, but I have only ever seen this with chrome on localhost, never with chrome on a remote server behind a proxy.
I've seen this issue before as well, a few of us have worked on it in the past, but it seems to be transient and not easy to reproduce. In my testing a couple years ago, I found that the call to ajaxSubmit() to actually POST the data never occurs, and I couldn't get Firebug to tell me why.
You can disable the AJAX upload method in tools/data_source/upload.xml, but that makes the UI a lot less usable, especially for large files.
--nate
-John
On Fri, Oct 4, 2013 at 8:55 AM, Carlos Borroto carlos.borroto@gmail.com wrote:
On Fri, Oct 4, 2013 at 8:11 AM, Tim Booth tbooth@ceh.ac.uk wrote:
When uploading a file, no job appears in the right-hand panel. If I click refresh I might see a job but it stays in the blue "Dataset is uploading" state forever.
Hi Tim,
It is great news to hear Galaxy deb packages could be a possibility in the near future. Regarding this issue, I can confirm I see it a lot on Chrome but never on Firefox. It has been so bad for me that I almost completely moved to using only Firefox when working on Galaxy. I thought it could be a cookies issue, but clearing out galaxy cookies from Chrome doesn't help in my case.
I'll be happy to do further testing as this is something I would love to see fixed.
Best, Carlos ___________________________________________________________ Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/
To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/
To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
Hi Guys,
Thanks for the replies. In that case it looks like the problem with my DEB package is not the same as the transient upload issue with Chrome. I was indeed using Chrome for most of the testing, but if I try to use the DEB package I've made then uploads still don't work at all in either Chrome or FF.
The file appears in database/file/000/ but I don't see any job in the history. Setting ajax-upload to false doesn't seem to change anything whatsoever - (to reassure myself the XML was actually being reloaded I changed the version number and saw that changed).
I've rolled back all the changes in my package that I think would reasonably impact the issue, in particular my patch that enables Galaxy to use certain system libraries rather than it's own eggs, but the problem still persists so I feel I have to try and understand it rather than blindly switching things around.
In terms of debugging, I can use tcpflow and FireBug to dig into the network communication but how do I get Galaxy to give me more info about what it is up to? I can't see any obvious errors in the server log, and when if comes to the internals of the thing I don't know what is actually supposed to happening. What is the expected sequence of events when a file is uploaded? How is the status of the job signalled to the right-hand pane? Where do I start adding debugging statements and assertions to help me see what is happening? Can the in-browser debugging mentioned in the config file help me out at all, and where can I find out more?
I'm happy to RTFM here but I've not yet found the right bit of the FM to read!
Cheers,
TIM
On Fri, 2013-10-04 at 15:12 +0100, Nate Coraor wrote:
On Oct 4, 2013, at 10:00 AM, John Chilton wrote:
I have seen this behavior too and I too have switched to Firefox, but I have only ever seen this with chrome on localhost, never with chrome on a remote server behind a proxy.
I've seen this issue before as well, a few of us have worked on it in the past, but it seems to be transient and not easy to reproduce. In my testing a couple years ago, I found that the call to ajaxSubmit() to actually POST the data never occurs, and I couldn't get Firebug to tell me why.
You can disable the AJAX upload method in tools/data_source/upload.xml, but that makes the UI a lot less usable, especially for large files.
--nate
-John
On Fri, Oct 4, 2013 at 8:55 AM, Carlos Borroto carlos.borroto@gmail.com wrote:
On Fri, Oct 4, 2013 at 8:11 AM, Tim Booth tbooth@ceh.ac.uk wrote:
When uploading a file, no job appears in the right-hand panel. If I click refresh I might see a job but it stays in the blue "Dataset is uploading" state forever.
Hi Tim,
It is great news to hear Galaxy deb packages could be a possibility in the near future. Regarding this issue, I can confirm I see it a lot on Chrome but never on Firefox. It has been so bad for me that I almost completely moved to using only Firefox when working on Galaxy. I thought it could be a cookies issue, but clearing out galaxy cookies from Chrome doesn't help in my case.
I'll be happy to do further testing as this is something I would love to see fixed.
Best, Carlos ___________________________________________________________ Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/
To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/
To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/
To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
Hey,
We are currently refactoring and redesigning the front-end javascript code. If the bug you are observing is 1) related to specifics of the current front-end implementation and 2) if fixing the bug is time consuming it might be reasonable to not invest that time and wait until we complete the new client code for the upload process.
Thanks, Sam
On Fri, Oct 4, 2013 at 11:48 AM, Tim Booth tbooth@ceh.ac.uk wrote:
Hi Guys,
Thanks for the replies. In that case it looks like the problem with my DEB package is not the same as the transient upload issue with Chrome. I was indeed using Chrome for most of the testing, but if I try to use the DEB package I've made then uploads still don't work at all in either Chrome or FF.
The file appears in database/file/000/ but I don't see any job in the history. Setting ajax-upload to false doesn't seem to change anything whatsoever - (to reassure myself the XML was actually being reloaded I changed the version number and saw that changed).
I've rolled back all the changes in my package that I think would reasonably impact the issue, in particular my patch that enables Galaxy to use certain system libraries rather than it's own eggs, but the problem still persists so I feel I have to try and understand it rather than blindly switching things around.
In terms of debugging, I can use tcpflow and FireBug to dig into the network communication but how do I get Galaxy to give me more info about what it is up to? I can't see any obvious errors in the server log, and when if comes to the internals of the thing I don't know what is actually supposed to happening. What is the expected sequence of events when a file is uploaded? How is the status of the job signalled to the right-hand pane? Where do I start adding debugging statements and assertions to help me see what is happening? Can the in-browser debugging mentioned in the config file help me out at all, and where can I find out more?
I'm happy to RTFM here but I've not yet found the right bit of the FM to read!
Cheers,
TIM
On Fri, 2013-10-04 at 15:12 +0100, Nate Coraor wrote:
On Oct 4, 2013, at 10:00 AM, John Chilton wrote:
I have seen this behavior too and I too have switched to Firefox, but I have only ever seen this with chrome on localhost, never with chrome on a remote server behind a proxy.
I've seen this issue before as well, a few of us have worked on it in
the past, but it seems to be transient and not easy to reproduce. In my testing a couple years ago, I found that the call to ajaxSubmit() to actually POST the data never occurs, and I couldn't get Firebug to tell me why.
You can disable the AJAX upload method in tools/data_source/upload.xml,
but that makes the UI a lot less usable, especially for large files.
--nate
-John
On Fri, Oct 4, 2013 at 8:55 AM, Carlos Borroto <
carlos.borroto@gmail.com> wrote:
On Fri, Oct 4, 2013 at 8:11 AM, Tim Booth tbooth@ceh.ac.uk wrote:
When uploading a file, no job appears in the right-hand panel. If I click refresh I might see a job but it stays in the blue "Dataset is uploading" state forever.
Hi Tim,
It is great news to hear Galaxy deb packages could be a possibility in the near future. Regarding this issue, I can confirm I see it a lot on Chrome but never on Firefox. It has been so bad for me that I almost completely moved to using only Firefox when working on Galaxy. I thought it could be a cookies issue, but clearing out galaxy cookies from Chrome doesn't help in my case.
I'll be happy to do further testing as this is something I would love to see fixed.
Best, Carlos ___________________________________________________________ Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/
To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/
To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/
To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
-- Tim Booth tbooth@ceh.ac.uk NERC Environmental Bioinformatics Centre
Centre for Ecology and Hydrology Maclean Bldg, Benson Lane Crowmarsh Gifford Wallingford, England OX10 8BB
http://nebc.nerc.ac.uk +44 1491 69 2705
Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/
To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
Hi Sam,
I just want to try and get a working Galaxy on Bio-Linux, and unless your new code is coming out imminently (ie. next week) I need to make progress before then. If I can't debug the problem I think I'm going to have to revert changes until I get to something that happens to work. The result will be far removed from anything that could ever become a proper Debian package, and given the progress I've made I'd prefer not to quit now. By the time your next release comes out I'll have other jobs on my plate. Is it really that hard to peek into the system and try to see where the upload is jamming?
Cheers,
TIM
On Fri, 2013-10-04 at 17:05 +0100, sam guerler wrote:
Hey,
We are currently refactoring and redesigning the front-end javascript code. If the bug you are observing is 1) related to specifics of the current front-end implementation and 2) if fixing the bug is time consuming it might be reasonable to not invest that time and wait until we complete the new client code for the upload process.
Thanks, Sam
On Fri, Oct 4, 2013 at 11:48 AM, Tim Booth tbooth@ceh.ac.uk wrote: Hi Guys,
Thanks for the replies. In that case it looks like the problem with my DEB package is not the same as the transient upload issue with Chrome. I was indeed using Chrome for most of the testing, but if I try to use the DEB package I've made then uploads still don't work at all in either Chrome or FF. The file appears in database/file/000/ but I don't see any job in the history. Setting ajax-upload to false doesn't seem to change anything whatsoever - (to reassure myself the XML was actually being reloaded I changed the version number and saw that changed). I've rolled back all the changes in my package that I think would reasonably impact the issue, in particular my patch that enables Galaxy to use certain system libraries rather than it's own eggs, but the problem still persists so I feel I have to try and understand it rather than blindly switching things around. In terms of debugging, I can use tcpflow and FireBug to dig into the network communication but how do I get Galaxy to give me more info about what it is up to? I can't see any obvious errors in the server log, and when if comes to the internals of the thing I don't know what is actually supposed to happening. What is the expected sequence of events when a file is uploaded? How is the status of the job signalled to the right-hand pane? Where do I start adding debugging statements and assertions to help me see what is happening? Can the in-browser debugging mentioned in the config file help me out at all, and where can I find out more? I'm happy to RTFM here but I've not yet found the right bit of the FM to read! Cheers, TIM On Fri, 2013-10-04 at 15:12 +0100, Nate Coraor wrote: > On Oct 4, 2013, at 10:00 AM, John Chilton wrote: > > > I have seen this behavior too and I too have switched to Firefox, but > > I have only ever seen this with chrome on localhost, never with chrome > > on a remote server behind a proxy. > > I've seen this issue before as well, a few of us have worked on it in the past, but it seems to be transient and not easy to reproduce. In my testing a couple years ago, I found that the call to ajaxSubmit() to actually POST the data never occurs, and I couldn't get Firebug to tell me why. > > You can disable the AJAX upload method in tools/data_source/upload.xml, but that makes the UI a lot less usable, especially for large files. > > --nate > > > > > -John > > > > On Fri, Oct 4, 2013 at 8:55 AM, Carlos Borroto <carlos.borroto@gmail.com> wrote: > >> On Fri, Oct 4, 2013 at 8:11 AM, Tim Booth <tbooth@ceh.ac.uk> wrote: > >>> When uploading a file, no job appears in the right-hand panel. If I > >>> click refresh I might see a job but it stays in the blue "Dataset is > >>> uploading" state forever. > >> > >> Hi Tim, > >> > >> It is great news to hear Galaxy deb packages could be a possibility in > >> the near future. Regarding this issue, I can confirm I see it a lot on > >> Chrome but never on Firefox. It has been so bad for me that I almost > >> completely moved to using only Firefox when working on Galaxy. I > >> thought it could be a cookies issue, but clearing out galaxy cookies > >> from Chrome doesn't help in my case. > >> > >> I'll be happy to do further testing as this is something I would love > >> to see fixed. > >> > >> Best, > >> Carlos > >> ___________________________________________________________ > >> Please keep all replies on the list by using "reply all" > >> in your mail client. To manage your subscriptions to this > >> and other Galaxy lists, please use the interface at: > >> http://lists.bx.psu.edu/ > >> > >> To search Galaxy mailing lists use the unified search at: > >> http://galaxyproject.org/search/mailinglists/ > > ___________________________________________________________ > > Please keep all replies on the list by using "reply all" > > in your mail client. To manage your subscriptions to this > > and other Galaxy lists, please use the interface at: > > http://lists.bx.psu.edu/ > > > > To search Galaxy mailing lists use the unified search at: > > http://galaxyproject.org/search/mailinglists/ > > > ___________________________________________________________ > Please keep all replies on the list by using "reply all" > in your mail client. To manage your subscriptions to this > and other Galaxy lists, please use the interface at: > http://lists.bx.psu.edu/ > > To search Galaxy mailing lists use the unified search at: > http://galaxyproject.org/search/mailinglists/ -- Tim Booth <tbooth@ceh.ac.uk> NERC Environmental Bioinformatics Centre Centre for Ecology and Hydrology Maclean Bldg, Benson Lane Crowmarsh Gifford Wallingford, England OX10 8BB http://nebc.nerc.ac.uk +44 1491 69 2705 ___________________________________________________________ Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
Tim,
Just to be certain, if you have AJAX upload enabled, you'll see this message after you click Execute on the upload tool:
http://www.bx.psu.edu/~nate/galaxy/ajax.png
Whereas with it disabled, you'll see:
http://www.bx.psu.edu/~nate/galaxy/noajax.png
--nate
On Oct 4, 2013, at 11:48 AM, Tim Booth wrote:
Hi Guys,
Thanks for the replies. In that case it looks like the problem with my DEB package is not the same as the transient upload issue with Chrome. I was indeed using Chrome for most of the testing, but if I try to use the DEB package I've made then uploads still don't work at all in either Chrome or FF.
The file appears in database/file/000/ but I don't see any job in the history. Setting ajax-upload to false doesn't seem to change anything whatsoever - (to reassure myself the XML was actually being reloaded I changed the version number and saw that changed).
I've rolled back all the changes in my package that I think would reasonably impact the issue, in particular my patch that enables Galaxy to use certain system libraries rather than it's own eggs, but the problem still persists so I feel I have to try and understand it rather than blindly switching things around.
In terms of debugging, I can use tcpflow and FireBug to dig into the network communication but how do I get Galaxy to give me more info about what it is up to? I can't see any obvious errors in the server log, and when if comes to the internals of the thing I don't know what is actually supposed to happening. What is the expected sequence of events when a file is uploaded? How is the status of the job signalled to the right-hand pane? Where do I start adding debugging statements and assertions to help me see what is happening? Can the in-browser debugging mentioned in the config file help me out at all, and where can I find out more?
I'm happy to RTFM here but I've not yet found the right bit of the FM to read!
Cheers,
TIM
On Fri, 2013-10-04 at 15:12 +0100, Nate Coraor wrote:
On Oct 4, 2013, at 10:00 AM, John Chilton wrote:
I have seen this behavior too and I too have switched to Firefox, but I have only ever seen this with chrome on localhost, never with chrome on a remote server behind a proxy.
I've seen this issue before as well, a few of us have worked on it in the past, but it seems to be transient and not easy to reproduce. In my testing a couple years ago, I found that the call to ajaxSubmit() to actually POST the data never occurs, and I couldn't get Firebug to tell me why.
You can disable the AJAX upload method in tools/data_source/upload.xml, but that makes the UI a lot less usable, especially for large files.
--nate
-John
On Fri, Oct 4, 2013 at 8:55 AM, Carlos Borroto carlos.borroto@gmail.com wrote:
On Fri, Oct 4, 2013 at 8:11 AM, Tim Booth tbooth@ceh.ac.uk wrote:
When uploading a file, no job appears in the right-hand panel. If I click refresh I might see a job but it stays in the blue "Dataset is uploading" state forever.
Hi Tim,
It is great news to hear Galaxy deb packages could be a possibility in the near future. Regarding this issue, I can confirm I see it a lot on Chrome but never on Firefox. It has been so bad for me that I almost completely moved to using only Firefox when working on Galaxy. I thought it could be a cookies issue, but clearing out galaxy cookies from Chrome doesn't help in my case.
I'll be happy to do further testing as this is something I would love to see fixed.
Best, Carlos ___________________________________________________________ Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/
To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/
To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/
To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
-- Tim Booth tbooth@ceh.ac.uk NERC Environmental Bioinformatics Centre
Centre for Ecology and Hydrology Maclean Bldg, Benson Lane Crowmarsh Gifford Wallingford, England OX10 8BB
http://nebc.nerc.ac.uk +44 1491 69 2705
Hi Tim,
Were you able to fix your problem?
Thanks, Sam
On Fri, Oct 4, 2013 at 1:05 PM, Nate Coraor nate@bx.psu.edu wrote:
Tim,
Just to be certain, if you have AJAX upload enabled, you'll see this message after you click Execute on the upload tool:
http://www.bx.psu.edu/~nate/galaxy/ajax.png
Whereas with it disabled, you'll see:
http://www.bx.psu.edu/~nate/galaxy/noajax.png
--nate
On Oct 4, 2013, at 11:48 AM, Tim Booth wrote:
Hi Guys,
Thanks for the replies. In that case it looks like the problem with my DEB package is not the same as the transient upload issue with Chrome. I was indeed using Chrome for most of the testing, but if I try to use the DEB package I've made then uploads still don't work at all in either Chrome or FF.
The file appears in database/file/000/ but I don't see any job in the history. Setting ajax-upload to false doesn't seem to change anything whatsoever - (to reassure myself the XML was actually being reloaded I changed the version number and saw that changed).
I've rolled back all the changes in my package that I think would reasonably impact the issue, in particular my patch that enables Galaxy to use certain system libraries rather than it's own eggs, but the problem still persists so I feel I have to try and understand it rather than blindly switching things around.
In terms of debugging, I can use tcpflow and FireBug to dig into the network communication but how do I get Galaxy to give me more info about what it is up to? I can't see any obvious errors in the server log, and when if comes to the internals of the thing I don't know what is actually supposed to happening. What is the expected sequence of events when a file is uploaded? How is the status of the job signalled to the right-hand pane? Where do I start adding debugging statements and assertions to help me see what is happening? Can the in-browser debugging mentioned in the config file help me out at all, and where can I find out more?
I'm happy to RTFM here but I've not yet found the right bit of the FM to read!
Cheers,
TIM
On Fri, 2013-10-04 at 15:12 +0100, Nate Coraor wrote:
On Oct 4, 2013, at 10:00 AM, John Chilton wrote:
I have seen this behavior too and I too have switched to Firefox, but I have only ever seen this with chrome on localhost, never with chrome on a remote server behind a proxy.
I've seen this issue before as well, a few of us have worked on it in
the past, but it seems to be transient and not easy to reproduce. In my testing a couple years ago, I found that the call to ajaxSubmit() to actually POST the data never occurs, and I couldn't get Firebug to tell me why.
You can disable the AJAX upload method in tools/data_source/upload.xml,
but that makes the UI a lot less usable, especially for large files.
--nate
-John
On Fri, Oct 4, 2013 at 8:55 AM, Carlos Borroto <
carlos.borroto@gmail.com> wrote:
On Fri, Oct 4, 2013 at 8:11 AM, Tim Booth tbooth@ceh.ac.uk wrote:
When uploading a file, no job appears in the right-hand panel. If I click refresh I might see a job but it stays in the blue "Dataset is uploading" state forever.
Hi Tim,
It is great news to hear Galaxy deb packages could be a possibility in the near future. Regarding this issue, I can confirm I see it a lot on Chrome but never on Firefox. It has been so bad for me that I almost completely moved to using only Firefox when working on Galaxy. I thought it could be a cookies issue, but clearing out galaxy cookies from Chrome doesn't help in my case.
I'll be happy to do further testing as this is something I would love to see fixed.
Best, Carlos ___________________________________________________________ Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/
To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/
To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/
To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
-- Tim Booth tbooth@ceh.ac.uk NERC Environmental Bioinformatics Centre
Centre for Ecology and Hydrology Maclean Bldg, Benson Lane Crowmarsh Gifford Wallingford, England OX10 8BB
http://nebc.nerc.ac.uk +44 1491 69 2705
Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/
To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
Hi Devs,
Just to let you know, I've nailed down my uploading issue to a reproducible test case which may be worth addressing if only by tweaking the notes in universe.wsgi.sample to be clearer. It was nothing to do with AJAX uploading in the end, and probably unrelated to the intermittent Chrome/localhost issue.
To reproduce:
1) In universe_wsgi.ini, set "cookie_path = /galaxy". 2) Point Galaxy to an empty database and start it up so it builds a new empty DB. 3) Browse to localhost:8080 and try to upload a file, and the upload fails.
Now you'll probably tell me there should be no / in the cookie path, but here's the weird thing...
4) Set "cookie_path = galaxy" (or back to None) and restart. 5) Upload a single file. 6) Set "cookie_path = /galaxy" and restart. 7) Upload a second file - and now it works!
So it appears that setting the cookie_path to /whatever breaks the very first upload on a new server. This explains why I couldn't easily spot the problem, since I'd already had this setting on an existing installation and it had seemed to work.
Does anyone have any insight into what might be happening?
Cheers,
TIM
On Fri, 2013-10-04 at 18:05 +0100, Nate Coraor wrote:
Tim,
Just to be certain, if you have AJAX upload enabled, you'll see this message after you click Execute on the upload tool:
http://www.bx.psu.edu/~nate/galaxy/ajax.png
Whereas with it disabled, you'll see:
http://www.bx.psu.edu/~nate/galaxy/noajax.png
--nate
On Oct 4, 2013, at 11:48 AM, Tim Booth wrote:
Hi Guys,
Thanks for the replies. In that case it looks like the problem with my DEB package is not the same as the transient upload issue with Chrome. I was indeed using Chrome for most of the testing, but if I try to use the DEB package I've made then uploads still don't work at all in either Chrome or FF.
The file appears in database/file/000/ but I don't see any job in the history. Setting ajax-upload to false doesn't seem to change anything whatsoever - (to reassure myself the XML was actually being reloaded I changed the version number and saw that changed).
I've rolled back all the changes in my package that I think would reasonably impact the issue, in particular my patch that enables Galaxy to use certain system libraries rather than it's own eggs, but the problem still persists so I feel I have to try and understand it rather than blindly switching things around.
In terms of debugging, I can use tcpflow and FireBug to dig into the network communication but how do I get Galaxy to give me more info about what it is up to? I can't see any obvious errors in the server log, and when if comes to the internals of the thing I don't know what is actually supposed to happening. What is the expected sequence of events when a file is uploaded? How is the status of the job signalled to the right-hand pane? Where do I start adding debugging statements and assertions to help me see what is happening? Can the in-browser debugging mentioned in the config file help me out at all, and where can I find out more?
I'm happy to RTFM here but I've not yet found the right bit of the FM to read!
Cheers,
TIM
On Fri, 2013-10-04 at 15:12 +0100, Nate Coraor wrote:
On Oct 4, 2013, at 10:00 AM, John Chilton wrote:
I have seen this behavior too and I too have switched to Firefox, but I have only ever seen this with chrome on localhost, never with chrome on a remote server behind a proxy.
I've seen this issue before as well, a few of us have worked on it in the past, but it seems to be transient and not easy to reproduce. In my testing a couple years ago, I found that the call to ajaxSubmit() to actually POST the data never occurs, and I couldn't get Firebug to tell me why.
You can disable the AJAX upload method in tools/data_source/upload.xml, but that makes the UI a lot less usable, especially for large files.
--nate
-John
On Fri, Oct 4, 2013 at 8:55 AM, Carlos Borroto carlos.borroto@gmail.com wrote:
On Fri, Oct 4, 2013 at 8:11 AM, Tim Booth tbooth@ceh.ac.uk wrote:
When uploading a file, no job appears in the right-hand panel. If I click refresh I might see a job but it stays in the blue "Dataset is uploading" state forever.
Hi Tim,
It is great news to hear Galaxy deb packages could be a possibility in the near future. Regarding this issue, I can confirm I see it a lot on Chrome but never on Firefox. It has been so bad for me that I almost completely moved to using only Firefox when working on Galaxy. I thought it could be a cookies issue, but clearing out galaxy cookies from Chrome doesn't help in my case.
I'll be happy to do further testing as this is something I would love to see fixed.
Best, Carlos ___________________________________________________________ Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/
To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/
To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/
To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
-- Tim Booth tbooth@ceh.ac.uk NERC Environmental Bioinformatics Centre
Centre for Ecology and Hydrology Maclean Bldg, Benson Lane Crowmarsh Gifford Wallingford, England OX10 8BB
http://nebc.nerc.ac.uk +44 1491 69 2705
galaxy-dev@lists.galaxyproject.org
-
Carlos Borroto -
John Chilton -
Nate Coraor -
sam guerler -
Tim Booth