Nullpoint Exception for different thead about nebula-java

[shuitai]

Exception in thread "Thread-1" java.lang.NullPointerException
at com.vesoft.nebula.client.graph.GraphClientImpl.executeQuery(GraphClientImpl.java:134)
at com.coney.microservice.dashboard.NebulaTest$1.run(NebulaTest.java:43)
at java.lang.Thread.run(Thread.java:748)

[shuitai]

From the code in client, I found that it should be connect, execute and close in same thread. If then, I need to create the client every time when access graph data. If connect and close frequently, will it affect the performance?

[Nicole00]

1. What's the client version used in your test?
   You just need to connect and close once for one socket, and switch space operator should be inner of sub-thread.
   refer to issue #171

[shuitai]

V1.1.0

[shuitai]

I have put the switch space operation in sub-thread, but the result is same.

import cn.hutool.core.util.StrUtil;
import com.coney.microservice.dashboard.dto.DashboardDto;
import com.facebook.thrift.TException;
import com.google.common.collect.Lists;
import com.vesoft.nebula.client.graph.*;
import com.vesoft.nebula.data.Result;
import com.vesoft.nebula.graph.RowValue;
import lombok.extern.slf4j.Slf4j;
import org.apache.poi.ss.formula.functions.T;

import java.util.List;

@slf4j
public class NebulaTest {

public static void main(String[] args) throws InterruptedException {
    GraphClientImpl graphClient = new GraphClientImpl("192.168.101.128", 3699);
    graphClient.setUser("user");
    graphClient.setPassword("password");
    try {
        graphClient.connect();
    } catch (TException e) {
        e.printStackTrace();
    }

    Thread t = new Thread(new Runnable() {
        @Override
        public void run() {
            try {
                int code = graphClient.switchSpace("dashboard_graph");
                System.out.println(code);
                String query = "GO FROM uuid(\"{}\") OVER e_user_own_dashboard " +
                        "yield " +
                        "$$.tag_dashboard.id as ID, " +
                        "$$.tag_dashboard.name AS name, " +
                        "$$.tag_dashboard.description AS description, " +
                        "$$.tag_dashboard.status AS status, " +
                        "$$.tag_dashboard.content AS content";
                ResultSet graphResult = graphClient.executeQuery(StrUtil.format(query, 1));
                List<ResultSet.Result> rows = graphResult.getResults();
                for (ResultSet.Result value : rows) {
                    log.info("ID: {}", value.getString("id"));
                    log.info("Name: {}", value.getString("name"));
                }
            } catch (ConnectionException e) {
                e.printStackTrace();
            } catch (NGQLException e) {
                e.printStackTrace();
            } catch (TException e) {
                e.printStackTrace();
            }
        }
    });

    t.start();
    t.join();

    graphClient.close();
}

}

[shuitai]

Exception in thread "Thread-1" java.lang.NullPointerException
at com.vesoft.nebula.client.graph.GraphClientImpl.execute(GraphClientImpl.java:107)
at com.vesoft.nebula.client.graph.GraphClientImpl.switchSpace(GraphClientImpl.java:88)
at com.coney.microservice.dashboard.NebulaTest$1.run(NebulaTest.java:32)
at java.lang.Thread.run(Thread.java:748)

[shuitai]

As you said in #171

GraphClient graphClient = new GraphClientImpl(addresses);
graphClient.connect();
graphClient.executeQuery(gql);

new Thread(() -> {
graphClient.connect();
graphClient.executeQuery(gql);
}).start();

Tsocket will be opened twice, and they are in different thread.

For example:

My App is based on springboot, event request may be in different threads, so we call nebula api, like this.
graphClient.connect();
graphClient.executeQuery(gql);
graphClient.close();

that means we need to connect & close frequently, and socket will close frequently too, when there are a lot of requests.
I think it will cause performance issue, and socket will appear many TIME_WAIT which may occur connection issue in client side.
meanwhile, the v1.1.0 cannot support connection pool.

I don't know if anyone use it in springboot or othere micro service framework.

[shuitai]

