rbetts / voltdbgo

[Deprecated] VoltDB driver for Google go (golang)
Other
31 stars 8 forks source link

NewConnection EOF error #11

Open plutov opened 9 years ago

plutov commented 9 years ago

Hi.

I have an issue on OSX. Steps: started database in VoltDB manager Security option disabled Try to do NewConnection without username/password And function returns EOF error localhost:21212

What does it mean? For issue: error message can be more meaningful.

curl to 8080 port:

curl http://127.0.0.1:8080/api/1.0/?Procedure=@SystemInformation
{"status":1,"appstatus":-128,"statusstring":null,"appstatusstring":null,"results":[{"status":-128,"schema":[{"name":"HOST_ID","type":5},{"name":"KEY","type":9},{"name":"VALUE","type":9}],"data":[[0,"IPADDRESS","172.19.0.156"],[0,"HOSTNAME","Sashas-MacBook-Pro.local"],[0,"CLIENTINTERFACE",""],[0,"CLIENTPORT","21212"],[0,"ADMININTERFACE",""],[0,"ADMINPORT","21211"],[0,"HTTPINTERFACE",""],[0,"HTTPPORT","8080"],[0,"INTERNALINTERFACE",""],[0,"INTERNALPORT","3021"],[0,"ZKINTERFACE","127.0.0.1"],[0,"ZKPORT","7181"],[0,"DRINTERFACE",""],[0,"DRPORT","5555"],[0,"PUBLICINTERFACE",""],[0,"BUILDSTRING","5.4_voltdb-5.4-0-g4a2c380-local"],[0,"VERSION","5.4"],[0,"CATALOG","/opt/voltdb/83886083/catalog.jar"],[0,"DEPLOYMENT","/opt/voltdb/83886083/deployment.xml"],[0,"CLUSTERSTATE","RUNNING"],[0,"INITIALIZED","true"],[0,"REPLICATIONROLE","NONE"],[0,"LASTCATALOGUPDATETXNID","3619631923216383"],[0,"CATALOGCRC","4125507496"],[0,"IV2ENABLED","true"],[0,"STARTTIME","1437287534723"],[0,"UPTIME","0 days 03:46:56.422"],[0,"LOG4JPORT","4567"],[0,"LICENSE","{\"hostcount\":12,\"commandlogging\":true,\"wanreplication\":true,\"expiration\":\"Mon Aug 24, 2015\",\"trial\":true}"]]}]}
martinhpedersen commented 9 years ago

Hello,

I guess it means that the connection was unexpectedly closed, possibly while reading the login response. I agree, the error could be more meaningful.

These net.Conn errors should probably be contained within the package, at least some of them.

The io.EOF documentation clearly states: "Functions should return EOF only to signal a graceful end of input. If the EOF occurs unexpectedly in a structured data stream, the appropriate error is either ErrUnexpectedEOF or some other error giving more detail."

As to why the connection was dropped, maybe you can find some answers in the server logs?

plutov commented 9 years ago

The real one exception is

WARN: Exception authenticating and registering user in ClientAcceptor
java.io.IOException: String length is bigger than total buffer 2148
    at org.voltdb.messaging.FastDeserializer.readString(FastDeserializer.java:194)
    at org.voltdb.ClientInterface$ClientAcceptor.authenticate(ClientInterface.java:642)
    at org.voltdb.ClientInterface$ClientAcceptor.access$300(ClientInterface.java:271)
    at org.voltdb.ClientInterface$ClientAcceptor$AuthRunnable.run(ClientInterface.java:361)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at org.voltcore.utils.CoreUtils$7$1.run(CoreUtils.java:735)
    at java.lang.Thread.run(Thread.java:745)
db7 commented 8 years ago

There is a field missing in the login message created by voltdbgo. According to the protocol documentation (page 10), the first byte of the login message should identify the password hash version. In the implementation this byte is missing.

The error can be fixed by adding the following lines into io.go:71 (serializeLoginMessage):

err = writeByte(&msg, 0)
if err != nil {
    return
}
bmconklin commented 8 years ago

The above fix was broken by Volt's newer version. While you will be able to connect with the above fix, you will not be able to run any operations at all without getting the error "Unknown BatchTimeoutType 0".

Another fix is to edit the protocol version and set it to "0". This can be found in fastserialize.go line 32, just change the line to be:

const protoVersion = 0 

With this change, it will bypass the check for BatchTimeoutType and not return this error on every call following the initial connect.

Also, note that this fix should be used instead of db7's fix. If you try to do both, it will not be able to connect.