[squeak-dev] The Inbox: WebClient-Core-cbc.118.mcz

Chris Cunningham cunningham.cb at gmail.com
Tue Oct 30 19:18:53 UTC 2018


Hi Karl,

Thank you for responding with the stack trace - I was going to yesterday
but got completely distracted with other issues. THat is roughly where it
fails for me, too (one windows 10).

Also, glad it helped.  It is still a hack that shouldn't be in the
production WebClient (too many other possible side-effects), but nice for
this process.

-cbc



On Tue, Oct 30, 2018 at 11:27 AM karl ramberg <karlramberg at gmail.com> wrote:

> And with  WebClient-Core-cbc.118.mcz I don't get this error.
>
> Cheers,
> Karl
>
>
> On Tue, Oct 30, 2018 at 7:16 PM karl ramberg <karlramberg at gmail.com>
> wrote:
>
>> Hi,
>> I get error on updating almost every time I try, and the fail is within a
>> second.
>> See log in attachment.
>> I'm on windows.
>>
>> Cheers,
>> Karl
>>
>>
>> On Mon, Oct 29, 2018 at 9:54 PM Levente Uzonyi <leves at caesar.elte.hu>
>> wrote:
>>
>>> On Sun, 28 Oct 2018, Chris Cunningham wrote:
>>>
>>> >
>>> >
>>> > On Sun, Oct 28, 2018, 17:55 Levente Uzonyi <leves at caesar.elte.hu>
>>> wrote:
>>> >       Hi Chris,
>>> >
>>> >       On Sun, 28 Oct 2018, Chris Cunningham wrote:
>>> >
>>> >       > Hi.
>>> >       > I was loading the VMMaker package(s), and after manually
>>> opening the debugger and restarting at #httpGet:do: about 10 times, I
>>> implemented this hack so that I didn't have to do that
>>> >       anymore.
>>> >       >
>>> >       > I *think* this is fixing the issue - haven't had it raise
>>> errors while 'timing out' on loading packages since this (the timeout were
>>> sub-second - the connection hadn't gone through
>>> >       yet).  Still, it
>>> >       > might just be timing - this isn't really a repeatable bug.
>>> >
>>> >       I'm sure this change helps with that issue, but it has unwelcome
>>> side
>>> >       effects to WebClient's other users.
>>> >
>>> > This this definitely will not be going to trunk.
>>> >
>>> >       The real solution would be to fix the server.
>>> >
>>> >       Where did you see sub-second timeouts? The default timeout
>>> should be 45
>>> >       seconds.
>>> >
>>> > It didn't wait 45 seconds - it is almost instantaneous for me.  The
>>> error received back (from Socket>>sendSomeData:startIndex:count:for: ) is
>>> "ConnectionTimedOut: send data timeout; data not sent",
>>> > but I'm pretty darn certain it is that the socket isn't yet connected
>>> (trace put into Socket>>waitForSendDoneFor: confirms this).  Looking at
>>> #waitForSendDoneFor: shows that before any wait, it checks
>>> > if the socket is connected - if not, it immediately exits with false,
>>> which triggers the time out error in the caller.
>>> >
>>> > If I trap it and immediately resend, then it works.  Weird.
>>>
>>> I've never seen that happening. Do you have a stack trace of the error?
>>>
>>> Levente
>>>
>>> >
>>> > -cbc
>>> >
>>> >       >
>>> >       > Not in Trunk because it is definitely a hack - but it makes
>>> things work nicer.
>>> >       >
>>> >       > Also, committing packages to the inbox with this loaded
>>> doesn't result in walkbacks (from timeouts and whatnot) for me.  Although
>>> it does take a long time to finish.
>>> >
>>> >       Uploads use PUT requests, so expect to still see walkbacks there.
>>> >
>>> >       Levente
>>> >
>>> >       >
>>> >       > -cbc
>>> >       >
>>> >       > On Sun, Oct 28, 2018 at 5:08 PM <commits at source.squeak.org>
>>> wrote:
>>> >       >       A new version of WebClient-Core was added to project The
>>> Inbox:
>>> >       >
>>> http://source.squeak.org/inbox/WebClient-Core-cbc.118.mcz
>>> >       >
>>> >       >       ==================== Summary ====================
>>> >       >
>>> >       >       Name: WebClient-Core-cbc.118
>>> >       >       Author: cbc
>>> >       >       Time: 28 October 2018, 5:08:23.571079 pm
>>> >       >       UUID: 683fbe3b-418f-a443-9a20-3f2a7af4b7e1
>>> >       >       Ancestors: WebClient-Core-pre.117
>>> >       >
>>> >       >       A hack to work around connectionTimedOut annoyances when
>>> opening packages from Trunk (sometimes).
>>> >       >
>>> >       >       =============== Diff against WebClient-Core-pre.117
>>> ===============
>>> >       >
>>> >       >       Item was changed:
>>> >       >         ----- Method: WebClient>>httpGet:do: (in category
>>> 'methods') -----
>>> >       >         httpGet: urlString do: aBlock
>>> >       >               "GET the response from the given url"
>>> >       >               "(WebClient httpGet: 'http://www.squeak.org')
>>> content"
>>> >       >
>>> >       >       +       | request errCount |
>>> >       >       -       | request |
>>> >       >               self initializeFromUrl: urlString.
>>> >       >               request := self requestWithUrl: urlString.
>>> >       >               request method: 'GET'.
>>> >       >               userAgent ifNotNil:[:ua | request headerAt:
>>> 'User-Agent' put: ua].
>>> >       >               self contentDecoders ifNotNil: [:decoders |
>>> request headerAt: 'Accept-Encoding' put: decoders].
>>> >       >       +
>>> >       >       +       errCount := 0. "Let's try resending to get
>>> around 'connection issues' trunk connections"
>>> >       >       +       [
>>> >       >       +               aBlock value: request.
>>> >       >       +               ^self sendRequest: request
>>> >       >       +       ] on: Error, NetworkError do: [:e| debugLog
>>> ifNotNil: [debugLog cr; nextPutAll: 'httpGet error: ', e; flush]. (errCount
>>> := errCount + 1) > 3 ifTrue: [e outer]. e retry].!
>>> >       >       -       aBlock value: request.
>>> >       >       -       ^self sendRequest: request
>>> >       >       - !
>>> >       >
>>> >       >
>>> >       >
>>> >       >
>>> >
>>> >
>>> >
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20181030/9ce43ac0/attachment.html>


More information about the Squeak-dev mailing list