[jira] [Comment Edited] (THRIFT-4285) Pull generated send/recv into library to allow behaviour to be customised
[ https://issues.apache.org/jira/browse/THRIFT-4285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16155962#comment-16155962 ] Chris Bannister edited comment on THRIFT-4285 at 9/6/17 8:16 PM: - Updated all tests (hopefully), changed NewTStandardClient to take input and output protocols instead of a transport and factory. It also appears gofmt has done things to the test files, sorry about that. was (Author: zariel): Updated all tests (hopefully), changed NewTStandardClient to take input and output protocols instead of a transport and factory. > Pull generated send/recv into library to allow behaviour to be customised > - > > Key: THRIFT-4285 > URL: https://issues.apache.org/jira/browse/THRIFT-4285 > Project: Thrift > Issue Type: Improvement > Components: Go - Compiler, Go - Library >Reporter: Chris Bannister >Assignee: Chris Bannister > Attachments: 0001-go-pull-generated-send-recv-into-lib-v6.patch, > 0001-go-pull-generated-send-recv-into-lib-v7.patch > > > Currently it is difficult to change how thrift writes messages onto the > transport because they are in the generated code. Instead the generated > send/recv methods should be in the library. This will greatly simplify the > client code and remove many duplicate methods whilst allowing users more > flexibility to implement connection pools and other features such as THeader. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (THRIFT-4285) Pull generated send/recv into library to allow behaviour to be customised
[ https://issues.apache.org/jira/browse/THRIFT-4285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bannister updated THRIFT-4285: Attachment: 0001-go-pull-generated-send-recv-into-lib-v7.patch Updated all tests (hopefully), changed NewTStandardClient to take input and output protocols instead of a transport and factory. > Pull generated send/recv into library to allow behaviour to be customised > - > > Key: THRIFT-4285 > URL: https://issues.apache.org/jira/browse/THRIFT-4285 > Project: Thrift > Issue Type: Improvement > Components: Go - Compiler, Go - Library >Reporter: Chris Bannister >Assignee: Chris Bannister > Attachments: 0001-go-pull-generated-send-recv-into-lib-v6.patch, > 0001-go-pull-generated-send-recv-into-lib-v7.patch > > > Currently it is difficult to change how thrift writes messages onto the > transport because they are in the generated code. Instead the generated > send/recv methods should be in the library. This will greatly simplify the > client code and remove many duplicate methods whilst allowing users more > flexibility to implement connection pools and other features such as THeader. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (THRIFT-4285) Pull generated send/recv into library to allow behaviour to be customised
[ https://issues.apache.org/jira/browse/THRIFT-4285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bannister updated THRIFT-4285: Attachment: (was: 0001-go-pull-generated-send-recv-into-lib-v5.patch) > Pull generated send/recv into library to allow behaviour to be customised > - > > Key: THRIFT-4285 > URL: https://issues.apache.org/jira/browse/THRIFT-4285 > Project: Thrift > Issue Type: Improvement > Components: Go - Compiler, Go - Library >Reporter: Chris Bannister >Assignee: Chris Bannister > Attachments: 0001-go-pull-generated-send-recv-into-lib-v6.patch > > > Currently it is difficult to change how thrift writes messages onto the > transport because they are in the generated code. Instead the generated > send/recv methods should be in the library. This will greatly simplify the > client code and remove many duplicate methods whilst allowing users more > flexibility to implement connection pools and other features such as THeader. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (THRIFT-4285) Pull generated send/recv into library to allow behaviour to be customised
[ https://issues.apache.org/jira/browse/THRIFT-4285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bannister updated THRIFT-4285: Attachment: 0001-go-pull-generated-send-recv-into-lib-v6.patch Fixed and updated the tests > Pull generated send/recv into library to allow behaviour to be customised > - > > Key: THRIFT-4285 > URL: https://issues.apache.org/jira/browse/THRIFT-4285 > Project: Thrift > Issue Type: Improvement > Components: Go - Compiler, Go - Library >Reporter: Chris Bannister >Assignee: Chris Bannister > Attachments: 0001-go-pull-generated-send-recv-into-lib-v5.patch, > 0001-go-pull-generated-send-recv-into-lib-v6.patch > > > Currently it is difficult to change how thrift writes messages onto the > transport because they are in the generated code. Instead the generated > send/recv methods should be in the library. This will greatly simplify the > client code and remove many duplicate methods whilst allowing users more > flexibility to implement connection pools and other features such as THeader. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (THRIFT-4285) Pull generated send/recv into library to allow behaviour to be customised
[ https://issues.apache.org/jira/browse/THRIFT-4285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bannister updated THRIFT-4285: Attachment: (was: 0001-go-pull-generated-send-recv-into-lib-v3.patch) > Pull generated send/recv into library to allow behaviour to be customised > - > > Key: THRIFT-4285 > URL: https://issues.apache.org/jira/browse/THRIFT-4285 > Project: Thrift > Issue Type: Improvement > Components: Go - Compiler, Go - Library >Reporter: Chris Bannister >Assignee: Chris Bannister > Attachments: 0001-go-pull-generated-send-recv-into-lib-v5.patch > > > Currently it is difficult to change how thrift writes messages onto the > transport because they are in the generated code. Instead the generated > send/recv methods should be in the library. This will greatly simplify the > client code and remove many duplicate methods whilst allowing users more > flexibility to implement connection pools and other features such as THeader. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (THRIFT-4285) Pull generated send/recv into library to allow behaviour to be customised
[ https://issues.apache.org/jira/browse/THRIFT-4285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bannister updated THRIFT-4285: Attachment: (was: 0001-go-pull-generated-send-recv-into-lib.patch) > Pull generated send/recv into library to allow behaviour to be customised > - > > Key: THRIFT-4285 > URL: https://issues.apache.org/jira/browse/THRIFT-4285 > Project: Thrift > Issue Type: Improvement > Components: Go - Compiler, Go - Library >Reporter: Chris Bannister >Assignee: Chris Bannister > Attachments: 0001-go-pull-generated-send-recv-into-lib-v5.patch > > > Currently it is difficult to change how thrift writes messages onto the > transport because they are in the generated code. Instead the generated > send/recv methods should be in the library. This will greatly simplify the > client code and remove many duplicate methods whilst allowing users more > flexibility to implement connection pools and other features such as THeader. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (THRIFT-4285) Pull generated send/recv into library to allow behaviour to be customised
[ https://issues.apache.org/jira/browse/THRIFT-4285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bannister updated THRIFT-4285: Attachment: (was: 0001-go-pull-generated-send-recv-into-lib-v4.patch) > Pull generated send/recv into library to allow behaviour to be customised > - > > Key: THRIFT-4285 > URL: https://issues.apache.org/jira/browse/THRIFT-4285 > Project: Thrift > Issue Type: Improvement > Components: Go - Compiler, Go - Library >Reporter: Chris Bannister >Assignee: Chris Bannister > Attachments: 0001-go-pull-generated-send-recv-into-lib-v5.patch > > > Currently it is difficult to change how thrift writes messages onto the > transport because they are in the generated code. Instead the generated > send/recv methods should be in the library. This will greatly simplify the > client code and remove many duplicate methods whilst allowing users more > flexibility to implement connection pools and other features such as THeader. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (THRIFT-4285) Pull generated send/recv into library to allow behaviour to be customised
[ https://issues.apache.org/jira/browse/THRIFT-4285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bannister updated THRIFT-4285: Attachment: 0001-go-pull-generated-send-recv-into-lib-v5.patch Fix nil error with a set type by using switch statement and returning directly, improve codegen slightly. > Pull generated send/recv into library to allow behaviour to be customised > - > > Key: THRIFT-4285 > URL: https://issues.apache.org/jira/browse/THRIFT-4285 > Project: Thrift > Issue Type: Improvement > Components: Go - Compiler, Go - Library >Reporter: Chris Bannister >Assignee: Chris Bannister > Attachments: 0001-go-pull-generated-send-recv-into-lib-v5.patch > > > Currently it is difficult to change how thrift writes messages onto the > transport because they are in the generated code. Instead the generated > send/recv methods should be in the library. This will greatly simplify the > client code and remove many duplicate methods whilst allowing users more > flexibility to implement connection pools and other features such as THeader. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (THRIFT-4285) Pull generated send/recv into library to allow behaviour to be customised
[ https://issues.apache.org/jira/browse/THRIFT-4285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bannister updated THRIFT-4285: Attachment: (was: 0001-go-pull-generated-send-recv-into-lib-2.patch) > Pull generated send/recv into library to allow behaviour to be customised > - > > Key: THRIFT-4285 > URL: https://issues.apache.org/jira/browse/THRIFT-4285 > Project: Thrift > Issue Type: Improvement > Components: Go - Compiler, Go - Library >Reporter: Chris Bannister >Assignee: Chris Bannister > Attachments: 0001-go-pull-generated-send-recv-into-lib-v5.patch > > > Currently it is difficult to change how thrift writes messages onto the > transport because they are in the generated code. Instead the generated > send/recv methods should be in the library. This will greatly simplify the > client code and remove many duplicate methods whilst allowing users more > flexibility to implement connection pools and other features such as THeader. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (THRIFT-4285) Pull generated send/recv into library to allow behaviour to be customised
[ https://issues.apache.org/jira/browse/THRIFT-4285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16132000#comment-16132000 ] Chris Bannister edited comment on THRIFT-4285 at 8/18/17 10:05 AM: --- Fix typo, use tmp names for args/results incase the service defines the argument name as 'args' or 'result'. This doesn't work with the read_write_private option as the type no longer implement TStruct, not sure what the use of that flag is given the rest of the read/write methods are public. was (Author: zariel): Fix typo, use tmp names for args/results incase the service defines the argument name as 'args' or 'result'. > Pull generated send/recv into library to allow behaviour to be customised > - > > Key: THRIFT-4285 > URL: https://issues.apache.org/jira/browse/THRIFT-4285 > Project: Thrift > Issue Type: Improvement > Components: Go - Compiler, Go - Library >Reporter: Chris Bannister >Assignee: Chris Bannister > Attachments: 0001-go-pull-generated-send-recv-into-lib-2.patch, > 0001-go-pull-generated-send-recv-into-lib.patch, > 0001-go-pull-generated-send-recv-into-lib-v3.patch, > 0001-go-pull-generated-send-recv-into-lib-v4.patch > > > Currently it is difficult to change how thrift writes messages onto the > transport because they are in the generated code. Instead the generated > send/recv methods should be in the library. This will greatly simplify the > client code and remove many duplicate methods whilst allowing users more > flexibility to implement connection pools and other features such as THeader. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (THRIFT-4285) Pull generated send/recv into library to allow behaviour to be customised
[ https://issues.apache.org/jira/browse/THRIFT-4285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bannister updated THRIFT-4285: Attachment: 0001-go-pull-generated-send-recv-into-lib-v4.patch Fix typo, use tmp names for args/results incase the service defines the argument name as 'args' or 'result'. > Pull generated send/recv into library to allow behaviour to be customised > - > > Key: THRIFT-4285 > URL: https://issues.apache.org/jira/browse/THRIFT-4285 > Project: Thrift > Issue Type: Improvement > Components: Go - Compiler, Go - Library >Reporter: Chris Bannister >Assignee: Chris Bannister > Attachments: 0001-go-pull-generated-send-recv-into-lib-2.patch, > 0001-go-pull-generated-send-recv-into-lib.patch, > 0001-go-pull-generated-send-recv-into-lib-v3.patch, > 0001-go-pull-generated-send-recv-into-lib-v4.patch > > > Currently it is difficult to change how thrift writes messages onto the > transport because they are in the generated code. Instead the generated > send/recv methods should be in the library. This will greatly simplify the > client code and remove many duplicate methods whilst allowing users more > flexibility to implement connection pools and other features such as THeader. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (THRIFT-4285) Pull generated send/recv into library to allow behaviour to be customised
[ https://issues.apache.org/jira/browse/THRIFT-4285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bannister updated THRIFT-4285: Attachment: 0001-go-pull-generated-send-recv-into-lib-v3.patch Export TStandardClient as it can be useful for those wanting to implement connection pools and maintain their own transports. Retain existing error format including method name. > Pull generated send/recv into library to allow behaviour to be customised > - > > Key: THRIFT-4285 > URL: https://issues.apache.org/jira/browse/THRIFT-4285 > Project: Thrift > Issue Type: Improvement > Components: Go - Compiler, Go - Library >Reporter: Chris Bannister >Assignee: Chris Bannister > Attachments: 0001-go-pull-generated-send-recv-into-lib-2.patch, > 0001-go-pull-generated-send-recv-into-lib.patch, > 0001-go-pull-generated-send-recv-into-lib-v3.patch > > > Currently it is difficult to change how thrift writes messages onto the > transport because they are in the generated code. Instead the generated > send/recv methods should be in the library. This will greatly simplify the > client code and remove many duplicate methods whilst allowing users more > flexibility to implement connection pools and other features such as THeader. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (THRIFT-4285) Pull generated send/recv into library to allow behaviour to be customised
[ https://issues.apache.org/jira/browse/THRIFT-4285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bannister updated THRIFT-4285: Attachment: 0001-go-pull-generated-send-recv-into-lib-2.patch removed unnecessary interfaces > Pull generated send/recv into library to allow behaviour to be customised > - > > Key: THRIFT-4285 > URL: https://issues.apache.org/jira/browse/THRIFT-4285 > Project: Thrift > Issue Type: Improvement > Components: Go - Compiler, Go - Library >Reporter: Chris Bannister >Assignee: Chris Bannister > Attachments: 0001-go-pull-generated-send-recv-into-lib-2.patch, > 0001-go-pull-generated-send-recv-into-lib.patch > > > Currently it is difficult to change how thrift writes messages onto the > transport because they are in the generated code. Instead the generated > send/recv methods should be in the library. This will greatly simplify the > client code and remove many duplicate methods whilst allowing users more > flexibility to implement connection pools and other features such as THeader. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (THRIFT-4285) Pull generated send/recv into library to allow behaviour to be customised
[ https://issues.apache.org/jira/browse/THRIFT-4285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16124980#comment-16124980 ] Chris Bannister commented on THRIFT-4285: - Something I just noticed, no need to define ArgWriter/ResultReader as they should just be TStructs > Pull generated send/recv into library to allow behaviour to be customised > - > > Key: THRIFT-4285 > URL: https://issues.apache.org/jira/browse/THRIFT-4285 > Project: Thrift > Issue Type: Improvement > Components: Go - Compiler, Go - Library >Reporter: Chris Bannister >Assignee: Chris Bannister > Attachments: 0001-go-pull-generated-send-recv-into-lib.patch > > > Currently it is difficult to change how thrift writes messages onto the > transport because they are in the generated code. Instead the generated > send/recv methods should be in the library. This will greatly simplify the > client code and remove many duplicate methods whilst allowing users more > flexibility to implement connection pools and other features such as THeader. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (THRIFT-4285) Pull generated send/recv into library to allow behaviour to be customised
[ https://issues.apache.org/jira/browse/THRIFT-4285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16124955#comment-16124955 ] Chris Bannister commented on THRIFT-4285: - This is a breaking change for the generated code as the methods NewXXXClientFactory no long exist, instead the NewXXXClient takes a TClient which can be customised with different protocol/transport options. > Pull generated send/recv into library to allow behaviour to be customised > - > > Key: THRIFT-4285 > URL: https://issues.apache.org/jira/browse/THRIFT-4285 > Project: Thrift > Issue Type: Improvement > Components: Go - Compiler, Go - Library >Reporter: Chris Bannister >Assignee: Chris Bannister > Attachments: 0001-go-pull-generated-send-recv-into-lib.patch > > > Currently it is difficult to change how thrift writes messages onto the > transport because they are in the generated code. Instead the generated > send/recv methods should be in the library. This will greatly simplify the > client code and remove many duplicate methods whilst allowing users more > flexibility to implement connection pools and other features such as THeader. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (THRIFT-4285) Pull generated send/recv into library to allow behaviour to be customised
[ https://issues.apache.org/jira/browse/THRIFT-4285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bannister updated THRIFT-4285: Attachment: 0001-go-pull-generated-send-recv-into-lib.patch > Pull generated send/recv into library to allow behaviour to be customised > - > > Key: THRIFT-4285 > URL: https://issues.apache.org/jira/browse/THRIFT-4285 > Project: Thrift > Issue Type: Improvement > Components: Go - Compiler, Go - Library >Reporter: Chris Bannister >Assignee: Chris Bannister > Attachments: 0001-go-pull-generated-send-recv-into-lib.patch > > > Currently it is difficult to change how thrift writes messages onto the > transport because they are in the generated code. Instead the generated > send/recv methods should be in the library. This will greatly simplify the > client code and remove many duplicate methods whilst allowing users more > flexibility to implement connection pools and other features such as THeader. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (THRIFT-4285) Pull generated send/recv into library to allow behaviour to be customised
Chris Bannister created THRIFT-4285: --- Summary: Pull generated send/recv into library to allow behaviour to be customised Key: THRIFT-4285 URL: https://issues.apache.org/jira/browse/THRIFT-4285 Project: Thrift Issue Type: Improvement Components: Go - Compiler, Go - Library Reporter: Chris Bannister Assignee: Chris Bannister Currently it is difficult to change how thrift writes messages onto the transport because they are in the generated code. Instead the generated send/recv methods should be in the library. This will greatly simplify the client code and remove many duplicate methods whilst allowing users more flexibility to implement connection pools and other features such as THeader. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (THRIFT-3799) Make constants to use iota
[ https://issues.apache.org/jira/browse/THRIFT-3799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15344427#comment-15344427 ] Chris Bannister commented on THRIFT-3799: - I would say this is not a good idea, and is not idiomatic Go. Using iota is for when the value does not matter, but in the case of thrift the value does matter so iota should not be used. It does not effect the code but makes it clear that the value of the enum is a specific value. > Make constants to use iota > -- > > Key: THRIFT-3799 > URL: https://issues.apache.org/jira/browse/THRIFT-3799 > Project: Thrift > Issue Type: Improvement > Components: Go - Library >Reporter: Mahendran Kathirvel >Priority: Minor > Labels: easyfix > Original Estimate: 24h > Remaining Estimate: 24h > > Now, the constants and enumerations are using hardcoded values but Go has a > elegant way of doing this by using `Iota` -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (THRIFT-3805) Golang server susceptible to memory spike from malformed message
[ https://issues.apache.org/jira/browse/THRIFT-3805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15275738#comment-15275738 ] Chris Bannister commented on THRIFT-3805: - The check for the buffer size should be, size <= cap(buffer) as it can still be expanded. > Golang server susceptible to memory spike from malformed message > > > Key: THRIFT-3805 > URL: https://issues.apache.org/jira/browse/THRIFT-3805 > Project: Thrift > Issue Type: Bug > Components: Go - Library >Affects Versions: 0.9.3 > Environment: OSX 10.10.5, Debian 7.10 >Reporter: Michael Scott Leuthaeuser >Priority: Critical > Attachments: thrift_golang_memory_spike_fix.patch > > > When a thrift server is started through the Go library, using the default > TServerSocket, the processor from the generated files, and a SimpleServer2 > (which uses BinaryProtocol), it listens on the created socket for incoming > messages. However, if the incoming message is *not* from another Thrift > server, and thus the data submitted over the connection does not conform to > the Thrift message serialization format (for us, this was triggered by > automated security scanners connecting to the exposed port and sending it > data to see how it would react), it triggers a massive memory spike. > This appears to happen because the BinaryProtocol expects the first 4 bytes > of the file to indicate the size of the following message, interpreted as a > signed Int32 in BigEndian format. If this value is positive, it reads that > many bytes from the connection. > However, to do this, it first *allocates* a slice of that many bytes. If the > provided message is not a thrift serialization, this signed Int32 can be > massive (we're typically seeing it have a value of 1-2 billion), causing it > to allocate *hundreds* of megabytes of data. This slice is retained until > the expected number of bytes are received (which generally doesn't happen for > a malformed connection), or until the connection is closed from the client > end. When either happen, the BinaryProtocol then type-casts the entire array > to a String type, which causes a *second* allocation of equal size, before > returning the message to be processed. > Since this processing fails, both the byte slice and the string are discarded > and reclaimed on the next garbage collection cycle, but in the mean type, it > will have allocated an amount of memory equal to double the value of that > Int32, in bytes. We're typically seeing this allocation exceed 800-1000 MB > per variable (so 800 MB when the connection is received, and another 800-1000 > MB when it's closed). The first allocation will persist as long as the > connection is maintained, and other connections that are similarly malformed > will cause concurrent allocation spikes, which can easily crash the server. > To demonstrate this, one can make an extremely simple single-method thrift > contract, start a server, then netcat to the host port and feed it at least 4 > characters of data. > To fix this, we implemented an iterative buffered read into the > BinaryProtocol itself. Instead of allocating the entire array at once, if > the message indicates it is larger than a certain size (we have it set at > 32kb, but the actual value is largely arbitrary), it instead reads the > message in increments of that size, and joins them using the standard library > bytes.Buffer type. Here's a diff of our changes: > https://gist.github.com/kaedys/53b8fd05690d5d8f202afa7878d6e3d5 > This fixes the issue of having a massive initial allocation due to a > malformed request, while still allowing messages of arbitrary incoming size. > It will likely marginally slow down the reading of extremely large messages > (ones substantially larger than the constant defined), but the bytes.Buffer > type is well optimized for growing itself as it is written to. I also > realize that this only occurs with malformed requests to the server, but I > would think a server package should be relatively hardened against malformed > data being submitted to it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (THRIFT-3533) Can not send nil pointer as service method argument
[ https://issues.apache.org/jira/browse/THRIFT-3533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bannister updated THRIFT-3533: Attachment: 0001-THRIFT-3533-go-check-that-the-struct-is-nil-before-w.patch > Can not send nil pointer as service method argument > --- > > Key: THRIFT-3533 > URL: https://issues.apache.org/jira/browse/THRIFT-3533 > Project: Thrift > Issue Type: Bug > Components: Go - Compiler >Affects Versions: 0.9.3 >Reporter: Chris Bannister >Assignee: Chris Bannister > Attachments: > 0001-THRIFT-3533-go-check-that-the-struct-is-nil-before-w.patch, > 0001-go-compiler-handle-nil-fields-correctly.patch > > > If you try to send a nil struct as an argument to a service method a panic > occurs as it tries to write out all the fields in the struct, the python > generated code has guarding 'if self.x != None:' for every struct field, > whereas Go only outputs the 'if p.IsSet()' when the field is declared > optional, which is not possible for argument lists. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (THRIFT-3533) Can not send nil pointer as service method argument
[ https://issues.apache.org/jira/browse/THRIFT-3533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15266835#comment-15266835 ] Chris Bannister commented on THRIFT-3533: - [~jensg] sorry for the delay, can you take a look at the latest patch, it does what you suggest which is simplest. > Can not send nil pointer as service method argument > --- > > Key: THRIFT-3533 > URL: https://issues.apache.org/jira/browse/THRIFT-3533 > Project: Thrift > Issue Type: Bug > Components: Go - Compiler >Affects Versions: 0.9.3 >Reporter: Chris Bannister >Assignee: Chris Bannister > Attachments: > 0001-THRIFT-3533-go-check-that-the-struct-is-nil-before-w.patch, > 0001-go-compiler-handle-nil-fields-correctly.patch > > > If you try to send a nil struct as an argument to a service method a panic > occurs as it tries to write out all the fields in the struct, the python > generated code has guarding 'if self.x != None:' for every struct field, > whereas Go only outputs the 'if p.IsSet()' when the field is declared > optional, which is not possible for argument lists. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (THRIFT-3575) Go compiler tries to use unexported library methods when using read_write_private
Chris Bannister created THRIFT-3575: --- Summary: Go compiler tries to use unexported library methods when using read_write_private Key: THRIFT-3575 URL: https://issues.apache.org/jira/browse/THRIFT-3575 Project: Thrift Issue Type: Bug Components: Go - Compiler Affects Versions: 0.9.3 Reporter: Chris Bannister Assignee: Chris Bannister Attachments: 0001-go-dont-use-reader-writer-names-for-lib-functions.patch The go compiler when using read_write_private will use lower case read and write methods for exceptions defined in the library package, which can not be accessed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (THRIFT-3575) Go compiler tries to use unexported library methods when using read_write_private
[ https://issues.apache.org/jira/browse/THRIFT-3575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bannister updated THRIFT-3575: Attachment: 0001-go-dont-use-reader-writer-names-for-lib-functions.patch > Go compiler tries to use unexported library methods when using > read_write_private > - > > Key: THRIFT-3575 > URL: https://issues.apache.org/jira/browse/THRIFT-3575 > Project: Thrift > Issue Type: Bug > Components: Go - Compiler >Affects Versions: 0.9.3 >Reporter: Chris Bannister >Assignee: Chris Bannister > Attachments: > 0001-go-dont-use-reader-writer-names-for-lib-functions.patch > > > The go compiler when using read_write_private will use lower case read and > write methods for exceptions defined in the library package, which can not be > accessed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (THRIFT-3533) Can not send nil pointer as service method argument
[
https://issues.apache.org/jira/browse/THRIFT-3533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15109649#comment-15109649
]
Chris Bannister edited comment on THRIFT-3533 at 1/20/16 10:56 PM:
---
Yeah that is a bit of a pain, I think that comes down to the *Args structs
being written out using the same code paths as user defined structs. The
internal Args struct will obviously not be nil, so this could be optimised
away. This change makes most sense when you look at user defined structs, for
example the {{Lock}}
{noformat}
func (p *Lock) writeField1(oprot thrift.TProtocol) (err error) {
if p.IsSetKey() {
if err := oprot.WriteFieldBegin("key", thrift.STRUCT, 1); err
!= nil {
return thrift.PrependError(fmt.Sprintf("%T write field
begin error 1:key: ", p), err)
}
if err := p.Key.Write(oprot); err != nil {
return thrift.PrependError(fmt.Sprintf("%T error
writing struct: ", p.Key), err)
}
if err := oprot.WriteFieldEnd(); err != nil {
return thrift.PrependError(fmt.Sprintf("%T write field
end error 1:key: ", p), err)
}
}
return err
}
{noformat}
Looking at the Java code this looks quite similar, except the Java compiler
does not generate it for the internal Arg structs.
{code}
public void write(org.apache.thrift.protocol.TProtocol oprot, Lock struct)
throws org.apache.thrift.TException {
struct.validate();
oprot.writeStructBegin(STRUCT_DESC);
if (struct.key != null) {
oprot.writeFieldBegin(KEY_FIELD_DESC);
struct.key.write(oprot);
oprot.writeFieldEnd();
}
{code}
was (Author: zariel):
Yeah that is a bit of a pain, I think that comes down to the *Args structs
being written out using the same code paths as user defined structs. The
internal Args struct will obviously not be nil, so this could be optimised
away. This change makes most sense when you look at user defined structs, for
example the {{Lock}}
{noformat}
func (p *Lock) writeField1(oprot thrift.TProtocol) (err error) {
if p.IsSetKey() {
if err := oprot.WriteFieldBegin("key", thrift.STRUCT, 1); err
!= nil {
return thrift.PrependError(fmt.Sprintf("%T write field
begin error 1:key: ", p), err)
}
if err := p.Key.Write(oprot); err != nil {
return thrift.PrependError(fmt.Sprintf("%T error
writing struct: ", p.Key), err)
}
if err := oprot.WriteFieldEnd(); err != nil {
return thrift.PrependError(fmt.Sprintf("%T write field
end error 1:key: ", p), err)
}
}
return err
}
{noformat}
Looking at the Java code this looks quite similar, except the Java compiler
does not generate it for the internal Arg structs.
{code}
public void write(org.apache.thrift.protocol.TProtocol oprot,
createJob_args struct) throws org.apache.thrift.TException {
struct.validate();
oprot.writeStructBegin(STRUCT_DESC);
if (struct.description != null) {
oprot.writeFieldBegin(DESCRIPTION_FIELD_DESC);
struct.description.write(oprot);
oprot.writeFieldEnd();
}
if (struct.lock != null) {
oprot.writeFieldBegin(LOCK_FIELD_DESC);
struct.lock.write(oprot);
oprot.writeFieldEnd();
}
oprot.writeFieldStop();
oprot.writeStructEnd();
}
{code}
> Can not send nil pointer as service method argument
> ---
>
> Key: THRIFT-3533
> URL: https://issues.apache.org/jira/browse/THRIFT-3533
> Project: Thrift
> Issue Type: Bug
> Components: Go - Compiler
>Affects Versions: 0.9.3
>Reporter: Chris Bannister
> Attachments: 0001-go-compiler-handle-nil-fields-correctly.patch
>
>
> If you try to send a nil struct as an argument to a service method a panic
> occurs as it tries to write out all the fields in the struct, the python
> generated code has guarding 'if self.x != None:' for every struct field,
> whereas Go only outputs the 'if p.IsSet()' when the field is declared
> optional, which is not possible for argument lists.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (THRIFT-3533) Can not send nil pointer as service method argument
[
https://issues.apache.org/jira/browse/THRIFT-3533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15109649#comment-15109649
]
Chris Bannister edited comment on THRIFT-3533 at 1/20/16 10:50 PM:
---
Yeah that is a bit of a pain, I think that comes down to the *Args structs
being written out using the same code paths as user defined structs. The
internal Args struct will obviously not be nil, so this could be optimised
away. This change makes most sense when you look at user defined structs, for
example the {{Lock}}
{noformat}
func (p *Lock) writeField1(oprot thrift.TProtocol) (err error) {
if p.IsSetKey() {
if err := oprot.WriteFieldBegin("key", thrift.STRUCT, 1); err
!= nil {
return thrift.PrependError(fmt.Sprintf("%T write field
begin error 1:key: ", p), err)
}
if err := p.Key.Write(oprot); err != nil {
return thrift.PrependError(fmt.Sprintf("%T error
writing struct: ", p.Key), err)
}
if err := oprot.WriteFieldEnd(); err != nil {
return thrift.PrependError(fmt.Sprintf("%T write field
end error 1:key: ", p), err)
}
}
return err
}
{noformat}
Looking at the Java code this looks quite similar, except the Java compiler
does not generate it for the internal Arg structs.
{code}
public void write(org.apache.thrift.protocol.TProtocol oprot,
createJob_args struct) throws org.apache.thrift.TException {
struct.validate();
oprot.writeStructBegin(STRUCT_DESC);
if (struct.description != null) {
oprot.writeFieldBegin(DESCRIPTION_FIELD_DESC);
struct.description.write(oprot);
oprot.writeFieldEnd();
}
if (struct.lock != null) {
oprot.writeFieldBegin(LOCK_FIELD_DESC);
struct.lock.write(oprot);
oprot.writeFieldEnd();
}
oprot.writeFieldStop();
oprot.writeStructEnd();
}
{code}
was (Author: zariel):
Yeah that is a bit of a pain, I think that comes down to the *Args structs
being written out using the same code paths as user defined structs. The
internal Args struct will obviously not be nil, so this could be optimised
away. This change makes most sense when you look at user defined structs, for
example the {{Lock}}
{{noformat}}
func (p *Lock) writeField1(oprot thrift.TProtocol) (err error) {
if p.IsSetKey() {
if err := oprot.WriteFieldBegin("key", thrift.STRUCT, 1); err
!= nil {
return thrift.PrependError(fmt.Sprintf("%T write field
begin error 1:key: ", p), err)
}
if err := p.Key.Write(oprot); err != nil {
return thrift.PrependError(fmt.Sprintf("%T error
writing struct: ", p.Key), err)
}
if err := oprot.WriteFieldEnd(); err != nil {
return thrift.PrependError(fmt.Sprintf("%T write field
end error 1:key: ", p), err)
}
}
return err
}
{{noformat}}
Looking at the Java code this looks quite similar, except the Java compiler
does not generate it for the internal Arg structs.
{{code}}
public void write(org.apache.thrift.protocol.TProtocol oprot,
createJob_args struct) throws org.apache.thrift.TException {
struct.validate();
oprot.writeStructBegin(STRUCT_DESC);
if (struct.description != null) {
oprot.writeFieldBegin(DESCRIPTION_FIELD_DESC);
struct.description.write(oprot);
oprot.writeFieldEnd();
}
if (struct.lock != null) {
oprot.writeFieldBegin(LOCK_FIELD_DESC);
struct.lock.write(oprot);
oprot.writeFieldEnd();
}
oprot.writeFieldStop();
oprot.writeStructEnd();
}
{{code}}
> Can not send nil pointer as service method argument
> ---
>
> Key: THRIFT-3533
> URL: https://issues.apache.org/jira/browse/THRIFT-3533
> Project: Thrift
> Issue Type: Bug
> Components: Go - Compiler
>Affects Versions: 0.9.3
>Reporter: Chris Bannister
> Attachments: 0001-go-compiler-handle-nil-fields-correctly.patch
>
>
> If you try to send a nil struct as an argument to a service method a panic
> occurs as it tries to write out all the fields in the struct, the python
> generated code has guarding 'if self.x != None:' for every struct field,
> whereas Go only outputs the 'if p.IsSet()' when the field is declared
> optional, which is not possible for argument lists.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (THRIFT-3533) Can not send nil pointer as service method argument
[
https://issues.apache.org/jira/browse/THRIFT-3533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15109649#comment-15109649
]
Chris Bannister commented on THRIFT-3533:
-
Yeah that is a bit of a pain, I think that comes down to the *Args structs
being written out using the same code paths as user defined structs. The
internal Args struct will obviously not be nil, so this could be optimised
away. This change makes most sense when you look at user defined structs, for
example the {{Lock}}
{{noformat}}
func (p *Lock) writeField1(oprot thrift.TProtocol) (err error) {
if p.IsSetKey() {
if err := oprot.WriteFieldBegin("key", thrift.STRUCT, 1); err
!= nil {
return thrift.PrependError(fmt.Sprintf("%T write field
begin error 1:key: ", p), err)
}
if err := p.Key.Write(oprot); err != nil {
return thrift.PrependError(fmt.Sprintf("%T error
writing struct: ", p.Key), err)
}
if err := oprot.WriteFieldEnd(); err != nil {
return thrift.PrependError(fmt.Sprintf("%T write field
end error 1:key: ", p), err)
}
}
return err
}
{{noformat}}
Looking at the Java code this looks quite similar, except the Java compiler
does not generate it for the internal Arg structs.
{{code}}
public void write(org.apache.thrift.protocol.TProtocol oprot,
createJob_args struct) throws org.apache.thrift.TException {
struct.validate();
oprot.writeStructBegin(STRUCT_DESC);
if (struct.description != null) {
oprot.writeFieldBegin(DESCRIPTION_FIELD_DESC);
struct.description.write(oprot);
oprot.writeFieldEnd();
}
if (struct.lock != null) {
oprot.writeFieldBegin(LOCK_FIELD_DESC);
struct.lock.write(oprot);
oprot.writeFieldEnd();
}
oprot.writeFieldStop();
oprot.writeStructEnd();
}
{{code}}
> Can not send nil pointer as service method argument
> ---
>
> Key: THRIFT-3533
> URL: https://issues.apache.org/jira/browse/THRIFT-3533
> Project: Thrift
> Issue Type: Bug
> Components: Go - Compiler
>Affects Versions: 0.9.3
>Reporter: Chris Bannister
> Attachments: 0001-go-compiler-handle-nil-fields-correctly.patch
>
>
> If you try to send a nil struct as an argument to a service method a panic
> occurs as it tries to write out all the fields in the struct, the python
> generated code has guarding 'if self.x != None:' for every struct field,
> whereas Go only outputs the 'if p.IsSet()' when the field is declared
> optional, which is not possible for argument lists.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (THRIFT-3533) Can not send nil pointer as service method argument
[ https://issues.apache.org/jira/browse/THRIFT-3533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15108954#comment-15108954 ] Chris Bannister commented on THRIFT-3533: - [~jensg] can you take a look at this patch, it causes the compiler to now generate IsSet* methods for all types to avoid nil pointer panics, and returns an error if the field is required but not set. > Can not send nil pointer as service method argument > --- > > Key: THRIFT-3533 > URL: https://issues.apache.org/jira/browse/THRIFT-3533 > Project: Thrift > Issue Type: Bug > Components: Go - Compiler >Affects Versions: 0.9.3 >Reporter: Chris Bannister > Attachments: 0001-go-compiler-handle-nil-fields-correctly.patch > > > If you try to send a nil struct as an argument to a service method a panic > occurs as it tries to write out all the fields in the struct, the python > generated code has guarding 'if self.x != None:' for every struct field, > whereas Go only outputs the 'if p.IsSet()' when the field is declared > optional, which is not possible for argument lists. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (THRIFT-3533) Can not send nil pointer as service method argument
[ https://issues.apache.org/jira/browse/THRIFT-3533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bannister updated THRIFT-3533: Patch Info: Patch Available > Can not send nil pointer as service method argument > --- > > Key: THRIFT-3533 > URL: https://issues.apache.org/jira/browse/THRIFT-3533 > Project: Thrift > Issue Type: Bug > Components: Go - Compiler >Affects Versions: 0.9.3 >Reporter: Chris Bannister > Attachments: 0001-go-compiler-handle-nil-fields-correctly.patch > > > If you try to send a nil struct as an argument to a service method a panic > occurs as it tries to write out all the fields in the struct, the python > generated code has guarding 'if self.x != None:' for every struct field, > whereas Go only outputs the 'if p.IsSet()' when the field is declared > optional, which is not possible for argument lists. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (THRIFT-3533) Can not send nil pointer as service method argument
[ https://issues.apache.org/jira/browse/THRIFT-3533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bannister updated THRIFT-3533: Attachment: 0001-go-compiler-handle-nil-fields-correctly.patch > Can not send nil pointer as service method argument > --- > > Key: THRIFT-3533 > URL: https://issues.apache.org/jira/browse/THRIFT-3533 > Project: Thrift > Issue Type: Bug > Components: Go - Compiler >Affects Versions: 0.9.3 >Reporter: Chris Bannister > Attachments: 0001-go-compiler-handle-nil-fields-correctly.patch > > > If you try to send a nil struct as an argument to a service method a panic > occurs as it tries to write out all the fields in the struct, the python > generated code has guarding 'if self.x != None:' for every struct field, > whereas Go only outputs the 'if p.IsSet()' when the field is declared > optional, which is not possible for argument lists. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (THRIFT-3533) Can not send nil pointer as service method argument
[
https://issues.apache.org/jira/browse/THRIFT-3533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15090984#comment-15090984
]
Chris Bannister edited comment on THRIFT-3533 at 1/10/16 11:12 AM:
---
In python you can write this,
service.method(None) which works fine, but in go if you do service.method(nil)
it panics.
Im not sure which is correct.
This is the code from
https://github.com/apache/aurora/blob/6b768bd3dd053b776a5b713c4fd5ce95e31e666b/api/src/main/thrift/org/apache/aurora/gen/api.thrift#L1008
for create_job args.Write in python,
{noformat}
def write(self, oprot):
if oprot.__class__ == TBinaryProtocol.TBinaryProtocolAccelerated and
self.thrift_spec is not None and fastbinary is not None:
oprot.trans.write(fastbinary.encode_binary(self, (self.__class__,
self.thrift_spec)))
return
oprot.writeStructBegin('createJob_args')
if self.description is not None:
oprot.writeFieldBegin('description', TType.STRUCT, 1)
self.description.write(oprot)
oprot.writeFieldEnd()
if self.lock is not None:
oprot.writeFieldBegin('lock', TType.STRUCT, 3)
self.lock.write(oprot)
oprot.writeFieldEnd()
oprot.writeFieldStop()
oprot.writeStructEnd()
{noformat}
and In Go it looks like this
{noformat}
func (p *AuroraSchedulerManagerCreateJobArgs) Write(oprot thrift.TProtocol)
error {
if err := oprot.WriteStructBegin("createJob_args"); err != nil {
return thrift.PrependError(fmt.Sprintf("%T write struct begin
error: ", p), err)
}
if err := p.writeField1(oprot); err != nil {
return err
}
if err := p.writeField3(oprot); err != nil {
return err
}
if err := oprot.WriteFieldStop(); err != nil {
return thrift.PrependError("write field stop error: ", err)
}
if err := oprot.WriteStructEnd(); err != nil {
return thrift.PrependError("write struct stop error: ", err)
}
return nil
}
func (p *AuroraSchedulerManagerCreateJobArgs) writeField1(oprot
thrift.TProtocol) (err error) {
if err := oprot.WriteFieldBegin("description", thrift.STRUCT, 1); err
!= nil {
return thrift.PrependError(fmt.Sprintf("%T write field begin
error 1:description: ", p), err)
}
if err := p.Description.Write(oprot); err != nil {
return thrift.PrependError(fmt.Sprintf("%T error writing
struct: ", p.Description), err)
}
if err := oprot.WriteFieldEnd(); err != nil {
return thrift.PrependError(fmt.Sprintf("%T write field end
error 1:description: ", p), err)
}
return err
}
{noformat}
Go will insert the 'x.IsSet' for optional fields, but args can't be optional.
was (Author: zariel):
In python you can write this,
service.method(None) which works fine, but in go if you do service.method(nil)
it panics.
Im not sure which is correct.
This is the code from
https://github.com/apache/aurora/blob/6b768bd3dd053b776a5b713c4fd5ce95e31e666b/api/src/main/thrift/org/apache/aurora/gen/api.thrift#L1008
for create_job args.Write in python,
{noformat}
def write(self, oprot):
if oprot.__class__ == TBinaryProtocol.TBinaryProtocolAccelerated and
self.thrift_spec is not None and fastbinary is not None:
oprot.trans.write(fastbinary.encode_binary(self, (self.__class__,
self.thrift_spec)))
return
oprot.writeStructBegin('createJob_args')
if self.description is not None:
oprot.writeFieldBegin('description', TType.STRUCT, 1)
self.description.write(oprot)
oprot.writeFieldEnd()
if self.lock is not None:
oprot.writeFieldBegin('lock', TType.STRUCT, 3)
self.lock.write(oprot)
oprot.writeFieldEnd()
oprot.writeFieldStop()
oprot.writeStructEnd()
{noformat}
and In Go it looks like this
{noformat}
func (p *AuroraSchedulerManagerCreateJobArgs) Write(oprot thrift.TProtocol)
error {
if err := oprot.WriteStructBegin("createJob_args"); err != nil {
return thrift.PrependError(fmt.Sprintf("%T write struct begin
error: ", p), err)
}
if err := p.writeField1(oprot); err != nil {
return err
}
if err := p.writeField3(oprot); err != nil {
return err
}
if err := oprot.WriteFieldStop(); err != nil {
return thrift.PrependError("write field stop error: ", err)
}
if err := oprot.WriteStructEnd(); err != nil {
return thrift.PrependError("write struct stop error: ", err)
}
return nil
}
{noformat}
Go will insert the 'x.IsSet' for optional fields, but args can't be optional.
> Can not send nil pointer as service method argument
> ---
>
>
[jira] [Comment Edited] (THRIFT-3533) Can not send nil pointer as service method argument
[
https://issues.apache.org/jira/browse/THRIFT-3533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15090984#comment-15090984
]
Chris Bannister edited comment on THRIFT-3533 at 1/10/16 11:11 AM:
---
In python you can write this,
service.method(None) which works fine, but in go if you do service.method(nil)
it panics.
Im not sure which is correct.
This is the code from
https://github.com/apache/aurora/blob/6b768bd3dd053b776a5b713c4fd5ce95e31e666b/api/src/main/thrift/org/apache/aurora/gen/api.thrift#L1008
for create_job args.Write in python,
{code:python}
def write(self, oprot):
if oprot.__class__ == TBinaryProtocol.TBinaryProtocolAccelerated and
self.thrift_spec is not None and fastbinary is not None:
oprot.trans.write(fastbinary.encode_binary(self, (self.__class__,
self.thrift_spec)))
return
oprot.writeStructBegin('createJob_args')
if self.description is not None:
oprot.writeFieldBegin('description', TType.STRUCT, 1)
self.description.write(oprot)
oprot.writeFieldEnd()
if self.lock is not None:
oprot.writeFieldBegin('lock', TType.STRUCT, 3)
self.lock.write(oprot)
oprot.writeFieldEnd()
oprot.writeFieldStop()
oprot.writeStructEnd()
{code}
and In Go it looks like this
{code:go}
func (p *AuroraSchedulerManagerCreateJobArgs) Write(oprot thrift.TProtocol)
error {
if err := oprot.WriteStructBegin("createJob_args"); err != nil {
return thrift.PrependError(fmt.Sprintf("%T write struct begin
error: ", p), err)
}
if err := p.writeField1(oprot); err != nil {
return err
}
if err := p.writeField3(oprot); err != nil {
return err
}
if err := oprot.WriteFieldStop(); err != nil {
return thrift.PrependError("write field stop error: ", err)
}
if err := oprot.WriteStructEnd(); err != nil {
return thrift.PrependError("write struct stop error: ", err)
}
return nil
}
{code}
Go will insert the 'x.IsSet' for optional fields, but args can't be optional.
was (Author: zariel):
In python you can write this,
service.method(None) which works fine, but in go if you do service.method(nil)
it panics.
Im not sure which is correct.
This is the code from
https://github.com/apache/aurora/blob/6b768bd3dd053b776a5b713c4fd5ce95e31e666b/api/src/main/thrift/org/apache/aurora/gen/api.thrift#L1008
for create_job args.Write in python,
{code}
def write(self, oprot):
if oprot.__class__ == TBinaryProtocol.TBinaryProtocolAccelerated and
self.thrift_spec is not None and fastbinary is not None:
oprot.trans.write(fastbinary.encode_binary(self, (self.__class__,
self.thrift_spec)))
return
oprot.writeStructBegin('createJob_args')
if self.description is not None:
oprot.writeFieldBegin('description', TType.STRUCT, 1)
self.description.write(oprot)
oprot.writeFieldEnd()
if self.lock is not None:
oprot.writeFieldBegin('lock', TType.STRUCT, 3)
self.lock.write(oprot)
oprot.writeFieldEnd()
oprot.writeFieldStop()
oprot.writeStructEnd()
{/code}
and In Go it looks like this
{code}
func (p *AuroraSchedulerManagerCreateJobArgs) Write(oprot thrift.TProtocol)
error {
if err := oprot.WriteStructBegin("createJob_args"); err != nil {
return thrift.PrependError(fmt.Sprintf("%T write struct begin
error: ", p), err)
}
if err := p.writeField1(oprot); err != nil {
return err
}
if err := p.writeField3(oprot); err != nil {
return err
}
if err := oprot.WriteFieldStop(); err != nil {
return thrift.PrependError("write field stop error: ", err)
}
if err := oprot.WriteStructEnd(); err != nil {
return thrift.PrependError("write struct stop error: ", err)
}
return nil
}
{/code}
Go will insert the 'x.IsSet' for optional fields, but args can't be optional.
> Can not send nil pointer as service method argument
> ---
>
> Key: THRIFT-3533
> URL: https://issues.apache.org/jira/browse/THRIFT-3533
> Project: Thrift
> Issue Type: Bug
> Components: Go - Compiler
>Affects Versions: 0.9.3
>Reporter: Chris Bannister
>
> If you try to send a nil struct as an argument to a service method a panic
> occurs as it tries to write out all the fields in the struct, the python
> generated code has guarding 'if self.x != None:' for every struct field,
> whereas Go only outputs the 'if p.IsSet()' when the field is declared
> optional, which is not possible for argument lists.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (THRIFT-3533) Can not send nil pointer as service method argument
[
https://issues.apache.org/jira/browse/THRIFT-3533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15090984#comment-15090984
]
Chris Bannister edited comment on THRIFT-3533 at 1/10/16 11:11 AM:
---
In python you can write this,
service.method(None) which works fine, but in go if you do service.method(nil)
it panics.
Im not sure which is correct.
This is the code from
https://github.com/apache/aurora/blob/6b768bd3dd053b776a5b713c4fd5ce95e31e666b/api/src/main/thrift/org/apache/aurora/gen/api.thrift#L1008
for create_job args.Write in python,
{noformat}
def write(self, oprot):
if oprot.__class__ == TBinaryProtocol.TBinaryProtocolAccelerated and
self.thrift_spec is not None and fastbinary is not None:
oprot.trans.write(fastbinary.encode_binary(self, (self.__class__,
self.thrift_spec)))
return
oprot.writeStructBegin('createJob_args')
if self.description is not None:
oprot.writeFieldBegin('description', TType.STRUCT, 1)
self.description.write(oprot)
oprot.writeFieldEnd()
if self.lock is not None:
oprot.writeFieldBegin('lock', TType.STRUCT, 3)
self.lock.write(oprot)
oprot.writeFieldEnd()
oprot.writeFieldStop()
oprot.writeStructEnd()
{noformat}
and In Go it looks like this
{noformat}
func (p *AuroraSchedulerManagerCreateJobArgs) Write(oprot thrift.TProtocol)
error {
if err := oprot.WriteStructBegin("createJob_args"); err != nil {
return thrift.PrependError(fmt.Sprintf("%T write struct begin
error: ", p), err)
}
if err := p.writeField1(oprot); err != nil {
return err
}
if err := p.writeField3(oprot); err != nil {
return err
}
if err := oprot.WriteFieldStop(); err != nil {
return thrift.PrependError("write field stop error: ", err)
}
if err := oprot.WriteStructEnd(); err != nil {
return thrift.PrependError("write struct stop error: ", err)
}
return nil
}
{noformat}
Go will insert the 'x.IsSet' for optional fields, but args can't be optional.
was (Author: zariel):
In python you can write this,
service.method(None) which works fine, but in go if you do service.method(nil)
it panics.
Im not sure which is correct.
This is the code from
https://github.com/apache/aurora/blob/6b768bd3dd053b776a5b713c4fd5ce95e31e666b/api/src/main/thrift/org/apache/aurora/gen/api.thrift#L1008
for create_job args.Write in python,
{code:python}
def write(self, oprot):
if oprot.__class__ == TBinaryProtocol.TBinaryProtocolAccelerated and
self.thrift_spec is not None and fastbinary is not None:
oprot.trans.write(fastbinary.encode_binary(self, (self.__class__,
self.thrift_spec)))
return
oprot.writeStructBegin('createJob_args')
if self.description is not None:
oprot.writeFieldBegin('description', TType.STRUCT, 1)
self.description.write(oprot)
oprot.writeFieldEnd()
if self.lock is not None:
oprot.writeFieldBegin('lock', TType.STRUCT, 3)
self.lock.write(oprot)
oprot.writeFieldEnd()
oprot.writeFieldStop()
oprot.writeStructEnd()
{code}
and In Go it looks like this
{code:go}
func (p *AuroraSchedulerManagerCreateJobArgs) Write(oprot thrift.TProtocol)
error {
if err := oprot.WriteStructBegin("createJob_args"); err != nil {
return thrift.PrependError(fmt.Sprintf("%T write struct begin
error: ", p), err)
}
if err := p.writeField1(oprot); err != nil {
return err
}
if err := p.writeField3(oprot); err != nil {
return err
}
if err := oprot.WriteFieldStop(); err != nil {
return thrift.PrependError("write field stop error: ", err)
}
if err := oprot.WriteStructEnd(); err != nil {
return thrift.PrependError("write struct stop error: ", err)
}
return nil
}
{code}
Go will insert the 'x.IsSet' for optional fields, but args can't be optional.
> Can not send nil pointer as service method argument
> ---
>
> Key: THRIFT-3533
> URL: https://issues.apache.org/jira/browse/THRIFT-3533
> Project: Thrift
> Issue Type: Bug
> Components: Go - Compiler
>Affects Versions: 0.9.3
>Reporter: Chris Bannister
>
> If you try to send a nil struct as an argument to a service method a panic
> occurs as it tries to write out all the fields in the struct, the python
> generated code has guarding 'if self.x != None:' for every struct field,
> whereas Go only outputs the 'if p.IsSet()' when the field is declared
> optional, which is not possible for argument lists.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (THRIFT-3533) Can not send nil pointer as service method argument
[
https://issues.apache.org/jira/browse/THRIFT-3533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15090984#comment-15090984
]
Chris Bannister edited comment on THRIFT-3533 at 1/10/16 11:10 AM:
---
In python you can write this,
service.method(None) which works fine, but in go if you do service.method(nil)
it panics.
Im not sure which is correct.
This is the code from
https://github.com/apache/aurora/blob/6b768bd3dd053b776a5b713c4fd5ce95e31e666b/api/src/main/thrift/org/apache/aurora/gen/api.thrift#L1008
for create_job args.Write in python,
{code}
def write(self, oprot):
if oprot.__class__ == TBinaryProtocol.TBinaryProtocolAccelerated and
self.thrift_spec is not None and fastbinary is not None:
oprot.trans.write(fastbinary.encode_binary(self, (self.__class__,
self.thrift_spec)))
return
oprot.writeStructBegin('createJob_args')
if self.description is not None:
oprot.writeFieldBegin('description', TType.STRUCT, 1)
self.description.write(oprot)
oprot.writeFieldEnd()
if self.lock is not None:
oprot.writeFieldBegin('lock', TType.STRUCT, 3)
self.lock.write(oprot)
oprot.writeFieldEnd()
oprot.writeFieldStop()
oprot.writeStructEnd()
{/code}
and In Go it looks like this
{code}
func (p *AuroraSchedulerManagerCreateJobArgs) Write(oprot thrift.TProtocol)
error {
if err := oprot.WriteStructBegin("createJob_args"); err != nil {
return thrift.PrependError(fmt.Sprintf("%T write struct begin
error: ", p), err)
}
if err := p.writeField1(oprot); err != nil {
return err
}
if err := p.writeField3(oprot); err != nil {
return err
}
if err := oprot.WriteFieldStop(); err != nil {
return thrift.PrependError("write field stop error: ", err)
}
if err := oprot.WriteStructEnd(); err != nil {
return thrift.PrependError("write struct stop error: ", err)
}
return nil
}
{/code}
Go will insert the 'x.IsSet' for optional fields, but args can't be optional.
was (Author: zariel):
In python you can write this,
service.method(None) which works fine, but in go if you do service.method(nil)
it panics.
Im not sure which is correct.
This is the code from
https://github.com/apache/aurora/blob/6b768bd3dd053b776a5b713c4fd5ce95e31e666b/api/src/main/thrift/org/apache/aurora/gen/api.thrift#L1008
for create_job args.Write in python,
{code}
def write(self, oprot):
if oprot.__class__ == TBinaryProtocol.TBinaryProtocolAccelerated and
self.thrift_spec is not None and fastbinary is not None:
oprot.trans.write(fastbinary.encode_binary(self, (self.__class__,
self.thrift_spec)))
return
oprot.writeStructBegin('createJob_args')
if self.description is not None:
oprot.writeFieldBegin('description', TType.STRUCT, 1)
self.description.write(oprot)
oprot.writeFieldEnd()
if self.lock is not None:
oprot.writeFieldBegin('lock', TType.STRUCT, 3)
self.lock.write(oprot)
oprot.writeFieldEnd()
oprot.writeFieldStop()
oprot.writeStructEnd()
{/code}
and In Go it looks like this
{code}
func (p *AuroraSchedulerManagerCreateJobArgs) Write(oprot thrift.TProtocol)
error {
if err := oprot.WriteStructBegin("createJob_args"); err != nil {
return thrift.PrependError(fmt.Sprintf("%T write struct begin
error: ", p), err)
}
if err := p.writeField1(oprot); err != nil {
return err
}
if err := p.writeField3(oprot); err != nil {
return err
}
if err := oprot.WriteFieldStop(); err != nil {
return thrift.PrependError("write field stop error: ", err)
}
if err := oprot.WriteStructEnd(); err != nil {
return thrift.PrependError("write struct stop error: ", err)
}
return nil
}
{/code}
Go will insert the 'x.IsSet' for optional fields, but args can't be optional.
> Can not send nil pointer as service method argument
> ---
>
> Key: THRIFT-3533
> URL: https://issues.apache.org/jira/browse/THRIFT-3533
> Project: Thrift
> Issue Type: Bug
> Components: Go - Compiler
>Affects Versions: 0.9.3
>Reporter: Chris Bannister
>
> If you try to send a nil struct as an argument to a service method a panic
> occurs as it tries to write out all the fields in the struct, the python
> generated code has guarding 'if self.x != None:' for every struct field,
> whereas Go only outputs the 'if p.IsSet()' when the field is declared
> optional, which is not possible for argument lists.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (THRIFT-3533) Can not send nil pointer as service method argument
[
https://issues.apache.org/jira/browse/THRIFT-3533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15090984#comment-15090984
]
Chris Bannister edited comment on THRIFT-3533 at 1/10/16 11:10 AM:
---
In python you can write this,
service.method(None) which works fine, but in go if you do service.method(nil)
it panics.
Im not sure which is correct.
This is the code from
https://github.com/apache/aurora/blob/6b768bd3dd053b776a5b713c4fd5ce95e31e666b/api/src/main/thrift/org/apache/aurora/gen/api.thrift#L1008
for create_job args.Write in python,
{code}
def write(self, oprot):
if oprot.__class__ == TBinaryProtocol.TBinaryProtocolAccelerated and
self.thrift_spec is not None and fastbinary is not None:
oprot.trans.write(fastbinary.encode_binary(self, (self.__class__,
self.thrift_spec)))
return
oprot.writeStructBegin('createJob_args')
if self.description is not None:
oprot.writeFieldBegin('description', TType.STRUCT, 1)
self.description.write(oprot)
oprot.writeFieldEnd()
if self.lock is not None:
oprot.writeFieldBegin('lock', TType.STRUCT, 3)
self.lock.write(oprot)
oprot.writeFieldEnd()
oprot.writeFieldStop()
oprot.writeStructEnd()
{/code}
and In Go it looks like this
{code}
func (p *AuroraSchedulerManagerCreateJobArgs) Write(oprot thrift.TProtocol)
error {
if err := oprot.WriteStructBegin("createJob_args"); err != nil {
return thrift.PrependError(fmt.Sprintf("%T write struct begin
error: ", p), err)
}
if err := p.writeField1(oprot); err != nil {
return err
}
if err := p.writeField3(oprot); err != nil {
return err
}
if err := oprot.WriteFieldStop(); err != nil {
return thrift.PrependError("write field stop error: ", err)
}
if err := oprot.WriteStructEnd(); err != nil {
return thrift.PrependError("write struct stop error: ", err)
}
return nil
}
{/code}
Go will insert the 'x.IsSet' for optional fields, but args can't be optional.
was (Author: zariel):
In python you can write this,
service.method(None) which works fine, but in go if you do service.method(nil)
it panics.
Im not sure which is correct.
This is the code from
https://github.com/apache/aurora/blob/6b768bd3dd053b776a5b713c4fd5ce95e31e666b/api/src/main/thrift/org/apache/aurora/gen/api.thrift#L1008
for create_job args.Write in python,
{code}
def write(self, oprot):
if oprot.__class__ == TBinaryProtocol.TBinaryProtocolAccelerated and
self.thrift_spec is not None and fastbinary is not None:
oprot.trans.write(fastbinary.encode_binary(self, (self.__class__,
self.thrift_spec)))
return
oprot.writeStructBegin('createJob_args')
if self.description is not None:
oprot.writeFieldBegin('description', TType.STRUCT, 1)
self.description.write(oprot)
oprot.writeFieldEnd()
if self.lock is not None:
oprot.writeFieldBegin('lock', TType.STRUCT, 3)
self.lock.write(oprot)
oprot.writeFieldEnd()
oprot.writeFieldStop()
oprot.writeStructEnd()
{/code}
and In Go it looks like this
{code}
func (p *AuroraSchedulerManagerCreateJobArgs) Write(oprot thrift.TProtocol)
error {
if err := oprot.WriteStructBegin("createJob_args"); err != nil {
return thrift.PrependError(fmt.Sprintf("%T write struct begin
error: ", p), err)
}
if err := p.writeField1(oprot); err != nil {
return err
}
if err := p.writeField3(oprot); err != nil {
return err
}
if err := oprot.WriteFieldStop(); err != nil {
return thrift.PrependError("write field stop error: ", err)
}
if err := oprot.WriteStructEnd(); err != nil {
return thrift.PrependError("write struct stop error: ", err)
}
return nil
}
{/code}
Go will insert the 'x.IsSet' for optional fields, but args can't be optional.
> Can not send nil pointer as service method argument
> ---
>
> Key: THRIFT-3533
> URL: https://issues.apache.org/jira/browse/THRIFT-3533
> Project: Thrift
> Issue Type: Bug
> Components: Go - Compiler
>Affects Versions: 0.9.3
>Reporter: Chris Bannister
>
> If you try to send a nil struct as an argument to a service method a panic
> occurs as it tries to write out all the fields in the struct, the python
> generated code has guarding 'if self.x != None:' for every struct field,
> whereas Go only outputs the 'if p.IsSet()' when the field is declared
> optional, which is not possible for argument lists.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (THRIFT-3533) Can not send nil pointer as service method argument
[
https://issues.apache.org/jira/browse/THRIFT-3533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15090984#comment-15090984
]
Chris Bannister edited comment on THRIFT-3533 at 1/10/16 11:08 AM:
---
In python you can write this,
service.method(None) which works fine, but in go if you do service.method(nil)
it panics.
Im not sure which is correct.
This is the code from
https://github.com/apache/aurora/blob/6b768bd3dd053b776a5b713c4fd5ce95e31e666b/api/src/main/thrift/org/apache/aurora/gen/api.thrift#L1008
for create_job args.Write in python,
{code}
def write(self, oprot):
if oprot.__class__ == TBinaryProtocol.TBinaryProtocolAccelerated and
self.thrift_spec is not None and fastbinary is not None:
oprot.trans.write(fastbinary.encode_binary(self, (self.__class__,
self.thrift_spec)))
return
oprot.writeStructBegin('createJob_args')
if self.description is not None:
oprot.writeFieldBegin('description', TType.STRUCT, 1)
self.description.write(oprot)
oprot.writeFieldEnd()
if self.lock is not None:
oprot.writeFieldBegin('lock', TType.STRUCT, 3)
self.lock.write(oprot)
oprot.writeFieldEnd()
oprot.writeFieldStop()
oprot.writeStructEnd()
{/code}
and In Go it looks like this
{code}
func (p *AuroraSchedulerManagerCreateJobArgs) Write(oprot thrift.TProtocol)
error {
if err := oprot.WriteStructBegin("createJob_args"); err != nil {
return thrift.PrependError(fmt.Sprintf("%T write struct begin
error: ", p), err)
}
if err := p.writeField1(oprot); err != nil {
return err
}
if err := p.writeField3(oprot); err != nil {
return err
}
if err := oprot.WriteFieldStop(); err != nil {
return thrift.PrependError("write field stop error: ", err)
}
if err := oprot.WriteStructEnd(); err != nil {
return thrift.PrependError("write struct stop error: ", err)
}
return nil
}
{code}
Go will insert the 'x.IsSet' for optional fields, but args can't be optional.
was (Author: zariel):
In python you can write this,
service.method(None) which works fine, but in go if you do service.method(nil)
it panics.
Im not sure which is correct.
This is the code from github.com/apache/aurora api.thrift for create_job
args.Write in python,
{code}
def write(self, oprot):
if oprot.__class__ == TBinaryProtocol.TBinaryProtocolAccelerated and
self.thrift_spec is not None and fastbinary is not None:
oprot.trans.write(fastbinary.encode_binary(self, (self.__class__,
self.thrift_spec)))
return
oprot.writeStructBegin('createJob_args')
if self.description is not None:
oprot.writeFieldBegin('description', TType.STRUCT, 1)
self.description.write(oprot)
oprot.writeFieldEnd()
if self.lock is not None:
oprot.writeFieldBegin('lock', TType.STRUCT, 3)
self.lock.write(oprot)
oprot.writeFieldEnd()
oprot.writeFieldStop()
oprot.writeStructEnd()
{/code}
and In Go it looks like this
{code}
func (p *AuroraSchedulerManagerCreateJobArgs) Write(oprot thrift.TProtocol)
error {
if err := oprot.WriteStructBegin("createJob_args"); err != nil {
return thrift.PrependError(fmt.Sprintf("%T write struct begin
error: ", p), err)
}
if err := p.writeField1(oprot); err != nil {
return err
}
if err := p.writeField3(oprot); err != nil {
return err
}
if err := oprot.WriteFieldStop(); err != nil {
return thrift.PrependError("write field stop error: ", err)
}
if err := oprot.WriteStructEnd(); err != nil {
return thrift.PrependError("write struct stop error: ", err)
}
return nil
}
{code}
Go will insert the 'x.IsSet' for optional fields, but args can't be optional.
> Can not send nil pointer as service method argument
> ---
>
> Key: THRIFT-3533
> URL: https://issues.apache.org/jira/browse/THRIFT-3533
> Project: Thrift
> Issue Type: Bug
> Components: Go - Compiler
>Affects Versions: 0.9.3
>Reporter: Chris Bannister
>
> If you try to send a nil struct as an argument to a service method a panic
> occurs as it tries to write out all the fields in the struct, the python
> generated code has guarding 'if self.x != None:' for every struct field,
> whereas Go only outputs the 'if p.IsSet()' when the field is declared
> optional, which is not possible for argument lists.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (THRIFT-3533) Can not send nil pointer as service method argument
[
https://issues.apache.org/jira/browse/THRIFT-3533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15090984#comment-15090984
]
Chris Bannister edited comment on THRIFT-3533 at 1/10/16 11:09 AM:
---
In python you can write this,
service.method(None) which works fine, but in go if you do service.method(nil)
it panics.
Im not sure which is correct.
This is the code from
https://github.com/apache/aurora/blob/6b768bd3dd053b776a5b713c4fd5ce95e31e666b/api/src/main/thrift/org/apache/aurora/gen/api.thrift#L1008
for create_job args.Write in python,
{code}
def write(self, oprot):
if oprot.__class__ == TBinaryProtocol.TBinaryProtocolAccelerated and
self.thrift_spec is not None and fastbinary is not None:
oprot.trans.write(fastbinary.encode_binary(self, (self.__class__,
self.thrift_spec)))
return
oprot.writeStructBegin('createJob_args')
if self.description is not None:
oprot.writeFieldBegin('description', TType.STRUCT, 1)
self.description.write(oprot)
oprot.writeFieldEnd()
if self.lock is not None:
oprot.writeFieldBegin('lock', TType.STRUCT, 3)
self.lock.write(oprot)
oprot.writeFieldEnd()
oprot.writeFieldStop()
oprot.writeStructEnd()
{/code}
and In Go it looks like this
{code}
func (p *AuroraSchedulerManagerCreateJobArgs) Write(oprot thrift.TProtocol)
error {
if err := oprot.WriteStructBegin("createJob_args"); err != nil {
return thrift.PrependError(fmt.Sprintf("%T write struct begin
error: ", p), err)
}
if err := p.writeField1(oprot); err != nil {
return err
}
if err := p.writeField3(oprot); err != nil {
return err
}
if err := oprot.WriteFieldStop(); err != nil {
return thrift.PrependError("write field stop error: ", err)
}
if err := oprot.WriteStructEnd(); err != nil {
return thrift.PrependError("write struct stop error: ", err)
}
return nil
}
{/code}
Go will insert the 'x.IsSet' for optional fields, but args can't be optional.
was (Author: zariel):
In python you can write this,
service.method(None) which works fine, but in go if you do service.method(nil)
it panics.
Im not sure which is correct.
This is the code from
https://github.com/apache/aurora/blob/6b768bd3dd053b776a5b713c4fd5ce95e31e666b/api/src/main/thrift/org/apache/aurora/gen/api.thrift#L1008
for create_job args.Write in python,
{code}
def write(self, oprot):
if oprot.__class__ == TBinaryProtocol.TBinaryProtocolAccelerated and
self.thrift_spec is not None and fastbinary is not None:
oprot.trans.write(fastbinary.encode_binary(self, (self.__class__,
self.thrift_spec)))
return
oprot.writeStructBegin('createJob_args')
if self.description is not None:
oprot.writeFieldBegin('description', TType.STRUCT, 1)
self.description.write(oprot)
oprot.writeFieldEnd()
if self.lock is not None:
oprot.writeFieldBegin('lock', TType.STRUCT, 3)
self.lock.write(oprot)
oprot.writeFieldEnd()
oprot.writeFieldStop()
oprot.writeStructEnd()
{/code}
and In Go it looks like this
{code}
func (p *AuroraSchedulerManagerCreateJobArgs) Write(oprot thrift.TProtocol)
error {
if err := oprot.WriteStructBegin("createJob_args"); err != nil {
return thrift.PrependError(fmt.Sprintf("%T write struct begin
error: ", p), err)
}
if err := p.writeField1(oprot); err != nil {
return err
}
if err := p.writeField3(oprot); err != nil {
return err
}
if err := oprot.WriteFieldStop(); err != nil {
return thrift.PrependError("write field stop error: ", err)
}
if err := oprot.WriteStructEnd(); err != nil {
return thrift.PrependError("write struct stop error: ", err)
}
return nil
}
{code}
Go will insert the 'x.IsSet' for optional fields, but args can't be optional.
> Can not send nil pointer as service method argument
> ---
>
> Key: THRIFT-3533
> URL: https://issues.apache.org/jira/browse/THRIFT-3533
> Project: Thrift
> Issue Type: Bug
> Components: Go - Compiler
>Affects Versions: 0.9.3
>Reporter: Chris Bannister
>
> If you try to send a nil struct as an argument to a service method a panic
> occurs as it tries to write out all the fields in the struct, the python
> generated code has guarding 'if self.x != None:' for every struct field,
> whereas Go only outputs the 'if p.IsSet()' when the field is declared
> optional, which is not possible for argument lists.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (THRIFT-3533) Can not send nil pointer as service method argument
[
https://issues.apache.org/jira/browse/THRIFT-3533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15090984#comment-15090984
]
Chris Bannister edited comment on THRIFT-3533 at 1/10/16 11:09 AM:
---
In python you can write this,
service.method(None) which works fine, but in go if you do service.method(nil)
it panics.
Im not sure which is correct.
This is the code from
https://github.com/apache/aurora/blob/6b768bd3dd053b776a5b713c4fd5ce95e31e666b/api/src/main/thrift/org/apache/aurora/gen/api.thrift#L1008
for create_job args.Write in python,
{code}
def write(self, oprot):
if oprot.__class__ == TBinaryProtocol.TBinaryProtocolAccelerated and
self.thrift_spec is not None and fastbinary is not None:
oprot.trans.write(fastbinary.encode_binary(self, (self.__class__,
self.thrift_spec)))
return
oprot.writeStructBegin('createJob_args')
if self.description is not None:
oprot.writeFieldBegin('description', TType.STRUCT, 1)
self.description.write(oprot)
oprot.writeFieldEnd()
if self.lock is not None:
oprot.writeFieldBegin('lock', TType.STRUCT, 3)
self.lock.write(oprot)
oprot.writeFieldEnd()
oprot.writeFieldStop()
oprot.writeStructEnd()
{/code}
and In Go it looks like this
{code}
func (p *AuroraSchedulerManagerCreateJobArgs) Write(oprot thrift.TProtocol)
error {
if err := oprot.WriteStructBegin("createJob_args"); err != nil {
return thrift.PrependError(fmt.Sprintf("%T write struct begin
error: ", p), err)
}
if err := p.writeField1(oprot); err != nil {
return err
}
if err := p.writeField3(oprot); err != nil {
return err
}
if err := oprot.WriteFieldStop(); err != nil {
return thrift.PrependError("write field stop error: ", err)
}
if err := oprot.WriteStructEnd(); err != nil {
return thrift.PrependError("write struct stop error: ", err)
}
return nil
}
{/code}
Go will insert the 'x.IsSet' for optional fields, but args can't be optional.
was (Author: zariel):
In python you can write this,
service.method(None) which works fine, but in go if you do service.method(nil)
it panics.
Im not sure which is correct.
This is the code from
https://github.com/apache/aurora/blob/6b768bd3dd053b776a5b713c4fd5ce95e31e666b/api/src/main/thrift/org/apache/aurora/gen/api.thrift#L1008
for create_job args.Write in python,
{code}
def write(self, oprot):
if oprot.__class__ == TBinaryProtocol.TBinaryProtocolAccelerated and
self.thrift_spec is not None and fastbinary is not None:
oprot.trans.write(fastbinary.encode_binary(self, (self.__class__,
self.thrift_spec)))
return
oprot.writeStructBegin('createJob_args')
if self.description is not None:
oprot.writeFieldBegin('description', TType.STRUCT, 1)
self.description.write(oprot)
oprot.writeFieldEnd()
if self.lock is not None:
oprot.writeFieldBegin('lock', TType.STRUCT, 3)
self.lock.write(oprot)
oprot.writeFieldEnd()
oprot.writeFieldStop()
oprot.writeStructEnd()
{/code}
and In Go it looks like this
{code}
func (p *AuroraSchedulerManagerCreateJobArgs) Write(oprot thrift.TProtocol)
error {
if err := oprot.WriteStructBegin("createJob_args"); err != nil {
return thrift.PrependError(fmt.Sprintf("%T write struct begin
error: ", p), err)
}
if err := p.writeField1(oprot); err != nil {
return err
}
if err := p.writeField3(oprot); err != nil {
return err
}
if err := oprot.WriteFieldStop(); err != nil {
return thrift.PrependError("write field stop error: ", err)
}
if err := oprot.WriteStructEnd(); err != nil {
return thrift.PrependError("write struct stop error: ", err)
}
return nil
}
{/code}
Go will insert the 'x.IsSet' for optional fields, but args can't be optional.
> Can not send nil pointer as service method argument
> ---
>
> Key: THRIFT-3533
> URL: https://issues.apache.org/jira/browse/THRIFT-3533
> Project: Thrift
> Issue Type: Bug
> Components: Go - Compiler
>Affects Versions: 0.9.3
>Reporter: Chris Bannister
>
> If you try to send a nil struct as an argument to a service method a panic
> occurs as it tries to write out all the fields in the struct, the python
> generated code has guarding 'if self.x != None:' for every struct field,
> whereas Go only outputs the 'if p.IsSet()' when the field is declared
> optional, which is not possible for argument lists.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (THRIFT-3533) Can not send nil pointer as service method argument
[
https://issues.apache.org/jira/browse/THRIFT-3533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15090984#comment-15090984
]
Chris Bannister commented on THRIFT-3533:
-
In python you can write this,
service.method(None) which works fine, but in go if you do service.method(nil)
it panics.
Im not sure which is correct.
This is the code from github.com/apache/aurora api.thrift for create_job
args.Write in python,
{code}
def write(self, oprot):
if oprot.__class__ == TBinaryProtocol.TBinaryProtocolAccelerated and
self.thrift_spec is not None and fastbinary is not None:
oprot.trans.write(fastbinary.encode_binary(self, (self.__class__,
self.thrift_spec)))
return
oprot.writeStructBegin('createJob_args')
if self.description is not None:
oprot.writeFieldBegin('description', TType.STRUCT, 1)
self.description.write(oprot)
oprot.writeFieldEnd()
if self.lock is not None:
oprot.writeFieldBegin('lock', TType.STRUCT, 3)
self.lock.write(oprot)
oprot.writeFieldEnd()
oprot.writeFieldStop()
oprot.writeStructEnd()
{/code}
and In Go it looks like this
{code}
func (p *AuroraSchedulerManagerCreateJobArgs) Write(oprot thrift.TProtocol)
error {
if err := oprot.WriteStructBegin("createJob_args"); err != nil {
return thrift.PrependError(fmt.Sprintf("%T write struct begin
error: ", p), err)
}
if err := p.writeField1(oprot); err != nil {
return err
}
if err := p.writeField3(oprot); err != nil {
return err
}
if err := oprot.WriteFieldStop(); err != nil {
return thrift.PrependError("write field stop error: ", err)
}
if err := oprot.WriteStructEnd(); err != nil {
return thrift.PrependError("write struct stop error: ", err)
}
return nil
}
{code}
Go will insert the 'x.IsSet' for optional fields, but args can't be optional.
> Can not send nil pointer as service method argument
> ---
>
> Key: THRIFT-3533
> URL: https://issues.apache.org/jira/browse/THRIFT-3533
> Project: Thrift
> Issue Type: Bug
> Components: Go - Compiler
>Affects Versions: 0.9.3
>Reporter: Chris Bannister
>
> If you try to send a nil struct as an argument to a service method a panic
> occurs as it tries to write out all the fields in the struct, the python
> generated code has guarding 'if self.x != None:' for every struct field,
> whereas Go only outputs the 'if p.IsSet()' when the field is declared
> optional, which is not possible for argument lists.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (THRIFT-3533) Can not send nil pointer as service method argument
Chris Bannister created THRIFT-3533: --- Summary: Can not send nil pointer as service method argument Key: THRIFT-3533 URL: https://issues.apache.org/jira/browse/THRIFT-3533 Project: Thrift Issue Type: Bug Components: Go - Compiler Affects Versions: 0.9.3 Reporter: Chris Bannister If you try to send a nil struct as an argument to a service method a panic occurs as it tries to write out all the fields in the struct, the python generated code has guarding 'if self.x != None:' for every struct field, whereas Go only outputs the 'if p.IsSet()' when the field is declared optional, which is not possible for argument lists. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (THRIFT-2791) Allowing use of buffered sockets in go server
[ https://issues.apache.org/jira/browse/THRIFT-2791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14183063#comment-14183063 ] Chris Bannister commented on THRIFT-2791: - Is this necessary as you can wrap the TTransport with a TBufferedTransport which will use bufio, https://github.com/apache/thrift/blob/master/lib/go/thrift/buffered_transport.go > Allowing use of buffered sockets in go server > - > > Key: THRIFT-2791 > URL: https://issues.apache.org/jira/browse/THRIFT-2791 > Project: Thrift > Issue Type: Improvement > Components: Go - Library >Reporter: Craig Peterson > > There is currently no way in a go server to use buffered sockets. Failing to > do so decreases performance significantly in my tests. > I added an option on TServerSocket to set the buffer size to use. This will > default to 1024 bytes, but can be disabled if desired to get back to the > original behavior by setting BufferSize to 0. > Github pull request: https://github.com/apache/thrift/pull/249 > Patch https://github.com/apache/thrift/pull/249.patch -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (THRIFT-2598) Add check for minimum Go version to configure.ac
[
https://issues.apache.org/jira/browse/THRIFT-2598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14051870#comment-14051870
]
Chris Bannister edited comment on THRIFT-2598 at 7/3/14 8:19 PM:
-
It should be possible to work around these issues with build flags and other
means. For instance we can define our own io.ByteWriter interface which will
suffice to fix this issue.
Although for instance io.ByteWriter is part of go1 so I guess that should be a
minimum requirement?
was (Author: zariel):
It should be possible to work around these issues with build flags and other
means. For instance we can define our own io.ByteWriter interface which will
suffice to fix this issue.
> Add check for minimum Go version to configure.ac
>
>
> Key: THRIFT-2598
> URL: https://issues.apache.org/jira/browse/THRIFT-2598
> Project: Thrift
> Issue Type: Bug
> Components: Build Process, Go - Library
>Reporter: Jens Geyer
> Fix For: 1.0
>
>
> The Go build currently fails, if some older Go version is installed, e.g.
> because of missing {{io.ByteWriter}}. Need to add appropriate check in
> configure.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (THRIFT-2598) Add check for minimum Go version to configure.ac
[
https://issues.apache.org/jira/browse/THRIFT-2598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14051870#comment-14051870
]
Chris Bannister commented on THRIFT-2598:
-
It should be possible to work around these issues with build flags and other
means. For instance we can define our own io.ByteWriter interface which will
suffice to fix this issue.
> Add check for minimum Go version to configure.ac
>
>
> Key: THRIFT-2598
> URL: https://issues.apache.org/jira/browse/THRIFT-2598
> Project: Thrift
> Issue Type: Bug
> Components: Build Process, Go - Library
>Reporter: Jens Geyer
> Fix For: 1.0
>
>
> The Go build currently fails, if some older Go version is installed, e.g.
> because of missing {{io.ByteWriter}}. Need to add appropriate check in
> configure.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (THRIFT-2502) Optimize go implementations of binary and compact protocols for speed
[ https://issues.apache.org/jira/browse/THRIFT-2502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13983157#comment-13983157 ] Chris Bannister commented on THRIFT-2502: - This is awesome > Optimize go implementations of binary and compact protocols for speed > - > > Key: THRIFT-2502 > URL: https://issues.apache.org/jira/browse/THRIFT-2502 > Project: Thrift > Issue Type: Improvement > Components: Go - Library >Reporter: Aleksey Pesternikov >Priority: Minor > > Go implementation of binary and compact protocols are slow and creating > unnecessary memory garbage -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (THRIFT-2488) Timeouts can leave client in unrecoverable state
[
https://issues.apache.org/jira/browse/THRIFT-2488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13975520#comment-13975520
]
Chris Bannister commented on THRIFT-2488:
-
You should get output along the lines of,
{code}
2014/04/21 11:52:04 &thrift.tTransportException{typeId:3,
err:(*net.OpError)(0xc210072000)}
2014/04/21 11:52:04 &thrift.tApplicationException{message:"Test failed: out of
sequence response", type_:4}
2014/04/21 11:52:04 &thrift.tProtocolException{typeId:4, message:"Missing
version in ReadMessageBegin"}
2014/04/21 11:52:04 &thrift.tProtocolException{typeId:4, message:"Missing
version in ReadMessageBegin"}
2014/04/21 11:52:04 &thrift.tProtocolException{typeId:4, message:"Missing
version in ReadMessageBegin"}
2014/04/21 11:52:04 &thrift.tApplicationException{message:"Test failed: out of
sequence response", type_:4}
2014/04/21 11:52:04 &thrift.tProtocolException{typeId:4, message:"Missing
version in ReadMessageBegin"}
2014/04/21 11:52:04 &thrift.tProtocolException{typeId:4, message:"Missing
version in ReadMessageBegin"}
2014/04/21 11:52:04 &thrift.tProtocolException{typeId:4, message:"Missing
version in ReadMessageBegin"}
2014/04/21 11:52:04 &thrift.tApplicationException{message:"Test failed: out of
sequence response", type_:4}
{code}
When the expected behaviour is that after the timeout the client should still
be usable
> Timeouts can leave client in unrecoverable state
>
>
> Key: THRIFT-2488
> URL: https://issues.apache.org/jira/browse/THRIFT-2488
> Project: Thrift
> Issue Type: Bug
> Components: Go - Library
>Affects Versions: 0.9.1
>Reporter: Chris Bannister
> Attachments: testcase.go, timeout.thrift
>
>
> If you set the timeout on a TSocket and experience a timeout the client will
> stop reading the struct and return the error as expected.
> But if you use the TSocket again after the remote system has sent the
> timedout data and the client has received it the client will be unusable
> because it ends up in a state with incorrect sequence-ids and unexpected data
> in its buffer.
> This means that the TSocket should be closed if there is any network level
> error when reading/writing.
> This can also be fixed by making more attempts to read/write when the error
> is a net.Error and err.Temporary() is true. Could also do something where the
> client is persistently reading from the socket and discards out of order
> messages or handle out of order sequences.
> Test case to show the failures attached
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (THRIFT-2488) Timeouts can leave client in unrecoverable state
[ https://issues.apache.org/jira/browse/THRIFT-2488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bannister updated THRIFT-2488: Attachment: timeout.thrift testcase.go > Timeouts can leave client in unrecoverable state > > > Key: THRIFT-2488 > URL: https://issues.apache.org/jira/browse/THRIFT-2488 > Project: Thrift > Issue Type: Bug > Components: Go - Library >Affects Versions: 0.9.1 >Reporter: Chris Bannister > Attachments: testcase.go, timeout.thrift > > > If you set the timeout on a TSocket and experience a timeout the client will > stop reading the struct and return the error as expected. > But if you use the TSocket again after the remote system has sent the > timedout data and the client has received it the client will be unusable > because it ends up in a state with incorrect sequence-ids and unexpected data > in its buffer. > This means that the TSocket should be closed if there is any network level > error when reading/writing. > This can also be fixed by making more attempts to read/write when the error > is a net.Error and err.Temporary() is true. Could also do something where the > client is persistently reading from the socket and discards out of order > messages or handle out of order sequences. > Test case to show the failures attached -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (THRIFT-2488) Timeouts can leave client in unrecoverable state
Chris Bannister created THRIFT-2488: --- Summary: Timeouts can leave client in unrecoverable state Key: THRIFT-2488 URL: https://issues.apache.org/jira/browse/THRIFT-2488 Project: Thrift Issue Type: Bug Components: Go - Library Reporter: Chris Bannister Attachments: testcase.go, timeout.thrift If you set the timeout on a TSocket and experience a timeout the client will stop reading the struct and return the error as expected. But if you use the TSocket again after the remote system has sent the timedout data and the client has received it the client will be unusable because it ends up in a state with incorrect sequence-ids and unexpected data in its buffer. This means that the TSocket should be closed if there is any network level error when reading/writing. This can also be fixed by making more attempts to read/write when the error is a net.Error and err.Temporary() is true. Could also do something where the client is persistently reading from the socket and discards out of order messages or handle out of order sequences. Test case to show the failures attached -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (THRIFT-2488) Timeouts can leave client in unrecoverable state
[ https://issues.apache.org/jira/browse/THRIFT-2488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bannister updated THRIFT-2488: Affects Version/s: 0.9.1 > Timeouts can leave client in unrecoverable state > > > Key: THRIFT-2488 > URL: https://issues.apache.org/jira/browse/THRIFT-2488 > Project: Thrift > Issue Type: Bug > Components: Go - Library >Affects Versions: 0.9.1 >Reporter: Chris Bannister > Attachments: testcase.go, timeout.thrift > > > If you set the timeout on a TSocket and experience a timeout the client will > stop reading the struct and return the error as expected. > But if you use the TSocket again after the remote system has sent the > timedout data and the client has received it the client will be unusable > because it ends up in a state with incorrect sequence-ids and unexpected data > in its buffer. > This means that the TSocket should be closed if there is any network level > error when reading/writing. > This can also be fixed by making more attempts to read/write when the error > is a net.Error and err.Temporary() is true. Could also do something where the > client is persistently reading from the socket and discards out of order > messages or handle out of order sequences. > Test case to show the failures attached -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (THRIFT-2009) Go redeclaration error
[
https://issues.apache.org/jira/browse/THRIFT-2009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13974878#comment-13974878
]
Chris Bannister commented on THRIFT-2009:
-
Not yet, I think we should change publicize to have an arg to indicate to
escape 'new' like we do with is_args_or_result, but I've yet to find all the
places where this needs to be escaped, its more complicated than just escaping
all the calls to publicize.
Should we escape IDL generated types (such as New) or the users type
names (struct NewTest{})?
> Go redeclaration error
> --
>
> Key: THRIFT-2009
> URL: https://issues.apache.org/jira/browse/THRIFT-2009
> Project: Thrift
> Issue Type: Bug
> Components: Go - Compiler
>Reporter: Jens Geyer
>Assignee: Jens Geyer
> Fix For: 0.9.2
>
> Attachments: thrift-2009_redeclaration_error.patch,
> thrift-2009_testcase.thrift
>
>
> The following IDL code works perfectly with other languages:
> {code}
> namespace * Test
> struct Project {
> 1 : required string projectID
> }
> struct NewProject {
> 1 : required string name
> }
> service Sample {
> Project CreateNewProject( 1: NewProject project)
> }
> {code}
> The result I get here is
> {quote}
> gen-go\Test\Sample.go:455: missing argument to conversion to NewProject:
> NewProject()
> gen-go\Test\ttypes.go:191: NewProject redeclared in this block
> previous declaration at gen-go\Test\ttypes.go:25
> {quote}
> Seems as if the generated NewProject() method conflicts with the struct name.
> As my Go knowledge is somewhat limited, I'm not sure about whether or not
> this issue blocks the acceptance of THRIFT-1980, so I created a new ticket.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (THRIFT-2009) Go redeclaration error
[
https://issues.apache.org/jira/browse/THRIFT-2009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13974138#comment-13974138
]
Chris Bannister commented on THRIFT-2009:
-
This change causes service methods which begin with New to be escaped, for
instance.
{code}
service Test {
void NewToken()
}
{code}
Generates
{code}
type Test interface {
NewToken_()
}
{code}
In reality I think this escaping should only happen for top level type
definitions.
> Go redeclaration error
> --
>
> Key: THRIFT-2009
> URL: https://issues.apache.org/jira/browse/THRIFT-2009
> Project: Thrift
> Issue Type: Bug
> Components: Go - Compiler
>Reporter: Jens Geyer
>Assignee: Jens Geyer
> Fix For: 0.9.2
>
> Attachments: thrift-2009_redeclaration_error.patch,
> thrift-2009_testcase.thrift
>
>
> The following IDL code works perfectly with other languages:
> {code}
> namespace * Test
> struct Project {
> 1 : required string projectID
> }
> struct NewProject {
> 1 : required string name
> }
> service Sample {
> Project CreateNewProject( 1: NewProject project)
> }
> {code}
> The result I get here is
> {quote}
> gen-go\Test\Sample.go:455: missing argument to conversion to NewProject:
> NewProject()
> gen-go\Test\ttypes.go:191: NewProject redeclared in this block
> previous declaration at gen-go\Test\ttypes.go:25
> {quote}
> Seems as if the generated NewProject() method conflicts with the struct name.
> As my Go knowledge is somewhat limited, I'm not sure about whether or not
> this issue blocks the acceptance of THRIFT-1980, so I created a new ticket.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (THRIFT-2445) THRIFT-2384 (code generation for go maps with binary keys) should be tested
[ https://issues.apache.org/jira/browse/THRIFT-2445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13959245#comment-13959245 ] Chris Bannister commented on THRIFT-2445: - Shouldnt this be part of test/go ? > THRIFT-2384 (code generation for go maps with binary keys) should be tested > --- > > Key: THRIFT-2445 > URL: https://issues.apache.org/jira/browse/THRIFT-2445 > Project: Thrift > Issue Type: Test > Components: Go - Compiler >Reporter: Aleksey Pesternikov >Assignee: Jens Geyer >Priority: Minor > Attachments: thrift-2384-test-v2.patch > > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (THRIFT-2419) golang - Fix fmt.Errorf in generated code
[ https://issues.apache.org/jira/browse/THRIFT-2419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13943032#comment-13943032 ] Chris Bannister commented on THRIFT-2419: - Yeah after your comment I figured I would go take a look at the generated code with go vet, it brought these up. I think im going to try to make the generated code easier to read / more go like so that it will be easier to identify these kind of mistakes. It might also be an idea to run go vet as part of the test suite. > golang - Fix fmt.Errorf in generated code > - > > Key: THRIFT-2419 > URL: https://issues.apache.org/jira/browse/THRIFT-2419 > Project: Thrift > Issue Type: Bug > Components: Go - Compiler >Reporter: Chris Bannister >Assignee: Jens Geyer > Fix For: 0.9.2 > > Attachments: 0001-Fix-fmt.Errorf-not-formatting-the-error.patch > > > The compiler generates code which uses fmt.Errorf without a value for a > formatting directive, go vet picked these up. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (THRIFT-2420) Go argument parser for methods without arguments does not skip fields
[
https://issues.apache.org/jira/browse/THRIFT-2420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13943029#comment-13943029
]
Chris Bannister commented on THRIFT-2420:
-
Again good spot :) Makes sense to me.
> Go argument parser for methods without arguments does not skip fields
> -
>
> Key: THRIFT-2420
> URL: https://issues.apache.org/jira/browse/THRIFT-2420
> Project: Thrift
> Issue Type: Bug
> Components: Go - Compiler
>Affects Versions: 0.9.2
> Environment: All
>Reporter: Frank Schroeder
> Fix For: 0.9.2
>
> Attachments: THRIFT-2420-with-indentation.patch
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> The Read() method of a struct of a thrift function which does not have
> arguments (e.g. foo()) calls iprot.ReadFieldBegin() to read the field type
> but does not consume/skip a field which it was not expecting.
> Read() methods for argument parsers for methods which have arguments have the
> correct code in the default section of the switch statement.
> This is the current code (I've added where the iprot.Skip() call is missing):
> {code}
> func (p *GetVersionDataArgs) Read(iprot thrift.TProtocol) error {
> if _, err := iprot.ReadStructBegin(); err != nil {
> return fmt.Errorf("%T read error: %s", p, err)
> }
> for {
> _, fieldTypeId, fieldId, err := iprot.ReadFieldBegin()
> if err != nil {
> return fmt.Errorf("%T field %d read error: %s", p,
> fieldId, err)
> }
> if fieldTypeId == thrift.STOP {
> break
> }
> // should call iprot.Skip(fieldTypeId) if not STOP
> if err := iprot.ReadFieldEnd(); err != nil {
> return err
> }
> }
> if err := iprot.ReadStructEnd(); err != nil {
> return fmt.Errorf("%T read struct end error: %s", p, err)
> }
> return nil
> }
> {code}
> After the check for {{thrift.STOP}} there needs to be this code
> {code}
> if err := iprot.Skip(fieldTypeId); err != nil {
> return err
> }
> {code}
> We've found this because on the Java side we dynamically inject fields into
> the struct on call which are ignored on the Go side as long as the function
> has arguments. When we make a call to the no-argument function some bytes are
> not consumed and make the thrift code go out of sync.
> I will attach a patch which fixes this.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (THRIFT-2419) golang - Fix fmt.Errorf in generated code
Chris Bannister created THRIFT-2419: --- Summary: golang - Fix fmt.Errorf in generated code Key: THRIFT-2419 URL: https://issues.apache.org/jira/browse/THRIFT-2419 Project: Thrift Issue Type: Bug Components: Go - Compiler Reporter: Chris Bannister Attachments: 0001-Fix-fmt.Errorf-not-formatting-the-error.patch The compiler generates code which uses fmt.Errorf without a value for a formatting directive, go vet picked these up. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (THRIFT-2419) golang - Fix fmt.Errorf in generated code
[ https://issues.apache.org/jira/browse/THRIFT-2419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bannister updated THRIFT-2419: Attachment: 0001-Fix-fmt.Errorf-not-formatting-the-error.patch > golang - Fix fmt.Errorf in generated code > - > > Key: THRIFT-2419 > URL: https://issues.apache.org/jira/browse/THRIFT-2419 > Project: Thrift > Issue Type: Bug > Components: Go - Compiler >Reporter: Chris Bannister > Attachments: 0001-Fix-fmt.Errorf-not-formatting-the-error.patch > > > The compiler generates code which uses fmt.Errorf without a value for a > formatting directive, go vet picked these up. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (THRIFT-2418) Go handler function panics on internal error
[
https://issues.apache.org/jira/browse/THRIFT-2418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13942205#comment-13942205
]
Chris Bannister commented on THRIFT-2418:
-
Good spot, looks good to me.
> Go handler function panics on internal error
>
>
> Key: THRIFT-2418
> URL: https://issues.apache.org/jira/browse/THRIFT-2418
> Project: Thrift
> Issue Type: Bug
> Components: Go - Compiler
>Affects Versions: 0.9.2
> Environment: All
>Reporter: Frank Schroeder
> Fix For: 0.9.2
>
> Attachments: THRIFT-2418.patch
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> The Go compiler is using the wrong err variable when handling an internal
> error in a handler method. Tested on fd62df75fa17d5c2af12302de6cee78ad7405692.
> The relevant generated code looks like this:
> {code}
> var err2 error
> if result.Success, err2 = p.handler.RemoveBatchBySource(args.SourceId,
> args.SourceSystem, args.SourceType, args.UserId); err2 != nil {
> x := thrift.NewTApplicationException(thrift.INTERNAL_ERROR, "Internal
> error processing removeBatchBySource: "+err.Error())
> oprot.WriteMessageBegin("removeBatchBySource", thrift.EXCEPTION, seqId)
> x.Write(oprot)
> oprot.WriteMessageEnd()
> oprot.Flush()
> return false, err2
> }
> {code}
> The error in the {{TApplicationException}} should be {{err2.Error()}} and not
> {{err.Error()}}. Since {{err}} is {{nil}} at that point the server panics.
> The patch for the Go compiler is a simple one line fix is attached.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (THRIFT-2388) GoLang - Fix data races in simple_server and server_socket
[ https://issues.apache.org/jira/browse/THRIFT-2388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bannister updated THRIFT-2388: Description: The documentation for Interrupt() on server_transport states that implementations of Interrupt() should be thread safe, but the implementation in server_socket.go is not. My tests also found a data race in simple_server.Stop(). was: The documentation for Interrupt() on server_transport states that implementations of Interrupt() should be thread safe, but the implementation in server_socket.go is not. My tests also found a data race in simple_server.Close. > GoLang - Fix data races in simple_server and server_socket > -- > > Key: THRIFT-2388 > URL: https://issues.apache.org/jira/browse/THRIFT-2388 > Project: Thrift > Issue Type: Bug > Components: Go - Library >Affects Versions: 0.9.1 >Reporter: Chris Bannister > Fix For: 0.9.2 > > Attachments: > 0001-Fix-data-races-in-simple_server-and-server_socket.patch > > > The documentation for Interrupt() on server_transport states that > implementations of Interrupt() should be thread safe, but the implementation > in server_socket.go is not. > My tests also found a data race in simple_server.Stop(). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (THRIFT-2388) GoLang - Fix data races in simple_server and server_socket
Chris Bannister created THRIFT-2388: --- Summary: GoLang - Fix data races in simple_server and server_socket Key: THRIFT-2388 URL: https://issues.apache.org/jira/browse/THRIFT-2388 Project: Thrift Issue Type: Bug Components: Go - Library Affects Versions: 0.9.1 Reporter: Chris Bannister Fix For: 0.9.2 Attachments: 0001-Fix-data-races-in-simple_server-and-server_socket.patch The documentation for Interrupt() on server_transport states that implementations of Interrupt() should be thread safe, but the implementation in server_socket.go is not. My tests also found a data race in simple_server.Close. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (THRIFT-2388) GoLang - Fix data races in simple_server and server_socket
[ https://issues.apache.org/jira/browse/THRIFT-2388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bannister updated THRIFT-2388: Attachment: 0001-Fix-data-races-in-simple_server-and-server_socket.patch > GoLang - Fix data races in simple_server and server_socket > -- > > Key: THRIFT-2388 > URL: https://issues.apache.org/jira/browse/THRIFT-2388 > Project: Thrift > Issue Type: Bug > Components: Go - Library >Affects Versions: 0.9.1 >Reporter: Chris Bannister > Fix For: 0.9.2 > > Attachments: > 0001-Fix-data-races-in-simple_server-and-server_socket.patch > > > The documentation for Interrupt() on server_transport states that > implementations of Interrupt() should be thread safe, but the implementation > in server_socket.go is not. > My tests also found a data race in simple_server.Close. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (THRIFT-2349) Golang - improve tutorial
Chris Bannister created THRIFT-2349: --- Summary: Golang - improve tutorial Key: THRIFT-2349 URL: https://issues.apache.org/jira/browse/THRIFT-2349 Project: Thrift Issue Type: Improvement Components: Tutorial Affects Versions: 0.9.2 Reporter: Chris Bannister Attachments: THRIFT-2349.patch Use a type switch to check what exception is thrown from the calculator handler. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (THRIFT-2349) Golang - improve tutorial
[ https://issues.apache.org/jira/browse/THRIFT-2349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bannister updated THRIFT-2349: Attachment: THRIFT-2349.patch > Golang - improve tutorial > - > > Key: THRIFT-2349 > URL: https://issues.apache.org/jira/browse/THRIFT-2349 > Project: Thrift > Issue Type: Improvement > Components: Tutorial >Affects Versions: 0.9.2 >Reporter: Chris Bannister > Attachments: THRIFT-2349.patch > > > Use a type switch to check what exception is thrown from the calculator > handler. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (THRIFT-2343) Golang - Return a single error for all exceptions instead of multiple return values
[ https://issues.apache.org/jira/browse/THRIFT-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bannister updated THRIFT-2343: Attachment: 0002-Update-tutorial-to-reflect-changes-to-exceptions.patch 0001-Only-expose-returning-a-single-error-return-in-Go.patch > Golang - Return a single error for all exceptions instead of multiple return > values > --- > > Key: THRIFT-2343 > URL: https://issues.apache.org/jira/browse/THRIFT-2343 > Project: Thrift > Issue Type: Improvement > Components: Go - Compiler >Affects Versions: 0.9.1 >Reporter: Chris Bannister >Assignee: Jens Geyer > Fix For: 0.9.2 > > Attachments: > 0001-Only-expose-returning-a-single-error-return-in-Go.patch, > 0001-Only-expose-returning-a-single-error-return-in-Go.patch, > 0002-Update-tutorial-to-reflect-changes-to-exceptions.patch, > 0002-go-processor-exceptions-are-treated-as-one-error.patch, > thrift-2343-fix-tutorial-and-methods-without-exceptions.patch > > > Currently the Thrift compiler for Go generates some very ugly (by Go's > standard) code for method calls. This is because of the fact that Go does not > have exceptions. > My proposal is to change the way the exceptions are handled in Go, instead of > returning each exception explicitly as a return value, instead return the > exceptions as a single error return. This has another benefit that Go servers > will no longer be able to 'throw' multiple exceptions, previously you could > assign an error to all the defined exceptions of a method which shouldn't be > possible. > This change relies on the fact that the exceptions generated by Thrift > implement the Error interface, which they now do (in 0.9.2). > It has the downside that the exceptions thrown to a client calling a thrift > method are no longer immediately visible. But this is the same way the Go > standard library handles it so it shouldn't be a problem. > It changes the generated interface so it will break backwards compatibility, > but as 0.9.2 is already breaking backwards compatibility this shouldn't be a > huge problem, but should be considered. > The proposed changes change the Processor methods for each method, doing a > type switch against all the defined exceptions for the method. The > fallthrough case is the same INTERNAL_SERVER_ERROR exception. > Please consider this a RFC. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (THRIFT-2343) Golang - Return a single error for all exceptions instead of multiple return values
[ https://issues.apache.org/jira/browse/THRIFT-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13891344#comment-13891344 ] Chris Bannister commented on THRIFT-2343: - I've fixed that, do you want me to submit the patches separately or as a single patch (including the previous 2)? > Golang - Return a single error for all exceptions instead of multiple return > values > --- > > Key: THRIFT-2343 > URL: https://issues.apache.org/jira/browse/THRIFT-2343 > Project: Thrift > Issue Type: Improvement > Components: Go - Compiler >Affects Versions: 0.9.1 >Reporter: Chris Bannister >Assignee: Jens Geyer > Fix For: 0.9.2 > > Attachments: > 0001-Only-expose-returning-a-single-error-return-in-Go.patch, > 0002-go-processor-exceptions-are-treated-as-one-error.patch > > > Currently the Thrift compiler for Go generates some very ugly (by Go's > standard) code for method calls. This is because of the fact that Go does not > have exceptions. > My proposal is to change the way the exceptions are handled in Go, instead of > returning each exception explicitly as a return value, instead return the > exceptions as a single error return. This has another benefit that Go servers > will no longer be able to 'throw' multiple exceptions, previously you could > assign an error to all the defined exceptions of a method which shouldn't be > possible. > This change relies on the fact that the exceptions generated by Thrift > implement the Error interface, which they now do (in 0.9.2). > It has the downside that the exceptions thrown to a client calling a thrift > method are no longer immediately visible. But this is the same way the Go > standard library handles it so it shouldn't be a problem. > It changes the generated interface so it will break backwards compatibility, > but as 0.9.2 is already breaking backwards compatibility this shouldn't be a > huge problem, but should be considered. > The proposed changes change the Processor methods for each method, doing a > type switch against all the defined exceptions for the method. The > fallthrough case is the same INTERNAL_SERVER_ERROR exception. > Please consider this a RFC. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (THRIFT-2343) Golang - Return a single error for all exceptions instead of multiple return values
[ https://issues.apache.org/jira/browse/THRIFT-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bannister updated THRIFT-2343: Description: Currently the Thrift compiler for Go generates some very ugly (by Go's standard) code for method calls. This is because of the fact that Go does not have exceptions. My proposal is to change the way the exceptions are handled in Go, instead of returning each exception explicitly as a return value, instead return the exceptions as a single error return. This has another benefit that Go servers will no longer be able to 'throw' multiple exceptions, previously you could assign an error to all the defined exceptions of a method which shouldn't be possible. This change relies on the fact that the exceptions generated by Thrift implement the Error interface, which they now do (in 0.9.2). It has the downside that the exceptions thrown to a client calling a thrift method are no longer immediately visible. But this is the same way the Go standard library handles it so it shouldn't be a problem. It changes the generated interface so it will break backwards compatibility, but as 0.9.2 is already breaking backwards compatibility this shouldn't be a huge problem, but should be considered. The proposed changes change the Processor methods for each method, doing a type switch against all the defined exceptions for the method. The fallthrough case is the same INTERNAL_SERVER_ERROR exception. Please consider this a RFC. was: Currently the Thrift compiler for Go generates some very ugly (by Go's standard) code for method calls. This is because of the fact that Go does not have exceptions. My proposal is to change the way the exceptions are handled in Go, instead of returning each exception explicitly as a return value, instead return the exceptions as a single error return. This has another benefit that Go servers will no longer be able to 'throw' multiple exceptions, previously you could assign an error to all the defined exceptions of a method which shouldn't be possible. This change relies on the fact that the exceptions generated by Thrift implement the Error interface, which they now do (in 0.9.2). It has the downside that the exceptions thrown to a client calling a thrift method are no longer immediately visible. But this is the same way the Go standard library handles it so it shouldn't be a problem. It changes the generated interface so it will break backwards compatibility, but as 0.9.2 is already breaking backwards compatibility this shouldn't be a huge problem, but should be considered. The proposed changes change the Processor methods for each method, doing a type switch against all the defined exceptions for the method. The fallthrough case is the same INTERNAL_SERVER_ERROR exception. Please consider this a RFC. > Golang - Return a single error for all exceptions instead of multiple return > values > --- > > Key: THRIFT-2343 > URL: https://issues.apache.org/jira/browse/THRIFT-2343 > Project: Thrift > Issue Type: Improvement > Components: Go - Compiler >Affects Versions: 0.9.1 >Reporter: Chris Bannister >Assignee: Jens Geyer > Fix For: 0.9.2 > > Attachments: > 0001-Only-expose-returning-a-single-error-return-in-Go.patch, > 0002-go-processor-exceptions-are-treated-as-one-error.patch > > > Currently the Thrift compiler for Go generates some very ugly (by Go's > standard) code for method calls. This is because of the fact that Go does not > have exceptions. > My proposal is to change the way the exceptions are handled in Go, instead of > returning each exception explicitly as a return value, instead return the > exceptions as a single error return. This has another benefit that Go servers > will no longer be able to 'throw' multiple exceptions, previously you could > assign an error to all the defined exceptions of a method which shouldn't be > possible. > This change relies on the fact that the exceptions generated by Thrift > implement the Error interface, which they now do (in 0.9.2). > It has the downside that the exceptions thrown to a client calling a thrift > method are no longer immediately visible. But this is the same way the Go > standard library handles it so it shouldn't be a problem. > It changes the generated interface so it will break backwards compatibility, > but as 0.9.2 is already breaking backwards compatibility this shouldn't be a > huge problem, but should be considered. > The proposed changes change the Processor methods for each method, doing a > type switch against all the defined exceptions for the method. The > fallthrough case is the same INTERNAL_SERVER_ERROR exception. > Please consider this a RFC. -- This message was s
[jira] [Updated] (THRIFT-2343) Golang - Return a single error for all exceptions instead of multiple return values
[ https://issues.apache.org/jira/browse/THRIFT-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bannister updated THRIFT-2343: Attachment: 0002-go-processor-exceptions-are-treated-as-one-error.patch 0001-Only-expose-returning-a-single-error-return-in-Go.patch > Golang - Return a single error for all exceptions instead of multiple return > values > --- > > Key: THRIFT-2343 > URL: https://issues.apache.org/jira/browse/THRIFT-2343 > Project: Thrift > Issue Type: Improvement > Components: Go - Compiler >Affects Versions: 0.9.1 >Reporter: Chris Bannister > Fix For: 0.9.2 > > Attachments: > 0001-Only-expose-returning-a-single-error-return-in-Go.patch, > 0002-go-processor-exceptions-are-treated-as-one-error.patch > > > Currently the Thrift compiler for Go generates some very ugly (by Go's > standard) code for method calls. This is because of the fact that Go does not > have exceptions. > My proposal is to change the way the exceptions are handled in Go, instead of > returning each exception explicitly as a return value, instead return the > exceptions as a single error return. This has another benefit that > Go servers will no longer be able to 'throw' multiple exceptions, previously > you could assign an error to all the defined exceptions of a method which > shouldn't be possible. > This change relies on the fact that the exceptions generated by Thrift > implement the Error interface, which they now do (in 0.9.2). > It has the downside that the exceptions thrown to a client calling a thrift > method are no longer immediately visible. But this is the same way the Go > standard library handles it so it shouldn't be a problem. > It changes the generated interface so it will break backwards compatibility, > but as 0.9.2 is already breaking backwards compatibility this shouldn't be a > huge problem, but should be considered. > The proposed changes change the Processor methods for each method, doing a > type switch against all the defined exceptions for the method. The > fallthrough case is the same INTERNAL_SERVER_ERROR exception. > Please consider this a RFC. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (THRIFT-2343) Golang - Return a single error for all exceptions instead of multiple return values
Chris Bannister created THRIFT-2343: --- Summary: Golang - Return a single error for all exceptions instead of multiple return values Key: THRIFT-2343 URL: https://issues.apache.org/jira/browse/THRIFT-2343 Project: Thrift Issue Type: Improvement Components: Go - Compiler Reporter: Chris Bannister Currently the Thrift compiler for Go generates some very ugly (by Go's standard) code for method calls. This is because of the fact that Go does not have exceptions. My proposal is to change the way the exceptions are handled in Go, instead of returning each exception explicitly as a return value, instead return the exceptions as a single error return. This has another benefit that Go servers will no longer be able to 'throw' multiple exceptions, previously you could assign an error to all the defined exceptions of a method which shouldn't be possible. This change relies on the fact that the exceptions generated by Thrift implement the Error interface, which they now do (in 0.9.2). It has the downside that the exceptions thrown to a client calling a thrift method are no longer immediately visible. But this is the same way the Go standard library handles it so it shouldn't be a problem. It changes the generated interface so it will break backwards compatibility, but as 0.9.2 is already breaking backwards compatibility this shouldn't be a huge problem, but should be considered. The proposed changes change the Processor methods for each method, doing a type switch against all the defined exceptions for the method. The fallthrough case is the same INTERNAL_SERVER_ERROR exception. Please consider this a RFC. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (THRIFT-2337) Golang does not report TIMED_OUT exceptions
[ https://issues.apache.org/jira/browse/THRIFT-2337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bannister updated THRIFT-2337: Attachment: THRIFT-2337-golang-timeouts.patch > Golang does not report TIMED_OUT exceptions > --- > > Key: THRIFT-2337 > URL: https://issues.apache.org/jira/browse/THRIFT-2337 > Project: Thrift > Issue Type: Bug > Components: Go - Library >Affects Versions: 0.9.1 >Reporter: Chris Bannister > Attachments: THRIFT-2337-golang-timeouts.patch > > > If you set the timeout on a TSocket, thrift will convert the error into a > TTransportException which never checks if the error is caused by a timeout so > the TypeId will always be UNKNOWN_TRANSPORT_EXCEPTION. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (THRIFT-2337) Golang does not report TIMED_OUT exceptions
Chris Bannister created THRIFT-2337: --- Summary: Golang does not report TIMED_OUT exceptions Key: THRIFT-2337 URL: https://issues.apache.org/jira/browse/THRIFT-2337 Project: Thrift Issue Type: Bug Components: Go - Library Affects Versions: 0.9.1 Reporter: Chris Bannister If you set the timeout on a TSocket, thrift will convert the error into a TTransportException which never checks if the error is caused by a timeout so the TypeId will always be UNKNOWN_TRANSPORT_EXCEPTION. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
