Thanks, everybody.


> So, I changed the production server code to only return the last 1000 of those 14000, it's "working" again.

Just in case this wasn't obvious, updating your image still doesn't work because many versions are missing. Round-robin or some date-based heuristic would surely be a better (yet more complex) workaround. :-)

Best,
Christoph

________________________________
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von David T. Lewis <lewis at mail.msen.com>
Gesendet: Dienstag, 27. Dezember 2022 20:07:32
An: Chris Muller
Cc: box-admins at lists.squeakfoundation.org; The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] trunk update stream appears to have become inaccessible

Thanks Chris,

++box-admins

I opened an item on the Slack box-admins channel to follow up on this.

Dave

On Mon, Dec 26, 2022 at 11:02:16PM -0600, Chris Muller wrote:
> Hi all,
>
> The server appeared to be running fine.  I was able to vnc into the
> image and everything appeared normal.  Nothing abnormal in the log.
> The only anomaly was it was taking up a lot of RAM (7 GB) which is
> really abnormal, so I restarted it.  After coming back up it's now
> taking between 1-2 GB which is normal for this sized repository.
>
> However, the trunk directory listing is still failing!
>
> After considerable live debugging, I could find no errors or
> abnormalities occuring in the Squeak image.  But, dog gone
> it, Seaside apps with continuations and dynamic vars are really
> difficult to debug, so I may have missed something, but I don't think so).
>
> So, it *appears* at this point to be some sort of HTTP response size
> limitation, possibly within the proxy server.  Levente?  There are
> currently over 14000 files in 'trunk'.  All the other projects have
> far fewer files (e.g., 'inbox', 'treated', etc.) and appear to be
> working.  So, I changed the production server code to only return the
> last 1000 of those 14000, it's "working" again.
>
> I'm afraid I'm at a loss for what else the problem might be, or how to
> solve it, so, here are my suggestions:
>
>   - any HTTP / Proxy experts know of any server configuration
> parameters that could be affecting this?
>   - If so, can we adjust it?  Or break up trunk into smaller projects?
>   - change the /ss code to only return one from each project
> round-robin until a total of 1000 have been retrieved.  But then we
> couldn't access old versions except directly -- which may or may not
> be a problem...?
>
> Thoughts?   We're going to have to put our heads together on this one.
>
>
>  - Chris
>
> On Mon, Dec 26, 2022 at 8:10 PM David T. Lewis <lewis at mail.msen.com> wrote:
> >
> > On Mon, Dec 26, 2022 at 08:13:11PM -0500, David T. Lewis wrote:
> > > On Mon, Dec 26, 2022 at 04:30:52PM -0800, tim Rowledge wrote:
> > > > I can't do a trunk update of any of my squeak 6 images right now. This is the case for several 6.0 release images on several platforms and a freshly downloaded 6.1alpha system.
> > > >
> > > > The problem is that the securesocketstream>receiveData method gets a connection closed response. This isn't new and 'm sure I should remember more about it but... in fact the only notes I have that relate to the problem date back to '04 and I certainly don't remember any details.
> > > >
> > > > The especially annoying thing is that using https://source.squeak.org/trunk/ in a web browser works fine, so it probably isn't that the server is dead. Is this another stupid SSL issue?
> > > >
> > >
> > > Confirmed, I'm seeing the same. It seems specific to source.squeak.org/trunk as
> > > opposed to source.squeak.org/inbox. Something has changed quite recently, I'm
> > > pretty sure that updates were working earlier today.
> > >
> >
> > Opening a repository browser on trunk gives the ConnectionClosed symptom
> > as described. So I tried it with an older Squeak 4.5 image, and it fails
> > with different symptoms, the progress bar stops part way through retrieving
> > the list of file names.
> >
> > This is not SSL related, it seems to be something on the server that is
> > specifically related to the trunk repository, or possibly something
> > related to the (size of?) list of file names being retrieved.
> >
> > Dave
> >

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20221227/d20c8ac5/attachment.html>