WARNING:galaxy.datatypes.registry:Overriding conflicting datatype
I now have 2 versions of snpeff installed from the toolshed on my galaxy server. Each snpeff version includes an identical datatypes_conf.xml The galaxy server is setting metadata externally. When any job runs, (in may case I was running a picard tool), the following message is written to the job stderr: WARNING:galaxy.datatypes.registry:Overriding conflicting datatype with extension 'snpeffdb', using datatype from /galaxy/database/tmp/tmpdKGVnQ. Without stdio tags or otherwise catching the stderr, the job state is set to error. I'm now assuming that best practice would be to put the datatypes in a separate toolshed repository that would be a dependency for the tools repository. Thus the datatypes would not loaded multiple times and avoid overrride conflicts. In the meantime, I have just commented out the warning message. Any other advice on this issue? Thanks, JJ -- James E. Johnson, Minnesota Supercomputing Institute, University of Minnesota
Hi JJ, On Feb 13, 2014, at 11:00 AM, Jim Johnson <johns198@umn.edu> wrote:
I now have 2 versions of snpeff installed from the toolshed on my galaxy server. Each snpeff version includes an identical datatypes_conf.xml The galaxy server is setting metadata externally.
When any job runs, (in may case I was running a picard tool), the following message is written to the job stderr: WARNING:galaxy.datatypes.registry:Overriding conflicting datatype with extension 'snpeffdb', using datatype from /galaxy/database/tmp/tmpdKGVnQ. Without stdio tags or otherwise catching the stderr, the job state is set to error.
I believe I'm responsible for the above warning message, but I'm not sure I like the resulting behavior - I wasn't aware that the job runner now captures warning messages like this and sets the job state to error. At the time I enhance the Galaxy datatypes components to work with the Tool Shed, this was not the behavior.
I'm now assuming that best practice would be to put the datatypes in a separate toolshed repository that would be a dependency for the tools repository. Thus the datatypes would not loaded multiple times and avoid overrride conflicts.
Yes, the above plan would be a "best practice".
In the meantime, I have just commented out the warning message.
Any other advice on this issue?
I'm wondering if we should just eliminate the warning message altogether sicne it now results in jobe errors. Do others agree?
Thanks,
JJ
-- James E. Johnson, Minnesota Supercomputing Institute, University of Minnesota
On Thu, Feb 13, 2014 at 4:22 PM, Greg Von Kuster <greg@bx.psu.edu> wrote:
Hi JJ,
On Feb 13, 2014, at 11:00 AM, Jim Johnson <johns198@umn.edu> wrote:
I now have 2 versions of snpeff installed from the toolshed on my galaxy server. Each snpeff version includes an identical datatypes_conf.xml The galaxy server is setting metadata externally.
When any job runs, (in may case I was running a picard tool), the following message is written to the job stderr: WARNING:galaxy.datatypes.registry:Overriding conflicting datatype with extension 'snpeffdb', using datatype from /galaxy/database/tmp/tmpdKGVnQ. Without stdio tags or otherwise catching the stderr, the job state is set to error.
I believe I'm responsible for the above warning message, but I'm not sure I like the resulting behavior - I wasn't aware that the job runner now captures warning messages like this and sets the job state to error. At the time I enhance the Galaxy datatypes components to work with the Tool Shed, this was not the behavior.
Anything on stderr from a tool has always been treated as an error (which I think was a bad design choice with hindsight). Had something changed with regards to something like the external metadata tasks being run as part of the job?
In the meantime, I have just commented out the warning message. Any other advice on this issue?
I'm wondering if we should just eliminate the warning message altogether sicne it now results in jobe errors. Do others agree?
Probably... Peter
On 2/13/14, 10:22 AM, Greg Von Kuster wrote:
Hi JJ,
On Feb 13, 2014, at 11:00 AM, Jim Johnson <johns198@umn.edu> wrote:
I now have 2 versions of snpeff installed from the toolshed on my galaxy server. Each snpeff version includes an identical datatypes_conf.xml The galaxy server is setting metadata externally.
When any job runs, (in may case I was running a picard tool), the following message is written to the job stderr: WARNING:galaxy.datatypes.registry:Overriding conflicting datatype with extension 'snpeffdb', using datatype from /galaxy/database/tmp/tmpdKGVnQ. Without stdio tags or otherwise catching the stderr, the job state is set to error. I believe I'm responsible for the above warning message, but I'm not sure I like the resulting behavior - I wasn't aware that the job runner now captures warning messages like this and sets the job state to error. At the time I enhance the Galaxy datatypes components to work with the Tool Shed, this was not the behavior.
I'm now assuming that best practice would be to put the datatypes in a separate toolshed repository that would be a dependency for the tools repository. Thus the datatypes would not loaded multiple times and avoid overrride conflicts. Yes, the above plan would be a "best practice". Though I could still have some issues on my test galaxy instance, since I often have tools from both the toolshed and testtoolshed simultaneously.
In the meantime, I have just commented out the warning message.
Any other advice on this issue? I'm wondering if we should just eliminate the warning message altogether sicne it now results in jobe errors. Do others agree?
Thanks,
JJ
-- James E. Johnson, Minnesota Supercomputing Institute, University of Minnesota Or we could move it to log.debug level, which wouldn't usually be set on a production server.
JJ -- James E. Johnson, Minnesota Supercomputing Institute, University of Minnesota
I've gone ahead and made the change in the datatypes registry to use log.debu instead of log.warning, so hopefully this issue is resolved. The changeset in central is 12497:0b0018fa5d20, which has also be grafted to stable. Greg Von Kuster On Feb 13, 2014, at 11:51 AM, Jim Johnson <johns198@umn.edu> wrote:
On 2/13/14, 10:22 AM, Greg Von Kuster wrote:
Hi JJ,
On Feb 13, 2014, at 11:00 AM, Jim Johnson <johns198@umn.edu> wrote:
I now have 2 versions of snpeff installed from the toolshed on my galaxy server. Each snpeff version includes an identical datatypes_conf.xml The galaxy server is setting metadata externally.
When any job runs, (in may case I was running a picard tool), the following message is written to the job stderr: WARNING:galaxy.datatypes.registry:Overriding conflicting datatype with extension 'snpeffdb', using datatype from /galaxy/database/tmp/tmpdKGVnQ. Without stdio tags or otherwise catching the stderr, the job state is set to error. I believe I'm responsible for the above warning message, but I'm not sure I like the resulting behavior - I wasn't aware that the job runner now captures warning messages like this and sets the job state to error. At the time I enhance the Galaxy datatypes components to work with the Tool Shed, this was not the behavior.
I'm now assuming that best practice would be to put the datatypes in a separate toolshed repository that would be a dependency for the tools repository. Thus the datatypes would not loaded multiple times and avoid overrride conflicts. Yes, the above plan would be a "best practice". Though I could still have some issues on my test galaxy instance, since I often have tools from both the toolshed and testtoolshed simultaneously.
In the meantime, I have just commented out the warning message.
Any other advice on this issue? I'm wondering if we should just eliminate the warning message altogether sicne it now results in jobe errors. Do others agree?
Thanks,
JJ -- James E. Johnson, Minnesota Supercomputing Institute, University of Minnesota Or we could move it to log.debug level, which wouldn't usually be set on a production server.
JJ
-- James E. Johnson, Minnesota Supercomputing Institute, University of Minnesota ___________________________________________________________ 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/
participants (3)
-
Greg Von Kuster -
Jim Johnson -
Peter Cock