Bioinformatics.org
[University of Birmingham]
[Patsnap]
Not logged in
  • Log in
    		•

    Bioinformatics.org
    Membership (44527+) Group hosting [?] Wiki
    Franklin Award
    Sponsorships

    Careers
    About bioinformatics
    Bioinformatics jobs

    Research
    All information groups
    Online databases Online analysis tools Online education tools More tools

    Development
    All software groups
    FTP repository
    SVN & CVS repositories [?]
    Mailing lists

    Forums
    News & Commentary
  • Submit
  • Archives
  • Subscribe

    • Jobs Forum
    (Career Center)
  • Submit
  • Archives
  • Subscribe
    		•

    BIRCH: Comprehensive bioinfo. system - Support tickets

    Submit | Open tickets | Closed tickets

    [ Ticket #1212 ] Getbirch hangs when untaring framework file
    Date:
    11/05/16 18:50
    Submitted by:
    B_Fristensky     		Assigned to:
    B_Fristensky
    Category:
    Getbirch     		Priority:
    8
    Ticket group:
    Bug     		Resolution:
    Resolved
    Summary:
    Getbirch hangs when untaring framework file
    Original submission:
    Getbirch often hangs when untaring framework.tar.gz files. This does not always happen, but happens often enough to be a problem. Sometimes it is necessary to cancel an install or update and start from the beginning, which requires a complete download of the framework and binaries.

    I can only guess at the cause. Two things come to mind:

    1) The default buffer size for the output stream to the log file, found in BIRCHIO.java. This appears to be set to 1000. the official Java default is 4096, based on one posting. Since file extraction generates a lot of output, the buffer size could make a difference.

    2) Would it help to run garbage collection before extracting each tar file? It probably couldn't hurt.
    Please log in to add comments and receive followups via email.
    Followups
    Comment Date By
    To fix the problem on Mac, I had to revert BIRCHIO.java to the original file from BIRCH 3.20. This reverts the elimination of the err thread, and launching tar after launching the threads. The increased buffer size in StreamCopier to 16384 remained the same. This worked in 7 installs on various flavors of Linux and 2 different Mac systems. 11/20/16 18:54 B_Fristensky
    Launching birchadmin in the forground from birch appears to fix the problem on Linux, but not on MacOSX. Even directly launching the jar file from the finder still results in no messages at all being printed while tar is running. Killing the installer allows tar to complete, but of course prevents the birch_install.py from running on Mac. Launching getbirch.jar from the command line gives the same result: no messages at all from tar. 11/20/16 16:22 B_Fristensky
    In $BIRCH/dat/birch/PCD/File/birchadmin.blmenu, birchadmin was being launched in the background: (birchadmin)&. Simply removing the ampersand and parentheses seems to have fixed the problem. Still need to test on multiple platforms. 11/20/16 15:01 B_Fristensky
    Important clue: When launching an update from birchadmin, the update process hangs. However, killing birchadmin causes the rest of the messages from tar to scroll down the message window, and the install completes normally.

    So it looks like there is something to do with being called from birchadmin that, perhaps, prevents the output buffer from getting flushed, so that the install can proceed to the end. The solution may be to figure out how to detach the output from update from birchadmin.     		11/19/16 18:35 B_Fristensky
    3) The order in which threads are activated can have an effect on whether or not threads get deadlocked:
    http://javarevisited.blogspot.ca/2010/10/what-is-deadlock-in-java-how-to-fix-it.html

    Tried moving the process.waitFor command to launch tar after starting the output threads. This way, the buffers are already waiting for output from tar when tar is launched.
    		11/19/16 15:23 B_Fristensky
    Oops, spoke too soon. Upping the buffer to 16384. 11/07/16 18:26 B_Fristensky
    Increased DEFAULT_BUFFER_SIZE to 8192. So far, install on 6 different systems have gone perfectly. Since failure to complete unpacking happened probably once every 2 or 3 installs, this counts as an improvement, if not a complete fix. We'll close this bug, and reopen if the problem reoccurs.

    The fix makes sense, because getbirch opens two threads for echoing the progress of an install, one to standard output and one to standard error. That would be at least 3 independent threads running, and the more often they have to be interrupted, the more chance there is for failure to continue. A larger buffer size means threads are interrupted less often.     		11/07/16 17:55 B_Fristensky
    No results for "Dependent on ticket"
    No results for "Dependent on Task"
    No other tickets are dependent on this ticket
    Ticket change history
    Field Old value Date By
    status_id Open 11/21/16 13:42 B_Fristensky
    resolution_id Not Resolved 11/21/16 13:42 B_Fristensky
    close_date 11/07/16 18:26 11/21/16 13:42 B_Fristensky
    status_id Closed 11/19/16 15:23 B_Fristensky
    priority 5 11/19/16 15:23 B_Fristensky
    resolution_id Resolved 11/19/16 15:23 B_Fristensky
    close_date 11/07/16 17:55 11/07/16 18:26 B_Fristensky
    status_id Open 11/07/16 17:55 B_Fristensky
    resolution_id Not Resolved 11/07/16 17:55 B_Fristensky
    close_date 12/31/69 19:00 11/07/16 17:55 B_Fristensky
    status_id Pending 11/05/16 18:51 B_Fristensky
    assigned_to unset 11/05/16 18:51 B_Fristensky
    resolution_id Unset 11/05/16 18:51 B_Fristensky

     
    Copyright © 2024 Scilico, LLC · Privacy Policy