[jira] [Commented] (THRIFT-5800) "Could not find include file foo.thrift" probably should be failure instead of warning

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17868466#comment-17868466
 ] 

Duru Can Celasun commented on THRIFT-5800:
--

Unconditional failure might break a lot of build scripts out there. +1 for 
-strict though.

> "Could not find include file foo.thrift" probably should be failure instead 
> of warning
> --
>
> Key: THRIFT-5800
> URL: https://issues.apache.org/jira/browse/THRIFT-5800
> Project: Thrift
>  Issue Type: Improvement
>  Components: Compiler (General)
>Reporter: Yuxuan Wang
>Priority: Major
>
> Currently when a thrift file includes a non-exist file and don't reference it 
> in any way otherwise, like this:
> {code}
> include "foo.thrift" // does not exist
> ... // don't reference anything that's foo.*
> {code}
> The compiler will generate a warning:
> {code}
> [WARNING:/path/to/file.thrift:N] Could not find include file foo.thrift
> {code}
> This probably should be failure instead of warning? Or at least be a failure 
> when -strict arg is passed in, and keep at warning without -strict.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (THRIFT-3037) Can not build Go code when using typedef in IDL

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-3037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17790269#comment-17790269
 ] 

Duru Can Celasun commented on THRIFT-3037:
--

You should be able to do it yourself. From the right sidebar: People -> 
Assignee -> Assign to me.

It doesn't really matter anyway.

> Can not build Go code when using typedef in IDL
> ---
>
> Key: THRIFT-3037
> URL: https://issues.apache.org/jira/browse/THRIFT-3037
> Project: Thrift
>  Issue Type: Bug
>  Components: Go - Compiler
>Affects Versions: 0.9.2
>Reporter: Joe Bruner
>Priority: Major
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> {code}
> // Base.thrift
> namespace go a.X.c
> struct Foo {
> 1: required string s
> }
> {code}
> and the dependent file
> {code}
> // Child.thrift
> namespace go a.Y.c
> include "Base.thrift"
> typedef Base.Foo Foo // < This is what causes the problem
> struct Bar {
> 1:Foo f  // <-- Will error
> // 1:Base.Foo f   Need to comment out typedef and use this instead
> }
> {code}
> Compiling the thrift as is works, but when you go to install the a.Y.c 
> package will produce:
> {code}
> /scratch/go/src/a/Y/c/ttypes.go:78: cannot use c.Foo literal (type *c.Foo) as 
> type *Foo in assignment
> /scratch/go/src/a/Y/c/ttypes.go:79: p.F.Read undefined (type *Foo has no 
> field or method Read)
> /scratch/go/src/a/Y/c/ttypes.go:105: p.F.Write undefined (type *Foo has no 
> field or method Write)
> {code}
> If I comment out the typedef and swap the lines in Bar then everything works 
> fine. This appears to only happen in Go.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Assigned] (THRIFT-3037) Can not build Go code when using typedef in IDL

[Duru Can Celasun (Jira)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-3037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duru Can Celasun reassigned THRIFT-3037:


Assignee: (was: Duru Can Celasun)

> Can not build Go code when using typedef in IDL
> ---
>
> Key: THRIFT-3037
> URL: https://issues.apache.org/jira/browse/THRIFT-3037
> Project: Thrift
>  Issue Type: Bug
>  Components: Go - Compiler
>Affects Versions: 0.9.2
>Reporter: Joe Bruner
>Priority: Major
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> {code}
> // Base.thrift
> namespace go a.X.c
> struct Foo {
> 1: required string s
> }
> {code}
> and the dependent file
> {code}
> // Child.thrift
> namespace go a.Y.c
> include "Base.thrift"
> typedef Base.Foo Foo // < This is what causes the problem
> struct Bar {
> 1:Foo f  // <-- Will error
> // 1:Base.Foo f   Need to comment out typedef and use this instead
> }
> {code}
> Compiling the thrift as is works, but when you go to install the a.Y.c 
> package will produce:
> {code}
> /scratch/go/src/a/Y/c/ttypes.go:78: cannot use c.Foo literal (type *c.Foo) as 
> type *Foo in assignment
> /scratch/go/src/a/Y/c/ttypes.go:79: p.F.Read undefined (type *Foo has no 
> field or method Read)
> /scratch/go/src/a/Y/c/ttypes.go:105: p.F.Write undefined (type *Foo has no 
> field or method Write)
> {code}
> If I comment out the typedef and swap the lines in Bar then everything works 
> fine. This appears to only happen in Go.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (THRIFT-5745) go: Implement slog.LogValuer for exceptions and/or structs

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787407#comment-17787407
 ] 

Duru Can Celasun commented on THRIFT-5745:
--

The Stringer implementation has been a long time source of pain for us as well, 
so I think this is a good idea. I wouldn't make it optional. And yes, let's add 
it to structs as well.

> go: Implement slog.LogValuer for exceptions and/or structs
> --
>
> Key: THRIFT-5745
> URL: https://issues.apache.org/jira/browse/THRIFT-5745
> Project: Thrift
>  Issue Type: Task
>  Components: Go - Compiler
>Reporter: Yuxuan Wang
>Priority: Major
>
> To follow up on THRIFT-5744, implement 
> [slog.LogValuer|https://pkg.go.dev/log/slog#LogValuer] on compiler generated 
> exceptions, and maybe also structs.
> The current problem is that when logging an exception, the Stringer 
> implementation will be used, but that usually gives you quite unhelpful 
> string, especially when optional fields are used.
> For example we have [this exception 
> defined|https://github.com/reddit/baseplate.py/blob/8c446337dab6a1692900decf9cd01f3f4e39d764/baseplate/thrift/baseplate.thrift#L197]:
> {code:java}
> exception Error {
> 1: optional i32 code
> 2: optional string message
> 3: optional map details
> 4: optional bool retryable
> }
> {code}
> When you create an instance of it:
> {code:go}
> return &baseplate.Error{
>   Code: thrift.Int32Ptr(404),
>   Message: thrift.Pointer("no such id"),
> }
> {code}
> And then log that error, instead of getting something useful with the code 
> (404) and message ("no such id") in it, you get something like this instead 
> because this is how we implemented fmt.Stringer from the compiler:
> {code:go}
> Error({Code:0xc000426648 Message:0xc00041ca10 Details:map[] Retryable:})
> {code}
> The compiler generates implementation for json.Marshaler for all exceptions, 
> which will be much more helpful. The marshaled json for such error would be:
> {code:json}
> {"code":400,"message":"no such id"}
> {code}
> They are also much more expensive, so probably not suitable to replace the 
> current Stringer implementation, but when logging them, it's probably worth 
> it to implement slog.LogValuer so we can log something more useful, probably 
> like this:
> {code:go}
> func (p *Error) LogValue() slog.Value{
>   var sb strings.Builder
>   sb.WriteString("baseplate.Error")
>   bytes, err := json.Marshal(p)
>   if err != nil {
> // should not happen
> return slog.StringValue(fmt.Sprintf("baseplate.Error.LogValue: failed to 
> marshal json: %v", err))
>   }
>   sb.Write(bytes)
>   return slog.StringValue(sb.String())
> }
> {code}
> Which will make the error logged show as:
> {code:json}
> baseplate.Error{"code":400,"message":"no such id"}
> {code}
> Some open questions:
> # Is this also useful for structs?
> # Do we want to make this optional (e.g. only generate LogValue function when 
> a compiler flag is passed in)?



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (THRIFT-5744) Proposal: Switch all go logging in the library to slog

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787349#comment-17787349
 ] 

Duru Can Celasun commented on THRIFT-5744:
--

I haven't had a chance to use slog at scale (we use zap) but it's clearly an 
improvement over status quo for thrift. Let's go for it.

> Proposal: Switch all go logging in the library to slog
> --
>
> Key: THRIFT-5744
> URL: https://issues.apache.org/jira/browse/THRIFT-5744
> Project: Thrift
>  Issue Type: Task
>  Components: Go - Library
>Reporter: Yuxuan Wang
>Assignee: Yuxuan Wang
>Priority: Major
>
> In the go library, we used to use the stdlib [log|https://pkg.go.dev/log] 
> library to do logging. Then in THRIFT-4985 we added a simple wrapper 
> interface, Logger, to replace all the logging usage in the library code.
> This Proposal is that we switch all internal logging to stdlib 
> [slog|https://pkg.go.dev/log/slog] (after go 1.22 release so our minimal 
> supported go version is at least 1.21 and has slog in stdlib), and 
> deprecate/remove the Logger wrapper interface.
> In the current go library code, there are 2 places logging is used:
> # TDebugProtocol: with this proposal we should switch them to 
> slog.DebugContext
> # TSimpleServer: we log errors from processRequests, so with this proposel we 
> should switch them to slog.ErrorContext, and also add a SetBaseContext api to 
> TSimpleServer so a base context can be set to be used in that logging
> The original, stdlib log approach, didn't work out well because the API of it 
> is too limited (no log level, no context, no structured logging/kv pair 
> ability, etc.), resulting in a lot of third-party logging library 
> implementations cannot be adapted to the stdlib log api (even when some of 
> them, for example zap, provided a way to replace the default log logger to be 
> zap backend, because of the limitation of the api a lot of the features like 
> log level and kv pairs are still unusable with log api), resulting in mixed 
> logging in applications.
> The Logger wrapper interface resolved the mixed logging issue, but its API is 
> still very limited (it's a common denominator approach), so it still have 
> issues like lack of fine grain control of the logging, and performance (see 
> THRIFT-5539, because the lack of log level we cannot skip the Sprintf used by 
> TDebugProtocol when we don't need the logging, resulting in us forking out 
> TDuplicateToProtocol).
> The new slog stdlib is go team's answer to the fragmentation of logging 
> library issue in the go ecosystem, and it does have a really good chance to 
> really unite all the logging libraries once and for all:
> * The context in logging calls provides the ability to: 1) attach context kv 
> pairs automatically (trace id, etc.); 2) control minimal log level (you can 
> provide a ctx before calling thrift code that could do potential logging to 
> raise/lower minimal log level as needed); 3) or even do additional log 
> suppressing logic based on the context
> * Even if some developers still prefer zap/zerolog/etc. for their performance 
> (zap still claims to be faster than slog, for example), there are wrapper 
> libraries to set the default slog handler to a zap/zerolog/etc. 
> implementation so they still have uniformed logging, and the new API from 
> slog means that they can still preserve the majority of the features from 
> those third party logging libraries.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (THRIFT-5609) TJSONProtocol and TSimpleJSONProtocol are unsafe to be used with TDeserializerPool and TSerializerPool

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17576063#comment-17576063
 ] 

Duru Can Celasun commented on THRIFT-5609:
--

4 is clean and safe, but 2 is cleaner. Can you think of a legitimate use case 
that would be broken by 2? Nothing comes to mind.

> TJSONProtocol and TSimpleJSONProtocol are unsafe to be used with 
> TDeserializerPool and TSerializerPool
> --
>
> Key: THRIFT-5609
> URL: https://issues.apache.org/jira/browse/THRIFT-5609
> Project: Thrift
>  Issue Type: Bug
>  Components: Go - Library
>Affects Versions: 0.16.0
>Reporter: Yuxuan Wang
>Assignee: Yuxuan Wang
>Priority: Major
>
> We just realized that when using TJSONProtocol with TDeserializerPool like 
> this:
> {code:go}
> var deserializerPool = thrift.NewTDeserializerPoolSizeFactory(1024, 
> thrift.NewTJSONProtocolFactory())
> {code}
> It only works when it never fails (e.g. it never encounters invalid json 
> blobs). Whenever a failure happens, because of the internal state stack and 
> other states in TJSONProtocol, it will be put back into the pool with the 
> wrong state, and when it's next used it will fail again.
> There are a few approaches we can take to fix it:
> # The simplest "fix" would be just document in TDeserializerPool and 
> TSerializerPool that TJSONProtocol and TSimpleJSONProtocol are not safe to be 
> used, and maybe provide some examples of how to use them (only pool the 
> TMemoryBuffer and recreate TProtocol every time)
> # In TJSONProtocol and TSimpleJSONProtocol's 
> [Read|Write][Message|Struct]Begin, implicitly reset the internal state. But 
> I'm not sure how safe that is
> # Make a breaking change to TProtocol to add a Reset (or maybe ResetState) 
> API to be used by TDeserializer/TSerializer (similar to how they always reset 
> the TMemoryBuffer before doing anything)
> # Similar to 3 but less breaking, just add a Reset/ResetState to 
> TJSONProtocol and TSimpleJSONProtocol (but not TProtocol), and in 
> TDeserializer/TSerializer do a type assertion and call the Reset API on the 
> protocol if it exists.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (THRIFT-5509) Potential connection leaks caused by the connectivity check

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17486650#comment-17486650
 ] 

Duru Can Celasun commented on THRIFT-5509:
--

Option 2, definitely.

> Potential connection leaks caused by the connectivity check
> ---
>
> Key: THRIFT-5509
> URL: https://issues.apache.org/jira/browse/THRIFT-5509
> Project: Thrift
>  Issue Type: Improvement
>  Components: Go - Library
>Affects Versions: 0.15.0
>Reporter: Yuxuan Wang
>Assignee: Yuxuan Wang
>Priority: Major
>
> Historically, for a TTransport, IsOpen returns true means that the connection 
> is already explicitly closed. So third party code (for example, client pool 
> management logic) could just throw the connection away after IsOpen returned 
> false without worry.
> But since the adding of connectivity check in go library (first release 
> version 0.14.0), that is no longer true: IsOpen could return true when the 
> remote closed the connection, and in such cases Close shall still be 
> explicitly called. If we just throw the connection away without explicitly 
> calling Close, the action of "throw away the connection" will cause 
> connection leaks.
> There are 2 ways to mitigate it:
>  # Document in IsOpen that IsOpen returning false does not necessarily mean 
> the connection is already closed, and an explicit Close call is still needed.
>  # Implicitly call Close inside IsOpen when connectivity check fails. This 
> way we keep the assumption that IsOpen returns false means Close was already 
> called being true.
> [~dcelasun] what's your preference between the 2 paths?



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Comment Edited] (THRIFT-5358) Add go.mod file(s)

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17287393#comment-17287393
 ] 

Duru Can Celasun edited comment on THRIFT-5358 at 2/19/21, 10:18 PM:
-

Sounds like a plan. I suggest we do a quick 0.14.1 release to unblock anyone on 
1.16.


was (Author: calcifer):
Sounds like a plan. I suggest we do a quick 0.14.1 release to unblock anyone on 
1.16.

[~jensg] thoughts?

> Add go.mod file(s)
> --
>
> Key: THRIFT-5358
> URL: https://issues.apache.org/jira/browse/THRIFT-5358
> Project: Thrift
>  Issue Type: Task
>  Components: Go - Library
>Affects Versions: 0.14.0
>Reporter: Yuxuan Wang
>Priority: Major
>
> Go 1.16 already disallowed building without go.mod file by default (still 
> override-able with GO111MODULES=auto environment variable), and Go 1.17 will 
> remove that override option, so we need to add go.mod file(s) to unblock 
> developers working on tip and using Go 1.16+.
> Based on the current discussion on https://github.com/golang/go/issues/34055, 
> we probably will need to add 2 go.mod files:
> # one under lib/go/thrift for our users to use. A release process change is 
> also required because of this file: for all the future releases, we would 
> need to double tag with "lib/go/thrift/" prefix (e.g. for 0.15.0 release we 
> would need to git tag "v0.15.0" and "lib/go/thrift/v0.15.0" on the same 
> commit)
> # another under root for the tests to work on Go 1.16+



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (THRIFT-5358) Add go.mod file(s)

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17287398#comment-17287398
 ] 

Duru Can Celasun commented on THRIFT-5358:
--

Ah ok, we haven't upgraded to 1.16 yet so I assumed it also affected users. No 
rush then.

> Add go.mod file(s)
> --
>
> Key: THRIFT-5358
> URL: https://issues.apache.org/jira/browse/THRIFT-5358
> Project: Thrift
>  Issue Type: Task
>  Components: Go - Library
>Affects Versions: 0.14.0
>Reporter: Yuxuan Wang
>Priority: Major
>
> Go 1.16 already disallowed building without go.mod file by default (still 
> override-able with GO111MODULES=auto environment variable), and Go 1.17 will 
> remove that override option, so we need to add go.mod file(s) to unblock 
> developers working on tip and using Go 1.16+.
> Based on the current discussion on https://github.com/golang/go/issues/34055, 
> we probably will need to add 2 go.mod files:
> # one under lib/go/thrift for our users to use. A release process change is 
> also required because of this file: for all the future releases, we would 
> need to double tag with "lib/go/thrift/" prefix (e.g. for 0.15.0 release we 
> would need to git tag "v0.15.0" and "lib/go/thrift/v0.15.0" on the same 
> commit)
> # another under root for the tests to work on Go 1.16+



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (THRIFT-5358) Add go.mod file(s)

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17287393#comment-17287393
 ] 

Duru Can Celasun edited comment on THRIFT-5358 at 2/19/21, 10:03 PM:
-

Sounds like a plan. I suggest we do a quick 0.14.1 release to unblock anyone on 
1.16.

[~jensg] thoughts?


was (Author: calcifer):
Sounds like a plan. I suggest we do a quick 0.14.1 release to unblock anyone on 
1.16.

@jensg thoughts?

> Add go.mod file(s)
> --
>
> Key: THRIFT-5358
> URL: https://issues.apache.org/jira/browse/THRIFT-5358
> Project: Thrift
>  Issue Type: Task
>  Components: Go - Library
>Affects Versions: 0.14.0
>Reporter: Yuxuan Wang
>Priority: Major
>
> Go 1.16 already disallowed building without go.mod file by default (still 
> override-able with GO111MODULES=auto environment variable), and Go 1.17 will 
> remove that override option, so we need to add go.mod file(s) to unblock 
> developers working on tip and using Go 1.16+.
> Based on the current discussion on https://github.com/golang/go/issues/34055, 
> we probably will need to add 2 go.mod files:
> # one under lib/go/thrift for our users to use. A release process change is 
> also required because of this file: for all the future releases, we would 
> need to double tag with "lib/go/thrift/" prefix (e.g. for 0.15.0 release we 
> would need to git tag "v0.15.0" and "lib/go/thrift/v0.15.0" on the same 
> commit)
> # another under root for the tests to work on Go 1.16+



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (THRIFT-5358) Add go.mod file(s)

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17287393#comment-17287393
 ] 

Duru Can Celasun commented on THRIFT-5358:
--

Sounds like a plan. I suggest we do a quick 0.14.1 release to unblock anyone on 
1.16.

@jensg thoughts?

> Add go.mod file(s)
> --
>
> Key: THRIFT-5358
> URL: https://issues.apache.org/jira/browse/THRIFT-5358
> Project: Thrift
>  Issue Type: Task
>  Components: Go - Library
>Affects Versions: 0.14.0
>Reporter: Yuxuan Wang
>Priority: Major
>
> Go 1.16 already disallowed building without go.mod file by default (still 
> override-able with GO111MODULES=auto environment variable), and Go 1.17 will 
> remove that override option, so we need to add go.mod file(s) to unblock 
> developers working on tip and using Go 1.16+.
> Based on the current discussion on https://github.com/golang/go/issues/34055, 
> we probably will need to add 2 go.mod files:
> # one under lib/go/thrift for our users to use. A release process change is 
> also required because of this file: for all the future releases, we would 
> need to double tag with "lib/go/thrift/" prefix (e.g. for 0.15.0 release we 
> would need to git tag "v0.15.0" and "lib/go/thrift/v0.15.0" on the same 
> commit)
> # another under root for the tests to work on Go 1.16+



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (THRIFT-4914) Go: Link between THeader and context object

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17270055#comment-17270055
 ] 

