Hi there, this is similar to Duplicacy Web UI hangs forever - #7 by mark3, but different, so I thought I’d start another thread.
The web UI is wedged again, and requests hang without response. This happened after I tried sending a test email (/test_schedule_email).
I used your /print_stack_trace trick to get this stack trace:
duplicacy-wedged-2.txt (1.4 MB)
Hopefully that helps make clear what’s stuck?
I was trying to send first to smtp.mailgun.com (failed, no port). Then I tried smtp.mailgun.com:465. I think this is where it first started hanging. Port 465 is apparently deprecated? Which SMTP Port Should I Use? Understanding Ports 25, 465, & 587 | Mailgun Maybe that’s a clue.
Then I tried smtp.mailgun.com:587, and the request just hung, I don’t think it did anything looking at the logs.
I see one thread blocked inside main.SendMail. I’m guessing this is holding a lock.
I looked at one of the blocked http.serve threads, and found a mutex up the stack
(dlv) args
m = (*sync.Mutex)(0x13b48f8)
(dlv) print *m
sync.Mutex {state: 161, sema: 0}
This looks like it’s our friend main.ConfigLock again, the address matches:
(dlv) print &main.ConfigLock
(*sync.Mutex)(0x13b48f8)
The smtp client blocks on smtp.mailgun.com:465 forever when attempting to read some response. I need to add a timeout there.
I tried smtp.mailgun.com:587 and it worked.
A timeout is reasonable, though I’m not sure how long is reasonable (maybe some gateways are slow?). Wonder also if the smtp/dial APIs take a context.Context that closes when the original browser request closes?
If you have a long-ish timeout, other requests will still hang while smtp is holding the mutex. I wonder if it’d be a good idea to hold the mutex only while getting the data you need, then release the mutex and continue with the long-running smtp operation?