Hi all,
I cannot update any of my images today and we also saw this in our CI:
Squeak Trunk: ConnectionClosed Squeak 6.0: Error: ZipArchive cannot find EOCD position in a stream When trying to save a new inbox version: NetworkError: Could not access https://source.squeak.org/inbox (status code 500) However, browsing versions in the web interface seems to work.
Could any of the server admins maybe take a look at this? :-)
Best, Christoph
--- Sent from Squeak Inbox Talk
On Mon, Sep 11, 2023 at 06:20:44PM +0200, christoph.thiede@student.hpi.uni-potsdam.de wrote:
Hi all,
I cannot update any of my images today and we also saw this in our CI:
Squeak Trunk: ConnectionClosed Squeak 6.0: Error: ZipArchive cannot find EOCD position in a stream When trying to save a new inbox version: NetworkError: Could not access https://source.squeak.org/inbox (status code 500) However, browsing versions in the web interface seems to work.
Could any of the server admins maybe take a look at this? :-)
I am seeing similar issues on the other SqueakSource server. I think I started seeing it yesterday or the day before, but I assumed it was something in my local system caches and did not look further.
To reproduce, try opening a Monticello browser on https://www.squeaksource.com/OSProcess any highlight any of the package files.
We apparently have issues with some packages on both source.squeak.org and squeaksource.com. I looked at the squeaksource.com image in VNC and saw no problems. I restarted that image anyway just be be safe, but the problem is still there.
In separate email, Levente noted that there were stuck processes (Squeak processes) in the source.squeak.org image so we know we have a problem there, but it might be unrelated to the EOCD errors that we are apparently now seeing on both servers.
That is all that I know right right now. Perhaps it would help to get some fresh eyes on the problem. Opening a MC browser on https://www.squeaksource.com/OSProcess is an easy way to reproduce what I have been seeing, so maybe someone can make sense out of the debugger stack there.
Dave
On Mon, Sep 11, 2023 at 01:59:51PM -0400, David T. Lewis wrote:
On Mon, Sep 11, 2023 at 06:20:44PM +0200, christoph.thiede@student.hpi.uni-potsdam.de wrote:
Hi all,
I cannot update any of my images today and we also saw this in our CI:
Squeak Trunk: ConnectionClosed Squeak 6.0: Error: ZipArchive cannot find EOCD position in a stream When trying to save a new inbox version: NetworkError: Could not access https://source.squeak.org/inbox (status code 500) However, browsing versions in the web interface seems to work.
Could any of the server admins maybe take a look at this? :-)
I am seeing similar issues on the other SqueakSource server. I think I started seeing it yesterday or the day before, but I assumed it was something in my local system caches and did not look further.
To reproduce, try opening a Monticello browser on https://www.squeaksource.com/OSProcess any highlight any of the package files.
We apparently have issues with some packages on both source.squeak.org and squeaksource.com. I looked at the squeaksource.com image in VNC and saw no problems. I restarted that image anyway just be be safe, but the problem is still there.
In separate email, Levente noted that there were stuck processes (Squeak processes) in the source.squeak.org image so we know we have a problem there, but it might be unrelated to the EOCD errors that we are apparently now seeing on both servers.
That is all that I know right right now. Perhaps it would help to get some fresh eyes on the problem. Opening a MC browser on https://www.squeaksource.com/OSProcess is an easy way to reproduce what I have been seeing, so maybe someone can make sense out of the debugger stack there.
I suspect that something in the infrastructure has changed such that http GET responses are being trimmed or limited in length.
It is tricky to debug this because MC does a lot of caching, but when MC has to go to the web with an HTTP GET request, it looks to me like long response strings may be getting trimmed. If I do MCFileBasedRepository flushAllCaches, and then put a halt in MCHttpRepository>>webClientDo: to look that the result of a WebResponse, then when I look at e.g. OSProcess-dtl.137.mcz in the MC browser I think I am seeing a web response with length 65264, which is much shorter than the expected length of OSProcess-dtl.137.mcz. That in turn seems to lead to the 'cannot find EOCD position' in the ZipArchive reader.
I cannot follow up more on this tonight, but hopefully this will trigger some thoughts.
Dave
squeak-dev@lists.squeakfoundation.org