Error writing data to socket

Permalink: HTTP NNTP

Posted Tue, 30 Jan 2018 17:22:36 GMT

An exception is thrown in line 2367 while writing to the connection, in ddb master.

2357 void write(const(ubyte[]) bytes)
2358  {
2359            // Vibe:  "... If connected is false, writing to the connection will trigger an exception ..."
2360            if (!tcpConnection.connected)
2361            {
2362                // Vibe: " ... Note that close must always be called, even if the remote has already closed the
2363                //             connection. Failure to do so will result in resource and memory leakage.
2364                tcpConnection.close();
2365                connect();
2366            }
2367            tcpConnection.write(bytes);
2368       }

I think that the remote peer (the Postgres service) is disconnecting the vibe client

object.Exception@../../../../root/.dub/packages/vibe-core-1.3.0/vibe-core/source/vibe/core/net.d(639): Error writing data to socket.
[main(eDjH) ERR] ----------------
[main(eDjH) ERR] ??:? [0x7e7c0e]
[main(eDjH) ERR] ??:? [0x7d9922]
[main(eDjH) ERR] net.d:639 [0x761753]
[main(eDjH) ERR] net.d:647 [0x76185a]
[main(eDjH) ERR] postgres.d:2367 [0x5fb5a4]
[main(eDjH) ERR] postgres.d:237 [0x5fb4fe]
[main(eDjH) ERR] postgres.d:250 [0x5fb640]
[main(eDjH) ERR] postgres.d:1102 [0x5fdabf]
[main(eDjH) ERR] postgres.d:1315 [0x600c0b]
[main(eDjH) ERR] postgres.d:2123 [0x605317]
[main(eDjH) ERR] postgres.d:2167 [0x5c8169]
[main(eDjH) ERR] postgres.d:1795 [0x5c7480]

As I'm checking the .connected method, I'm not sure why the exception is raised...

Is there a reliable way to avoid the exception, or I need a try/catch block around the write in line 2367?

Thanks, below you can find the build log.

$ dub build --build=debug || dub build --build=debug
Fetching libevent 2.0.2+2.0.16 (getting selected version)...
Fetching diet-ng 1.4.4 (getting selected version)...
Fetching taggedalgebraic 0.10.9 (getting selected version)...
Fetching openssl 1.1.6+1.0.1g (getting selected version)...
Fetching mars 1.3.0 (getting selected version)...
Fetching botan 1.12.9 (getting selected version)...
Fetching memutils 0.4.9 (getting selected version)...
Fetching vibe-d 0.8.2 (getting selected version)...
Fetching vibe-core 1.3.0 (getting selected version)...
Fetching libasync 0.8.3 (getting selected version)...
Fetching botan-math 1.0.3 (getting selected version)...
Fetching ddb ~master (getting selected version)...
Fetching eventcore 0.8.27 (getting selected version)...

## Warning for package botan, configuration 32mscoff ##

The following compiler flags have been specified in the package description
file. They are handled by DUB and direct use in packages is discouraged.
Alternatively, you can set the DFLAGS environment variable to pass custom flags
to the compiler, or use one of the suggestions below:

-m32mscoff: Use --arch=x86/--arch=x86_64/--arch=x86_mscoff to specify the target architecture


## Warning for package botan-math, configuration regular ##

The following compiler flags have been specified in the package description
file. They are handled by DUB and direct use in packages is discouraged.
Alternatively, you can set the DFLAGS environment variable to pass custom flags
to the compiler, or use one of the suggestions below:

-m32mscoff: Use --arch=x86/--arch=x86_64/--arch=x86_mscoff to specify the target architecture


## Warning for package botan-math, configuration 32mscoff ##

The following compiler flags have been specified in the package description
file. They are handled by DUB and direct use in packages is discouraged.
Alternatively, you can set the DFLAGS environment variable to pass custom flags
to the compiler, or use one of the suggestions below:

-m32mscoff: Use --arch=x86/--arch=x86_64/--arch=x86_mscoff to specify the target architecture

Package ddb can be upgraded from ~master to 0.3.0.
Use "dub upgrade" to perform those changes.
Performing "debug" build using ldc2 for x86_64.
taggedalgebraic 0.10.9: building configuration "library"...
eventcore 0.8.27: building configuration "epoll"...
vibe-core 1.3.0: building configuration "epoll"...
vibe-d:utils 0.8.2: building configuration "library"...
vibe-d:data 0.8.2: building configuration "library"...
immutable(ubyte)[]
ddb ~master: building configuration "library"...
../../../../root/.dub/packages/ddb-master/ddb/source/ddb/postgres.d(2408,22): Deprecation: constructor vibe.core.connectionpool.ConnectionPool!(PGConnection).ConnectionPool.this is deprecated - Use an @safe callback instead
diet-ng 1.4.4: building configuration "library"...
vibe-d:crypto 0.8.2: building configuration "library"...
vibe-d:stream 0.8.2: building configuration "library"...
vibe-d:textfilter 0.8.2: building configuration "library"...
vibe-d:inet 0.8.2: building configuration "library"...
/root/dlang/ldc-1.3.0-beta1/bin/../import/std/format.d(2823,28): Deprecation: function vibe.core.path.GenericPath!(PosixPathFormat).GenericPath.Segment.toString is deprecated - Use .name instead.
vibe-d:tls 0.8.2: building configuration "openssl"...
vibe-d:http 0.8.2: building configuration "library"...
immutable(ubyte)[]
/root/dlang/ldc-1.3.0-beta1/bin/../import/std/format.d(2823,28): Deprecation: function vibe.core.path.GenericPath!(PosixPathFormat).GenericPath.Segment.toString is deprecated - Use .name instead.
mars 1.3.0: building configuration "library"...
vibe-d:web 0.8.2: building configuration "library"...
/root/dlang/ldc-1.3.0-beta1/bin/../import/std/format.d(2823,28): Deprecation: function vibe.core.path.GenericPath!(PosixPathFormat).GenericPath.Segment.toString is deprecated - Use .name instead.
4uattro ~master: building configuration "application"...
/root/dlang/ldc-1.3.0-beta1/bin/../import/std/format.d(2823,28): Deprecation: function vibe.core.path.GenericPath!(PosixPathFormat).GenericPath.Segment.toString is deprecated - Use .name instead.
Uploading artifacts...
webservice/bin/4uattro: found 1 matching files     
Uploading artifacts to coordinator... ok            id=50164480 responseStatus=201 Created token=z-2p_qF5
Job succeeded

