(close-buffer-socket {:keys [client]})Idempotent.
Idempotent.
(connected? client)True until the socket is destroyed, as it is once the server hangs up. Writes made while it is still connecting are buffered.
True until the socket is destroyed, as it is once the server hangs up. Writes made while it is still connecting are buffered.
(get-buffer-socket port address ssl)Connects, blocking until the connection, and its TLS handshake if ssl asks for one, is ready. ssl is nil, or the TLS settings clunk.tls/connect takes. Throws if either fails.
Connects, blocking until the connection, and its TLS handshake if ssl asks for one, is ready. ssl is nil, or the TLS settings clunk.tls/connect takes. Throws if either fails.
Starts connecting and returns at once; writes wait until the connection is ready. ssl is nil, or the TLS settings clunk.tls/connect takes.
Starts connecting and returns at once; writes wait until the connection is ready. ssl is nil, or the TLS settings clunk.tls/connect takes.
(pause _)(pause {:keys [client]})Stops reading until resume, so a slow reader pushes back on the server.
Stops reading until resume, so a slow reader pushes back on the server.
(start! {:keys [client reader-name]} on-chunk on-close)Calls on-chunk with each chunk read, as a byte array, then on-close once, when the connection ends. Both run on the connection's own thread, named clunk-reader-<host>:<port>, which reads for as long as the connection is open, idle or not, so it sees messages the server sends unasked and notices a server that hangs up. on-chunk may block it, which pushes back on the server.
It's a daemon platform thread, not a virtual one: on a 24-thread machine a platform reader handled up to half again as many small queries, at less than half the CPU each, since waking a virtual thread blocked on a socket also wakes the JDK's poller threads. A daemon, so a client nobody closed doesn't keep the JVM running.
Calls on-chunk with each chunk read, as a byte array, then on-close once, when the connection ends. Both run on the connection's own thread, named clunk-reader-<host>:<port>, which reads for as long as the connection is open, idle or not, so it sees messages the server sends unasked and notices a server that hangs up. on-chunk may block it, which pushes back on the server. It's a daemon platform thread, not a virtual one: on a 24-thread machine a platform reader handled up to half again as many small queries, at less than half the CPU each, since waking a virtual thread blocked on a socket also wakes the JDK's poller threads. A daemon, so a client nobody closed doesn't keep the JVM running.
(start! {:keys [client]} on-chunk on-close)Calls on-chunk with each chunk read, as an ArrayBuffer, then on-close once the connection ends.
Calls on-chunk with each chunk read, as an ArrayBuffer, then on-close once the connection ends.
(write! {:keys [client]} bs)Writes a ByteBuffer whose position is at the end of its bytes, on the caller's thread. SocketChannel and SSLSocket each keep concurrent writes whole. clunk writes a query only once the server has answered the last one, so the socket's send buffer is empty and only a request larger than it waits for the server to read.
Writes a ByteBuffer whose position is at the end of its bytes, on the caller's thread. SocketChannel and SSLSocket each keep concurrent writes whole. clunk writes a query only once the server has answered the last one, so the socket's send buffer is empty and only a request larger than it waits for the server to read.
Writes a binf view (a DataView); Node buffers what the socket can't take yet.
Writes a binf view (a DataView); Node buffers what the socket can't take yet.
cljdoc builds & hosts documentation for Clojure/Script libraries
| Ctrl+k | Jump to recent docs |
| ← | Move to previous article |
| → | Move to next article |
| Ctrl+/ | Jump to the search field |