Duru Can Celasun commented on THRIFT-4914:
--

Sounds reasonable. I agree that there are likely very few direct users of 
Tclient.Call so the BC break is minor.

> Go: Link between THeader and context object
> ---
>
> Key: THRIFT-4914
> URL: https://issues.apache.org/jira/browse/THRIFT-4914
> Project: Thrift
>  Issue Type: New Feature
>  Components: Go - Library
>Reporter: Yuxuan Wang
>Priority: Major
> Fix For: 0.14.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> We have "raw" THeader support for Go in THRIFT-4612 now, the next step would 
> be to make them more easily accessible.
> The are 2 directions, 4 parts of this ticket:
>  * client -> server (requests)
>  ** Read headers on server
>  ** Write headers on client
>  * server -> client (responses)
>  ** Write headers on server
>  ** Read headers on client
> Take the reading on server as an example. Currently we can read the headers 
> from either the transport or the protocol, but neither the transport nor the 
> protocol objects are "easily accessible" when you are writing the business 
> logic code (writing the request handler in the server code). It would be much 
> better if we inject the headers into the context object passed into the 
> request handlers.
> We already have code injecting the headers to the context object that lives 
> outside of the thrift library working. I'll send out a PR in the coming days 
> to add that to the thrift library, so the performance would be better (we no 
> longer need to do the extra injecting work), and it would be a lot easier to 
> use.
> We'll think about how to best do the client writing part (probably auto read 
> the headers from the context object that passed into the client request code, 
> and write to THeaderProtocol automatically), and send out a PR soon-ish.
> The other direction, server -> client, is used much less often with headers, 
> so we'll probably punt on it for now, and come back revisit them in the 
> future.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (THRIFT-5338) Proposal: Raise minimal supported Go version with upcoming 0.14.0 release

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17268065#comment-17268065
 ] 

Duru Can Celasun edited comment on THRIFT-5338 at 1/19/21, 5:35 PM:


I'm happy to go for 1.14x. It has been quite a while since the last thrift 
release and anyone willing to upgrade thrift can surely use a newer version of 
Go, which doesn't break BC.


was (Author: calcifer):
I'm happy to go for 1.14x. It has been quite a while since the last thrift 
release and anyone willing to upgrade thrift can surely use newer version of 
Go, which doesn't break BC.