Re: Error writing data to socket

Permalink: HTTP NNTP

Sönke Ludwig

Posted Fri, 16 Feb 2018 15:04:19 +0100 in reply to Paolo Invernizzi

Am 30.01.2018 um 18:22 schrieb Paolo Invernizzi:

An exception is thrown in line 2367 while writing to the connection, in ddb master.

2357 void write(const(ubyte[]) bytes)
2358  {
2359            // Vibe:  "... If connected is false, writing to the connection will trigger an exception ..."
2360            if (!tcpConnection.connected)
2361            {
2362                // Vibe: " ... Note that close must always be called, even if the remote has already closed the
2363                //             connection. Failure to do so will result in resource and memory leakage.
2364                tcpConnection.close();
2365                connect();
2366            }
2367            tcpConnection.write(bytes);
2368       }

I think that the remote peer (the Postgres service) is disconnecting the vibe client

(...)

How many bytes are written in that call to write? Since write by
default tries to write all bytes, it may need to be broken up into
multiple packets, meaning that the connection reset could happen during
the call between any of those packets.

If vibe-core is used, a possible approach to avoid that would be to use
IOMode.once and to put a while (bytes.length) loop around the
function body (shrinking the slice according to the return value of
tcpConnection.write).

However, since this is talking to a Postgres server that would of course
just corrupt the communication protocol. So I'd probably just wrap the
code that sends a single message in a try/catch, attempt to
re-connect in the catch, and then resend the whole message instead.
After all, there will always be cases where writing can unexpectedly
fail. Of course, there would still be a .connected check in the
beginning to avoid spurious errors if the connection was closed cleanly.

Talking about protocol, is there maybe a possibility that the Postgres
server forcably closes the connection, because the first part of the
message is in some way invalid?

Re: Error writing data to socket

Permalink: HTTP NNTP

Paolo Invernizzi

Posted Sat, 03 Mar 2018 17:28:40 GMT in reply to Sönke Ludwig

On Fri, 16 Feb 2018 15:04:19 +0100, Sönke Ludwig wrote:

Am 30.01.2018 um 18:22 schrieb Paolo Invernizzi:
An exception is thrown in line 2367 while writing to the connection, in ddb master.
2357 void write(const(ubyte[]) bytes)
2358  {
2359            // Vibe:  "... If connected is false, writing to the connection will trigger an exception ..."
2360            if (!tcpConnection.connected)
2361            {
2362                // Vibe: " ... Note that close must always be called, even if the remote has already closed the
2363                //             connection. Failure to do so will result in resource and memory leakage.
2364                tcpConnection.close();
2365                connect();
2366            }
2367            tcpConnection.write(bytes);
2368       }
I think that the remote peer (the Postgres service) is disconnecting the vibe client

(...)
How many bytes are written in that call to write? Since write by
default tries to write all bytes, it may need to be broken up into
multiple packets, meaning that the connection reset could happen during
the call between any of those packets.

If vibe-core is used, a possible approach to avoid that would be to use
IOMode.once and to put a while (bytes.length) loop around the
function body (shrinking the slice according to the return value of
tcpConnection.write).

However, since this is talking to a Postgres server that would of course
just corrupt the communication protocol. So I'd probably just wrap the
code that sends a single message in a try/catch, attempt to
re-connect in the catch, and then resend the whole message instead.
After all, there will always be cases where writing can unexpectedly
fail. Of course, there would still be a .connected check in the
beginning to avoid spurious errors if the connection was closed cleanly.

Talking about protocol, is there maybe a possibility that the Postgres
server forcably closes the connection, because the first part of the
message is in some way invalid?

Thanks for your reply Sönke,

I've finally find out that the exceptions is related to network errors that are occurring in the connection between two docker containers in a docker swarm.
It seems that there's a lot of people suffering from unreliable network in the current implementation...

I've just given up in using a swarm until the thing is fixed on docker-side, and everything is fine again.

Anyway, I've tried also to reconnect in the catch, but the following call to write simply hangs vibe-core.

/Paolo