1)
Message boards :
Number crunching :
Anonymous Platform - Scheduler request failed: HTTP internal server error
(Message 38916)
Posted 20 May 2019 by Jacob Klein Post: Thanks for confirmation of the problem. Please be sure to post a link here, to the dev server thread, when you create one. Thanks again. |
2)
Message boards :
Number crunching :
Anonymous Platform - Scheduler request failed: HTTP internal server error
(Message 38905)
Posted 19 May 2019 by Jacob Klein Post: I did try it, hence the report. No need to be like that. It has admittedly been a long time since I've done app_info testing. If I mixed up file_info instead of file, then that could be a culprit. Thanks for giving me ideas to try again. But I could have sworn this worked fine before using file tags. I must not be paying enough attention about things maybe. Could you try with file tags and see what you get? PS: It's not redundant. My goal is to test all 3 applications against the vboxwrapper, so I set up a single app_info.xml file to do that. |
3)
Message boards :
Number crunching :
Anonymous Platform - Scheduler request failed: HTTP internal server error
(Message 38899)
Posted 19 May 2019 by Jacob Klein Post: I doubt it. Scheduler replies were working just fine, before and after, when not using the app_info.xml. Can you try? |
4)
Message boards :
Number crunching :
Anonymous Platform - Scheduler request failed: HTTP internal server error
(Message 38897)
Posted 19 May 2019 by Jacob Klein Post: Thanks. I think I'll have to wait a week to test it again, going out of town until next Monday. Regarding the original post, were you able to repro the "Scheduler request failed: HTTP internal server error" when trying to get tasks with a 26202 app_info.xml in place? |
5)
Message boards :
Number crunching :
Anonymous Platform - Scheduler request failed: HTTP internal server error
(Message 38895)
Posted 19 May 2019 by Jacob Klein Post: Any chance you could also test on Windows 10? I will also redo my testing, using a release OS version instead of Insider version, and using a release version of VirtualBox instead of a Testbuild. Perhaps I'm hitting on a beta bug. It would explain why 26202 seemed to work fine for me earlier, and now doesn't. |
6)
Message boards :
Number crunching :
Anonymous Platform - Scheduler request failed: HTTP internal server error
(Message 38892)
Posted 18 May 2019 by Jacob Klein Post: If your post is unrelated to: Scheduler request failed: HTTP internal server error ... then move it to a new thread please, per etiquette. |
7)
Message boards :
Number crunching :
Anonymous Platform - Scheduler request failed: HTTP internal server error
(Message 38890)
Posted 18 May 2019 by Jacob Klein Post: Hi Crystal, I don't think the space matters. This web issue deals with the server code processing my sched_request, I believe. Dev support will be needed to fix it. Edit: How did you see my data folder - were you already inspecting web logs? :) Something is broken. Also, yes please test vboxwrapper 26202. I'm noticing some big problems with it, and I'm logging them here: https://github.com/BOINC/boinc/issues/2915 |
8)
Message boards :
Number crunching :
Anonymous Platform - Scheduler request failed: HTTP internal server error
(Message 38888)
Posted 18 May 2019 by Jacob Klein Post: Hey LHC Devs, I was doing some testing today, to see how compatible the new 26202 vboxwrapper is for your apps. But I hit a problem during work fetch. Could you please take a look, and let us know what you find? Thanks! Work fetch log: 5/18/2019 9:26:10 AM | LHC@home | Requesting new tasks for CPU 5/18/2019 9:26:13 AM | LHC@home | Scheduler request failed: HTTP internal server error 5/18/2019 9:26:13 AM | | [work_fetch] Request work fetch: RPC complete sched_reply_lhcathome.cern.ch_lhcathome.xml: <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>500 Internal Server Error</title> </head><body> <h1>Internal Server Error</h1> <p>The server encountered an internal error or misconfiguration and was unable to complete your request.</p> <p>Please contact the server administrator at boinc-server-admin@cern.ch to inform them of the time this error occurred, and the actions you performed just before this error.</p> <p>More information about this error may be available in the server error log.</p> </body></html> app_info.xml (with all related files in the project folder): <app_info> <app> <name>CMS</name> <user_friendly_name>CMS Simulation</user_friendly_name> <non_cpu_intensive>0</non_cpu_intensive> </app> <app> <name>Theory</name> <user_friendly_name>Theory Simulation</user_friendly_name> <non_cpu_intensive>0</non_cpu_intensive> </app> <app> <name>ATLAS</name> <user_friendly_name>ATLAS Simulation</user_friendly_name> <non_cpu_intensive>0</non_cpu_intensive> </app> <file> <name>vboxwrapper_26202_windows_x86_64.exe</name> <nbytes>1639936.000000</nbytes> <max_nbytes>0.000000</max_nbytes> <status>1</status> <executable/> </file> <file> <name>CMS_2016_03_22.xml</name> <nbytes>577.000000</nbytes> <max_nbytes>0.000000</max_nbytes> <status>1</status> </file> <file> <name>CMS_2019_03_25.vdi</name> <nbytes>3008364544.000000</nbytes> <max_nbytes>0.000000</max_nbytes> <status>1</status> </file> <file> <name>Theory_2017_05_29.xml</name> <nbytes>615.000000</nbytes> <max_nbytes>0.000000</max_nbytes> <status>1</status> </file> <file> <name>Theory_2018_11_23.vdi</name> <nbytes>504365056.000000</nbytes> <max_nbytes>0.000000</max_nbytes> <status>1</status> </file> <file> <name>ATLAS_2017_01_09.xml</name> <nbytes>451.000000</nbytes> <max_nbytes>0.000000</max_nbytes> <status>1</status> </file> <file> <name>ATLASM_2017_03_01.vdi</name> <nbytes>1745879040.000000</nbytes> <max_nbytes>0.000000</max_nbytes> <status>1</status> <executable/> </file> <file> <name>vboxwrapper_26202_windows_x86_64.pdb</name> <nbytes>7392256.000000</nbytes> <max_nbytes>0.000000</max_nbytes> <status>1</status> <executable/> </file> <app_version> <app_name>CMS</app_name> <version_num>4900</version_num> <platform>windows_x86_64</platform> <avg_ncpus>1.000000</avg_ncpus> <flops>30512450318.842464</flops> <plan_class>vbox64</plan_class> <api_version>7.7.0</api_version> <file_ref> <file_name>vboxwrapper_26202_windows_x86_64.exe</file_name> <main_program/> </file_ref> <file_ref> <file_name>CMS_2016_03_22.xml</file_name> <open_name>vbox_job.xml</open_name> </file_ref> <file_ref> <file_name>CMS_2019_03_25.vdi</file_name> <open_name>vm_image.vdi</open_name> <copy_file/> </file_ref> <dont_throttle/> <needs_network/> </app_version> <app_version> <app_name>Theory</app_name> <version_num>26390</version_num> <platform>windows_x86_64</platform> <avg_ncpus>2.000000</avg_ncpus> <flops>9003518068.638815</flops> <plan_class>vbox64_mt_mcore</plan_class> <api_version>7.7.0</api_version> <cmdline>--memory_size_mb 830</cmdline> <file_ref> <file_name>vboxwrapper_26202_windows_x86_64.exe</file_name> <main_program/> </file_ref> <file_ref> <file_name>Theory_2017_05_29.xml</file_name> <open_name>vbox_job.xml</open_name> </file_ref> <file_ref> <file_name>Theory_2018_11_23.vdi</file_name> <open_name>vm_image.vdi</open_name> <copy_file/> </file_ref> <dont_throttle/> <needs_network/> </app_version> <app_version> <app_name>ATLAS</app_name> <version_num>101</version_num> <platform>windows_x86_64</platform> <avg_ncpus>4.000000</avg_ncpus> <flops>3017627035.548801</flops> <plan_class>vbox64_mt_mcore_atlas</plan_class> <api_version>7.7.0</api_version> <cmdline>--memory_size_mb 6600</cmdline> <file_ref> <file_name>vboxwrapper_26202_windows_x86_64.exe</file_name> <main_program/> </file_ref> <file_ref> <file_name>ATLAS_2017_01_09.xml</file_name> <open_name>vbox_job.xml</open_name> </file_ref> <file_ref> <file_name>ATLASM_2017_03_01.vdi</file_name> <open_name>vm_image.vdi</open_name> <copy_file/> </file_ref> <file_ref> <file_name>vboxwrapper_26202_windows_x86_64.pdb</file_name> <open_name>vboxwrapper_26202_windows_x86_64.pdb</open_name> <copy_file/> </file_ref> <dont_throttle/> <is_wrapper/> <needs_network/> </app_version> </app_info> |
9)
Message boards :
LHC@home Science :
Sixtrack apps - Bad "api_version" - BOINC 7.8.2 display grids failing
(Message 32414)
Posted 13 Sep 2017 by Jacob Klein Post: Wow. He's not saying that your reply is corrupted. His wasn't. I think he's saying that BOINC is expecting 16 chars or less for that field, and will have problems if you put so much in there. Why can't that field just say "7.7.0" ? <api_version>7.7.0 API_VERSION LPAPI_VERSION</api_version> |
10)
Message boards :
LHC@home Science :
Sixtrack apps - Bad "api_version" - BOINC 7.8.2 display grids failing
(Message 32388)
Posted 11 Sep 2017 by Jacob Klein Post: Might be useful to search for: API_VERSI |
11)
Message boards :
LHC@home Science :
Sixtrack apps - Bad "api_version" - BOINC 7.8.2 display grids failing
(Message 32386)
Posted 11 Sep 2017 by Jacob Klein Post: I'm an active BOINC Alpha tester, attached to all of the projects, routinely getting work from about 11 ... and this is the first time I've ever seen this problem. The only applications I've ever seen this problem with, are Sixtrack and Sixtracktest, on BOINC 7.8.2. Note: This new version of BOINC (client AND server) does have many string sprintf changes. It's possible that something isn't terminating a string correctly, or a reader isn't reading correctly. I'm attached to your dev project too, but my workload doesn't really offer much of a chance to do work for your projects. I'll try to adjust that. Regarding "how" it might be garbled ... Please read the following, which might help you do some testing to see if you can recreate the problem or find the fault. Richard Haselgrove (another tester who knows much more about the code than I do), said this, to the BOINC Alpha list service:
Let us know what you find! Kind regards, Jacob Klein |
12)
Message boards :
LHC@home Science :
Sixtrack apps - Bad "api_version" - BOINC 7.8.2 display grids failing
(Message 32368)
Posted 9 Sep 2017 by Jacob Klein Post: I'm still troubleshooting, and the bug (where it crashes the 7.8.2 BOINC Manager) is a little bit elusive, but... I think sometimes it'll say: API_VERSI</api_version> and sometimes it'll say API_VERSI*</api_version> where * is some crazy binary character. If that binary character gets into a sched_reply or your client_state.xml file, and attempted to be loaded into memory, then things get hosed. Either way, I believe that LHC@Home fixing <api_version> will be the answer. Can we get it fixed? PS: You can encapsulate a block in "pre" (for pre-formatted text), to keep the formatting and tab stops. |
13)
Message boards :
LHC@home Science :
Sixtrack apps - Bad "api_version" - BOINC 7.8.2 display grids failing
(Message 32358)
Posted 8 Sep 2017 by Jacob Klein Post: I'm noticing a problem, where BOINC 7.8.2 Advanced View will fail to correctly load the Project/Task grids, every second, only partially loading, then reloading, repeatedly. I've tracked it to this project, specifically to apps having bad info within their "api_version" XML properties. This causes the 7.8.2 manager to freak out trying to parse that xml and read the strings! Once I remove this project, all is well. But then when I re-added it, it broke again! Could you guys please investigate how your <api_version> XML properties are becoming messed up, and fix it? Note: The first one has a binary character before the close tag, which is ultimately what hoses BOINC, I think. But I don't know how. See below. Thanks, Jacob Klein For sure caused a problem: <app_version> <app_name>sixtracktest</app_name> <version_num>4630</version_num> <platform>windows_x86_64</platform> <avg_ncpus>1.000000</avg_ncpus> <max_ncpus>1.000000</max_ncpus> <flops>4763423249.552478</flops> <plan_class>sse2</plan_class> <api_version>7.7.0 API_VERSI</api_version> <file_ref> <file_name>sixtracktest_win64_4630_sse2.exe</file_name> <main_program/> </file_ref> </app_version> Older set, that maybe caused a problem: <app_version> <app_name>sixtrack</app_name> <version_num>45107</version_num> <platform>windows_intelx86</platform> <avg_ncpus>1.000000</avg_ncpus> <max_ncpus>1.000000</max_ncpus> <flops>6757081731.981332</flops> <plan_class>pni</plan_class> <api_version>7.1.0</api_version> <file_ref> <file_name>sixtrack_win32_4517_pni.exe</file_name> <main_program/> </file_ref> </app_version> <app_version> <app_name>sixtrack</app_name> <version_num>4630</version_num> <platform>windows_intelx86</platform> <avg_ncpus>1.000000</avg_ncpus> <max_ncpus>1.000000</max_ncpus> <flops>14855145875.554390</flops> <plan_class>sse2</plan_class> <api_version>7.7.0 API_VERSI</api_version> <file_ref> <file_name>sixtrack_win32_4630_sse2.exe</file_name> <main_program/> </file_ref> </app_version> <app_version> <app_name>sixtrack</app_name> <version_num>4630</version_num> <platform>windows_x86_64</platform> <avg_ncpus>1.000000</avg_ncpus> <max_ncpus>1.000000</max_ncpus> <flops>19207728646.985275</flops> <plan_class>sse2</plan_class> <api_version>7.7.0 API_VERSI</api_version> <file_ref> <file_name>sixtrack_win64_4630_sse2.exe</file_name> <main_program/> </file_ref> </app_version> <app_version> <app_name>sixtracktest</app_name> <version_num>4630</version_num> <platform>windows_intelx86</platform> <avg_ncpus>1.000000</avg_ncpus> <max_ncpus>1.000000</max_ncpus> <flops>4480961228.675860</flops> <plan_class>sse2</plan_class> <api_version>7.7.0 API_VERSI</api_version> <file_ref> <file_name>sixtracktest_win32_4630_sse2.exe</file_name> <main_program/> </file_ref> </app_version> |
©2024 CERN