-
Notifications
You must be signed in to change notification settings - Fork 385
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Genome switching via port commands does not always work correctly #1271
Comments
You say "very often the second instance tries to load a genome and
fails...". Any idea why it fails? If it fails DEFAULT_GENOME_KEY
might come into play, but not before.
…On Mon, Dec 19, 2022 at 2:40 AM Alexandr Chernov ***@***.***> wrote:
Hello Jim,
I have encountered a strange problem while switching between genomes by
means of port commands.
We have two instances of IGV running at the same time on different ports.
Each of them is initialized and started via port commands. The instances
use different genomes. Very often the second instance tries to load a
genome and fails, after that it switches to the genome used by the first
instance. Sometimes when the second instance is loaded with the correct
genome IGV duplicates the Sequence track (see the screenshot):
[image: image]
<https://user-images.githubusercontent.com/5293569/208402860-b3078856-130c-40d2-9b51-891a36d6ad16.png>
I suspect that it may have something to do with the "DEFAULT_GENOME_KEY"
from the settings. IGV overwrites the settings file each time we load a
genome via port commands and switch genomes (also via port commands).
In the log file I often see a severe error message for the second genome
saying: "[ReferenceFrame]" Null chromosome:"
As far as I understood from the source code, each port command is running
in a separate thread (but I did not dig too deep). Is it possible that the
genome thread is too slow, but IGV does not care about it and loads all the
rest tracks? I also tried to use "setSleepInterval" command to introduce an
artificial delay before loading a genome and it improved the situation.
However, IGV still does not work reliably for our scenario with two
instances.
The problem is very difficult reproduce and I could not come up with a
better description. We also believe that it may be related to the bug we
reported earlier: #1094 <#1094>
I will try to debug it and will let you know, if I find out more.
—
Reply to this email directly, view it on GitHub
<#1271>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAHD2HGXO3IQBCLEUYDVJN3WOA3RTANCNFSM6AAAAAATDGRRHY>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
Thank you for replying so quickly. It is hard to be very specific, since the problem does not occur consistently (or I have not found the pattern yet). By saying "very often" I mean in 80-90% of cases. I assume that simultaneous writing/reading to/from the same config file (by different IGV instances) maybe causing that. It seems to me that modifying the config after calling the "genome" port command is not a good idea. Maybe the modification of the settings should be made only from the GUI. |
I'm not sure why this is still open, commit a41b029 should fix it. If the problem recurs reopen with specifics. |
Hello Jim,
I have encountered a strange problem while switching between genomes by means of port commands.
We have two instances of IGV running at the same time on different ports. Each of them is initialized and started via port commands. The instances use different genomes. Very often the second instance tries to load a genome and fails, after that it switches to the genome used by the first instance. Sometimes when the second instance is loaded with the correct genome IGV duplicates the Sequence track (see the screenshot):
I suspect that it may have something to do with the "DEFAULT_GENOME_KEY" from the settings. IGV overwrites the settings file each time we load a genome via port commands and switch genomes (also via port commands).
In the log file I often see a severe error message for the second genome saying: "[ReferenceFrame] Null chromosome:"
As far as I understood from the source code, each port command is running in a separate thread (but I did not dig too deep). Is it possible that the genome thread is too slow, but IGV does not care about it and loads all the rest tracks? I also tried to use "setSleepInterval" command to introduce an artificial delay before loading a genome and it improved the situation. However, IGV still does not work reliably for our scenario with two instances.
The problem is very difficult reproduce and I could not come up with a better description. We also believe that it may be related to the bug we reported earlier: #1094
I will try to debug it and will let you know, if I find out more.
The text was updated successfully, but these errors were encountered: