On Sun, 21 Sep 2014 06:38:09 GMT, Fred Douglas wrote:
I've run into a really bizarre problem. I'm using createSSLStream, with a SSLContextKind.server that has a cert+key associated with it, to create an SSLStream on top of a TCPConnection I've created with connectTCP. The handshake goes fine, and I can read() on the SSLStream to get data that the other side sends. However, write()ing to it (even with a flush() afterwards) does nothing - as in, tcpdump shows that no packets ever get sent when that write() happens.
On the other hand, if I have the other side initiate the TCP connection, receiving it via listenTCP, all the SSL stuff works exactly as I would expect.
One thing that I'm thinking might be a problem: I'm using the D Thread class to spin off the thread that is doing the problematic createSSLStream()s. It and the main thread (the one that can correctly receive TLS connections) both have their own SSLContext to use, because using one that was created in the other thread was crashing the whole program. (I also had the same crashing problem with trying to share Mongo connections among threads. I tried using runTask before going to the thread approach, but it wasn't working... )
(...)
So, are my not-exactly-the-vibe-way threads causing problems, am I making some non-thread-related configuration mistake, or is this a bug?
OpenSSL is initialized in thread-safe mode, so I would expect the thread to not be the issue in general. I'm not sure if using the same SSL context would be allowed to be used from multiple threads, though, so that crash may or may not indicate an issue with the way thread-safe OpenSSL is set up. But generally, non-shared classes in vibe.d should never be passed between threads, because they are tied to a single event loop. The only notable exceptions are ManualEvent, TaskMutex and TaskCondition.
Regarding the runTask version, it would be interesting to see why that failed, because that would usually be the best way to implement this. What exactly went wrong in that case?
To get some more data for the issue, can you run the program with --vvvv (LogLevel.trace) and see if the write("K") produces an "evbuffer_add ..." log entry? That should give a hint about the issue being on the OpenSSL side or on the libevent side of things.
BTW, the libevent driver only blocks when its internal write buffer fills up. The buffer is always written to the socket by libevent in the background, which can make debugging with a packet capture tool a bit more difficult. One possible explanation could be that the event loop gets terminated before the buffer was fully written (and the connection properly closed), but it doesn't sound like that could be the case here, right?