Re: [galaxy-dev] Blank history panel / Error in history API at listing contents

2013-01-25 Thread Carl Eberhard
They likely shouldn't say 'Error' and do increase the noise to signal in
the logs.

The web transactions have a convenience function for getting the most
current history for that transaction's user (get_history). If I understand
correctly, these messages occur the transaction can't get or create a
history ( when no user is currently logged in - or other situations
where such as web crawlers).

You can also see these messages in the day-to-day logs of your server,
local instance, or the Galaxy main or test servers. As far as I know,
they're harmless.
C



On Fri, Jan 25, 2013 at 5:41 AM, Peter Cock p.j.a.c...@googlemail.comwrote:

 On Tue, Jan 22, 2013 at 4:43 PM, Carl Eberhard carlfeberh...@gmail.com
 wrote:
  Short form:
  Both the API and client side should handle single datasets error-ing
 more
  gracefully than they did and the history panel should be more
 resilient and
  useful during and after a server error (at least of this kind).
 
  Please let me know if you see more problems,
  C

 I'm seeing some (apparently harmless) errors in the output during the
 'upload'
 step when running Galaxy unit tests - in this case for one of my tools:

 functional_tests.py INFO 2013-01-25 10:37:19,810 Functional tests will
 be run against localhost:9500
 nose.plugins.manager DEBUG 2013-01-25 10:37:19,865
 DefaultPluginManager load plugin sqlalchemy =
 sqlalchemy.test.noseplugin:NoseSQLAlchemy
 nose.plugins.manager DEBUG 2013-01-25 10:37:19,986
 DefaultPluginManager load plugin nosetestdiff =
 nosetestdiff.plugin:NoseTestDiff
 nose.plugins.manager DEBUG 2013-01-25 10:37:19,989
 DefaultPluginManager load plugin nosehtml = nosehtml.plugin:NoseHTML
 TMHMM 2.0 ( tmhmm2 )  Test-1 ... galaxy.web.framework DEBUG
 2013-01-25 10:37:20,366 Error: this request returned None from
 get_history(): http://localhost:9500/
 galaxy.web.framework DEBUG 2013-01-25 10:37:20,425 Error: this request
 returned None from get_history(): http://localhost:9500/
 galaxy.web.framework DEBUG 2013-01-25 10:37:20,676 Error: this request
 returned None from get_history(): http://localhost:9500/user/logout
 galaxy.web.framework DEBUG 2013-01-25 10:37:20,731 Error: this request
 returned None from get_history(): http://localhost:9500/
 galaxy.tools.actions.upload_common INFO 2013-01-25 10:37:24,312 tool
 upload1 created job id 1
 galaxy.jobs.manager DEBUG 2013-01-25 10:37:27,460 (1) Job assigned to
 handler 'main'
 galaxy.jobs DEBUG 2013-01-25 10:37:32,755 (1) Working directory for
 job is: /mnt/galaxy/galaxy-central/database/job_working_directory/000/1
 galaxy.jobs.handler DEBUG 2013-01-25 10:37:32,755 dispatching job 1 to
 local runner
 galaxy.jobs.handler INFO 2013-01-25 10:37:33,041 (1) Job dispatched
 galaxy.jobs.runners.local DEBUG 2013-01-25 10:37:33,153 Local runner:
 starting job 1
 galaxy.jobs.runners.local DEBUG 2013-01-25 10:37:33,712 executing: ...

 Are these lines just false positives?
 Error: this request returned None from get_history():
 http://localhost:9500/
 Error: this request returned None from get_history():
 http://localhost:9500/user/logout
 Error: this request returned None from get_history():
 http://localhost:9500/

 Thanks,

 Peter

___
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/

Re: [galaxy-dev] Blank history panel / Error in history API at listing contents

2013-01-17 Thread Peter Cock
On Thursday, January 17, 2013, Carl Eberhard wrote:

 Hello, Peter

 The blank panel should definitely be handled more gracefully in this
 situation - I'll work on that.


Great :)


 Have you noticed though, since your patch, any particular pattern to which
 metadata names are turning out to equal None (some obviously missing
 metadata field)? Is there a particular datatype?


No, and thus far I've only had it on my development Galaxy install which
has (compared to a production system) been exposed to plenty of cluster
oddities and other corner cases. It is also running on SQLite (easy to
reset and it is just me running jobs so contention is not normally an
issue).

Note that without adding more debugging or looking directly in the database
there is no easy way to tell what the datasets causing this problem were,
or what file type.




Have you seen the assertion fail?
 C


Not yet, no. The fact the two fields were both None suggests to me
sometimes an entry was not recorded properly...

Regards,

Peter
___
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/