Connection-pool nil problem when using master about dexador

[ajberkley]

Closing as I am 99% sure this isn't a dexador problem. Please re-open if you can pin it down more.

[ajberkley]

That's not good! I was careful to try and preserve the ability to do external connection pooling, but it's possible I made a mistake or wrong assumption. Do you know the assumptions you are making about passing in streams / returning streams? Of course better would be a real stack trace!

[K1D77A]

Hi, I was not performing any manual connection pooling, I was use using :use-connection-pool nil as an argument in order to prevent the weird bugs that were present before you fixed it. Unfortunately I do not have access to a full stack trace :(

[ajberkley]

Ah, OK. The message usually indicates a proxy issue or an issue with self signed certificates in the chain somewhere. Unfortunately I think I'd need some more info to debug :(

[K1D77A]

Error code: "unhandled"
Error value: #1#
Description: "A request was made that generated a condition which 
has returned an unknown condition."
Args: (#1=Condition CL+SSL::SSL-ERROR was signalled.)
   [Condition of type API-ERROR]

Restarts:
 0: [RETRY] Retry calling the generic function.
 1: [TRY-AGAIN] Try again?
 2: [RETRY] Retry SLY mREPL evaluation request.
 3: [*ABORT] Return to SLY's top level.
 4: [ABORT] abort thread (#<THREAD "sly-channel-1-mrepl-remote-1" RUNNING {1001808333}>)

Backtrace:
 0: ((:METHOD NO-APPLICABLE-METHOD ((EQL (FUNCTION %CALL-CONDITION-HANDLER)))) #<unused argument> #<CL+SSL::SSL-ERROR {100F914763}>) [fast-method]
      Locals:
        ARGS = (#<CL+SSL::SSL-ERROR {100F914763}>)
 1: (SB-PCL::CALL-NO-APPLICABLE-METHOD #<STANDARD-GENERIC-FUNCTION LUNAMECH-MATRIX-API/V2:%CALL-CONDITION-HANDLER (3)> (#<CL+SSL::SSL-ERROR {100F914763}>))
      Locals:
        ARGS = (#<CL+SSL::SSL-ERROR {100F914763}>)
        GF = #<STANDARD-GENERIC-FUNCTION LUNAMECH-MATRIX-API/V2:%CALL-CONDITION-HANDLER (3)>
 2: ((LAMBDA NIL :IN EXECUTE-API-CALL))
      [No Locals]
 3: ((LABELS TRY-AGAIN-RESTART :IN EXECUTE-API-CALL) #<FUNCTION (LAMBDA NIL :IN EXECUTE-API-CALL) {100F91217B}>)
      Locals:
        FUN = #<FUNCTION (LAMBDA () :IN EXECUTE-API-CALL) {100F91217B}>
        ```
This is one error I found.
I will keep looking

```lisp
Connection Timeout.
Message: No network. Socket-condition.
Original condition: The condition Name service error in "getaddrinfo": -11 (System error) occurred with errno: 0.
   [Condition of type API-NO-CONNECTION]

Restarts:
 0: [TRY-AGAIN] Try again?
 1: [RETRY] Retry SLY mREPL evaluation request.
 2: [*ABORT] Return to SLY's top level.
 3: [ABORT] abort thread (#<THREAD "sly-channel-1-mrepl-remote-1" RUNNING {1001808333}>)

Backtrace:
 0: ((:METHOD %CALL-CONDITION-HANDLER (USOCKET:SOCKET-CONDITION)) #<USOCKET:UNKNOWN-ERROR {10101B0AA3}>) [fast-method]
 1: ((LAMBDA NIL :IN EXECUTE-API-CALL))
      [No Locals]
 2: ((LABELS TRY-AGAIN-RESTART :IN EXECUTE-API-CALL) #<FUNCTION (LAMBDA NIL :IN EXECUTE-API-CALL) {10101B059B}>)
      Locals:
        FUN = #<FUNCTION (LAMBDA () :IN EXECUTE-API-CALL) {10101B059B}>
 3: ((:METHOD CALL-API (API)) #<SYNC  ..) [fast-method]
      Locals:
        API = #<SYNC 
        ```

[ajberkley]

Maybe the reason it is more stable with use-connection-pool t is because you are hitting the DNS and opening new connections less often. One question is whether dexador should arbitrarily retry things for all possible network errors. What do you think? I don't know why it would be less stable then before unless I deleted a big retry on all possible errors in dexador, but I don't see that I did that (though the control flow of the code is... unnecessarily complex... and hard to reason about).

With regards to getting ESYSTEM plus ERRNO = 0 in the dns call, this is a big can of worms. I don't think ERRNO is well defined in the lisp context, because you can get interrupted by gcs which make system calls, etc, and I don't think implementations restore errno... but I'd have to look and see. I'd prefer is someone with more common lisp network experience would just tell me the answer though.

It may be that this should be handled by usocket.