runtime: g18: leftover defer sp=0x0 pc=0x0
    defer 0xc208140000 sp=0xc20829fce8 pc=0x776a02
    defer 0xc208416040 sp=0x0 pc=0x0
fatal error: traceback has leftover defers

runtime stack:
runtime.throw(0xa0a070, 0x1d)
    /home/yanyiwu/local/go/src/runtime/panic.go:492 +0x98
runtime.gentraceback(0x776dd0, 0xc20829e570, 0x0, 0xc208092120, 0x0, 0x0, 0x7fffffff, 0xa93290, 0x7f19cde98cc0, 0x0, ...)
    /home/yanyiwu/local/go/src/runtime/traceback.go:414 +0x6dc
runtime.copystack(0xc208092120, 0x4000)
    /home/yanyiwu/local/go/src/runtime/stack1.go:553 +0x187
runtime.newstack()
    /home/yanyiwu/local/go/src/runtime/stack1.go:725 +0xaa4
runtime.morestack()
    /home/yanyiwu/local/go/src/runtime/asm_amd64.s:309 +0x7e

goroutine 18 [copystack]:
github.com/samuel/go-thrift/thrift.(*decoder).readValue(0xc2082808c0, 0xc208280b0c, 0x7c58e0, 0xc208280ba0, 0xd6)
    /home/yanyiwu/golang/src/github.com/samuel/go-thrift/thrift/decoder.go:51 fp=0xc20829e578 sp=0xc20829e570
github.com/samuel/go-thrift/thrift.(*decoder).readValue(0xc2082808c0, 0xc208280b0c, 0x7c4f20, 0xc208280b90, 0xd6)
    /home/yanyiwu/golang/src/github.com/samuel/go-thrift/thrift/decoder.go:164 +0x1521 fp=0xc20829ea28 sp=0xc20829e578
github.com/samuel/go-thrift/thrift.(*decoder).readValue(0xc2082808c0, 0xc20846200c, 0x7c5a00, 0xc208462028, 0xd6)
    /home/yanyiwu/golang/src/github.com/samuel/go-thrift/thrift/decoder.go:164 +0x1521 fp=0xc20829eed8 sp=0xc20829ea28
github.com/samuel/go-thrift/thrift.(*decoder).readValue(0xc2082808c0, 0xc20841620f, 0x7c7620, 0xc208416250, 0xd7)
    /home/yanyiwu/golang/src/github.com/samuel/go-thrift/thrift/decoder.go:212 +0x272d fp=0xc20829f388 sp=0xc20829eed8
github.com/samuel/go-thrift/thrift.(*decoder).readValue(0xc2082808c0, 0xc20847a00c, 0x7c59a0, 0xc20847a010, 0xd6)
    /home/yanyiwu/golang/src/github.com/samuel/go-thrift/thrift/decoder.go:164 +0x1521 fp=0xc20829f838 sp=0xc20829f388
github.com/samuel/go-thrift/thrift.(*decoder).readValue(0xc2082808c0, 0xc20847a00c, 0x8bd740, 0xc20847a010, 0xd9)
    /home/yanyiwu/golang/src/github.com/samuel/go-thrift/thrift/decoder.go:164 +0x1521 fp=0xc20829fce8 sp=0xc20829f838
github.com/samuel/go-thrift/thrift.DecodeStruct(0x7f19cf032dc0, 0xc208047680, 0x7c5760, 0xc20847a010, 0x0, 0x0)
    /home/yanyiwu/golang/src/github.com/samuel/go-thrift/thrift/decoder.go:43 +0x460 fp=0xc20829fda8 sp=0xc20829fce8
github.com/samuel/go-thrift/thrift.(*clientCodec).ReadResponseBody(0xc2080a21b0, 0x7c5760, 0xc20847a010, 0x0, 0x0)
    /home/yanyiwu/golang/src/github.com/samuel/go-thrift/thrift/client.go:159 +0xa5 fp=0xc20829fe00 sp=0xc20829fda8
