<body><div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000;text-align: left" dir="ltr">
                                        Hi Chris --<div><br></div><div>I just committed Morphic-mt.1983 and had again that long delay. At least, I got no network error. Hmmm...</div><div><br></div><div>Best,</div><div>Marcel</div><div class="mb_sig"></div><blockquote class='history_container' type='cite' style='border-left-style:solid;border-width:1px; margin-top:20px; margin-left:0px;padding-left:10px;'>
                        <p style='color: #AAAAAA; margin-top: 10px;'>Am 05.05.2022 10:09:55 schrieb Marcel Taeumel <marcel.taeumel@hpi.de>:</p><div style='font-family:Arial,Helvetica,sans-serif'><div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000;text-align: left" dir="ltr">
                                        Hi Chris --<div><br></div><div>That old <span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">201811272342 VM seems to work fine:</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">- </span><span style="font-family: Arial, Helvetica, sans-serif"><span style="font-size: 13px">https://github.com/marceltaeumel/squeak-ffi/actions</span></span></div><div><span style="font-family: Arial, Helvetica, sans-serif"><span style="font-size: 13px">- https://github.com/squeak-smalltalk/squeak-app/actions</span></span></div><div><span style="font-family: Arial, Helvetica, sans-serif"><span style="font-size: 13px"><br></span></span></div><div><span style="font-family: Arial, Helvetica, sans-serif"><span style="font-size: 13px">Now we have to figure out what the problem is with the new one.</span></span></div><div><span style="font-family: Arial, Helvetica, sans-serif"><span style="font-size: 13px">Network sockets? File handles? Flushing? Hmm...</span></span></div><div><span style="font-family: Arial, Helvetica, sans-serif"><span style="font-size: 13px"><br></span></span></div><div><span style="font-family: Arial, Helvetica, sans-serif"><span style="font-size: 13px">Best,</span></span></div><div><span style="font-family: Arial, Helvetica, sans-serif"><span style="font-size: 13px">Marcel</span></span></div><div class="mb_sig"></div><blockquote class='history_container' type='cite' style='border-left-style:solid;border-width:1px; margin-top:20px; margin-left:0px;padding-left:10px;'>
                        <p style='color: #AAAAAA; margin-top: 10px;'>Am 05.05.2022 03:15:44 schrieb Chris Muller <ma.chris.m@gmail.com>:</p><div style='font-family:Arial,Helvetica,sans-serif'>Hi Marcel, <br> <br>I had hope based on your excellent observations that looking at the <br>code would reveal some obvious concurrency issue, but nothing jumped <br>out at me.  It looks functionally identical to the old code that had <br>been working. <br> <br>So, let's just see if we can eliminate the VM by going back to the old <br>VM.  I _really_ wanted to try the production VM, 20200302, because I <br>believe it may support OSProcess AIO better.  Unfortunately, I cannot <br>get that VM to run at all on our server.  I can't even get it to <br>identify its version: <br>_____ <br>./sqcogspur64linuxht/squeak -version <br>./sqcogspur64linuxht/lib/squeak/5.0-202003021730/squeak: error while <br>loading shared libraries: libpulse-simple.so.0: cannot open shared <br>object file: No such file or directory <br>_____ <br> <br>SO, I'm back running on the old 201811272342 which we've been running for years. <br> <br>I can't work any more on this today, my testing was somewhat erratic. <br>I really hope the server does better tomorrow with this old VM.  If <br>not, I'll have to keep digging and possibly reconsider a different <br>design.  Otherwise, we should suspect the new vm.  Please let me know <br>how Thursday goes. <br> <br>Best, <br>  Chris <br> <br>On Wed, May 4, 2022 at 7:06 AM Marcel Taeumel <marcel.taeumel@hpi.de> wrote: <br>> <br>> I just made the squeak-app CI fail [1] by committing something to Trunk while the CI wanted to access source.squeak.org. <br>> <br>> Consequently, we have a serious concurrency problem with connections to that SqueakSource instance at the moment. :-) Maybe it is related to #primitiveFileFlush in FilePlugin? Hmm.... <br>> <br>> Best, <br>> Marcel <br>> <br>> [1] https://github.com/squeak-smalltalk/squeak-app/runs/6287653142?check_suite_focus=true <br>> <br>> Am 04.05.2022 10:36:03 schrieb Marcel Taeumel <marcel.taeumel@hpi.de>: <br>> <br>> Commiting to Trunk still takes 1-2 minutes to then fail with a Network error that it could not access source.squeak.org/trunk. <br>> <br>> Interestingly, as soon as the commit mail arrives in my inbox, the server is responsive again. In a parallel image, even the download stopped as if the entire SqueakSource image stopped responding just because something is waiting for something ... maybe related to a lock in the file system? Is it a flush operation that blocks the entire Squeak image? <br>> <br>> Best, <br>> Marcel <br>> <br>> Am 04.05.2022 09:26:39 schrieb Marcel Taeumel <marcel.taeumel@hpi.de>: <br>> <br>> Hi Chris -- <br>> <br>> Thanks for looking into this. :-) I will report back. <br>> <br>> Best, <br>> Marcel <br>> <br>> Am 04.05.2022 05:00:19 schrieb Chris Muller <asqueaker@gmail.com>: <br>> <br>> Hi Marcel, <br>> <br>> Sorry for the inconvenience! <br>> <br>> I switched back to the aggressive caching strategy from before, full performance *should* be restored.  I was trying a light caching strategy and expected slightly degraded performance only for the first few minutes after the server started, when it not only doesn't have anything cached, but performs its recovery process (in a lower background process, but still competitive for CPU).  But all that finished, so it shouldn't have been THAT slow.  The weird thing is the CPU was pegged at 100% even after it finished the recovery, but I couldn't find anything it was doing.  There's nothing it should've been doing, and running a MessageTally spyAllOn: [ (Delay forSeconds: 10) wait ] (in the running image via RFB connection) just showed basically Seaside waiting for a request.  This is why I'm normally conservative about wanting to use new VM's in production, but maybe this is a productive test then if it's the release-candidate and it uncovers any issues. <br>> <br>> So, I won't relax just yet, but I'm not working in trunk a lot, so I'm not as aware of the ebb and flow of the performance level.  Those performance reports were immensely helpful.  If issues arise again, please let me know. <br>> <br>>  - Chris <br>> <br>> On Tue, May 3, 2022 at 7:14 AM Marcel Taeumel <marcel.taeumel@hpi.de> wrote: <br>>> <br>>> Hi Chris -- <br>>> <br>>> It takes about 1-2 minutes to commit something to Trunk at the moment. Then I get a NetworkError in the image. Thus, it is currently not feasible to commit anything to Trunk. <br>>> <br>>> Let's see if we can resolve this until tomorrow. Then I will move the deadline for the 6.0 Feature Freeze for a week or two so that we can work on this issue.. <br>>> <br>>> Best, <br>>> Marcel <br>>> <br>>> Am 03.05.2022 12:09:11 schrieb Marcel Taeumel <marcel.taeumel@hpi.de>: <br>>> <br>>> Hi Chris -- <br>>> <br>>> Okay. Let's hope that the connectivity issues will resolve themselves in a few days. They still have not. Usually, updating a Trunk image from 19432 should take about 12 minutes. At the moment, it hits the 20-minutes marker. On my local machine, it just took about 40 minutes. <br>>> <br>>> On the bright side, there are no "NetworkErrors" or other things. Code loading works. It is just kind of slow. <br>>> <br>>> Best, <br>>> Marcel <br>>> <br>>> Am 02.05.2022 18:10:42 schrieb Chris Muller <ma.chris.m@gmail.com>: <br>>> <br>>> Okay, it is catching back up on recovering a bunch of versions since <br>>> last March and code loading would be in competition with that. I <br>>> might have to consider a different design yet. But it should clear up <br>>> pretty soon, although it looks like it's currently doing VMMaker which <br>>> are large Version objects. I *thought* I was only indexing the <br>>> Versions in 'trunk', but now I can't find where I restricted that. <br>>> <br>>> I'll keep my eye on it. Thanks for your patience. Let me know if it <br>>> gets too broken, I can always turn off the indexing again. <br>>> <br>>> On Mon, May 2, 2022 at 10:42 AM Chris Muller wrote: <br>>> > <br>>> > Hi Marcel, <br>>> > <br>>> > I didn't know about --headless, I had always used "-vm display=none", <br>>> > but now I've changed it to -vm-display-null which seems to be working <br>>> > with that 20220419 vm. I suppose we have about 3 different ways to <br>>> > launch in headless mode. <br>>> > <br>>> > That's strange about the builds. I can't think of anything that would <br>>> > be slowing down code loading, except I am seeing the VM using a lot of <br>>> > CPU right now when I don't think it should be. I just bounced it and <br>>> > now I see a process called "driveclient" using about half the CPU, and <br>>> > the server is not back up. Checking... <br>>> > <br>>> > On Mon, May 2, 2022 at 3:55 AM Marcel Taeumel wrote: <br>>> > > <br>>> > > Hi Chris -- <br>>> > > <br>>> > > Thanks for upgrading our backend to Squeak 5.3! Note that the --headless mode in the 20220419 VM is not working. We will do another RC for that. The bug itself got already fixed [2]. Squeak-ffi tests also show the code-loading issue [3]. <br>>> > > <br>>> > > Hmmm... access to source.squeak.org is flakey again. squeak-app builds [1] are not running through because code loading times out. <br>>> > > <br>>> > > Can you see from the logs what is happening? <br>>> > > <br>>> > > Best, <br>>> > > Marcel <br>>> > > <br>>> > > [1] https://github.com/squeak-smalltalk/squeak-app/actions <br>>> > > [2] https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/2d7105db755928fd90823d264fc64e17b1c57ad4 <br>>> > > [3] https://github.com/marceltaeumel/squeak-ffi/actions <br>>> > > <br>>> > > <br>>> > > Am 02.05.2022 03:42:46 schrieb Chris Muller : <br>>> > > <br>>> > > Hi all, <br>>> > > <br>>> > > Revision history is working in the IDE again. The SqueakSource instance behind source.squeak.org has been upgraded to Squeak 5.3 and the 20220419 vm, and now requires less RAM thanks to some design optimizations. <br>>> > > <br>>> > > - Chris <br>>> <br>>> <br></ma.chris.m@gmail.com></marcel.taeumel@hpi.de></marcel.taeumel@hpi.de></asqueaker@gmail.com></marcel.taeumel@hpi.de></marcel.taeumel@hpi.de></marcel.taeumel@hpi.de></div></blockquote>
                                        </div></div></blockquote>
                                        </div></body>