On Wed, Oct 9, 2013 at 11:42 AM, David T. Lewis lewis@mail.msen.com wrote:
On Wed, Oct 09, 2013 at 10:23:06AM -0500, Chris Muller wrote:
On Tue, Oct 08, 2013 at 07:54:05PM -0500, Chris Muller wrote:
I just deployed an updated image for "new trunk" at box4.squeak.org:8888/trunk. This is the one that uses the Magma backend. I haven't done any benchmarks but the response time seems pretty snappy, even compared to regular source.squeak.org. Could be due to Cog, the Magma backend, or box4 being under less load than box3.
It might be all of the above. I'm thinking that the priority for the squeaksource.com image is to first get it up to date to the level of source.squeak.org, then at our leisure we can bring both of them together up to a the level that you are demonstarting with Cog and Magma. But the main thing is to get squeaksource.com stable, which is not yet the case.
source.squeak.org is getting slow too, and it runs on an old image. The work I've done to bring it to a trunk image under Cog is based on the source.squeak.org image, and really not that many changes.
It turns out that the following snippet from the workspace that SCG provided took care of the problem for now:
" kill runaway processes " ProcessBrowser open. Process allInstances do: [ :each | each priority = 30 ifTrue: [ each terminate ] ].
OMG! No wonder SS has so many problems if it is so unloved that someone would arbitrarily kill processes based on their priority!
That's just something I found in the workspace that came with the image. I figured it must be there for a reason, so I tried it and it "fixed" the problem.
You are right about one thing - SS was not getting much love. Even I, who knew absolutely nothing about SqueakSource before I volunteered to move it, was able to fix some of the worst problems. That's why I am confident that we can get it running reliably once we have given it a little bit of long-overdue attention.
So I'm guessing that some Seaside handler got wedged, presumably concurrent with an excessive memory usage condition, and it probably failed in some way that did not let the garbage collector clean up the mess.
SS forks the email out to Project subscribers at priority 30. See SSEMailSubscription>>#versionAdded:to:. I wonder whether that's what those were?
Outbound mail notification from squeaksource.com is disabled, so that should not have been a concern.
Which switch are you referring to that is "disabled"? Did you check SSProject>>#versionAdded:? For the path of someone saving a version, it _unconditionally_ sends out mail to all subscribers, there is no single switch to disable that..
Note, I still need help from someone with access to box2 to enable mail delivery. I don't want to install an entire mail system on box3 just to handle notifications from squeaksource on box3, so I expect that configuring box2 to accept smtp from box3 would be the right thing to do.
Is SMTP support not already part of box3? Seems like a relatively basic service we're gonna want at some point because we want to be focusing on transitioning all responsibilities away from box2 toward box3 and box4 anyway.