net/rpc.(*Client).input(0xc208094120)
    /home/yanyiwu/local/go/src/net/rpc/client.go:141 +0xa62 fp=0xc20829ffd8 sp=0xc20829fe00
runtime.goexit()
    /home/yanyiwu/local/go/src/runtime/asm_amd64.s:2403 +0x1 fp=0xc20829ffe0 sp=0xc20829ffd8
created by net/rpc.NewClientWithCodec
    /home/yanyiwu/local/go/src/net/rpc/client.go:201 +0xdb

Does anyone else run into this bug?

Example:

const map<string,string> M1 = {"hello": "world", "goodnight": "moon"}

The parser chokes when it gets to the {.

I would expect this to yield the following Go, I think:

var M1 = map[string]string{"hello": "world", "goodnight": "moon"}

I'm currently working on fixing this, but any pointers you could give would be great.

According to this doc:

https://diwakergupta.github.io/thrift-missing-guide/#_types

The Thrift byte type is a signed type. My understanding is that Go's byte is an alias to unsigned uint8.

Using go-thrift, I get the following transformation:

Thrift method signature

    AcmResponse buildAcm(1: list<byte> byteList, 2: string dataType,
                       3: map<string, string> propertiesMap)
        throws(1: InvalidInputException ex1, 2: SecurityServiceException ex2),

Interface go-thrift generated

BuildAcm(byteList []byte, dataType string, propertiesMap map[string]string) (*AcmResponse, error)

The Apache go thrift library generated the following, as a reference:

BuildAcm(byteList []int8, dataType string, propertiesMap map[string]string) (r *AcmResponse, err error)

I noticed this when interoperating with a Java service via Thrift. In Java, the byte type is a signed 8 bit integer.

Since we have "git.apache.org/thrift.git/lib/go/thrift", this project seems like less useful now!

If it is better to tell us such infos in readme.md

Thanks.

I'm trying to create an RPC service and expose it via go-thrift so that it supports a Go-RPC style method which takes args and a reply and returns an error. Critically, the modified reply struct should be available at the client. I don't think go-thrift currently allows this, but in a previous discussion, you hinted it could; maybe I'm doing something wrong.

type Cave struct{}

func (self *Cave) Echo(args *echoer_thrift.EchoArgs, reply *echoer_thrift.EchoReply) (error) {
    reply.Echo = args.Message
    return nil
}

And the Thrift definition,

struct EchoArgs {
    1: required string Message
}

struct EchoReply {
    1: required string Echo
}

service EchoerThriftface {
    void Echo(
        1: EchoArgs args
        2: EchoReply reply
    )
}

In a client,

var args = echoer_thrift.EchoArgs{}
args.Message = "hello!"
var reply echoer_thrift.EchoReply

conn, _ := net.Dial("tcp", ":1234")
thriftClient := thrift.NewClient(thrift.NewFramedReadWriteCloser(conn, 1024), thrift.NewBinaryProtocol(true, true), false)
client := &echoer_thrift.EchoerThriftfaceClient{thriftClient}
error := client.Echo(&args, &reply)

fmt.Println(reply.Echo)   // reply is EMPTY !!!

Looking at the code generated by go-thrift, it makes sense to my why this occurs. This is the expected behavior right?

Prefixing method names with "Thrift." causes Scribed to get confused and unable to talk to the Go Thrift server. I modified server.go so that it removes the prefix from the response and it works now but I don't know enough about Thrift to tell whether this is a good solution.

thrift idl: http://wiki.apache.org/hadoop/Hbase/ThriftApi

server is writen by java. client use go-thrift to call a remote method will be blocked. the method can't return.

I found it in Go standard library: // Call invokes the named function, waits for it to complete, and returns its error status. func (client *Client) Call(serviceMethod string, args interface{}, reply interface{}) error { call := <-client.Go(serviceMethod, args, reply, make(chan *Call, 1)).Done return call.Error }

client is blocked here. the length of the "Done" channel is 0, so will block here. But I don't know why the "Done" is empty.

Hope resolve it... thx~

Currently when I try to parse a Thrift file using union, I'll get the following error messages:

2015/08/17 10:37:41 Could not parse .thrift file: <reader>:164:1 (3915): rule SyntaxError: parser: syntax error

By some search, below is a real world example Thrift file using union quite a lot. Would be nice to also add this to test files. https://github.com/apache/aurora/blob/master/api/src/main/thrift/org/apache/aurora/gen/api.thrift

Previously, the generated code only referred to a typedef's underlying resolved type. It's useful (and probably expected) to formally declare and use any custom types in the Go-level interface.

This is similar to #20 (although greatly simplified) and closes #19.

I have writen some service using the code generated by apache official tool,then use go-thrift in the client,but the client failed to call the service.Is it compatible with codes generated by the official tool ?

I tried to make a client with go-thrift and communicate with C++ server, however after the client connects to the server, it just hangs there and never return. Though go-thrift is cleaner, I have to switch to thrift4go now. Hopefully go-thrift will add more compatibility tests and become better in the future.

Hi there,

I made a PR recently that updated some function comments. This one will make CodeLingo review your PRs and find similar issues automatically. It will find issues from the Effective Go bundle, and the Code Review Comments bundle. You just have to merge this PR and install the the CodeLingo GitHub App.

Let me know if this is useful :smile: Thanks!

Example:

struct Foo {
  1: optional list<string> Bar = 
  [
    "hello",
    "world"
  ]
}

Returns:

$ generator example.thrift $GOPATH/src
example.thrift:1:1 (0): rule SyntaxError: parser: syntax error

This only happens if you're defining a list within a struct, and doesn't happen with list const. Example:

const list<string> Bar = 
[
  "hello",
  "world"
]

Works as expected.

Example:

const map<string, string> Foo = {
  "hello": "it's me"
  "hi": "how are you",
}

Returns:

$ generator example.thrift $GOPATH/src
example.thrift:1:1 (0): rule SyntaxError: parser: syntax error

It works as expected if I add a trailing comma:

const map<string, string> Foo = {
  "hello": "it's me",
  "hi": "how are you",
}

Go packages can't be nested but you can nest namespaces in Thrift. If you have two Thrift files with the same "leaf" namespace name then when both namespaces are used together the generated Go code won't compile. The error is redeclared as imported package name ...

Eg for this thrift:

  include "Person.Address.thrift"
  include "Computer.Address.thrift"

  struct Details
  {
	1 : optional Person.Address.Primary addr,
	2 : optional Computer.Address.Primary ip,
  }

the Go code looks something like this:

  import (
	"Person/Address"
	"Computer/Address"     // Address redeclared as imported package name
	"git.apache.org/thrift.git/lib/go/thrift"
  )
  .....
  type Details struct {
	Addr             *Address.Primary
	Ip               *Address.Primary
  }

This is not a big problem but could be avoided by importing the package under a non-conflicting name like this:

  import (
	PersonAddress   "Person/Address"
	ComputerAddress "Computer/Address"
	"git.apache.org/thrift.git/lib/go/thrift"
  )
  .....
  type Details struct {
	Addr             *PersonAddress.Primary
	Ip               *ComputerAddress.Primary
  }

• Normalizes as Required for field name vs Optional
• Adds tag 'implicit' when not declared.
• Don't error when decoding if a required field is implicit.

Reference: https://thrift.apache.org/docs/idl#field-requiredness

optional

• Write: Optional fields are only written when they are set
• Read: Optional fields may, or may not be part of the input stream.
• Default values: are written when the isset flag is set

Most language implementations use the recommended practice of so-called "isset" flags to indicate whether a particular optional field is set or not. Only fields with this flag set are written, and conversely the flag is only set when a field value has been read from the input stream.