pcdv / jocket Goto Github PK

Software caused connection abort: socket write error

Exception in thread "main" java.net.SocketException: Software caused connection abort: socket write error
	at java.net.SocketOutputStream.socketWrite0(Native Method)
	at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:111)
	at java.net.SocketOutputStream.write(SocketOutputStream.java:134)
	at java.io.DataOutputStream.writeInt(DataOutputStream.java:199)
	at jocket.net.ServerJocket.accept(ServerJocket.java:76)

The default benchmark, in spite of overall good performance, shows some latency spikes.

These are probably due to false sharing, eg. the writer keeps on fetching the latest sequence number from the reader even when it has sufficient headroom to perform writes. [NB: they could also be caused by interruptions by the task scheduler. Need to test again with cpu isolation/pinning to make sure.]

I have taken a few shots at "minimizing reads to any external data which may be rapidly changing" (to paraphrase Nitsan Wakart) but without outstanding success.

This is probably due to the nature of the benchmark which is kind of a worst-case scenario: the client and server are almost constantly waiting for data to arrive and are thus compelled to fetch rapidly changing data, causing many cache misses.

Another benchmark with batched reads and writes would probably show greater improvements but I'm afraid a full rewrite of JocketReader and JocketWriter is necessary.

When the following code is run it incrementally allocates memory until it takes full capacity of /run/shm (/dev/shm) despite the fact that all of the close() methods on sockets are called.
Is there a way how to correctly free JocketSocket/JocketFile so it doesn't occupy any more space in shm?

package com.generalbytes.bus.test;

import jocket.net.JocketSocket;
import jocket.net.ServerJocket;

import java.io.IOException;

public class TestX {
    public static void main(String[] args) {
        try {
            final ServerJocket ssocket = new ServerJocket(2000,1024,134217728);
            new Thread(new Runnable() {
                @Override
                public void run() {
                    while (true) {
                        try {
                            final JocketSocket accept = ssocket.accept();
                            if (accept == null) {
                                return;
                            }else{
                                accept.close();
                            }
                        } catch (IOException e) {
                            e.printStackTrace();
                        } catch (Exception e) {
                            e.printStackTrace();
                        }
                    }
                }
            }).start();
            try {
                Thread.sleep(1000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            for (int i=0;i<10000;i++){
                    JocketSocket sock = new JocketSocket(2000);
                    sock.close();
            }
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
}

Instead of spinning/sleeping, a thread could wait on a futex and be woken up from another process.

This requires some JNI/JNA and some Unsafe magic.

Beware of the extra latency on the writer...

To supplement close() methods and shutdown hook, a heartbeat could be used to detect dead sockets (eg. when peer process has been killed with -9 or under windows where shutdown hooks do not work).

Currently, the only reader API is InputStream-ish, eg. copy data into a byte array supplied by the user. However, as the data is already present in a ByteBuffer, it would make sense to allow the user to access it directly without copying it first.

Conversely, the writer should be able to directly write into the shared ByteBuffer: no need to serialize data in a byte array and copy it back.

There is no major difficulty in doing that and it would further reduce IPC latency.