TCP 192.168.101.1:8960 192.168.101.128:3699 TIME_WAIT 0
TCP 192.168.101.1:8961 192.168.101.128:3699 TIME_WAIT 0
TCP 192.168.101.1:8962 192.168.101.128:3699 TIME_WAIT 0
TCP 192.168.101.1:8963 192.168.101.128:3699 TIME_WAIT 0
TCP 192.168.101.1:8964 192.168.101.128:3699 TIME_WAIT 0
TCP 192.168.101.1:8965 192.168.101.128:3699 TIME_WAIT 0
TCP 192.168.101.1:8966 192.168.101.128:3699 TIME_WAIT 0
TCP 192.168.101.1:8967 192.168.101.128:3699 TIME_WAIT 0
TCP 192.168.101.1:8968 192.168.101.128:3699 TIME_WAIT 0
TCP 192.168.101.1:8969 192.168.101.128:3699 TIME_WAIT 0
TCP 192.168.101.1:8970 192.168.101.128:3699 TIME_WAIT 0
TCP 192.168.101.1:8971 192.168.101.128:3699 TIME_WAIT 0
TCP 192.168.101.1:8972 192.168.101.128:3699 TIME_WAIT 0
TCP 192.168.101.1:8973 192.168.101.128:3699 TIME_WAIT 0
TCP 192.168.101.1:8974 192.168.101.128:3699 TIME_WAIT 0
TCP 192.168.101.1:8975 192.168.101.128:3699 TIME_WAIT 0
TCP 192.168.101.1:8976 192.168.101.128:3699 TIME_WAIT 0
TCP 192.168.101.1:8977 192.168.101.128:3699 TIME_WAIT 0
TCP 192.168.101.1:8978 192.168.101.128:3699 TIME_WAIT 0
TCP 192.168.101.1:8979 192.168.101.128:3699 TIME_WAIT 0
TCP 192.168.101.1:8980 192.168.101.128:3699 TIME_WAIT 0
TCP 192.168.101.1:8981 192.168.101.128:3699 TIME_WAIT 0
TCP 192.168.101.1:8982 192.168.101.128:3699 TIME_WAIT 0
TCP 192.168.101.1:8983 192.168.101.128:3699 TIME_WAIT 0
TCP 192.168.101.1:8984 192.168.101.128:3699 TIME_WAIT 0
TCP 192.168.101.1:8985 192.168.101.128:3699 TIME_WAIT 0
TCP 192.168.101.1:8986 192.168.101.128:3699 TIME_WAIT 0
TCP 192.168.101.1:8987 192.168.101.128:3699 TIME_WAIT 0
TCP 192.168.101.1:8988 192.168.101.128:3699 TIME_WAIT 0
TCP 192.168.101.1:8989 192.168.101.128:3699 TIME_WAIT 0
TCP 192.168.101.1:8990 192.168.101.128:3699 TIME_WAIT 0
TCP 192.168.101.1:8991 192.168.101.128:3699 TIME_WAIT 0
TCP 192.168.101.1:8992 192.168.101.128:3699 TIME_WAIT 0
TCP 192.168.101.1:8993 192.168.101.128:3699 TIME_WAIT 0
TCP 192.168.101.1:8994 192.168.101.128:3699 TIME_WAIT 0
TCP 192.168.101.1:8995 192.168.101.128:3699 TIME_WAIT 0
TCP 192.168.101.1:8996 192.168.101.128:3699 TIME_WAIT 0
TCP 192.168.101.1:8997 192.168.101.128:3699 TIME_WAIT 0
TCP 192.168.101.1:8998 192.168.101.128:3699 TIME_WAIT 0
TCP 192.168.101.1:8999 192.168.101.128:3699 TIME_WAIT 0
TCP 192.168.101.1:9000 192.168.101.128:3699 TIME_WAIT 0
TCP 192.168.101.1:9001 192.168.101.128:3699 TIME_WAIT 0

[Nicole00]

graphClient.close();

Your program throws NPE because the graphClient is closed in main thread, and NPE happens when sub-thread use graphClient to execute statements.

Sorry that Client 1.x does not support connection pool, if you want to support multi-thread query in SpringClould or SpringBoot, you can use pools to manage graphClient and graphClient's status to avoid graphClient being used by mutil-thread at the same time.