> Proposal: Raise minimal supported Go version with upcoming 0.14.0 release
> -
>
> Key: THRIFT-5338
> URL: https://issues.apache.org/jira/browse/THRIFT-5338
> Project: Thrift
>  Issue Type: Task
>  Components: Go - Library
>Reporter: Yuxuan Wang
>Priority: Major
>
> Currently (as of 0.13.0), the minimal supported Go version is 1.10.8, which 
> is the latest point release in 1.10.x (released on 2019-01-23). I propose 
> that we raise this version with 0.14.0 release. There are 3 potential 
> versions we can raise it to:
> 1. go1.12.17 (released on 2020-02-12). This proposal is based on the release 
> cycles of the 2 projects. (Go has a release very 6 months, while thrift has a 
> release roughly every 12 months, so we raise 2 versions of Go with our 
> release). This would give us benefit of proper go modules support, which was 
> introduced in go 1.11.
> 2. go1.13.15 (released on 2020-08-06). This would give us the additional 
> benefit of better error/exception handling, as currently in go library code 
> there are a few places we have to do extra work because we have to support 
> pre-go1.13 (examples: 
> [1|https://github.com/apache/thrift/blob/7f9abb1cc0f4b2793a48f45ddfcf0d2b287cc50c/lib/go/thrift/transport_exception_test.go#L50-L51],
>  
> [2|https://github.com/apache/thrift/blob/7f9abb1cc0f4b2793a48f45ddfcf0d2b287cc50c/lib/go/thrift/transport_exception_test.go#L69-L70],
>  
> [3|https://github.com/apache/thrift/blob/7f9abb1cc0f4b2793a48f45ddfcf0d2b287cc50c/lib/go/thrift/simple_server.go#L318-L319])
> 3. go1.14.x. There's no additional benefit for this one, but this will be the 
> -latest- minimal officially supported go release when we release 0.14.0 (as 
> stated by [Go release 
> policy|https://golang.org/doc/devel/release.html#policy], only 2 most recent 
> major releases will be supported by security fixes).
> I don't know if any of the thrift users are stuck with an older Go version. 
> Consider go has very strong backward compatibility guarantee on the whole 1.x 
> tree, I highly doubt that would be the case (unless someone is stuck on a 
> platform that's dropped in later Go releases).



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (THRIFT-5338) Proposal: Raise minimal supported Go version with upcoming 0.14.0 release

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17268065#comment-17268065
 ] 

Duru Can Celasun commented on THRIFT-5338:
--

I'm happy to go for 1.14x. It has been quite a while since the last thrift 
release and anyone willing to upgrade thrift can surely use newer version of 
Go, which doesn't break BC.

> Proposal: Raise minimal supported Go version with upcoming 0.14.0 release
> -
>
> Key: THRIFT-5338
> URL: https://issues.apache.org/jira/browse/THRIFT-5338
> Project: Thrift
>  Issue Type: Task
>  Components: Go - Library
>Reporter: Yuxuan Wang
>Priority: Major
>
> Currently (as of 0.13.0), the minimal supported Go version is 1.10.8, which 
> is the latest point release in 1.10.x (released on 2019-01-23). I propose 
> that we raise this version with 0.14.0 release. There are 3 potential 
> versions we can raise it to:
> 1. go1.12.17 (released on 2020-02-12). This proposal is based on the release 
> cycles of the 2 projects. (Go has a release very 6 months, while thrift has a 
> release roughly every 12 months, so we raise 2 versions of Go with our 
> release). This would give us benefit of proper go modules support, which was 
> introduced in go 1.11.
> 2. go1.13.15 (released on 2020-08-06). This would give us the additional 
> benefit of better error/exception handling, as currently in go library code 
> there are a few places we have to do extra work because we have to support 
> pre-go1.13 (examples: 
> [1|https://github.com/apache/thrift/blob/7f9abb1cc0f4b2793a48f45ddfcf0d2b287cc50c/lib/go/thrift/transport_exception_test.go#L50-L51],
>  
> [2|https://github.com/apache/thrift/blob/7f9abb1cc0f4b2793a48f45ddfcf0d2b287cc50c/lib/go/thrift/transport_exception_test.go#L69-L70],
>  
> [3|https://github.com/apache/thrift/blob/7f9abb1cc0f4b2793a48f45ddfcf0d2b287cc50c/lib/go/thrift/simple_server.go#L318-L319])
> 3. go1.14.x. There's no additional benefit for this one, but this will be the 
> latest officially supported go release when we release 0.14.0 (as stated by 
> [Go release policy|https://golang.org/doc/devel/release.html#policy], only 2 
> most recent major releases will be supported by security fixes).
> I don't know if any of the thrift users are stuck with an older Go version. 
> Consider go has very strong backward compatibility guarantee on the whole 1.x 
> tree, I highly doubt that would be the case (unless someone is stuck on a 
> platform that's dropped in later Go releases).



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (THRIFT-5326) Expand TException interface in go library

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17253300#comment-17253300
 ] 

Duru Can Celasun commented on THRIFT-5326:
--

I like the enum approach better. This will break type assertions, but judging 
by a [quick search on 
Github|https://github.com/search?q=TException+ok&type=Code&l=Go] it won't 
really be a problem.

> Expand TException interface in go library
> -
>
> Key: THRIFT-5326
> URL: https://issues.apache.org/jira/browse/THRIFT-5326
> Project: Thrift
>  Issue Type: Task
>  Components: Go - Compiler, Go - Library
>Affects Versions: 0.13.0
>Reporter: Yuxuan Wang
>Priority: Major
>
> This is an issue unique to go, because of go's duck typing interface system: 
> There's no way to distinguish TException from other errors.
> Currently TException is defined to be identical to error 
> ([link|https://github.com/apache/thrift/blob/3b9259d88b6ceb13bb6b8c6afe676fed707dcd4e/lib/go/thrift/exception.go#L27-L29]):
> {code:go}
> type TException interface {
>   error
> }
> {code}
> Which means when you try to do
> {code:go}
> var texception thrift.TException
> if errors.As(err, &texception) {
> }
> {code}
> It's always true.
> TTransportException, TApplicationException, and TProtocolException are 
> identifiable, but for exceptions generated from the compiler (that's defined 
> in thrift files), TExecption is the only "common" type they share and it's 
> very hard to write library code to handle them collectively.
> My proposal is to add a new function to TException interface (which also need 
> to be added to TTransportException, TApplicationException, 
> TProtocolException, and all compiler generated exceptions). There are 2 ways 
> to define this new function:
> 1. TExceptionType() TExceptionType, where TExceptionType is an enum type, 
> with values of TTransportException, TApplicationException, 
> TProtocolException, TIDLException (name tbd, open to suggestions, this is the 
> one intended to be used by compiler)
> 2. TExceptionName() string, which for TTransportException the string would 
> just be "TTransportException", etc. For compiler generated exceptions, I 
> think the name should be the name of the exception with the thrift filename 
> as the namespace. For example, for:
> {code}
> exception MyError {
>   ...
> }
> {code}
> that's defined in my_service.thrift, the compiler generated name would be 
> "my_service.MyError". Note that the namespace could be different from the 
> actual go import namespace, as in if the thrift file have the line of 
> "namespace go foo.bar.my_service_2", the go namespace would be "my_service_2" 
> instead of "my_service"
> I would slightly prefer the enum approach as it's simpler (there's no 
> ambiguity on the namespace part of the string approach). Either way this 
> requires compiler change to add the new function to generated exception types.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (THRIFT-5322) Go compact_protocol allocating unreasonable buffer size

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17247254#comment-17247254
 ] 

Duru Can Celasun commented on THRIFT-5322:
--

Buffer size limits have been implemented [1] for a number of languages in the 
aftermath of CVE-2019-11939 [2] but nobody has done so for Go yet. PRs are very 
welcome.


[1] Java example: https://github.com/apache/thrift/pull/2191


[2] https://nvd.nist.gov/vuln/detail/CVE-2019-11939

> Go compact_protocol allocating unreasonable buffer size
> ---
>
> Key: THRIFT-5322
> URL: https://issues.apache.org/jira/browse/THRIFT-5322
> Project: Thrift
>  Issue Type: Bug
>  Components: Go - Library
>Affects Versions: 0.13.0
>Reporter: Juraci Paixão Kröhling
>Priority: Major
>
> I don't yet know all the pieces to this puzzle, and it's quite possible that 
> the problem is on our side, but we use the Thrift Go library in the Jaeger 
> Agent and we are seeing a case where the memory consumption for a payload of 
> 4k bytes to result in a buffer allocation in the compact_protocol.go with 
> unreasonable sizes. I found buffers of 1.4GiB while debugging the issue.
>  
> This is the code that we are seeing this memory usage:
> [https://github.com/apache/thrift/blob/b75e88a33d67ae05ef9b5fa001d2a63a2effe377/lib/go/thrift/compact_protocol.go#L556-L577]
>  
> Here's more information about this, including a reproducer and initial 
> diagnostics:
> [https://github.com/jaegertracing/jaeger/issues/2638#issuecomment-741848201]
>  
> As mentioned above, I'm still getting all the pieces together, but perhaps 
> you've seen this before or know what might be going on. What I know for sure 
> at the moment is that this happens on malformed payloads, but I would expect 
> the library to have an upper limit on the buffer size.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (THRIFT-4685) Support the new golang modules (1.11 or later)

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17246095#comment-17246095
 ] 

Duru Can Celasun commented on THRIFT-4685:
--

Indeed, even the Go module spec [1] mentions it:

> A version is considered unstable if its major version is 0 or it has a 
> pre-release suffix. Unstable versions are not subject to compatibility 
> requirements. For example, v0.2.0 may not be compatible with v0.1.0, and 
> v1.5.0-beta may not be compatible with v1.5.0.

[1] https://golang.org/ref/mod#versions

> Support the new golang modules (1.11 or later)
> --
>
> Key: THRIFT-4685
> URL: https://issues.apache.org/jira/browse/THRIFT-4685
> Project: Thrift
>  Issue Type: Improvement
>  Components: Go - Library
>Affects Versions: 0.12.0
> Environment: golang 1.11 or later
>Reporter: James E. King III
>Assignee: Duru Can Celasun
>Priority: Minor
>
> Go added new module support in 1.11, see:
> https://github.com/golang/go/wiki/Modules
> We should move towards it.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (THRIFT-4685) Support the new golang modules (1.11 or later)

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17245965#comment-17245965
 ] 

Duru Can Celasun commented on THRIFT-4685:
--

I'm not sure if it's ok to change the versioning scheme for the whole project 
for the sake of one language but I'm not really opposed to it either.

The trouble is, we allow breaking changes for every tagged release, so 
basically all releases would come with a new major version, even if there are 
no breaking changes for Go.

In any case, this should probably be settled when we decide to do another 
release, whenever that might be.

What do you think [~jensg]?

> Support the new golang modules (1.11 or later)
> --
>
> Key: THRIFT-4685
> URL: https://issues.apache.org/jira/browse/THRIFT-4685
> Project: Thrift
>  Issue Type: Improvement
>  Components: Go - Library
>Affects Versions: 0.12.0
> Environment: golang 1.11 or later
>Reporter: James E. King III
>Assignee: Duru Can Celasun
>Priority: Minor
>
> Go added new module support in 1.11, see:
> https://github.com/golang/go/wiki/Modules
> We should move towards it.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (THRIFT-5269) Contexts are missing from GO generated code

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17183399#comment-17183399
 ] 

Duru Can Celasun commented on THRIFT-5269:
--

Sorry, we don't have a fixed schedule. It should be released this year though.

> Contexts are missing from GO generated code
> ---
>
> Key: THRIFT-5269
> URL: https://issues.apache.org/jira/browse/THRIFT-5269
> Project: Thrift
>  Issue Type: Bug
>  Components: Go - Compiler
>Affects Versions: 0.13.0
> Environment: ubuntu, thrift 0.13.0, go 1.14.6
>Reporter: Paolo Elefante
>Priority: Trivial
>
> Hi,
> [Contexts|https://golang.org/pkg/context/#Context] are missing from golang 
> generated code.
> I'm on ubuntu, thrift 0.13.0 and go 1.14.6.
> To reproduce the fault just follow the Go Tutorial 
> ([link|https://thrift.apache.org/tutorial/go])
> Thanks. 
> BR, Paolo



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (THRIFT-5269) Contexts are missing from GO generated code

[Duru Can Celasun (Jira)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-5269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duru Can Celasun resolved THRIFT-5269.
--
Resolution: Not A Problem

> Contexts are missing from GO generated code
> ---
>
> Key: THRIFT-5269
> URL: https://issues.apache.org/jira/browse/THRIFT-5269
> Project: Thrift
>  Issue Type: Bug
>  Components: Go - Compiler
>Affects Versions: 0.13.0
> Environment: ubuntu, thrift 0.13.0, go 1.14.6
>Reporter: Paolo Elefante
>Priority: Blocker
>
> Hi,
> [Contexts|https://golang.org/pkg/context/#Context] are missing from golang 
> generated code.
> I'm on ubuntu, thrift 0.13.0 and go 1.14.6.
> To reproduce the fault just follow the Go Tutorial 
> ([link|https://thrift.apache.org/tutorial/go])
> Thanks. 
> BR, Paolo



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (THRIFT-5269) Contexts are missing from GO generated code

[Duru Can Celasun (Jira)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-5269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duru Can Celasun updated THRIFT-5269:
-
Priority: Trivial  (was: Blocker)

> Contexts are missing from GO generated code
> ---
>
> Key: THRIFT-5269
> URL: https://issues.apache.org/jira/browse/THRIFT-5269
> Project: Thrift
>  Issue Type: Bug
>  Components: Go - Compiler
>Affects Versions: 0.13.0
> Environment: ubuntu, thrift 0.13.0, go 1.14.6
>Reporter: Paolo Elefante
>Priority: Trivial
>
> Hi,
> [Contexts|https://golang.org/pkg/context/#Context] are missing from golang 
> generated code.
> I'm on ubuntu, thrift 0.13.0 and go 1.14.6.
> To reproduce the fault just follow the Go Tutorial 
> ([link|https://thrift.apache.org/tutorial/go])
> Thanks. 
> BR, Paolo



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (THRIFT-5269) Contexts are missing from GO generated code

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17183373#comment-17183373
 ] 

Duru Can Celasun commented on THRIFT-5269:
--

OK, I see the problem. You are trying to use the Go library from master, but 
the compiler from 0.13. This is unsupported. Context support for protocol 
read/write methods were added in [this 
commit|https://github.com/apache/thrift/commit/e79f764f09afdfe829a06ca721059d34244d7c20],
 which will only be included in the upcoming 0.14 release.

Make sure to use the same version for library and compiler.

> Contexts are missing from GO generated code
> ---
>
> Key: THRIFT-5269
> URL: https://issues.apache.org/jira/browse/THRIFT-5269
> Project: Thrift
>  Issue Type: Bug
>  Components: Go - Compiler
>Affects Versions: 0.13.0
> Environment: ubuntu, thrift 0.13.0, go 1.14.6
>Reporter: Paolo Elefante
>Priority: Blocker
>
> Hi,
> [Contexts|https://golang.org/pkg/context/#Context] are missing from golang 
> generated code.
> I'm on ubuntu, thrift 0.13.0 and go 1.14.6.
> To reproduce the fault just follow the Go Tutorial 
> ([link|https://thrift.apache.org/tutorial/go])
> Thanks. 
> BR, Paolo



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (THRIFT-5269) Contexts are missing from GO generated code

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17183362#comment-17183362
 ] 

Duru Can Celasun commented on THRIFT-5269:
--

Missing where? There are many places where contexts are used. The generated 
service looks fine to me:
{code:java}
type Calculator interface {
  shared.SharedService
  //Ahh, now onto the cool part, defining a service. Services just need a name
  //and can optionally inherit from another service using the extends keyword.  
// A method definition looks like C code. It has a return type, arguments,
  // and optionally a list of exceptions that it may throw. Note that argument
  // lists and exception lists are specified using the exact same syntax as
  // field lists in struct or exception definitions.
  Ping(ctx context.Context) (err error)
  // Parameters:
  //  - Num1
  //  - Num2
  Add(ctx context.Context, num1 int32, num2 int32) (r int32, err error)
  // Parameters:
  //  - Logid
  //  - W
  Calculate(ctx context.Context, logid int32, w *Work) (r int32, err error)
  // This method has a oneway modifier. That means the client only makes
  // a request and does not listen for any response at all. Oneway methods
  // must be void.
  Zip(ctx context.Context) (err error)
}
{code}

> Contexts are missing from GO generated code
> ---
>
> Key: THRIFT-5269
> URL: https://issues.apache.org/jira/browse/THRIFT-5269
> Project: Thrift
>  Issue Type: Bug
>  Components: Go - Compiler
>Affects Versions: 0.13.0
> Environment: ubuntu, thrift 0.13.0, go 1.14.6
>Reporter: Paolo Elefante
>Priority: Blocker
>
> Hi,
> [Contexts|https://golang.org/pkg/context/#Context] are missing from golang 
> generated code.
> I'm on ubuntu, thrift 0.13.0 and go 1.14.6.
> To reproduce the fault just follow the Go Tutorial 
> ([link|https://thrift.apache.org/tutorial/go])
> Thanks. 
> BR, Paolo



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (THRIFT-5233) I/O timeout handling in go library

[Duru Can Celasun (Jira)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-5233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duru Can Celasun resolved THRIFT-5233.
--
Fix Version/s: 0.14.0
   Resolution: Fixed

> I/O timeout handling in go library
> --
>
> Key: THRIFT-5233
> URL: https://issues.apache.org/jira/browse/THRIFT-5233
> Project: Thrift
>  Issue Type: Improvement
>  Components: Go - Compiler, Go - Library
>Affects Versions: 0.13.0
>Reporter: Yuxuan Wang
>Priority: Major
>  Labels: Breaking-Change
> Fix For: 0.14.0
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> While debugging the bug in the first implementation of THRIFT-5214, I started 
> to look into the rabbit hole of I/O timeouts in the go library (mainly the 
> socket timeout on TSocket), and start to realize that the current way we 
> handle it is not great.
> From client's perspective, how a request goes is:
> client prepare the request TStruct -> send the request over the wire -> start 
> reading the response over the wire -> handle the response or I/O error
> The problem here, is that server will only send the first byte of response 
> out after it finished processing the request. So if the client incorrectly 
> configured a socket timeout on the TSocket used by this request to a value 
> that's too low, the reading will just report i/o timeout when the deadline 
> reaches, and the client will just fail the whole request.
> This will cause problems:
> # Client can't set socket timeout to something too low. In fact, if they use 
> a client pool (so for most requests there's no overhead on connecting), they 
> need the socket timeout to be at least the latency SLA of the server they 
> talk to, otherwise there's a serious risk that the client will fail a lot of 
> requests prematurely.
> # On the other hand, setting the socket timeout to something too high is also 
> a bad practice. In case that server is overloaded and cannot handle requests 
> in a timely fashion, client should have a way to fail faster, instead of 
> waiting for a very long timeout to expire.
> If the client set a deadline on the context object with the call, their 
> expectation usually would be that the request will fail after the deadline 
> passed (a small overhead is usually acceptable). But the socket timeout is 
> usually some fixed value configured to the program, while the actual deadline 
> on the context is more variable (e.g. this could be a server talking to 
> upstream server, it has a fixed totally deadline for the whole endpoint, but 
> the steps before that might take variable time so the deadline left here can 
> vary a lot).
> This leads to the point that we would need a way to keep socket timeout and 
> the deadline set in the context object in-sync.
> There are a few different options. The first obvious one, is to pass the 
> context object all the way to TSocket.Read, so that function can extract the 
> deadline out of the context object (if any), and set that as the socket 
> timeout instead of the pre-configured, fixed one.
> But that is also easy to be ruled out, because that would change the function 
> signature of TSocket.Read, making TSocket no longer implement io.Reader 
> interface.
> The next option, I think, is to handle it on TProtocol level. The idea is 
> that we pass the context object all the way into TProtocol.ReadMessageBegin 
> (and maybe other read functions of TProcotol?). This way, it can handle the 
> read errors, check if it's a timeout error, and if it is and the context 
> deadline haven't passed, it can just keep retrying again. This way, we can 
> set the fixed socket timeout to a low number when we know we will always have 
> a real deadline in the context attached, and just let TProtocol 
> implementation to keep retrying instead. If the user don't attach a deadline 
> to the context object, then they still need to set a large number on the 
> socket timeout.
> A slightly different option, is to add SetReadTimeout function to TTransport 
> interface. So all the TTransport implementations wrapping TSocket should just 
> pass that along. If the terminal one is actually not a TSocket (for example, 
> it's TMemoryBuffer), then this function just does nothing. This way, the 
> TProtocol.Read* functions can just extract deadline out of the context 
> object, and call their TTransport.SetReadTimeout with that deadline.
> Either way, this is going to be a breaking change that we need to add context 
> object to TProtocol.Read* function signatures. As a result, I believe some 
> compiler change might also be required to pass it all the way to TProtocol 
> calls. But even if compiler changes are needed, that part should be minimal 
> (just make sure we are passing context object correctly), and most of the 
> changes would b

[jira] [Commented] (THRIFT-5233) I/O timeout handling in go library

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17134564#comment-17134564
 ] 

Duru Can Celasun commented on THRIFT-5233:
--

> I started to look into the rabbit hole of I/O timeouts in the go library 
> (mainly the socket timeout on TSocket), and start to realize that the current 
> way we handle it is not great.

Yeah, most of that code predates context in stdlib so there is nothing more 
granular than the socket timeout. The problem you describe is valid, but 
honestly none of the options seem ideal.

Option 1 is definitely off the table. If I understand your proposal correctly, 
option 2 only breaks TProtocol whereas option 3 breaks TTransport as well. 
Custom TProtocol in the wild are rare, but we should definitely try to avoid 
breaking TTransport. So if you'd like to open a PR, let's go with option 2.

Even then, it's a fairly big BC break. I don't like it, but we broke 
compatibility for context propagation before and this is more of the same.

> I believe some compiler change might also be required to pass it all the way 
> to TProtocol calls.

Yes, I think you'll have to pass the context into various iprot.Read* calls in 
the compiler but that should be a small change.

> I/O timeout handling in go library
> --
>
> Key: THRIFT-5233
> URL: https://issues.apache.org/jira/browse/THRIFT-5233
> Project: Thrift
>  Issue Type: Improvement
>  Components: Go - Compiler, Go - Library
>Affects Versions: 0.13.0
>Reporter: Yuxuan Wang
>Priority: Major
>
> While debugging the bug in the first implementation of THRIFT-5214, I started 
> to look into the rabbit hole of I/O timeouts in the go library (mainly the 
> socket timeout on TSocket), and start to realize that the current way we 
> handle it is not great.
> From client's perspective, how a request goes is:
> client prepare the request TStruct -> send the request over the wire -> start 
> reading the response over the wire -> handle the response or I/O error
> The problem here, is that server will only send the first byte of response 
> out after it finished processing the request. So if the client incorrectly 
> configured a socket timeout on the TSocket used by this request to a value 
> that's too low, the reading will just report i/o timeout when the deadline 
> reaches, and the client will just fail the whole request.
> This will cause problems:
> # Client can't set socket timeout to something too low. In fact, if they use 
> a client pool (so for most requests there's no overhead on connecting), they 
> need the socket timeout to be at least the latency SLA of the server they 
> talk to, otherwise there's a serious risk that the client will fail a lot of 
> requests prematurely.
> # On the other hand, setting the socket timeout to something too high is also 
> a bad practice. In case that server is overloaded and cannot handle requests 
> in a timely fashion, client should have a way to fail faster, instead of 
> waiting for a very long timeout to expire.
> If the client set a deadline on the context object with the call, their 
> expectation usually would be that the request will fail after the deadline 
> passed (a small overhead is usually acceptable). But the socket timeout is 
> usually some fixed value configured to the program, while the actual deadline 
> on the context is more variable (e.g. this could be a server talking to 
> upstream server, it has a fixed totally deadline for the whole endpoint, but 
> the steps before that might take variable time so the deadline left here can 
> vary a lot).
> This leads to the point that we would need a way to keep socket timeout and 
> the deadline set in the context object in-sync.
> There are a few different options. The first obvious one, is to pass the 
> context object all the way to TSocket.Read, so that function can extract the 
> deadline out of the context object (if any), and set that as the socket 
> timeout instead of the pre-configured, fixed one.
> But that is also easy to be ruled out, because that would change the function 
> signature of TSocket.Read, making TSocket no longer implement io.Reader 
> interface.
> The next option, I think, is to handle it on TProtocol level. The idea is 
> that we pass the context object all the way into TProtocol.ReadMessageBegin 
> (and maybe other read functions of TProcotol?). This way, it can handle the 
> read errors, check if it's a timeout error, and if it is and the context 
> deadline haven't passed, it can just keep retrying again. This way, we can 
> set the fixed socket timeout to a low number when we know we will always have 
> a real deadline in the context attached, and just let TProtocol 
> implementation to keep retrying instead. If the user don't attach a deadline 
> to the context

[jira] [Comment Edited] (THRIFT-5164) Go middleware support

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17134473#comment-17134473
 ] 

Duru Can Celasun edited comment on THRIFT-5164 at 6/12/20, 7:35 PM:


I think both approaches have their merits. [~fishywang]'s minimal approach is 
cleaner by being limited to the library, which is why I quite liked it and 
accepted the PR.

The [other one|https://github.com/apache/thrift/pull/1992] is much heavier and 
requires extensive changes to the compiler. I'm not opposed to it in principle 
and I like that it makes it easier to intercept RPC parameters, but it adds a 
lot of verbosity and duplicated code to the generator output for something 
that's not strictly necessary. As [~fishywang] showed above, 
ProcessorMiddleware can be used to the same effect, it just needs a bit of 
manual mapping.

There is also the fact that the thrift project is understaffed nowadays and 
active contributors who understand the compiler are few, so I'm hesitant to 
increase our maintenance burden when the same functionality can be achieved in 
user code.

That said, I still haven't made up my mind about it so the PR remains open.


was (Author: calcifer):
I think both approaches have their merits. [~fishywang]'s minimal approach is 
cleaner by being limited to the library, which is why I quite liked it and 
accepted the PR.

The [other one|https://github.com/apache/thrift/pull/1992] is much heavier and 
requires extensive changes to the compiler. I'm not opposed to it in principle, 
but it adds a lot of verbosity and duplicated code to the generator output for 
something that's not strictly necessary. As [~fishywang] showed above, 
ProcessorMiddleware can be used to the same effect, it just needs a bit of 
manual mapping.

There is also the fact that the thrift project is understaffed nowadays and 
active contributors who understand the compiler are few, so I'm hesitant to 
increase our maintenance burden when the same functionality can be achieved in 
user code.

That said, I still haven't made up my mind about it so the PR remains open.

> Go middleware support
> -
>
> Key: THRIFT-5164
> URL: https://issues.apache.org/jira/browse/THRIFT-5164
> Project: Thrift
>  Issue Type: Improvement
>  Components: Go - Library
>Reporter: Yuxuan Wang
>Assignee: Duru Can Celasun
>Priority: Major
>  Labels: Breaking-Change
> Fix For: 0.14.0
>
>  Time Spent: 2h
>  Remaining Estimate: 0h
>
> I saw that this idea was discussed before in THRIFT-4553, but want to reopen 
> the discussion to see if there's a change of mind.
> We (Reddit) recently implemented TProcessor level middleware support in our 
> Baseplate.go library, and we think that our implementation is generic enough 
> that it might make sense to contribute that into the thrift library. The 
> related implementation are all in this file: 
> https://github.com/reddit/baseplate.go/blob/4225e42dc8dde56b222ac7ea3a4ff63aa726f6a6/thriftbp/middlewares.go
> https://github.com/reddit/baseplate.go/blob/4225e42dc8dde56b222ac7ea3a4ff63aa726f6a6/tracing/middlewares.go#L40-L64
>  is an example of how a tracing middleware is implemented.
> If we think that's a good idea, then we can contribute that into thrift repo 
> (with renames, of course). One implementation detail I'm not sure is that 
> whether we want to expand the TProcessor interface to also include 
> ProcessorMap and AddToProcessorMap, or do we want to keep the two iinterfaces 
> separate.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (THRIFT-5164) Go middleware support

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17134473#comment-17134473
 ] 

Duru Can Celasun commented on THRIFT-5164:
--

I think both approaches have their merits. [~fishywang]'s minimal approach is 
cleaner by being limited to the library, which is why I quite liked it and 
accepted the PR.

The [other one|https://github.com/apache/thrift/pull/1992] is much heavier and 
requires extensive changes to the compiler. I'm not opposed to it in principle, 
but it adds a lot of verbosity and duplicated code to the generator output for 
something that's not strictly necessary. As [~fishywang] showed above, 
ProcessorMiddleware can be used to the same effect, it just needs a bit of 
manual mapping.

There is also the fact that the thrift project is understaffed nowadays and 
active contributors who understand the compiler are few, so I'm hesitant to 
increase our maintenance burden when the same functionality can be achieved in 
user code.

That said, I still haven't made up my mind about it so the PR remains open.

> Go middleware support
> -
>
> Key: THRIFT-5164
> URL: https://issues.apache.org/jira/browse/THRIFT-5164
> Project: Thrift
>  Issue Type: Improvement
>  Components: Go - Library
>Reporter: Yuxuan Wang
>Assignee: Duru Can Celasun
>Priority: Major
>  Labels: Breaking-Change
> Fix For: 0.14.0
>
>  Time Spent: 2h
>  Remaining Estimate: 0h
>
> I saw that this idea was discussed before in THRIFT-4553, but want to reopen 
> the discussion to see if there's a change of mind.
> We (Reddit) recently implemented TProcessor level middleware support in our 
> Baseplate.go library, and we think that our implementation is generic enough 
> that it might make sense to contribute that into the thrift library. The 
> related implementation are all in this file: 
> https://github.com/reddit/baseplate.go/blob/4225e42dc8dde56b222ac7ea3a4ff63aa726f6a6/thriftbp/middlewares.go
> https://github.com/reddit/baseplate.go/blob/4225e42dc8dde56b222ac7ea3a4ff63aa726f6a6/tracing/middlewares.go#L40-L64
>  is an example of how a tracing middleware is implemented.
> If we think that's a good idea, then we can contribute that into thrift repo 
> (with renames, of course). One implementation detail I'm not sure is that 
> whether we want to expand the TProcessor interface to also include 
> ProcessorMap and AddToProcessorMap, or do we want to keep the two iinterfaces 
> separate.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (THRIFT-5214) go: Implement connection check in TSocket

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17118910#comment-17118910
 ] 

Duru Can Celasun commented on THRIFT-5214:
--

[~fishywang] 0.14 isn't a concern right now so we can wait a few days. Can you 
share what exactly went wrong? Increased latency, error rates?

Before merging I've played with your PR locally and it seemed fine. We only 
have Go servers, not clients at work so there is no real traffic I can test it 
on.

> go: Implement connection check in TSocket
> -
>
> Key: THRIFT-5214
> URL: https://issues.apache.org/jira/browse/THRIFT-5214
> Project: Thrift
>  Issue Type: Improvement
>  Components: Go - Library
>Reporter: Yuxuan Wang
>Priority: Major
> Fix For: 0.14.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> The first issue described in [this GitHub engineering blog 
> article|https://github.blog/2020-05-20-three-bugs-in-the-go-mysql-driver/] is 
> also an issue when we use thrift client pools. We implemented a thrift client 
> pool by checking client's TTransport.IsOpen before using that client, and 
> also added (arbitrary) TTL to the clients to avoid using clients that's been 
> opened for too long, but we still occasionally get broken pipes and 
> unexpected EOF errors when using those clients. I think implementing the same 
> connection check described by that article in TSocket.IsOpen (and/or when try 
> to read 0 byte from TSocket.Read) would greatly help the situation.
> But there are a few limitations of the connection check implementation, and 
> I'm not sure how acceptable are they in the thrift library:
> 1. It only works on non-windows systems (so for windows we'll have to 
> fallback to the old IsOpen implementation, I guess?)
> 2. It requires go 1.9+, what's thrift library's minimal go version supported?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (THRIFT-5214) go: Implement connection check in TSocket

[Duru Can Celasun (Jira)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-5214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duru Can Celasun resolved THRIFT-5214.
--
Fix Version/s: 0.14.0
   Resolution: Fixed

> go: Implement connection check in TSocket
> -
>
> Key: THRIFT-5214
> URL: https://issues.apache.org/jira/browse/THRIFT-5214
> Project: Thrift
>  Issue Type: Improvement
>  Components: Go - Library
>Reporter: Yuxuan Wang
>Priority: Major
> Fix For: 0.14.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> The first issue described in [this GitHub engineering blog 
> article|https://github.blog/2020-05-20-three-bugs-in-the-go-mysql-driver/] is 
> also an issue when we use thrift client pools. We implemented a thrift client 
> pool by checking client's TTransport.IsOpen before using that client, and 
> also added (arbitrary) TTL to the clients to avoid using clients that's been 
> opened for too long, but we still occasionally get broken pipes and 
> unexpected EOF errors when using those clients. I think implementing the same 
> connection check described by that article in TSocket.IsOpen (and/or when try 
> to read 0 byte from TSocket.Read) would greatly help the situation.
> But there are a few limitations of the connection check implementation, and 
> I'm not sure how acceptable are they in the thrift library:
> 1. It only works on non-windows systems (so for windows we'll have to 
> fallback to the old IsOpen implementation, I guess?)
> 2. It requires go 1.9+, what's thrift library's minimal go version supported?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (THRIFT-5214) go: Implement connection check in TSocket

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17113828#comment-17113828
 ] 

Duru Can Celasun commented on THRIFT-5214:
--

1. Github's fix for that issue was also non-windows only, but I'm not sure why. 
Windows sockets seem to have EWOULDBLOCK (as 
[WSAEWOULDBLOCK|https://docs.microsoft.com/en-us/windows/win32/winsock/windows-sockets-error-codes-2])
 as well but I'm not really familiar with Windows so I can't be sure. In any 
case, a non-windows build tag is fine.
2. [Officially|https://github.com/apache/thrift/blob/v0.13.0/LANGUAGES.md] we 
support 1.10.8+ so that should be fine.

> go: Implement connection check in TSocket
> -
>
> Key: THRIFT-5214
> URL: https://issues.apache.org/jira/browse/THRIFT-5214
> Project: Thrift
>  Issue Type: Improvement
>  Components: Go - Library
>Reporter: Yuxuan Wang
>Priority: Major
>
> The first issue described in [this GitHub engineering blog 
> article|https://github.blog/2020-05-20-three-bugs-in-the-go-mysql-driver/] is 
> also an issue when we use thrift client pools. We implemented a thrift client 
> pool by checking client's TTransport.IsOpen before using that client, and 
> also added (arbitrary) TTL to the clients to avoid using clients that's been 
> opened for too long, but we still occasionally get broken pipes and 
> unexpected EOF errors when using those clients. I think implementing the same 
> connection check described by that article in TSocket.IsOpen (and/or when try 
> to read 0 byte from TSocket.Read) would greatly help the situation.
> But there are a few limitations of the connection check implementation, and 
> I'm not sure how acceptable are they in the thrift library:
> 1. It only works on non-windows systems (so for windows we'll have to 
> fallback to the old IsOpen implementation, I guess?)
> 2. It requires go 1.9+, what's thrift library's minimal go version supported?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (THRIFT-5209) WIP: Support TinyGo

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17106975#comment-17106975
 ] 

Duru Can Celasun commented on THRIFT-5209:
--

I'm generally open to this sort of addition to Thrift's Go support and the diff 
so far seems small enough to not create any maintenance headaches.

That said, I do have a few concerns:

- The transports and protocols supported for Go with the gc compiler is listed 
[here|https://github.com/apache/thrift/blob/26e6c84cde490a22d39c43ba3903dd94bbb8497f/LANGUAGES.md].
 Since TinyGo can't support all of them, it will need a separate entry on that 
table.

- Tests. There are tests that use encoding/json. These will either have to be 
updated, or have separate TinyGo versions guarded by build tags.

- Continuous Integration. TinyGo must be added to the Travis CI config and must 
support [cross 
tests|https://github.com/apache/thrift/tree/master/test#apache-thrift---integration-test-suite]
 which tests every language against every other language.

- Server support. Are you planning to support servers or just clients? Servers 
implement 
[TServerTransport|https://github.com/apache/thrift/blob/26e6c84cde490a22d39c43ba3903dd94bbb8497f/lib/go/thrift/server_transport.go#L23-L34]
 and usually depend on net.

> Personally I think I would lean toward using the "Android" model I described 
> above with a single generator/library using a compiler option and build 
> flags, respectively. 

I agree.

> WIP: Support TinyGo
> ---
>
> Key: THRIFT-5209
> URL: https://issues.apache.org/jira/browse/THRIFT-5209
> Project: Thrift
>  Issue Type: New Feature
>  Components: Go - Compiler, Go - Library
>Reporter: Benjamin Gould
>Priority: Minor
>
> TinyGo ([https://tinygo.org/)] provides a compiler for the Go programming 
> language that is an alternative to the standard Go compiler and is based on 
> LLVM.  It uses the standard Go toolchain to compile programs to Go's SSA 
> format, and then translates the SSA to LLVM IR that can subsequently be 
> compiled for various microcontrollers, wasm, or Linux.  The important 
> takeaway from that explanation is that since TinyGo programs use the standard 
> Go compiler for the compiler frontend, is not is a subset of the Go language 
> - it is the same language, with some small caveats.
> The main caveat as far as Thrift support is concerned is that not all 
> packages in the standard library are supported yet, including the {{net}} and 
> {{encoding/json}} packages.  This presents an obvious problem for using 
> Thrift, since these packages are imported by the Thrift Go library.  
> Additionally, some small tweaks to the code from the compiler are necessary 
> to work around limited support for the {{reflect}} and {{database/sql 
> packages}}.
> In general, Thrift can work with TinyGo, but until TinyGo gains more complete 
> support for the standard library it does require a compiler flag and 
> excluding a number of features of the Thrift Go library.
> Initial support for TinyGo is found here: 
> [https://github.com/bgould/thrift/tree/fc2f380a2a390860160df851e9a9698f8e3c66f4]
> However I have the following questions about the best way to proceed:
>  # Should TinyGo support be implemented in the compiler via a flag on the Go 
> generator that eliminates references to packages unsupported by TinyGo such 
> as reflect and database/sql from the generated code?  This would be similar 
> in concept I think to the -android option to the Java generator. 
> Alternatively, should a separate generator altogether be added, in the same 
> way that Java and JavaME are separate generators in Thrift?  For reference, 
> the scope of the changes to the Go generator for supporting TinyGo are 
> roughly this - 
> [https://github.com/bgould/thrift/commit/f1a57bf94731a262b68d5a519bcbbb4c8c303a23#diff-36ef31e670e3df20e286373dfb7ecc23]
>  # Similarly, the changes in the Thrift library can mostly be implemented by 
> adding build tags to exclude unsupported transports etc when compiling for 
> TinyGo (the TinyGo compiler sets a {{tinygo}} build tag automatically for all 
> TinyGo builds).  It would also be feasible to maintain a separate library 
> that is explicitly compatible with TinyGo.  Again, the analogy of the 
> distinction between Java/Android and Java/JavaME applies here I think.  The 
> sorts of changes necessary are like this: 
> https://github.com/bgould/thrift/commit/f1a57bf94731a262b68d5a519bcbbb4c8c303a23#diff-90f0f50bdfa55c6a4a1d53580c103ae0
> The main reason I am asking these questions is that I would really like to 
> land this feature, and the same time want to make sure it does not create 
> undue burden on Thrift maintainers working on supporting the standard Go 
> implementation.  Personally I think I would lean toward using the "Android

[jira] [Commented] (THRIFT-5205) Tag prior releases with "v" prefix for compatibility with go.mod

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17105554#comment-17105554
 ] 

Duru Can Celasun commented on THRIFT-5205:
--

I think doing "go get library@revision" only in libA would solve your problem.

> the leaf repositories cannot inherit this restriction since it's not a 
> constraint that Go modules can follow

Are you sure? I'm not aware of anything in the module spec that says this. Can 
you share a repo, even a dummy one, to reproduce this problem?

> Tag prior releases with "v" prefix for compatibility with go.mod
> 
>
> Key: THRIFT-5205
> URL: https://issues.apache.org/jira/browse/THRIFT-5205
> Project: Thrift
>  Issue Type: Wish
>  Components: Go - Library
>Affects Versions: 0.10.0, 0.11.0
>Reporter: Prashant V
>Priority: Minor
>
> Thrift 0.13.0 uses the tag "v0.13.0", while prior releases do not have the 
> "v" prefix. Is it possible to add an additional tag "v0.10.0", "v0.11.0", etc 
> for older releases so that Go modules works correctly with them, see 
> [https://github.com/golang/go/issues/32945]
>  
> We have some projects that use older versions and can't update due to the 
> breaking changes where ctx was added as a parameter, so need to use old 
> versions, but would still like to use go.mod.
>  
> Adding additional tags (the old ones should still be valid) would help 
> unblock usage of Go modules.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (THRIFT-5205) Tag prior releases with "v" prefix for compatibility with go.mod

[Duru Can Celasun (Jira)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-5205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duru Can Celasun updated THRIFT-5205:
-
Issue Type: Wish  (was: Task)

> Tag prior releases with "v" prefix for compatibility with go.mod
> 
>
> Key: THRIFT-5205
> URL: https://issues.apache.org/jira/browse/THRIFT-5205
> Project: Thrift
>  Issue Type: Wish
>  Components: Go - Library
>Affects Versions: 0.10.0, 0.11.0
>Reporter: Prashant V
>Priority: Blocker
>
> Thrift 0.13.0 uses the tag "v0.13.0", while prior releases do not have the 
> "v" prefix. Is it possible to add an additional tag "v0.10.0", "v0.11.0", etc 
> for older releases so that Go modules works correctly with them, see 
> [https://github.com/golang/go/issues/32945]
>  
> We have some projects that use older versions and can't update due to the 
> breaking changes where ctx was added as a parameter, so need to use old 
> versions, but would still like to use go.mod.
>  
> Adding additional tags (the old ones should still be valid) would help 
> unblock usage of Go modules.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (THRIFT-5205) Tag prior releases with "v" prefix for compatibility with go.mod

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17105132#comment-17105132
 ] 

Duru Can Celasun edited comment on THRIFT-5205 at 5/12/20, 6:34 AM:


v0.12.0 is already [tagged|https://github.com/apache/thrift/tree/v0.12.0] with 
the "v" prefix.

If you need to use older versions, you can simply use "go get" with a specific 
commit hash. For example 0.11.0 was tagged on [this 
commit|https://github.com/apache/thrift/commit/327ebb6c2b6df8bf075da02ef45a2a034e9b79ba]
 and you can simply run:

{code}
$ go get github.com/apache/thrift@327ebb6c2b6df8bf075da02ef45a2a034e9b79ba
{code}

and your go.mod file will look like this:

{code}
module github.com/example/project

go 1.14

require github.com/apache/thrift v0.0.0-20171203172758-327ebb6c2b6d // indirect
{code}


was (Author: calcifer):
v0.12.0 is already [tagged|https://github.com/apache/thrift/tree/v0.12.0] with 
the "v" prefix.

If you need to use older version, you can simply use "go get" with a specific 
commit hash. For example 0.11.0 was tagged on [this 
commit|https://github.com/apache/thrift/commit/327ebb6c2b6df8bf075da02ef45a2a034e9b79ba]
 and you can simply run:

{code}
$ go get github.com/apache/thrift@327ebb6c2b6df8bf075da02ef45a2a034e9b79ba
{code}

and your go.mod file will look like this:

{code}
module github.com/example/project

go 1.14

require github.com/apache/thrift v0.0.0-20171203172758-327ebb6c2b6d // indirect
{code}

> Tag prior releases with "v" prefix for compatibility with go.mod
> 
>
> Key: THRIFT-5205
> URL: https://issues.apache.org/jira/browse/THRIFT-5205
> Project: Thrift
>  Issue Type: Wish
>  Components: Go - Library
>Affects Versions: 0.10.0, 0.11.0
>Reporter: Prashant V
>Priority: Minor
>
> Thrift 0.13.0 uses the tag "v0.13.0", while prior releases do not have the 
> "v" prefix. Is it possible to add an additional tag "v0.10.0", "v0.11.0", etc 
> for older releases so that Go modules works correctly with them, see 
> [https://github.com/golang/go/issues/32945]
>  
> We have some projects that use older versions and can't update due to the 
> breaking changes where ctx was added as a parameter, so need to use old 
> versions, but would still like to use go.mod.
>  
> Adding additional tags (the old ones should still be valid) would help 
> unblock usage of Go modules.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (THRIFT-5205) Tag prior releases with "v" prefix for compatibility with go.mod

[Duru Can Celasun (Jira)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-5205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duru Can Celasun updated THRIFT-5205:
-
Affects Version/s: (was: 0.12.0)

> Tag prior releases with "v" prefix for compatibility with go.mod
> 
>
> Key: THRIFT-5205
> URL: https://issues.apache.org/jira/browse/THRIFT-5205
> Project: Thrift
>  Issue Type: Task
>  Components: Go - Library
>Affects Versions: 0.10.0, 0.11.0
>Reporter: Prashant V
>Priority: Blocker
>
> Thrift 0.13.0 uses the tag "v0.13.0", while prior releases do not have the 
> "v" prefix. Is it possible to add an additional tag "v0.10.0", "v0.11.0", etc 
> for older releases so that Go modules works correctly with them, see 
> [https://github.com/golang/go/issues/32945]
>  
> We have some projects that use older versions and can't update due to the 
> breaking changes where ctx was added as a parameter, so need to use old 
> versions, but would still like to use go.mod.
>  
> Adding additional tags (the old ones should still be valid) would help 
> unblock usage of Go modules.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (THRIFT-5205) Tag prior releases with "v" prefix for compatibility with go.mod

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17105132#comment-17105132
 ] 

Duru Can Celasun commented on THRIFT-5205:
--

v0.12.0 is already [tagged|https://github.com/apache/thrift/tree/v0.12.0] with 
the "v" prefix.

If you need to use older version, you can simply use "go get" with a specific 
commit hash. For example 0.11.0 was tagged on [this 
commit|https://github.com/apache/thrift/commit/327ebb6c2b6df8bf075da02ef45a2a034e9b79ba]
 and you can simply run:

{code}
$ go get github.com/apache/thrift@327ebb6c2b6df8bf075da02ef45a2a034e9b79ba
{code}

and your go.mod file will look like this:

{code}
module github.com/example/project

go 1.14

require github.com/apache/thrift v0.0.0-20171203172758-327ebb6c2b6d // indirect
{code}

> Tag prior releases with "v" prefix for compatibility with go.mod
> 
>
> Key: THRIFT-5205
> URL: https://issues.apache.org/jira/browse/THRIFT-5205
> Project: Thrift
>  Issue Type: Task
>  Components: Go - Library
>Affects Versions: 0.10.0, 0.11.0, 0.12.0
>Reporter: Prashant V
>Priority: Blocker
>
> Thrift 0.13.0 uses the tag "v0.13.0", while prior releases do not have the 
> "v" prefix. Is it possible to add an additional tag "v0.10.0", "v0.11.0", etc 
> for older releases so that Go modules works correctly with them, see 
> [https://github.com/golang/go/issues/32945]
>  
> We have some projects that use older versions and can't update due to the 
> breaking changes where ctx was added as a parameter, so need to use old 
> versions, but would still like to use go.mod.
>  
> Adding additional tags (the old ones should still be valid) would help 
> unblock usage of Go modules.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (THRIFT-5205) Tag prior releases with "v" prefix for compatibility with go.mod

[Duru Can Celasun (Jira)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-5205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duru Can Celasun updated THRIFT-5205:
-
Priority: Minor  (was: Blocker)

> Tag prior releases with "v" prefix for compatibility with go.mod
> 
>
> Key: THRIFT-5205
> URL: https://issues.apache.org/jira/browse/THRIFT-5205
> Project: Thrift
>  Issue Type: Wish
>  Components: Go - Library
>Affects Versions: 0.10.0, 0.11.0
>Reporter: Prashant V
>Priority: Minor
>
> Thrift 0.13.0 uses the tag "v0.13.0", while prior releases do not have the 
> "v" prefix. Is it possible to add an additional tag "v0.10.0", "v0.11.0", etc 
> for older releases so that Go modules works correctly with them, see 
> [https://github.com/golang/go/issues/32945]
>  
> We have some projects that use older versions and can't update due to the 
> breaking changes where ctx was added as a parameter, so need to use old 
> versions, but would still like to use go.mod.
>  
> Adding additional tags (the old ones should still be valid) would help 
> unblock usage of Go modules.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (THRIFT-5164) Go middleware support

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17094199#comment-17094199
 ] 

Duru Can Celasun commented on THRIFT-5164:
--

I use something very similar with opencensus and it's definitely a good idea to 
have it upstream. Go ahead and send a PR :) 

> Go middleware support
> -
>
> Key: THRIFT-5164
> URL: https://issues.apache.org/jira/browse/THRIFT-5164
> Project: Thrift
>  Issue Type: Improvement
>  Components: Go - Library
>Reporter: Yuxuan Wang
>Assignee: Duru Can Celasun
>Priority: Major
>  Labels: Breaking-Change
> Fix For: 0.14.0
>
>
> I saw that this idea was discussed before in THRIFT-4553, but want to reopen 
> the discussion to see if there's a change of mind.
> We (Reddit) recently implemented TProcessor level middleware support in our 
> Baseplate.go library, and we think that our implementation is generic enough 
> that it might make sense to contribute that into the thrift library. The 
> related implementation are all in this file: 
> https://github.com/reddit/baseplate.go/blob/4225e42dc8dde56b222ac7ea3a4ff63aa726f6a6/thriftbp/middlewares.go
> https://github.com/reddit/baseplate.go/blob/4225e42dc8dde56b222ac7ea3a4ff63aa726f6a6/tracing/middlewares.go#L40-L64
>  is an example of how a tracing middleware is implemented.
> If we think that's a good idea, then we can contribute that into thrift repo 
> (with renames, of course). One implementation detail I'm not sure is that 
> whether we want to expand the TProcessor interface to also include 
> ProcessorMap and AddToProcessorMap, or do we want to keep the two iinterfaces 
> separate.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (THRIFT-5179) Thrift compiler will generate wrong code if IDL struct's name is 'a' or 'b'

[Duru Can Celasun (Jira)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-5179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duru Can Celasun resolved THRIFT-5179.
--
Fix Version/s: 0.14.0
   Resolution: Fixed

> Thrift compiler will generate wrong code if IDL struct's name is 'a' or  'b'
> 
>
> Key: THRIFT-5179
> URL: https://issues.apache.org/jira/browse/THRIFT-5179
> Project: Thrift
>  Issue Type: Bug
>  Components: C++ - Compiler
>Reporter: Zezeng Wang
>Assignee: Zezeng Wang
>Priority: Minor
> Fix For: 0.14.0
>
>
> test.thrift file is as below:
> struct a {
>  1: string name,
>  2: double price
> }
> struct b {
>  1: i8 size,
>  2: i32 seq
> }
> struct a1 {
>  1: i8 size,
>  2: i32 seq
> }
> struct a2 {
>  1: i8 size,
>  2: i32 seq
> }
> When struct is named as 'a' or 'b' will throw compile errors as below:
> In file included from test_constants.h:10:0,
>  from test_constants.cpp:7:
> test_types.h:76:17: error: ‘a’ is not a type
>  void swap(a &a, a &b);
>  ^
> In file included from test_types.cpp:7:0:
> test_types.h:76:17: error: ‘a’ is not a type
>  void swap(a &a, a &b);
>  ^
> test_types.cpp:102:17: error: ‘a’ is not a type
>  void swap(a &a, a &b) {
>  ^
> test_types.cpp: In function ‘void swap(a&, int&)’:
> test_types.cpp:104:18: error: request for member ‘name’ in ‘b’, which is of 
> non-class type ‘int’
>  swap(a.name, b.name);
>  ^~~~
> test_types.cpp:105:19: error: request for member ‘price’ in ‘b’, which is of 
> non-class type ‘int’
>  swap(a.price, b.price);
>  ^
> test_types.cpp:106:21: error: request for member ‘__isset’ in ‘b’, which is 
> of non-class type ‘int’
>  swap(a.__isset, b.__isset);
>  ^~~



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (THRIFT-5164) Go middleware support

[Duru Can Celasun (Jira)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-5164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duru Can Celasun resolved THRIFT-5164.
--
Fix Version/s: 0.14.0
   Resolution: Fixed

> Go middleware support
> -
>
> Key: THRIFT-5164
> URL: https://issues.apache.org/jira/browse/THRIFT-5164
> Project: Thrift
>  Issue Type: Improvement
>  Components: Go - Library
>Reporter: Yuxuan Wang
>Assignee: Duru Can Celasun
>Priority: Major
>  Labels: Breaking-Change
> Fix For: 0.14.0
>
>
> I saw that this idea was discussed before in THRIFT-4553, but want to reopen 
> the discussion to see if there's a change of mind.
> We (Reddit) recently implemented TProcessor level middleware support in our 
> Baseplate.go library, and we think that our implementation is generic enough 
> that it might make sense to contribute that into the thrift library. The 
> related implementation are all in this file: 
> https://github.com/reddit/baseplate.go/blob/4225e42dc8dde56b222ac7ea3a4ff63aa726f6a6/thriftbp/middlewares.go
> https://github.com/reddit/baseplate.go/blob/4225e42dc8dde56b222ac7ea3a4ff63aa726f6a6/tracing/middlewares.go#L40-L64
>  is an example of how a tracing middleware is implemented.
> If we think that's a good idea, then we can contribute that into thrift repo 
> (with renames, of course). One implementation detail I'm not sure is that 
> whether we want to expand the TProcessor interface to also include 
> ProcessorMap and AddToProcessorMap, or do we want to keep the two iinterfaces 
> separate.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (THRIFT-5184) D: WebSocket Server Transport Fix for Firefox

[Duru Can Celasun (Jira)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-5184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duru Can Celasun resolved THRIFT-5184.
--
Resolution: Fixed

> D: WebSocket Server Transport Fix for Firefox
> -
>
> Key: THRIFT-5184
> URL: https://issues.apache.org/jira/browse/THRIFT-5184
> Project: Thrift
>  Issue Type: Bug
>  Components: D - Library
>Affects Versions: 0.14.0
>Reporter: James Lacey
>Assignee: James Lacey
>Priority: Major
> Fix For: 0.14.0
>
>
> When establishing a WebSocket connection, Firefox sends Connection: 
> keep-alive, Upgrade instead of just Connection: Upgrade. Check to see if 
> Upgrade is in the header instead of checking to see if it is the entire 
> header value.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Assigned] (THRIFT-5164) Go middleware support

[Duru Can Celasun (Jira)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-5164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duru Can Celasun reassigned THRIFT-5164:


Assignee: Duru Can Celasun

> Go middleware support
> -
>
> Key: THRIFT-5164
> URL: https://issues.apache.org/jira/browse/THRIFT-5164
> Project: Thrift
>  Issue Type: Improvement
>  Components: Go - Library
>Reporter: Yuxuan Wang
>Assignee: Duru Can Celasun
>Priority: Major
>  Labels: Breaking-Change
>
> I saw that this idea was discussed before in THRIFT-4553, but want to reopen 
> the discussion to see if there's a change of mind.
> We (Reddit) recently implemented TProcessor level middleware support in our 
> Baseplate.go library, and we think that our implementation is generic enough 
> that it might make sense to contribute that into the thrift library. The 
> related implementation are all in this file: 
> https://github.com/reddit/baseplate.go/blob/4225e42dc8dde56b222ac7ea3a4ff63aa726f6a6/thriftbp/middlewares.go
> https://github.com/reddit/baseplate.go/blob/4225e42dc8dde56b222ac7ea3a4ff63aa726f6a6/tracing/middlewares.go#L40-L64
>  is an example of how a tracing middleware is implemented.
> If we think that's a good idea, then we can contribute that into thrift repo 
> (with renames, of course). One implementation detail I'm not sure is that 
> whether we want to expand the TProcessor interface to also include 
> ProcessorMap and AddToProcessorMap, or do we want to keep the two iinterfaces 
> separate.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (THRIFT-4282) StressTestNonBlocking is disabled in Appveyor as it is unstable on Windows in general

[Duru Can Celasun (Jira)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-4282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duru Can Celasun resolved THRIFT-4282.
--
Fix Version/s: 0.14.0
   Resolution: Resolved

> StressTestNonBlocking is disabled in Appveyor as it is unstable on Windows in 
> general
> -
>
> Key: THRIFT-4282
> URL: https://issues.apache.org/jira/browse/THRIFT-4282
> Project: Thrift
>  Issue Type: Bug
>  Components: C++ - Library
>Affects Versions: 0.10.0
> Environment: Windows, Appveyor
>Reporter: James E. King III
>Priority: Major
> Fix For: 0.14.0
>
>
> I have not been able to complete most of my local builds including 
> StressTestNonBlocking because the test fails.  It is disabled in AppVeyor so 
> the builds will pass.  We need this test to be fixed so we can enable it for 
> CI builds again.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (THRIFT-5171) Fix maven-ant-tasks to use HTTPS instead of HTTP

[Duru Can Celasun (Jira)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-5171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duru Can Celasun resolved THRIFT-5171.
--
Fix Version/s: 0.14.0
   Resolution: Fixed

> Fix maven-ant-tasks to use HTTPS instead of HTTP
> 
>
> Key: THRIFT-5171
> URL: https://issues.apache.org/jira/browse/THRIFT-5171
> Project: Thrift
>  Issue Type: Bug
>  Components: Test Suite
>Reporter: Kengo Seki
>Assignee: Kengo Seki
>Priority: Major
> Fix For: 0.14.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> I ran {{make check}} in the lib/json directory and came across the following 
> error.
> {code:java}
> $ ./bootstrap.sh
> $ ./configure
> $ make
> $ cd lib/json
> $ make check
> (snip)
> mvn.init:
> [artifact:dependencies] Downloading: 
> com/github/fge/json-schema-validator/2.2.6/json-schema-validator-2.2.6.pom 
> from repository central at http://repo1.maven.org/maven2
> [artifact:dependencies] Error transferring file: Server returned HTTP 
> response code: 501 for URL: 
> http://repo1.maven.org/maven2/com/github/fge/json-schema-validator/2.2.6/json-schema-validator-2.2.6.pom
> [artifact:dependencies] [WARNING] Unable to get resource 
> 'com.github.fge:json-schema-validator:pom:2.2.6' from repository central 
> (http://repo1.maven.org/maven2): Error transferring file: Server returned 
> HTTP response code: 501 for URL: 
> http://repo1.maven.org/maven2/com/github/fge/json-schema-validator/2.2.6/json-schema-validator-2.2.6.pom
> [artifact:dependencies] Downloading: 
> com/github/fge/json-schema-validator/2.2.6/json-schema-validator-2.2.6.jar 
> from repository central at http://repo1.maven.org/maven2
> [artifact:dependencies] Error transferring file: Server returned HTTP 
> response code: 501 for URL: 
> http://repo1.maven.org/maven2/com/github/fge/json-schema-validator/2.2.6/json-schema-validator-2.2.6.jar
> [artifact:dependencies] [WARNING] Unable to get resource 
> 'com.github.fge:json-schema-validator:jar:2.2.6' from repository central 
> (http://repo1.maven.org/maven2): Error transferring file: Server returned 
> HTTP response code: 501 for URL: 
> http://repo1.maven.org/maven2/com/github/fge/json-schema-validator/2.2.6/json-schema-validator-2.2.6.jar
> [artifact:dependencies] An error has occurred while processing the Maven 
> artifact tasks.
> [artifact:dependencies]  Diagnosis:
> [artifact:dependencies] 
> [artifact:dependencies] Unable to resolve artifact: Missing:
> [artifact:dependencies] --
> [artifact:dependencies] 1) com.github.fge:json-schema-validator:jar:2.2.6
> [artifact:dependencies] 
> [artifact:dependencies]   Try downloading the file manually from the project 
> website.
> [artifact:dependencies] 
> [artifact:dependencies]   Then, install it using the command: 
> [artifact:dependencies]   mvn install:install-file 
> -DgroupId=com.github.fge -DartifactId=json-schema-validator -Dversion=2.2.6 
> -Dpackaging=jar -Dfile=/path/to/file
> [artifact:dependencies] 
> [artifact:dependencies]   Alternatively, if you host your own repository you 
> can deploy the file there: 
> [artifact:dependencies]   mvn deploy:deploy-file -DgroupId=com.github.fge 
> -DartifactId=json-schema-validator -Dversion=2.2.6 -Dpackaging=jar 
> -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
> [artifact:dependencies] 
> [artifact:dependencies]   Path to dependency: 
> [artifact:dependencies]   1) org.apache.maven:super-pom:pom:2.0
> [artifact:dependencies]   2) 
> com.github.fge:json-schema-validator:jar:2.2.6
> [artifact:dependencies] 
> [artifact:dependencies] --
> [artifact:dependencies] 1 required artifact is missing.
> [artifact:dependencies] 
> [artifact:dependencies] for artifact: 
> [artifact:dependencies]   org.apache.maven:super-pom:pom:2.0
> [artifact:dependencies] 
> [artifact:dependencies] from the specified remote repositories:
> [artifact:dependencies]   central (http://repo1.maven.org/maven2)
> [artifact:dependencies] 
> [artifact:dependencies] 
> BUILD FAILED
> /home/sekikn/repos/thrift/lib/json/test/build.xml:116: Unable to resolve 
> artifact: Missing:
> --
> 1) com.github.fge:json-schema-validator:jar:2.2.6
>   Try downloading the file manually from the project website.
>   Then, install it using the command: 
>   mvn install:install-file -DgroupId=com.github.fge 
> -DartifactId=json-schema-validator -Dversion=2.2.6 -Dpackaging=jar 
> -Dfile=/path/to/file
>   Alternatively, if you host your own repository you can deploy the file 
> there: 
>   mvn deploy:deploy-file -DgroupId=com.github.fge 
> -DartifactId=json-schema-validator -Dversion=2.2.6 -Dpackaging=jar 
> -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
>   Path to dependency: 
>   1) org.apache.maven:super-pom:pom:2.0
>   2) com.github.fge:jso

[jira] [Commented] (THRIFT-5164) Go middleware support

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17083083#comment-17083083
 ] 

Duru Can Celasun commented on THRIFT-5164:
--

I agree that middleware isn't exactly transferable between languages.

[~fishywang] your work overlaps with [this 
PR|https://github.com/apache/thrift/pull/1992] but judging by the baseplate 
repo I like your version better so a PR would definitely be appreciated.

> Go middleware support
> -
>
> Key: THRIFT-5164
> URL: https://issues.apache.org/jira/browse/THRIFT-5164
> Project: Thrift
>  Issue Type: Improvement
>  Components: Go - Library
>Reporter: Yuxuan Wang
>Priority: Major
>
> I saw that this idea was discussed before in THRIFT-4553, but want to reopen 
> the discussion to see if there's a change of mind.
> We (Reddit) recently implemented TProcessor level middleware support in our 
> Baseplate.go library, and we think that our implementation is generic enough 
> that it might make sense to contribute that into the thrift library. The 
> related implementation are all in this file: 
> https://github.com/reddit/baseplate.go/blob/4225e42dc8dde56b222ac7ea3a4ff63aa726f6a6/thriftbp/middlewares.go
> https://github.com/reddit/baseplate.go/blob/4225e42dc8dde56b222ac7ea3a4ff63aa726f6a6/tracing/middlewares.go#L40-L64
>  is an example of how a tracing middleware is implemented.
> If we think that's a good idea, then we can contribute that into thrift repo 
> (with renames, of course). One implementation detail I'm not sure is that 
> whether we want to expand the TProcessor interface to also include 
> ProcessorMap and AddToProcessorMap, or do we want to keep the two iinterfaces 
> separate.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (THRIFT-5164) Go middleware support

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17074391#comment-17074391
 ] 

Duru Can Celasun commented on THRIFT-5164:
--

I'm much more open to the idea today than I was back then. Your tracing 
middleware certainly looks much cleaner than what we use for tracing.

As for the interface, I'm happy to expand TProcessor for this. Please go ahead 
with the PR and I'll take a look.

> Go middleware support
> -
>
> Key: THRIFT-5164
> URL: https://issues.apache.org/jira/browse/THRIFT-5164
> Project: Thrift
>  Issue Type: Improvement
>  Components: Go - Library
>Reporter: Yuxuan Wang
>Priority: Major
>
> I saw that this idea was discussed before in THRIFT-4553, but want to reopen 
> the discussion to see if there's a change of mind.
> We (Reddit) recently implemented TProcessor level middleware support in our 
> Baseplate.go library, and we think that our implementation is generic enough 
> that it might make sense to contribute that into the thrift library. The 
> related implementation are all in this file: 
> https://github.com/reddit/baseplate.go/blob/4225e42dc8dde56b222ac7ea3a4ff63aa726f6a6/thriftbp/middlewares.go
> https://github.com/reddit/baseplate.go/blob/4225e42dc8dde56b222ac7ea3a4ff63aa726f6a6/tracing/middlewares.go#L40-L64
>  is an example of how a tracing middleware is implemented.
> If we think that's a good idea, then we can contribute that into thrift repo 
> (with renames, of course). One implementation detail I'm not sure is that 
> whether we want to expand the TProcessor interface to also include 
> ProcessorMap and AddToProcessorMap, or do we want to keep the two iinterfaces 
> separate.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (THRIFT-4710) Move all ASF CMS website content to GitHub

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17046188#comment-17046188
 ] 

Duru Can Celasun commented on THRIFT-4710:
--

That's good to know, thanks. We should stick to supported ways to reduce 
maintenance burden as much as possible.  Though I do remember Apache Airflow 
using readthedocs until recently, so it might already be supported by INFRA.

> Move all ASF CMS website content to GitHub
> --
>
> Key: THRIFT-4710
> URL: https://issues.apache.org/jira/browse/THRIFT-4710
> Project: Thrift
>  Issue Type: Documentation
>  Components: Documentation, Website
>Affects Versions: 0.13.0
>Reporter: James E. King III
>Assignee: Duru Can Celasun
>Priority: Major
>
> Recent changes in Apache infrastructure has made it impossible to use the 
> existing ASF CMS system to manage the Apache Thrift web site.  We need to 
> extract and move the content somewhere else.  For reference, see:
> https://issues.apache.org/jira/browse/INFRA-17519
> This is a bunch of work nobody was expecting to have to do.
> My recommendation is to put the documentation into the "docs/" (or leave it 
> in "doc/", perhaps, it if works) and use https://readthedocs.org/ to create 
> the documentation web site.  Documentation updates can be pushed into the 
> repository with {{`[ci skip]`}} or maybe we teach GitHub and/or our Appveyor 
> and Travis to do nothing on pull requests that only contain updates to 
> markdown and/or rst files.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (THRIFT-4710) Move all ASF CMS website content to GitHub

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17045922#comment-17045922
 ] 

Duru Can Celasun commented on THRIFT-4710:
--

That can all be figured out later, once the new website is up and running. The 
more important work of building API docs on Travis with every commit can happen 
in parallel.

> Move all ASF CMS website content to GitHub
> --
>
> Key: THRIFT-4710
> URL: https://issues.apache.org/jira/browse/THRIFT-4710
> Project: Thrift
>  Issue Type: Documentation
>  Components: Documentation, Website
>Affects Versions: 0.13.0
>Reporter: James E. King III
>Assignee: Duru Can Celasun
>Priority: Major
>
> Recent changes in Apache infrastructure has made it impossible to use the 
> existing ASF CMS system to manage the Apache Thrift web site.  We need to 
> extract and move the content somewhere else.  For reference, see:
> https://issues.apache.org/jira/browse/INFRA-17519
> This is a bunch of work nobody was expecting to have to do.
> My recommendation is to put the documentation into the "docs/" (or leave it 
> in "doc/", perhaps, it if works) and use https://readthedocs.org/ to create 
> the documentation web site.  Documentation updates can be pushed into the 
> repository with {{`[ci skip]`}} or maybe we teach GitHub and/or our Appveyor 
> and Travis to do nothing on pull requests that only contain updates to 
> markdown and/or rst files.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (THRIFT-4710) Move all ASF CMS website content to GitHub

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17045902#comment-17045902
 ] 

Duru Can Celasun commented on THRIFT-4710:
--

I don't personally have any plans for it but I'm happy to accept contributions 
to auto generate API docs for specific languages.

> Move all ASF CMS website content to GitHub
> --
>
> Key: THRIFT-4710
> URL: https://issues.apache.org/jira/browse/THRIFT-4710
> Project: Thrift
>  Issue Type: Documentation
>  Components: Documentation, Website
>Affects Versions: 0.13.0
>Reporter: James E. King III
>Assignee: Duru Can Celasun
>Priority: Major
>
> Recent changes in Apache infrastructure has made it impossible to use the 
> existing ASF CMS system to manage the Apache Thrift web site.  We need to 
> extract and move the content somewhere else.  For reference, see:
> https://issues.apache.org/jira/browse/INFRA-17519
> This is a bunch of work nobody was expecting to have to do.
> My recommendation is to put the documentation into the "docs/" (or leave it 
> in "doc/", perhaps, it if works) and use https://readthedocs.org/ to create 
> the documentation web site.  Documentation updates can be pushed into the 
> repository with {{`[ci skip]`}} or maybe we teach GitHub and/or our Appveyor 
> and Travis to do nothing on pull requests that only contain updates to 
> markdown and/or rst files.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (THRIFT-5113) Web-based developer and user chat?

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17045882#comment-17045882
 ] 

Duru Can Celasun commented on THRIFT-5113:
--

I've been slowly working on a new version of the website that unifies various 
bits of documentation here: https://issues.apache.org/jira/browse/THRIFT-4710 
It's quite stalled at this point, but I'd like to get back to it eventually. 
Contributions are welcome.

I agree that the current state of documentation is somewhere between lacking 
and abysmal and makes the project less approachable. However, nobody assigns 
tasks in thrift, so any improvements must come from volunteers and so far 
nobody has really stepped up to the (admittedly monumental) task.

I also generally agree about mailing lists. I grew up with them, but their 
suitability for attracting new talent decreases every day. I'd personally be 
happy to suggest the ASF Slack as the official communication medium on the 
website, but that should be approved by at least a few more PMC members.

> Web-based developer and user chat?
> --
>
> Key: THRIFT-5113
> URL: https://issues.apache.org/jira/browse/THRIFT-5113
> Project: Thrift
>  Issue Type: Wish
>Reporter: Mario Emmenlauer
>Priority: Minor
>
> I think it would be very helpful if there where a developer chat, where users 
> and developers could ask questions and get (sometimes) a response with 
> shorter turnaround times and less overhead. Is this something thrift 
> developers could consider?
> An often-used web-based chat with little overhead that integrates well with 
> github is [https://gitter.im/]. There are already a significant number of 
> Apache projects present:
>  * [https://gitter.im/apache/home]
> Relates to THRIFT-5112



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (THRIFT-5107) Travis build fails with missing Python 3.3 or newer?

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17042212#comment-17042212
 ] 

Duru Can Celasun commented on THRIFT-5107:
--

Nice find! Mind sending in a PR?

> Travis build fails with missing Python 3.3 or newer?
> 
>
> Key: THRIFT-5107
> URL: https://issues.apache.org/jira/browse/THRIFT-5107
> Project: Thrift
>  Issue Type: Improvement
>Reporter: Mario Emmenlauer
>Priority: Major
>
> The travis tests seem to fail because of a missing Python error. See 
> [https://travis-ci.org/apache/thrift/builds/653469766?utm_source=github_status&utm_medium=notification]
> I would like to help fix this, but I do not understand how travis docker 
> images are set or created. Can someone help?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (THRIFT-5075) Backport fixes for CVE-2019-0205 to (Java) 0.9.3-1 version

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17023641#comment-17023641
 ] 

Duru Can Celasun commented on THRIFT-5075:
--

I don't think it's a good idea either. Which specific projects are still 
depending on a half a decade old version of thrift and what exactly is blocking 
them from upgrading to a newer version?

> Backport fixes for CVE-2019-0205 to (Java) 0.9.3-1 version
> --
>
> Key: THRIFT-5075
> URL: https://issues.apache.org/jira/browse/THRIFT-5075
> Project: Thrift
>  Issue Type: Bug
>Reporter: Laurent Goujon
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Similar to THRIFT-4506, would it be possible to backport fixes for 
> CVE-2019-0205 to 0.9.x branch. There are still several projects still relying 
> on 0.9.3-1, and the vulnerability seems to impact them as well.
> I believe the fix for Java was part of THRIFT-4024



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (THRIFT-5069) Go: TDserializer is not resource pool friendly

[Duru Can Celasun (Jira)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-5069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duru Can Celasun resolved THRIFT-5069.
--
Fix Version/s: 0.14.0
   Resolution: Fixed

> Go: TDserializer is not resource pool friendly
> --
>
> Key: THRIFT-5069
> URL: https://issues.apache.org/jira/browse/THRIFT-5069
> Project: Thrift
>  Issue Type: Improvement
>  Components: Go - Library
>Reporter: Yuxuan Wang
>Priority: Major
> Fix For: 0.14.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Currently TSerializer is resource pool friendly (see 
> [here|https://github.com/reddit/baseplate.go/blob/7b73f185eacd319a018df85d683fb2c29b50e2a9/events/events.go#L105-L111]
>  for an example), but TDeserializer is not. When putting a TDeserializer back 
> into resource pool, some extra works need to be done:
> {code:go}
> defer func() {
>   deserializer.Transport.(*thrift.TMemoryBuffer).Reset()
>   deserializerPool.Put(deserializer)
> }()
> {code}
> If we change the type of TDeserializer.Transport to *TMemoryBuffer, and also 
> call Transport.Reset() at the beginning of Read and ReadString (we already do 
> both in TSerializer), it will make it more resource pool friendly.
> This will be a breaking change, though.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (THRIFT-5069) Go: TDserializer is not resource pool friendly

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17018526#comment-17018526
 ] 

Duru Can Celasun commented on THRIFT-5069:
--

OK, sounds good. Let's include that in this PR.

> Go: TDserializer is not resource pool friendly
> --
>
> Key: THRIFT-5069
> URL: https://issues.apache.org/jira/browse/THRIFT-5069
> Project: Thrift
>  Issue Type: Improvement
>  Components: Go - Library
>Reporter: Yuxuan Wang
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Currently TSerializer is resource pool friendly (see 
> [here|https://github.com/reddit/baseplate.go/blob/7b73f185eacd319a018df85d683fb2c29b50e2a9/events/events.go#L105-L111]
>  for an example), but TDeserializer is not. When putting a TDeserializer back 
> into resource pool, some extra works need to be done:
> {code:go}
> defer func() {
>   deserializer.Transport.(*thrift.TMemoryBuffer).Reset()
>   deserializerPool.Put(deserializer)
> }()
> {code}
> If we change the type of TDeserializer.Transport to *TMemoryBuffer, and also 
> call Transport.Reset() at the beginning of Read and ReadString (we already do 
> both in TSerializer), it will make it more resource pool friendly.
> This will be a breaking change, though.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (THRIFT-5069) Go: TDserializer is not resource pool friendly

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17018163#comment-17018163
 ] 

Duru Can Celasun commented on THRIFT-5069:
--

[~fishywang] it could be useful, depends on what exactly you have in mind. Is 
it just a wrapper around sync.Pool?

> Go: TDserializer is not resource pool friendly
> --
>
> Key: THRIFT-5069
> URL: https://issues.apache.org/jira/browse/THRIFT-5069
> Project: Thrift
>  Issue Type: Improvement
>  Components: Go - Library
>Reporter: Yuxuan Wang
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Currently TSerializer is resource pool friendly (see 
> [here|https://github.com/reddit/baseplate.go/blob/7b73f185eacd319a018df85d683fb2c29b50e2a9/events/events.go#L105-L111]
>  for an example), but TDeserializer is not. When putting a TDeserializer back 
> into resource pool, some extra works need to be done:
> {code:go}
> defer func() {
>   deserializer.Transport.(*thrift.TMemoryBuffer).Reset()
>   deserializerPool.Put(deserializer)
> }()
> {code}
> If we change the type of TDeserializer.Transport to *TMemoryBuffer, and also 
> call Transport.Reset() at the beginning of Read and ReadString (we already do 
> both in TSerializer), it will make it more resource pool friendly.
> This will be a breaking change, though.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (THRIFT-5068) CI is broken due to http://repo1.maven.org

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17017960#comment-17017960
 ] 

Duru Can Celasun commented on THRIFT-5068:
--

Thanks for the PR! Travis is all green now.

> CI is broken due to http://repo1.maven.org
> --
>
> Key: THRIFT-5068
> URL: https://issues.apache.org/jira/browse/THRIFT-5068
> Project: Thrift
>  Issue Type: Bug
>  Components: Build Process
>Reporter: Duru Can Celasun
>Priority: Major
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Upstream has 
> [removed|https://support.sonatype.com/hc/en-us/articles/360041287334] support 
> for HTTP based access. I've 
> [updated|https://github.com/apache/thrift/commit/70c4e7a7c7b2a2b4146372868702b7ea0d143e05]
>  all references I could find, but the build is [still 
> broken|https://travis-ci.org/apache/thrift/builds/637642594] as we somehow 
> still have references to the HTTP endpoint.
> [~jensg] any ideas?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (THRIFT-5068) CI is broken due to http://repo1.maven.org

[Duru Can Celasun (Jira)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-5068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duru Can Celasun resolved THRIFT-5068.
--
Resolution: Fixed

> CI is broken due to http://repo1.maven.org
> --
>
> Key: THRIFT-5068
> URL: https://issues.apache.org/jira/browse/THRIFT-5068
> Project: Thrift
>  Issue Type: Bug
>  Components: Build Process
>Reporter: Duru Can Celasun
>Priority: Major
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Upstream has 
> [removed|https://support.sonatype.com/hc/en-us/articles/360041287334] support 
> for HTTP based access. I've 
> [updated|https://github.com/apache/thrift/commit/70c4e7a7c7b2a2b4146372868702b7ea0d143e05]
>  all references I could find, but the build is [still 
> broken|https://travis-ci.org/apache/thrift/builds/637642594] as we somehow 
> still have references to the HTTP endpoint.
> [~jensg] any ideas?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (THRIFT-5068) CI is broken due to http://repo1.maven.org

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17017881#comment-17017881
 ] 

Duru Can Celasun commented on THRIFT-5068:
--

Thanks, that does seem to be the cause. I won't have time to investigate this 
in the next few weeks, so PRs are appreciated.

> CI is broken due to http://repo1.maven.org
> --
>
> Key: THRIFT-5068
> URL: https://issues.apache.org/jira/browse/THRIFT-5068
> Project: Thrift
>  Issue Type: Bug
>  Components: Build Process
>Reporter: Duru Can Celasun
>Priority: Major
>
> Upstream has 
> [removed|https://support.sonatype.com/hc/en-us/articles/360041287334] support 
> for HTTP based access. I've 
> [updated|https://github.com/apache/thrift/commit/70c4e7a7c7b2a2b4146372868702b7ea0d143e05]
>  all references I could find, but the build is [still 
> broken|https://travis-ci.org/apache/thrift/builds/637642594] as we somehow 
> still have references to the HTTP endpoint.
> [~jensg] any ideas?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (THRIFT-5068) CI is broken due to http://repo1.maven.org

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17016374#comment-17016374
 ] 

Duru Can Celasun commented on THRIFT-5068:
--

This has effected other Apache projects as well: 
https://issues.apache.org/jira/browse/THRIFT-5068?jql=summary%20~%20%22repo1.maven.org*%22%20OR%20description%20~%20%22repo1.maven.org*%22%20ORDER%20BY%20created%20DESC

> CI is broken due to http://repo1.maven.org
> --
>
> Key: THRIFT-5068
> URL: https://issues.apache.org/jira/browse/THRIFT-5068
> Project: Thrift
>  Issue Type: Bug
>  Components: Build Process
>Reporter: Duru Can Celasun
>Priority: Major
>
> Upstream has 
> [removed|https://support.sonatype.com/hc/en-us/articles/360041287334] support 
> for HTTP based access. I've 
> [updated|https://github.com/apache/thrift/commit/70c4e7a7c7b2a2b4146372868702b7ea0d143e05]
>  all references I could find, but the build is [still 
> broken](https://travis-ci.org/apache/thrift/builds/637642594) as we somehow 
> still have references to the HTTP endpoint.
> [~jensg] any ideas?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (THRIFT-5068) CI is broken due to http://repo1.maven.org

[Duru Can Celasun (Jira)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-5068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duru Can Celasun updated THRIFT-5068:
-
Description: 
Upstream has 
[removed|https://support.sonatype.com/hc/en-us/articles/360041287334] support 
for HTTP based access. I've 
[updated|https://github.com/apache/thrift/commit/70c4e7a7c7b2a2b4146372868702b7ea0d143e05]
 all references I could find, but the build is [still 
broken|https://travis-ci.org/apache/thrift/builds/637642594] as we somehow 
still have references to the HTTP endpoint.

[~jensg] any ideas?

  was:
Upstream has 
[removed|https://support.sonatype.com/hc/en-us/articles/360041287334] support 
for HTTP based access. I've 
[updated|https://github.com/apache/thrift/commit/70c4e7a7c7b2a2b4146372868702b7ea0d143e05]
 all references I could find, but the build is [still 
broken](https://travis-ci.org/apache/thrift/builds/637642594) as we somehow 
still have references to the HTTP endpoint.

[~jensg] any ideas?


> CI is broken due to http://repo1.maven.org
> --
>
> Key: THRIFT-5068
> URL: https://issues.apache.org/jira/browse/THRIFT-5068
> Project: Thrift
>  Issue Type: Bug
>  Components: Build Process
>Reporter: Duru Can Celasun
>Priority: Major
>
> Upstream has 
> [removed|https://support.sonatype.com/hc/en-us/articles/360041287334] support 
> for HTTP based access. I've 
> [updated|https://github.com/apache/thrift/commit/70c4e7a7c7b2a2b4146372868702b7ea0d143e05]
>  all references I could find, but the build is [still 
> broken|https://travis-ci.org/apache/thrift/builds/637642594] as we somehow 
> still have references to the HTTP endpoint.
> [~jensg] any ideas?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (THRIFT-5068) CI is broken due to http://repo1.maven.org

[Duru Can Celasun (Jira)]

Duru Can Celasun created THRIFT-5068:


 Summary: CI is broken due to http://repo1.maven.org
 Key: THRIFT-5068
 URL: https://issues.apache.org/jira/browse/THRIFT-5068
 Project: Thrift
  Issue Type: Bug
  Components: Build Process
Reporter: Duru Can Celasun


Upstream has 
[removed|https://support.sonatype.com/hc/en-us/articles/360041287334] support 
for HTTP based access. I've 
[updated|https://github.com/apache/thrift/commit/70c4e7a7c7b2a2b4146372868702b7ea0d143e05]
 all references I could find, but the build is [still 
broken](https://travis-ci.org/apache/thrift/builds/637642594) as we somehow 
still have references to the HTTP endpoint.

[~jensg] any ideas?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (THRIFT-5003) Websocket Connection in Browsers with nodejs code

[Duru Can Celasun (Jira)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-5003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duru Can Celasun resolved THRIFT-5003.
--
Resolution: Fixed

> Websocket Connection in Browsers with nodejs code
> -
>
> Key: THRIFT-5003
> URL: https://issues.apache.org/jira/browse/THRIFT-5003
> Project: Thrift
>  Issue Type: Improvement
>  Components: Node.js - Library, TypeScript - Library
>Affects Versions: 0.13.0
> Environment: Webpack 4.41.2
> Thrift 0.13.0
> NodeJS thrift lib required in browser env
>Reporter: Eugen Kandakov
>Assignee: Eugen Kandakov
>Priority: Major
>  Labels: Browser, JavaScript, WebSocket, webpack
> Fix For: 0.14.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> After some changes to the ws_connection.js file in the nodejs code, I could 
> create a version of the WSConnection, createWSConnection and createWSClient 
> which is able to run similar code of WebSocket connections in the browser and 
> NodeJS
> Solution is package, `{{isomorphic-ws` which provides the proper Websocket 
> libs depending on the env (browser or node)}}
>  
> Testable Repo with thrift branch from PR: 
> [https://github.com/alabama/thrift-testing]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (THRIFT-5049) Process panic in generated processor

[Duru Can Celasun (Jira)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-5049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duru Can Celasun updated THRIFT-5049:
-
Issue Type: Wish  (was: Improvement)

> Process panic in generated processor
> 
>
> Key: THRIFT-5049
> URL: https://issues.apache.org/jira/browse/THRIFT-5049
> Project: Thrift
>  Issue Type: Wish
>  Components: Go - Compiler
>Affects Versions: 0.13.0
>Reporter: Serhii
>Priority: Major
>
> Hello. In current version go generator doesn't provide functionality to 
> handle panic in generated processor. You can pass defer function which will 
> write TApplicationException to output protocol there 
> https://github.com/apache/thrift/blob/0.13.0/compiler/cpp/src/thrift/generate/t_go_generator.cc#L2787.
>  
> In current version on processor we need to process panic in custom server to 
> send NewTApplicationException to clients and it is very uncomfortable.
> Thanks.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (THRIFT-5049) Process panic in generated processor

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17008676#comment-17008676
 ] 

Duru Can Celasun commented on THRIFT-5049:
--

The library - correctly - doesn't handle panics caused by the user's code. If 
there are panics _in the library_ though, please point them out and we'll fix 
them.

> Process panic in generated processor
> 
>
> Key: THRIFT-5049
> URL: https://issues.apache.org/jira/browse/THRIFT-5049
> Project: Thrift
>  Issue Type: Improvement
>  Components: Go - Compiler
>Affects Versions: 0.13.0
>Reporter: Serhii
>Priority: Major
>
> Hello. In current version go generator doesn't provide functionality to 
> handle panic in generated processor. You can pass defer function which will 
> write TApplicationException to output protocol there 
> https://github.com/apache/thrift/blob/0.13.0/compiler/cpp/src/thrift/generate/t_go_generator.cc#L2787.
>  
> In current version on processor we need to process panic in custom server to 
> send NewTApplicationException to clients and it is very uncomfortable.
> Thanks.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (THRIFT-5049) Process panic in generated processor

[Duru Can Celasun (Jira)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-5049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duru Can Celasun updated THRIFT-5049:
-
Priority: Minor  (was: Major)

> Process panic in generated processor
> 
>
> Key: THRIFT-5049
> URL: https://issues.apache.org/jira/browse/THRIFT-5049
> Project: Thrift
>  Issue Type: Wish
>  Components: Go - Compiler
>Affects Versions: 0.13.0
>Reporter: Serhii
>Priority: Minor
>
> Hello. In current version go generator doesn't provide functionality to 
> handle panic in generated processor. You can pass defer function which will 
> write TApplicationException to output protocol there 
> https://github.com/apache/thrift/blob/0.13.0/compiler/cpp/src/thrift/generate/t_go_generator.cc#L2787.
>  
> In current version on processor we need to process panic in custom server to 
> send NewTApplicationException to clients and it is very uncomfortable.
> Thanks.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (THRIFT-5039) thrift npm package should be published from root folder

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16998999#comment-16998999
 ] 

Duru Can Celasun commented on THRIFT-5039:
--

cc [~jking]

> thrift npm package should be published from root folder
> ---
>
> Key: THRIFT-5039
> URL: https://issues.apache.org/jira/browse/THRIFT-5039
> Project: Thrift
>  Issue Type: Bug
>  Components: JavaScript - Library
>Affects Versions: 0.13.0
>Reporter: Soner Okur
>Priority: Major
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> Thrift npm package was published from js folder. Therefore, we can't build 
> our software because lack of nodejs library. Can you re-publish the package ?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (THRIFT-4995) [Rust] Use `ToSocketAddrs` for expressing network addresses

[Duru Can Celasun (Jira)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-4995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duru Can Celasun resolved THRIFT-4995.
--
Fix Version/s: 0.14.0
   Resolution: Fixed

> [Rust] Use `ToSocketAddrs` for expressing network addresses
> ---
>
> Key: THRIFT-4995
> URL: https://issues.apache.org/jira/browse/THRIFT-4995
> Project: Thrift
>  Issue Type: Improvement
>  Components: Rust - Library
>Reporter: Marcin Pajkowski
>Priority: Minor
> Fix For: 0.14.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Right now addresses must be a &str and must match format host:port. However, 
> there are no obstacles for using types bound by ToSocketAddrs trait.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (THRIFT-5046) Custom tags remove db and json tags

[Duru Can Celasun (Jira)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-5046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duru Can Celasun resolved THRIFT-5046.
--
Fix Version/s: 0.14.0
   Resolution: Fixed

> Custom tags remove db and json tags
> ---
>
> Key: THRIFT-5046
> URL: https://issues.apache.org/jira/browse/THRIFT-5046
> Project: Thrift
>  Issue Type: Improvement
>  Components: Go - Compiler
>Affects Versions: 0.13.0
>Reporter: Duru Can Celasun
>Assignee: Duru Can Celasun
>Priority: Minor
> Fix For: 0.14.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Given the IDL:
> {code}
> struct Example {
>   1: bool withTag (go.tag = "foo:\"bar\"")
>   2: bool withoutTag
> }
> {code}
> The generated code looks like:
> {code}
> type Example struct {
>   WithTag bool `thrift:"withTag,1", foo:"bar"`
>   WithoutTag bool `thrift:"withoutTag,2" db:"withoutTag" json:"withoutTag"`
> }
> {code}
> The bug is on [this 
> line|https://github.com/apache/thrift/blob/6e023df1ded255dda00eb4c041c201e66c8d1fbc/compiler/cpp/src/thrift/generate/t_go_generator.cc#L1396]
>  of the Go generator where any custom tag overwrites the existing db and json 
> tags.
> Custom tags that aren't overrides should be appended instead of replacing the 
> whole thing.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (THRIFT-5013) Use Java Objects RequireNonNull

[Duru Can Celasun (Jira)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-5013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duru Can Celasun resolved THRIFT-5013.
--
Fix Version/s: 0.14.0
   Resolution: Fixed

> Use Java Objects RequireNonNull
> ---
>
> Key: THRIFT-5013
> URL: https://issues.apache.org/jira/browse/THRIFT-5013
> Project: Thrift
>  Issue Type: Improvement
>Reporter: David Mollitor
>Assignee: David Mollitor
>Priority: Minor
> Fix For: 0.14.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> https://github.com/apache/thrift/blob/b3745eea10cde93957882df56ef21f05f5e3cf6b/compiler/cpp/src/thrift/generate/t_java_generator.cc#L1064
> https://docs.oracle.com/javase/8/docs/api/java/util/Objects.html



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (THRIFT-4710) Move all ASF CMS website content to GitHub

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16995390#comment-16995390
 ] 

Duru Can Celasun commented on THRIFT-4710:
--

{quote}Will the official ASF site be generated using tooling from the 
readthedocs.io service and updated to the ASF site (which should be fine)?
{quote}
Yes. Once the website is ready and everyone had a chance to give feedback, I'll 
contact INFRA.

> Move all ASF CMS website content to GitHub
> --
>
> Key: THRIFT-4710
> URL: https://issues.apache.org/jira/browse/THRIFT-4710
> Project: Thrift
>  Issue Type: Documentation
>  Components: Documentation, Website
>Affects Versions: 0.13.0
>Reporter: James E. King III
>Assignee: Duru Can Celasun
>Priority: Major
>
> Recent changes in Apache infrastructure has made it impossible to use the 
> existing ASF CMS system to manage the Apache Thrift web site.  We need to 
> extract and move the content somewhere else.  For reference, see:
> https://issues.apache.org/jira/browse/INFRA-17519
> This is a bunch of work nobody was expecting to have to do.
> My recommendation is to put the documentation into the "docs/" (or leave it 
> in "doc/", perhaps, it if works) and use https://readthedocs.org/ to create 
> the documentation web site.  Documentation updates can be pushed into the 
> repository with {{`[ci skip]`}} or maybe we teach GitHub and/or our Appveyor 
> and Travis to do nothing on pull requests that only contain updates to 
> markdown and/or rst files.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (THRIFT-4252) Cannot shutdown Java server when clients are still connected

[Duru Can Celasun (Jira)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-4252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duru Can Celasun resolved THRIFT-4252.
--
Fix Version/s: 0.14.0
   Resolution: Fixed

> Cannot shutdown Java server when clients are still connected
> 
>
> Key: THRIFT-4252
> URL: https://issues.apache.org/jira/browse/THRIFT-4252
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Library
>Affects Versions: 0.10.0
>Reporter: Mario Emmenlauer
>Assignee: Qinghui Xu
>Priority: Major
>  Labels: pull-request-available
> Fix For: 0.14.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> I found issue https://issues.apache.org/jira/browse/THRIFT-2441 and I believe 
> that the same problem still exists in the Java servers, and I'm affected by 
> it. Short summary: I can not shut down the Java server (neither TSimpleServer 
> nor TThreadedServer) while clients are still connected. That is pretty bad, 
> because essentially the clients are not under by control, but they can 
> essentially "block" server maintenance operations by blocking the shutdown.
> *In more detail:* I have a Java TSimpleServer runnable in a thread running. 
> The main thread eventually asks the server to stop(). But they seem to ignore 
> the request. I checked the code of TSimpleServer.java and I'm under the 
> impression that the innermost loop the server does not poll the variable 
> stopped_ or does it? Looking at 
> https://github.com/apache/thrift/blob/master/lib/java/src/org/apache/thrift/server/TSimpleServer.java
>  from line 76:
> {code}
>   while (true) {
> if (eventHandler_ != null) {
>   eventHandler_.processContext(connectionContext, inputTransport, 
> outputTransport);
> }
> if(!processor.process(inputProtocol, outputProtocol)) {
>   break;
> }
>   }
> {code}
> I found that this loop is only interrupted if the client disconnects. I tried 
> changing {{while(true)}} for {{while(!stopped_)}} but that did not help. I 
> guess that one of the methods in the loop must be blocking.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (THRIFT-4974) Add cross test for Python's Unix domain socket transport

[Duru Can Celasun (Jira)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-4974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duru Can Celasun resolved THRIFT-4974.
--
Fix Version/s: 0.14.0
   Resolution: Fixed

> Add cross test for Python's Unix domain socket transport
> 
>
> Key: THRIFT-4974
> URL: https://issues.apache.org/jira/browse/THRIFT-4974
> Project: Thrift
>  Issue Type: Test
>  Components: Test Suite
>Reporter: Kengo Seki
>Assignee: Kengo Seki
>Priority: Major
> Fix For: 0.14.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> The Python library supports Unix domain socket, but it doesn't seem to be 
> tested by the cross test.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (THRIFT-5003) Websocket Connection in Browsers with nodejs code

[Duru Can Celasun (Jira)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-5003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duru Can Celasun updated THRIFT-5003:
-
Affects Version/s: (was: 0.14.0)
   0.13.0

> Websocket Connection in Browsers with nodejs code
> -
>
> Key: THRIFT-5003
> URL: https://issues.apache.org/jira/browse/THRIFT-5003
> Project: Thrift
>  Issue Type: Improvement
>  Components: Node.js - Library, TypeScript - Library
>Affects Versions: 0.13.0
> Environment: Webpack 4.41.2
> Thrift 0.13.0
> NodeJS thrift lib required in browser env
>Reporter: Eugen Kandakov
>Assignee: Eugen Kandakov
>Priority: Major
>  Labels: Browser, JavaScript, WebSocket, webpack
> Fix For: 0.14.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> After some changes to the ws_connection.js file in the nodejs code, I could 
> create a version of the WSConnection, createWSConnection and createWSClient 
> which is able to run similar code of WebSocket connections in the browser and 
> NodeJS
> Solution is package, `{{isomorphic-ws` which provides the proper Websocket 
> libs depending on the env (browser or node)}}
>  
> Testable Repo with thrift branch from PR: 
> [https://github.com/alabama/thrift-testing]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (THRIFT-5034) Allow for Reverse Connection servers

[Duru Can Celasun (Jira)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-5034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duru Can Celasun updated THRIFT-5034:
-
Component/s: Python - Library

> Allow for Reverse Connection servers
> 
>
> Key: THRIFT-5034
> URL: https://issues.apache.org/jira/browse/THRIFT-5034
> Project: Thrift
>  Issue Type: Improvement
>  Components: Python - Library
>Reporter: Paulo Neves
>Priority: Major
>
> Hello,
> One of the reasons I migrated from gRPC to Thrift was because of the 
> fundamental distinction between RPC Client/Server and Transport 
> Client/Server. This has allowed me to create RPC processors that actually 
> connect to a server(broker), in a similar way to a reverse proxy. This is 
> immensely useful for restricted networks.
> As said, due to the elegant separation between processor and transport this 
> turned out to be trivial and I would like to share my implementation of such 
> a transport "decorator" so that we can have Client transports work in 
> Processor servers.
> I do not have tests yet, besides my own working private implementations but 
> will try soon to prepare such for at least the Socket examples.
> I also do not know very well how the naming should be so i just made it 
> TReverseTunnelServer.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Issue Comment Deleted] (THRIFT-5046) Custom tags remove db and json tags

[Duru Can Celasun (Jira)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-5046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duru Can Celasun updated THRIFT-5046:
-
Comment: was deleted

(was: Turns out this is not trivial to implement. The generator would have to 
understand and parse the Go struct tag syntax.)

> Custom tags remove db and json tags
> ---
>
> Key: THRIFT-5046
> URL: https://issues.apache.org/jira/browse/THRIFT-5046
> Project: Thrift
>  Issue Type: Improvement
>  Components: Go - Compiler
>Affects Versions: 0.13.0
>Reporter: Duru Can Celasun
>Assignee: Duru Can Celasun
>Priority: Minor
>
> Given the IDL:
> {code}
> struct Example {
>   1: bool withTag (go.tag = "foo:\"bar\"")
>   2: bool withoutTag
> }
> {code}
> The generated code looks like:
> {code}
> type Example struct {
>   WithTag bool `thrift:"withTag,1", foo:"bar"`
>   WithoutTag bool `thrift:"withoutTag,2" db:"withoutTag" json:"withoutTag"`
> }
> {code}
> The bug is on [this 
> line|https://github.com/apache/thrift/blob/6e023df1ded255dda00eb4c041c201e66c8d1fbc/compiler/cpp/src/thrift/generate/t_go_generator.cc#L1396]
>  of the Go generator where any custom tag overwrites the existing db and json 
> tags.
> Custom tags that aren't overrides should be appended instead of replacing the 
> whole thing.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Assigned] (THRIFT-5046) Custom tags remove db and json tags

[Duru Can Celasun (Jira)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-5046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duru Can Celasun reassigned THRIFT-5046:


Assignee: Duru Can Celasun

> Custom tags remove db and json tags
> ---
>
> Key: THRIFT-5046
> URL: https://issues.apache.org/jira/browse/THRIFT-5046
> Project: Thrift
>  Issue Type: Improvement
>  Components: Go - Compiler
>Affects Versions: 0.13.0
>Reporter: Duru Can Celasun
>Assignee: Duru Can Celasun
>Priority: Minor
>
> Given the IDL:
> {code}
> struct Example {
>   1: bool withTag (go.tag = "foo:\"bar\"")
>   2: bool withoutTag
> }
> {code}
> The generated code looks like:
> {code}
> type Example struct {
>   WithTag bool `thrift:"withTag,1", foo:"bar"`
>   WithoutTag bool `thrift:"withoutTag,2" db:"withoutTag" json:"withoutTag"`
> }
> {code}
> The bug is on [this 
> line|https://github.com/apache/thrift/blob/6e023df1ded255dda00eb4c041c201e66c8d1fbc/compiler/cpp/src/thrift/generate/t_go_generator.cc#L1396]
>  of the Go generator where any custom tag overwrites the existing db and json 
> tags.
> Custom tags that aren't overrides should be appended instead of replacing the 
> whole thing.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (THRIFT-4002) Thrift exceptions are not hashable in Python 3

[Duru Can Celasun (Jira)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-4002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duru Can Celasun resolved THRIFT-4002.
--
Fix Version/s: 0.14.0
   Resolution: Fixed

> Thrift exceptions are not hashable in Python 3
> --
>
> Key: THRIFT-4002
> URL: https://issues.apache.org/jira/browse/THRIFT-4002
> Project: Thrift
>  Issue Type: Bug
>  Components: Python - Compiler
>Reporter: Jelle Zijlstra
>Priority: Major
>  Labels: compiler, python
> Fix For: 0.14.0
>
> Attachments: thrift-hashable-exc.patch
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> The Thrift-to-Python compiler generates `__eq__` but not `__hash__` for 
> Thrift exception classes, which makes them not hashable in Python 3. Due to 
> http://bugs.python.org/issue28603, this can lead the Python standard library 
> to throw an error while printing tracebacks involving Thrift exceptions.
> The attached patch generates `__hash__` for Thrift exceptions. This can 
> technically be incorrect since Thrift exceptions are mutable (compare 
> https://issues.apache.org/jira/browse/THRIFT-162), but in practice it seems 
> unlikely that people would mutate exception instances other than directly 
> after creating them, and without this patch some Thrift exceptions cannot be 
> displayed by the standard library.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (THRIFT-5046) Custom tags remove db and json tags

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16994504#comment-16994504
 ] 

Duru Can Celasun commented on THRIFT-5046:
--

Turns out this is not trivial to implement. The generator would have to 
understand and parse the Go struct tag syntax.

> Custom tags remove db and json tags
> ---
>
> Key: THRIFT-5046
> URL: https://issues.apache.org/jira/browse/THRIFT-5046
> Project: Thrift
>  Issue Type: Improvement
>  Components: Go - Compiler
>Affects Versions: 0.13.0
>Reporter: Duru Can Celasun
>Priority: Minor
>
> Given the IDL:
> {code}
> struct Example {
>   1: bool withTag (go.tag = "foo:\"bar\"")
>   2: bool withoutTag
> }
> {code}
> The generated code looks like:
> {code}
> type Example struct {
>   WithTag bool `thrift:"withTag,1", foo:"bar"`
>   WithoutTag bool `thrift:"withoutTag,2" db:"withoutTag" json:"withoutTag"`
> }
> {code}
> The bug is on [this 
> line|https://github.com/apache/thrift/blob/6e023df1ded255dda00eb4c041c201e66c8d1fbc/compiler/cpp/src/thrift/generate/t_go_generator.cc#L1396]
>  of the Go generator where any custom tag overwrites the existing db and json 
> tags.
> Custom tags that aren't overrides should be appended instead of replacing the 
> whole thing.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Assigned] (THRIFT-5046) Custom tags remove db and json tags

[Duru Can Celasun (Jira)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-5046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duru Can Celasun reassigned THRIFT-5046:


Assignee: (was: Duru Can Celasun)

> Custom tags remove db and json tags
> ---
>
> Key: THRIFT-5046
> URL: https://issues.apache.org/jira/browse/THRIFT-5046
> Project: Thrift
>  Issue Type: Improvement
>  Components: Go - Compiler
>Affects Versions: 0.13.0
>Reporter: Duru Can Celasun
>Priority: Minor
>
> Given the IDL:
> {code}
> struct Example {
>   1: bool withTag (go.tag = "foo:\"bar\"")
>   2: bool withoutTag
> }
> {code}
> The generated code looks like:
> {code}
> type Example struct {
>   WithTag bool `thrift:"withTag,1", foo:"bar"`
>   WithoutTag bool `thrift:"withoutTag,2" db:"withoutTag" json:"withoutTag"`
> }
> {code}
> The bug is on [this 
> line|https://github.com/apache/thrift/blob/6e023df1ded255dda00eb4c041c201e66c8d1fbc/compiler/cpp/src/thrift/generate/t_go_generator.cc#L1396]
>  of the Go generator where any custom tag overwrites the existing db and json 
> tags.
> Custom tags that aren't overrides should be appended instead of replacing the 
> whole thing.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (THRIFT-5046) Custom tags remove db and json tags

[Duru Can Celasun (Jira)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-5046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duru Can Celasun updated THRIFT-5046:
-
Priority: Minor  (was: Major)

> Custom tags remove db and json tags
> ---
>
> Key: THRIFT-5046
> URL: https://issues.apache.org/jira/browse/THRIFT-5046
> Project: Thrift
>  Issue Type: Bug
>  Components: Go - Compiler
>Affects Versions: 0.13.0
>Reporter: Duru Can Celasun
>Assignee: Duru Can Celasun
>Priority: Minor
>
> Given the IDL:
> {code}
> struct Example {
>   1: bool withTag (go.tag = "foo:\"bar\"")
>   2: bool withoutTag
> }
> {code}
> The generated code looks like:
> {code}
> type Example struct {
>   WithTag bool `thrift:"withTag,1", foo:"bar"`
>   WithoutTag bool `thrift:"withoutTag,2" db:"withoutTag" json:"withoutTag"`
> }
> {code}
> The bug is on [this 
> line|https://github.com/apache/thrift/blob/6e023df1ded255dda00eb4c041c201e66c8d1fbc/compiler/cpp/src/thrift/generate/t_go_generator.cc#L1396]
>  of the Go generator where any custom tag overwrites the existing db and json 
> tags.
> Custom tags that aren't overrides should be appended instead of replacing the 
> whole thing.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (THRIFT-5046) Custom tags remove db and json tags

[Duru Can Celasun (Jira)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-5046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duru Can Celasun updated THRIFT-5046:
-
Issue Type: Improvement  (was: Bug)

> Custom tags remove db and json tags
> ---
>
> Key: THRIFT-5046
> URL: https://issues.apache.org/jira/browse/THRIFT-5046
> Project: Thrift
>  Issue Type: Improvement
>  Components: Go - Compiler
>Affects Versions: 0.13.0
>Reporter: Duru Can Celasun
>Assignee: Duru Can Celasun
>Priority: Minor
>
> Given the IDL:
> {code}
> struct Example {
>   1: bool withTag (go.tag = "foo:\"bar\"")
>   2: bool withoutTag
> }
> {code}
> The generated code looks like:
> {code}
> type Example struct {
>   WithTag bool `thrift:"withTag,1", foo:"bar"`
>   WithoutTag bool `thrift:"withoutTag,2" db:"withoutTag" json:"withoutTag"`
> }
> {code}
> The bug is on [this 
> line|https://github.com/apache/thrift/blob/6e023df1ded255dda00eb4c041c201e66c8d1fbc/compiler/cpp/src/thrift/generate/t_go_generator.cc#L1396]
>  of the Go generator where any custom tag overwrites the existing db and json 
> tags.
> Custom tags that aren't overrides should be appended instead of replacing the 
> whole thing.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (THRIFT-5046) Custom tags remove db and json tags

[Duru Can Celasun (Jira)]

Duru Can Celasun created THRIFT-5046:


 Summary: Custom tags remove db and json tags
 Key: THRIFT-5046
 URL: https://issues.apache.org/jira/browse/THRIFT-5046
 Project: Thrift
  Issue Type: Bug
  Components: Go - Compiler
Affects Versions: 0.13.0
Reporter: Duru Can Celasun
Assignee: Duru Can Celasun


Given the IDL:

{code}
struct Example {
  1: bool withTag (go.tag = "foo:\"bar\"")
  2: bool withoutTag
}
{code}

The generated code looks like:

{code}
type Example struct {
  WithTag bool `thrift:"withTag,1", foo:"bar"`
  WithoutTag bool `thrift:"withoutTag,2" db:"withoutTag" json:"withoutTag"`
}
{code}

The bug is on [this 
line|https://github.com/apache/thrift/blob/6e023df1ded255dda00eb4c041c201e66c8d1fbc/compiler/cpp/src/thrift/generate/t_go_generator.cc#L1396]
 of the Go generator where any custom tag overwrites the existing db and json 
tags.

Custom tags that aren't overrides should be appended instead of replacing the 
whole thing.




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (THRIFT-5045) Updating from 0.9.3 to 0.13.0 breaks

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16989210#comment-16989210
 ] 

Duru Can Celasun commented on THRIFT-5045:
--

0.9.3 is more than 4 years old, there has been many releases with breaking 
changes since then. You can see the changelog 
[here|https://github.com/apache/thrift/blob/master/CHANGES.md].

Keep in mind that all tagged releases in thrift are major releases (with the 
rare exception of backports, e.g 0.9.3.1) where breaking changes are allowed as 
long as they are justified and documented.

> Updating from 0.9.3 to 0.13.0 breaks
> 
>
> Key: THRIFT-5045
> URL: https://issues.apache.org/jira/browse/THRIFT-5045
> Project: Thrift
>  Issue Type: Bug
>Affects Versions: 0.10.0, 0.11.0, 0.12.0, 0.13.0
>Reporter: xia0c
>Priority: Major
>
> When I try to upgrade Thrift from 0.9.3 to the version after 0.10.0. The 
> upgrade breaks my existing code when I extend org.apache.thrift.async. e.g.
> {code:java}
> public class Testlibthrift extends org.apache.thrift.async.TAsyncMethodCall{
>   
> protected Testlibthrift(TAsyncClient client, TProtocolFactory 
> protocolFactory, TNonblockingTransport transport,
>   AsyncMethodCallback callback, boolean isOneway) {
>   super(client, protocolFactory, transport, callback, isOneway);
>   // TODO Auto-generated constructor stub
>   }
>   public void write_args(org.apache.thrift.protocol.TProtocol prot) 
> throws org.apache.thrift.TException {
> prot.writeMessageBegin(new 
> org.apache.thrift.protocol.TMessage("ping", 
> org.apache.thrift.protocol.TMessageType.CALL, 0));
>   }
>   public void getResult() throws org.apache.thrift.TException {
> if (getState() != 
> org.apache.thrift.async.TAsyncMethodCall.State.RESPONSE_READ) {
>   throw new IllegalStateException("Method call not finished!");
> }
> org.apache.thrift.transport.TMemoryInputTransport memoryTransport = 
> new 
> org.apache.thrift.transport.TMemoryInputTransport(getFrameBuffer().array());
> org.apache.thrift.protocol.TProtocol prot = 
> client.getProtocolFactory().getProtocol(memoryTransport);
>   }
> }
> {code}
> The code should pass. However, it throws an error:
> {code:java}
> Testlibthrift is not abstract and does not override abstract method 
> getResult() in org.apache.thrift.async.TAsyncMethodCall
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (THRIFT-4124) Connection to non-thrift server crashes android app

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16983999#comment-16983999
 ] 

Duru Can Celasun commented on THRIFT-4124:
--

I'm working on a Go version of THRIFT-5021 in 
[THRIFT-5035|https://issues.apache.org/jira/browse/THRIFT-5035]. If you'd like 
to work on the Java version, we could review each other's patches.

For the docs, I'm working on a vastly improved version of the website in 
[THRIFT-4710|https://issues.apache.org/jira/browse/THRIFT-4710]. It'd be easier 
if you could send that PR against [my 
branch|https://github.com/dcelasun/thrift/tree/docs].





> Connection to non-thrift server crashes android app
> ---
>
> Key: THRIFT-4124
> URL: https://issues.apache.org/jira/browse/THRIFT-4124
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Library
>Affects Versions: 0.10.0
> Environment: Android Studio
>Reporter: Alexey Andronov
>Assignee: Qinghui Xu
>Priority: Major
>  Labels: async
>
> I connect to server like this:
> {code}m_client = new DispatchBackend.AsyncClient(
> new TBinaryProtocol.Factory(),
> new TAsyncClientManager(),
> new TNonblockingSocket("google.com", 80)
> );{code}
> Then I execute request:
> {code}
> try {
> m_client.request();
> } catch (TException e) {
> // never reaches here
> }{code}
> And my app crashes with OOM error.
> The problem is that I can't catch exception from thrift library inside my 
> application i.e.
> inner library exception always crashes my app which is very sad.
> P.S. I tried to catch Throwable instead of TException and it didn't help
> Stacktrace:
> {code}E/art: Throwing OutOfMemoryError "Failed to allocate a 1213486172 byte 
> allocation with 3514240 free bytes and 122MB until OOM"
> E/AndroidRuntime: FATAL EXCEPTION: TAsyncClientManager#SelectorThread 9112
>Process: com.myapp, PID: 20608
>java.lang.OutOfMemoryError: Failed to allocate a 1213486172 byte 
> allocation with 3514240 free bytes and 122MB until OOM
>  at java.nio.ByteBuffer.allocate(ByteBuffer.java:56)
>  at 
> org.apache.thrift.async.TAsyncMethodCall.doReadingResponseSize(TAsyncMethodCall.java:250)
>  at 
> org.apache.thrift.async.TAsyncMethodCall.transition(TAsyncMethodCall.java:198)
>  at 
> org.apache.thrift.async.TAsyncClientManager$SelectThread.transitionMethods(TAsyncClientManager.java:143)
>  at 
> org.apache.thrift.async.TAsyncClientManager$SelectThread.run(TAsyncClientManager.java:113){code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (THRIFT-5035) MAX_MESSAGE_SIZE support for Go

[Duru Can Celasun (Jira)]

Duru Can Celasun created THRIFT-5035:


 Summary: MAX_MESSAGE_SIZE support for Go
 Key: THRIFT-5035
 URL: https://issues.apache.org/jira/browse/THRIFT-5035
 Project: Thrift
  Issue Type: Improvement
  Components: Go - Library
Reporter: Duru Can Celasun
Assignee: Duru Can Celasun


This is [THRIFT-5021|https://issues.apache.org/jira/browse/THRIFT-5021], but 
for Go.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (THRIFT-5031) Fix javadoc of TIOStreamTransport

[Duru Can Celasun (Jira)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-5031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duru Can Celasun resolved THRIFT-5031.
--
Fix Version/s: 0.14.0
   Resolution: Fixed

> Fix javadoc of TIOStreamTransport
> -
>
> Key: THRIFT-5031
> URL: https://issues.apache.org/jira/browse/THRIFT-5031
> Project: Thrift
>  Issue Type: Improvement
>Reporter: Qinghui Xu
>Assignee: Qinghui Xu
>Priority: Minor
> Fix For: 0.14.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> The current javadoc is unclear about the support for oneway (input or output 
> only) io.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (THRIFT-5022) TIOStreamTransport.isOpen is false for InputStream or Outpstream only use.

[Duru Can Celasun (Jira)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-5022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duru Can Celasun resolved THRIFT-5022.
--
Fix Version/s: 0.14.0
   Resolution: Fixed

> TIOStreamTransport.isOpen is false for InputStream or Outpstream only use.
> --
>
> Key: THRIFT-5022
> URL: https://issues.apache.org/jira/browse/THRIFT-5022
> Project: Thrift
>  Issue Type: Task
>  Components: Java - Library
>Affects Versions: 0.13.0
>Reporter: Andy Seaborne
>Priority: Major
> Fix For: 0.14.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> This follows from THRIFT-2530.
> {{TIOStreamTransaport.isOpen}} changed to be
>  
> {noformat}
>   public boolean isOpen() {
> return inputStream_ != null && outputStream_ != null;
>   }
> {noformat}
> but constructors {{TIOStreamTransaport(InputStream)}} and 
> {{TIOStreamTransaport(OutputStream)}} leave one of {{inputStream_}} or 
> {{outputStream_}} null.
> This makes isOpen false immediately, no close() called. open() does not 
> change the state of object.
>  Example:
> {noformat}
> TIOStreamTransport x1 = new TIOStreamTransport(new ByteArrayInputStream(new 
> byte[1]));
>  System.out.println(x1.isOpen());
>  TIOStreamTransport x2 = new TIOStreamTransport(new ByteArrayOutputStream());
>  System.out.println(x2.isOpen());
> {noformat}
> is prints false both times.
>  
> It should be:
> {noformat}
>   public boolean isOpen() {
> return inputStream_ != null || outputStream_ != null;
>   }
> {noformat}
> or an explicit flag for the open/close state but {{inputStream_ != null || 
> outputStream_ != null;}} is enough given the current close implementation.
>  
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (THRIFT-5019) Multiple import same namespace for go included files

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16979643#comment-16979643
 ] 

Duru Can Celasun commented on THRIFT-5019:
--

I think it's too late for that, it'd break a lot of code out there. I've 
personally used multiple files with the same namespace with go, netstd and 
[thrifty|https://github.com/microsoft/thrifty] :)

> Multiple import same namespace for go included files
> 
>
> Key: THRIFT-5019
> URL: https://issues.apache.org/jira/browse/THRIFT-5019
> Project: Thrift
>  Issue Type: Bug
>  Components: Go - Compiler
>Affects Versions: 0.12.0, 0.13.0
>Reporter: Andrey Petko
>Assignee: Duru Can Celasun
>Priority: Major
> Fix For: 0.14.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> When I include two files with same namespace for go language:
> {code:java}
> include "common/Exceptions.thrift"
> include "common/Typedefs.thrift"{code}
> And generate it for golang in result in import I have import of this 
> namespace twice:
> {code:java}
> import(
>"bytes"
>"context"
>"reflect"
>"fmt"
>"github.com/apache/thrift/lib/go/thrift"
>"my_namespace"
>"my_namespace"
> )
> {code}
> And when I try to use I have an error because of this:
> "'my_namespace' redeclared as imported package name"



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (THRIFT-5019) Multiple import same namespace for go included files

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16979637#comment-16979637
 ] 

Duru Can Celasun commented on THRIFT-5019:
--

Not sure about other languages but for Go specifically, having multiple IDL 
files within the same namespace always worked fine as long as those files were 
not included into another namespace.

More generally, since [the spec doesn't mention such 
limitations|https://github.com/apache/thrift/blob/master/doc/specs/idl.md#thrift-include],
 it's worth fixing this in other generators as well.

> Multiple import same namespace for go included files
> 
>
> Key: THRIFT-5019
> URL: https://issues.apache.org/jira/browse/THRIFT-5019
> Project: Thrift
>  Issue Type: Bug
>  Components: Go - Compiler
>Affects Versions: 0.12.0, 0.13.0
>Reporter: Andrey Petko
>Assignee: Duru Can Celasun
>Priority: Major
> Fix For: 0.14.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> When I include two files with same namespace for go language:
> {code:java}
> include "common/Exceptions.thrift"
> include "common/Typedefs.thrift"{code}
> And generate it for golang in result in import I have import of this 
> namespace twice:
> {code:java}
> import(
>"bytes"
>"context"
>"reflect"
>"fmt"
>"github.com/apache/thrift/lib/go/thrift"
>"my_namespace"
>"my_namespace"
> )
> {code}
> And when I try to use I have an error because of this:
> "'my_namespace' redeclared as imported package name"



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (THRIFT-5019) Multiple import same namespace for go included files

[Duru Can Celasun (Jira)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-5019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duru Can Celasun resolved THRIFT-5019.
--
Resolution: Fixed

> Multiple import same namespace for go included files
> 
>
> Key: THRIFT-5019
> URL: https://issues.apache.org/jira/browse/THRIFT-5019
> Project: Thrift
>  Issue Type: Bug
>  Components: Go - Compiler
>Affects Versions: 0.12.0, 0.13.0
>Reporter: Andrey Petko
>Assignee: Duru Can Celasun
>Priority: Major
> Fix For: 0.14.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> When I include two files with same namespace for go language:
> {code:java}
> include "common/Exceptions.thrift"
> include "common/Typedefs.thrift"{code}
> And generate it for golang in result in import I have import of this 
> namespace twice:
> {code:java}
> import(
>"bytes"
>"context"
>"reflect"
>"fmt"
>"github.com/apache/thrift/lib/go/thrift"
>"my_namespace"
>"my_namespace"
> )
> {code}
> And when I try to use I have an error because of this:
> "'my_namespace' redeclared as imported package name"



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (THRIFT-5019) Multiple import same namespace for go included files

[Duru Can Celasun (Jira)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-5019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duru Can Celasun updated THRIFT-5019:
-
Fix Version/s: 0.14.0

> Multiple import same namespace for go included files
> 
>
> Key: THRIFT-5019
> URL: https://issues.apache.org/jira/browse/THRIFT-5019
> Project: Thrift
>  Issue Type: Bug
>  Components: Go - Compiler
>Affects Versions: 0.12.0, 0.13.0
>Reporter: Andrey Petko
>Assignee: Duru Can Celasun
>Priority: Major
> Fix For: 0.14.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> When I include two files with same namespace for go language:
> {code:java}
> include "common/Exceptions.thrift"
> include "common/Typedefs.thrift"{code}
> And generate it for golang in result in import I have import of this 
> namespace twice:
> {code:java}
> import(
>"bytes"
>"context"
>"reflect"
>"fmt"
>"github.com/apache/thrift/lib/go/thrift"
>"my_namespace"
>"my_namespace"
> )
> {code}
> And when I try to use I have an error because of this:
> "'my_namespace' redeclared as imported package name"



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (THRIFT-5019) Multiple import same namespace for go included files

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16978526#comment-16978526
 ] 

Duru Can Celasun commented on THRIFT-5019:
--

Fixed by 
https://github.com/apache/thrift/commit/f4475ff76fe3dcc1b3774d52bf28b333ab9acd01

> Multiple import same namespace for go included files
> 
>
> Key: THRIFT-5019
> URL: https://issues.apache.org/jira/browse/THRIFT-5019
> Project: Thrift
>  Issue Type: Bug
>  Components: Go - Compiler
>Affects Versions: 0.12.0, 0.13.0
>Reporter: Andrey Petko
>Assignee: Duru Can Celasun
>Priority: Major
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> When I include two files with same namespace for go language:
> {code:java}
> include "common/Exceptions.thrift"
> include "common/Typedefs.thrift"{code}
> And generate it for golang in result in import I have import of this 
> namespace twice:
> {code:java}
> import(
>"bytes"
>"context"
>"reflect"
>"fmt"
>"github.com/apache/thrift/lib/go/thrift"
>"my_namespace"
>"my_namespace"
> )
> {code}
> And when I try to use I have an error because of this:
> "'my_namespace' redeclared as imported package name"



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (THRIFT-5019) Multiple import same namespace for go included files

[Duru Can Celasun (Jira)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-5019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duru Can Celasun updated THRIFT-5019:
-
Component/s: Go - Compiler

> Multiple import same namespace for go included files
> 
>
> Key: THRIFT-5019
> URL: https://issues.apache.org/jira/browse/THRIFT-5019
> Project: Thrift
>  Issue Type: Bug
>  Components: Go - Compiler
>Affects Versions: 0.12.0, 0.13.0
>Reporter: Andrey Petko
>Assignee: Duru Can Celasun
>Priority: Major
>
> When I include two files with same namespace for go language:
> {code:java}
> include "common/Exceptions.thrift"
> include "common/Typedefs.thrift"{code}
> And generate it for golang in result in import I have import of this 
> namespace twice:
> {code:java}
> import(
>"bytes"
>"context"
>"reflect"
>"fmt"
>"github.com/apache/thrift/lib/go/thrift"
>"my_namespace"
>"my_namespace"
> )
> {code}
> And when I try to use I have an error because of this:
> "'my_namespace' redeclared as imported package name"



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (THRIFT-5019) Multiple import same namespace for go included files

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16978313#comment-16978313
 ] 

Duru Can Celasun commented on THRIFT-5019:
--

Confirmed, can reproduce.

> Multiple import same namespace for go included files
> 
>
> Key: THRIFT-5019
> URL: https://issues.apache.org/jira/browse/THRIFT-5019
> Project: Thrift
>  Issue Type: Bug
>Affects Versions: 0.12.0, 0.13.0
>Reporter: Andrey Petko
>Assignee: Duru Can Celasun
>Priority: Major
>
> When I include two files with same namespace for go language:
> {code:java}
> include "common/Exceptions.thrift"
> include "common/Typedefs.thrift"{code}
> And generate it for golang in result in import I have import of this 
> namespace twice:
> {code:java}
> import(
>"bytes"
>"context"
>"reflect"
>"fmt"
>"github.com/apache/thrift/lib/go/thrift"
>"my_namespace"
>"my_namespace"
> )
> {code}
> And when I try to use I have an error because of this:
> "'my_namespace' redeclared as imported package name"



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Assigned] (THRIFT-5019) Multiple import same namespace for go included files

[Duru Can Celasun (Jira)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-5019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duru Can Celasun reassigned THRIFT-5019:


Assignee: Duru Can Celasun

> Multiple import same namespace for go included files
> 
>
> Key: THRIFT-5019
> URL: https://issues.apache.org/jira/browse/THRIFT-5019
> Project: Thrift
>  Issue Type: Bug
>Affects Versions: 0.12.0, 0.13.0
>Reporter: Andrey Petko
>Assignee: Duru Can Celasun
>Priority: Major
>
> When I include two files with same namespace for go language:
> {code:java}
> include "common/Exceptions.thrift"
> include "common/Typedefs.thrift"{code}
> And generate it for golang in result in import I have import of this 
> namespace twice:
> {code:java}
> import(
>"bytes"
>"context"
>"reflect"
>"fmt"
>"github.com/apache/thrift/lib/go/thrift"
>"my_namespace"
>"my_namespace"
> )
> {code}
> And when I try to use I have an error because of this:
> "'my_namespace' redeclared as imported package name"



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (THRIFT-5019) Multiple import same namespace for go included files

[Duru Can Celasun (Jira)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-5019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duru Can Celasun updated THRIFT-5019:
-
Fix Version/s: (was: 0.13.0)
   (was: 0.12.0)

> Multiple import same namespace for go included files
> 
>
> Key: THRIFT-5019
> URL: https://issues.apache.org/jira/browse/THRIFT-5019
> Project: Thrift
>  Issue Type: Bug
>Affects Versions: 0.12.0, 0.13.0
>Reporter: Andrey Petko
>Priority: Major
>
> When I include two files with same namespace for go language:
> {code:java}
> include "common/Exceptions.thrift"
> include "common/Typedefs.thrift"{code}
> And generate it for golang in result in import I have import of this 
> namespace twice:
> {code:java}
> import(
>"bytes"
>"context"
>"reflect"
>"fmt"
>"github.com/apache/thrift/lib/go/thrift"
>"my_namespace"
>"my_namespace"
> )
> {code}
> And when I try to use I have an error because of this:
> "'my_namespace' redeclared as imported package name"



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (THRIFT-4710) Move all ASF CMS website content to GitHub

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16978247#comment-16978247
 ] 

Duru Can Celasun commented on THRIFT-4710:
--

I've reached out to the author of Thrift: The Missing Guide and he has once 
again said he'd be happy to contribute the guide to thrift, so I'll be moving 
ahead with integrating it into the draft website.

> Move all ASF CMS website content to GitHub
> --
>
> Key: THRIFT-4710
> URL: https://issues.apache.org/jira/browse/THRIFT-4710
> Project: Thrift
>  Issue Type: Documentation
>  Components: Documentation, Website
>Affects Versions: 0.13.0
>Reporter: James E. King III
>Assignee: Duru Can Celasun
>Priority: Major
>
> Recent changes in Apache infrastructure has made it impossible to use the 
> existing ASF CMS system to manage the Apache Thrift web site.  We need to 
> extract and move the content somewhere else.  For reference, see:
> https://issues.apache.org/jira/browse/INFRA-17519
> This is a bunch of work nobody was expecting to have to do.
> My recommendation is to put the documentation into the "docs/" (or leave it 
> in "doc/", perhaps, it if works) and use https://readthedocs.org/ to create 
> the documentation web site.  Documentation updates can be pushed into the 
> repository with {{`[ci skip]`}} or maybe we teach GitHub and/or our Appveyor 
> and Travis to do nothing on pull requests that only contain updates to 
> markdown and/or rst files.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (THRIFT-4710) Move all ASF CMS website content to GitHub

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16972218#comment-16972218
 ] 

Duru Can Celasun commented on THRIFT-4710:
--

I have finished an initial port of the existing website to Read The Docs using 
Sphinx. You can see it here: 
https://thrift-fork.readthedocs.io/en/docs/index.html

Source code: https://github.com/apache/thrift/compare/master...dcelasun:docs

Build instructions:

- Python 3.7 and virtualenv required
- cd /docs && virtualenv venv && source venv/bin/activate && make clean html && 
deactivate

This will generate the HTML version. The website has a PDF version as well.

Changelog & notes:

- Simplified tutorial, removed copy/pasted language specific code, linked to 
Github instead.
- Moved the old package managers table into the download page.
- "How To Contribute" now includes everything from bug reports, PRs and adding 
new languages.
- "Coding Standards" has been simplified greatly.
- Merged several pages, particularly around contributing to make them flow 
better.
- Fix lots of grammar / spelling errors.
- Removed various outdated bits, particularly around old build errors.

Next steps:

- I will start integrating Thrift: The Missing Guide and will reach out to the 
author. He has already given us permission, but that was 7 years ago so there 
is no harm in checking with him again.
- Similarly I'll contact the RPC specification's author and seek his permission.

Any feedback & thoughts are welcome.

> Move all ASF CMS website content to GitHub
> --
>
> Key: THRIFT-4710
> URL: https://issues.apache.org/jira/browse/THRIFT-4710
> Project: Thrift
>  Issue Type: Documentation
>  Components: Documentation, Website
>Affects Versions: 0.13.0
>Reporter: James E. King III
>Assignee: Duru Can Celasun
>Priority: Major
>
> Recent changes in Apache infrastructure has made it impossible to use the 
> existing ASF CMS system to manage the Apache Thrift web site.  We need to 
> extract and move the content somewhere else.  For reference, see:
> https://issues.apache.org/jira/browse/INFRA-17519
> This is a bunch of work nobody was expecting to have to do.
> My recommendation is to put the documentation into the "docs/" (or leave it 
> in "doc/", perhaps, it if works) and use https://readthedocs.org/ to create 
> the documentation web site.  Documentation updates can be pushed into the 
> repository with {{`[ci skip]`}} or maybe we teach GitHub and/or our Appveyor 
> and Travis to do nothing on pull requests that only contain updates to 
> markdown and/or rst files.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Assigned] (THRIFT-4710) Move all ASF CMS website content to GitHub

[Duru Can Celasun (Jira)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-4710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duru Can Celasun reassigned THRIFT-4710:


Assignee: Duru Can Celasun

> Move all ASF CMS website content to GitHub
> --
>
> Key: THRIFT-4710
> URL: https://issues.apache.org/jira/browse/THRIFT-4710
> Project: Thrift
>  Issue Type: Documentation
>  Components: Documentation, Website
>Affects Versions: 0.13.0
>Reporter: James E. King III
>Assignee: Duru Can Celasun
>Priority: Major
>
> Recent changes in Apache infrastructure has made it impossible to use the 
> existing ASF CMS system to manage the Apache Thrift web site.  We need to 
> extract and move the content somewhere else.  For reference, see:
> https://issues.apache.org/jira/browse/INFRA-17519
> This is a bunch of work nobody was expecting to have to do.
> My recommendation is to put the documentation into the "docs/" (or leave it 
> in "doc/", perhaps, it if works) and use https://readthedocs.org/ to create 
> the documentation web site.  Documentation updates can be pushed into the 
> repository with {{`[ci skip]`}} or maybe we teach GitHub and/or our Appveyor 
> and Travis to do nothing on pull requests that only contain updates to 
> markdown and/or rst files.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (THRIFT-4710) Move all ASF CMS website content to GitHub

[Duru Can Celasun (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16971427#comment-16971427
 ] 

Duru Can Celasun commented on THRIFT-4710:
--

Since there hasn't been any objections, I'll start working on this as outlined 
above.

> Move all ASF CMS website content to GitHub
> --
>
> Key: THRIFT-4710
> URL: https://issues.apache.org/jira/browse/THRIFT-4710
> Project: Thrift
>  Issue Type: Documentation
>  Components: Documentation, Website
>Affects Versions: 0.13.0
>Reporter: James E. King III
>Priority: Major
>
> Recent changes in Apache infrastructure has made it impossible to use the 
> existing ASF CMS system to manage the Apache Thrift web site.  We need to 
> extract and move the content somewhere else.  For reference, see:
> https://issues.apache.org/jira/browse/INFRA-17519
> This is a bunch of work nobody was expecting to have to do.
> My recommendation is to put the documentation into the "docs/" (or leave it 
> in "doc/", perhaps, it if works) and use https://readthedocs.org/ to create 
> the documentation web site.  Documentation updates can be pushed into the 
> repository with {{`[ci skip]`}} or maybe we teach GitHub and/or our Appveyor 
> and Travis to do nothing on pull requests that only contain updates to 
> markdown and/or rst files.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)